I run some FMP databases locally on my mac, and for years have relied on my hourly TimeMachine backups to save me in cases where I made a big mistake (accidentally deleted data, a script, layout, etc.)
This has always worked fine.
Today, I tried the same thing, and ran into big problems:
my hourly time machine backups were there, but the FileMaker database (which I had been using basically all day) was not showing up with hourly backups
I did have a backup from the prior evening, but when I copied that out from the Time Machine drive there were two issues:
the timestamp on the .fmp12 file was over 24 hours before the Time Machine backup timestamp
the file was corrupt when I restored from the Time Machine drive
Ugh!
The last time I did a restore from time machine like this, I was using FMP19 and macOS 14 (and it worked normally)
Now I'm using FMP 21.1.41 and macOS 15.4.
This behavior reminds me a bit of the complaints people are having with version 21 of FileMaker Server : cached data is not written to disk properly.
I wonder if there's a similar issue with FMP ?
I suppose it's entirely possible this is a macOS/Time Machine bug - quality of macOS has not been great lately.
In any case... If you have local FMP files, and run Time Machine backups, can you check to see if (A) the backups seem to have the expected modification date, and (B) if the backups are corrupt?
I'm curious if this is just a "me" bug or is affecting others...
Edit to add: my FMP Cache settings were as follows:
Don't get me wrong: Time Machine is not a magic backup system. Clearly, if data is still in memory and hasn't been saved to disk, TM can't back it up.
But if the file has been saved to disk, simply having it open in an editor is generally not enough to cause TM backup failures.
Also, if FMP were saving the cache to disk "during idle time" then the file modification date should be fresh, matching the backup timestamp (give or take), and should not be 24+ hours stale.
The coincidence that other folks are having similar issues with FMS21 makes me suspicious that the bug is in fact in FM.
there is no promise that the “real” copy is the disk copy or the cache until the file is closed. At that point the disk copy is accurate.
I have had issues with timeMachine backups of FileMaker databases. I attach a simple backup script to run on last window close when files are run locally. I trust Time Machine to back them up safely because they are not open.
I just did three tests, in which I copy a file from my time machine backup drive to the desktop and open it in FMP 21.1.41.
Test 1: backup from 7am when I woke my computer. The FMP file is timestamped 3pm yesterday. I believe the FMP file was not open at 3pm (but I'm not sure). Result: Damaged.
Test 2 : force a backup right now. The original file is open in FMP (but hasn't been edited since yesterday). The backup FMP file has the same 3pm timestamp (so it's probably just a hard-link to the prior file). Result: Damaged
Test 3: Quit FileMaker Force a backup at 8am. The original and backup files both have a matching timestamp of 758am. Copy the backup file to the desktop. Open it. Damaged
Test 3 is the smoking gun: A time machine backup of a known good FMP12 file, with the backup taken with FMP not running, and the modification timestamp of the file confirmed to match, is Damaged.
Can anyone out there repeat this test on their system?
I did new tests in which I opened the original file, made an edit change, closed and quit FMP, and then used the original or made a copy of the file in one of 4 ways:
the Original file
Copy the file in the Finder (Edit/Copy, Edit/Paste)
Compress the file in the Finder to a Zip file
Use the FMP12 Recover command (using all defaults)
Open the file, FileMaker / File / Save A Copy As...
I then forced a Time Machine backup, then copied the files from the backup drive back to the Desktop (for the .zip file, unzipping it by double-clicking) and tried to open each one in FMP 21.
Results:
Damaged
Damaged
OK
OK
OK
This is now feeling like it may be some sort of insane APFS/Time Machine/Spotlight bug, e.g...
The Finder (and TimeMachine and Spotlight) have lost track of the actual bytes in the file, so that doing a Finder Copy (which under APFS doesn't actually copy the file) or Time Machine backup (ditto) is giving corrupt data.
The actual bytes on disk are actually OK (so that FileMaker has no trouble reading them).
Attempting to backup ANY live database - FM, Oracle, DB2, MySQL, etc. - will almost always result in database corruption. That is because any open database has activity going on between memory and disk.
Using Time Machine is possible (see attached article), but in general, you've been lucky that your TM backups are probably off hours and little to no current activity is going on. There are also things that may be executing that have nothing to do with user interaction - YMMV
Agree, but I'm seeing corruption with backing up a cold, dead database file. The file is not live, it's not open, it's not in use.
I can confirm that the bytes stored in the Time Machine backup do not match the byes in the original file, so I'm now leaning toward this being a macOS bug.
I will try some further debug steps (rebooting, rebuilding spotlight, disk first aid, etc.) and see if I can clear it up...
Are the byte comparison on the same physical and logical disk partition? disk sector and block sizes can cause wide disparity in storage used calculations.
More info: I have 2 Time Machine drives, one of which lives in a fire safe and only comes out every few weeks. I found a point at which both drives have a backup of the same file with identical timestamp. Copied these to the desktop:
they have identical lengths:
-rw-r--r--@ 1 staff 19165184 Mar 26 15:15 File-From-Drive1.fmp12
-rw-r--r--@ 1 staff 19165184 Mar 26 15:15 File-From-Drive2.fmp12
Given that the "identical" file on two different time machine drives are not identical, this is strong evidence to me that this is more likely some sort of macOS / Time Machine / APFS bug.
I think the ultimate problem is that my Time Machine backup of this one file became corrupted somehow, and that once this happens, further backups were also corrupted.
My theory is that this happens because APFS and Time Machine use an aggressive "diff" algorithm which saves space by saving new files as a "diff" referencing the older file. But something went wrong.
Once in this state, you have to do something which convinces macOS that you have created a new file from scratch, so it will start backing up the entire file.
Duplicating the file in the Finder does not work (because again, APFS stores this duplicate as a diff from the prior file). Several other approaches do work, including:
zipping the file, then unzipping it to a new name
Save As a Copy... from within FileMaker
running FileMaker Recover on the file
etc...
Once I did that, and started using the new copy of the file, everything is back to normal:
I can have the file open in FMP, and make an edit change and commit the record
force a Time Machine backup (with the FMP file still open)
restore a copy of the backup
When opening the backup file, FileMaker does a mini recovery operation since the file was open when it was backed up:
|Timestamp|Filename|Error|Message|
|2025-04-15 14:04:36.947 -0700|file1.fmp12|0|*** Started consistency check of improperly closed file, total of 6206 block(s) to check|
|2025-04-15 14:04:36.978 -0700|file1.fmp12|0|Reset maximum block sequence number to 42072381|
|2025-04-15 14:04:36.979 -0700|file1.fmp12|0|*** Completed consistency check, checked 6206 block(s)|
But FMP does this transparently, opens the file, and the edits I had just made are there.
I'm not recommending you rely on backups of open FMP12 files as a routine basis, but my experience is now back to what I'm used to over the years: in an emergency, it almost always works perfectly.
Time Machine makes a snapshot of the blocks on disk at a time.
FileMaker has usually the lastest changes in RAM and synchronizes periodically with the disk every few seconds.
The snapshot from Time Machine usually gets your database in the open state. The latest changes may be missing in the database file. So when you restore FileMaker will notice and run recovery. If you like to avoid this, you would need to use terminal to close databases, do Time Machine now and then open databases.
Usually we have FileMaker Server make backups into a separate folder and then have that folder be included in backups. Some clients upload their backup automatically in the cloud (e.g. copy to dropbox).
Snapshots and hard links are the “culprits” in this case, as Christian and other people here stated, for Time Machine to work “properly” the files must be closed, the under the hood details are so technical that makes no sense to go deeper here, for future events a) Install Filemaker server(fms) on an spare macmini. b) if not practical, install fms in the local machine, let fms to handle the backups and do time machine to the backups folder, remember to exclude de databases from timemachine
I also had to learn the hard way years ago that open FMP databases are not backed up by Time Machine. Since then I have been using a script that saves a copy of the open file once every hour.
In some FM lecture I learned that the script command “Save Copy” does exactly the same as the automatic backups of FileMaker Server. I can't remember which one though. That was a few years ago.
In the meantime, I have expanded my backup system and built my own Time Machine script using the MBS plugin. Once an hour, the open file is backed up with a time stamp. Files from the previous day are deleted down to the last saved copy. The same applies to files from the last week and the last month. In this way, the number of copies is reduced over time, just like Time Machine does. That means I keep a maximum of 24 copies from today (more likely 8, depending on working hours), 6 from last week, and 11 from last year.
