The Fine Art of FileMaker Recovery

The Japanese art of Kintsugi, the graceful repair of broken bowls with gold . . .

This is part four in this series - if you need these steps now - please repair your files - then return and review the first parts of this series - FileMaker Prevention Maintenance.

Recovery Options.

With the right steps in the right order, we can remove, or at least minimise, the damage within the files when Prevention and/or Maintenance is not enough.

Claris FileMaker and FileMaker Server have tools and functions to verify and check the integrity of Database Files. FileMaker Server has the option to verify backups as part of the Backup schedule.

The first signs you have damaged file(s) may failure to pass the Consistency Check as part of the FileMaker Server Backup.

Another early sign of damaged file(s) may just be that it closes, rather than opening, while attempting to publish via FileMaker Server.

Attempting to open a FileMaker file locally - or via FileMaker Server - will perform a Consistency Check on files not closed 'correctly' and may show damage:

Here are the FileMaker Pro 'built-in' Advanced Recovery Options - we could publish an entire blog post on these options, and the times each option has worked, and more importantly, not worked.

Note: Be warned that the FileMaker Recovery process can result in a file that Claris recommends the resulting file 'not' be used in a Production environment.

And further on this warning, the Recovery process can pass the Consistency test - with the file ending up being un-useable and hangs on layouts and scripts on open.

The following steps were required to create a new Database file that opens and verifies, as it did before this most 'recent' damage.

Key to these steps is to start with a good know Clone Back up of your Database.

Recovery Steps.

Set up the Clone File.

1. Ensure you have a clean 'know good' verified backup, this will be your Clone file.

2. Run Consistency over this Clone file to ensure good structure.

Setting up Data File.

1. Take the LIVE file offline, copy to drive where performing the recovery.

2. Open file without on open scripts, via the script debugger.

3. Remove all but one blank layout, remove all scripts.

4. Option to Truncate any tables with possible data damage.

Run the Recovery.

1. Recover the Data file, include the option to rebuild the indexes.

2. Open the recovered file after recovery.

Perform DMT.

1. Configure and perform the DMT to copy in the data into the clone.

2. Run Consistency over this destination file.

3. Upload file back to the LIVE Server.

4. Run full backup with consistency check.

Post Recovery Gotchas and Exceptions to the Rules.

The above steps are due to situations that may or may not be present in your Recovery.

The DMT failed with an early error that flashed up within the Terminal Window:

Couldn't open the source file because"(804): File cannot be opened as read only in its current state."

This was due to the Recovery process did not display the final report, and FileMaker actually crashed out, before completed the Recovery.

This is even though the Recovery.log reported it completed on line 27,535:

0	*** Completed recovery to 'file_recovered.fmp12'

It's also worth noting that when all the layouts, scripts and suspect table records were still part of the data file - the Recovery process stalled around the 50% mark.

Recovery Take Away.

This is just one example - your milage may vary - and the steps your recovery requires may differ due to the cause and outcome of the damage in your file.