FileMaker Disaster Recovery (DR)
- Darrin Southern
- Nov 25, 2025
- 3 min read
Updated: Dec 3, 2025
This blog post started out with two basic sections - then three, now four sections - so I decided to split this Content . . .
Blog Post Titles.
FileMaker Disaster Recovery (DR)
The first blog outlines a number of options to prevent Disaster Recovery (DR) via Prevention & Maintenance, which in this context, I've defined as two separate concerns.
The second blog is a small window to the future features promised by Claris in updates coming in the next week and next month. This section will be updated on feature release.
The third blog is a set of steps and sample code for two methods of soft closing your FileMaker Server published Databases.
The fourth blog provides a sample set of steps to follow when there is systematic damage to your file's schema, the data, or even both.
'Back up as much as you are willing to loose.' ~ my good-self to every client, every time.
Let that sink in. At any time, at any moment, your LIVE Server can fall over, files and your files are damaged or gone - that's just a reality of computing, even in this modern age.
General.
The overall concept of Disaster Recovery (DR) is universal across most Server Platforms. Disaster doesn't discriminate between On-premise and Cloud Servers.
Situations can differ; here are a few examples to consider for action.
Server Crash
Server Down
Database Damage
Record Deletion
Natural Disaster
Power Outage
Network Outage
Internet Outage
DNS Outage
Disgruntled Ex-employee
Cybersecurity Attack
Ransomware Attack
DDoS Attack
Developer Hit by A Kangaroo
The exact processes and policies required should be defined at the Company Policy level, customised to the Company's value of the data, and consequences of lost data.
Example: One client had their Office physically burn down. It was only the fact that one Technician grabbed the backup tapes from the Server Room before fleeing the flames. Without really knowing, the only other 'offsite' back up was four weeks old.
Preventative.
Nothing replaces a scheduled and complete backup strategy. This is where the 3-2-1 rule for backups comes into play.
Three copies of your data.
Two different storage methods.
One offsite copy.
Your back up strategy will differ slightly for Bare Metal or Virtualised Servers.
Recent outages highlight that even international platforms from top tier provides can escape the cure of one bad patch, one incorrect system configuration, or even the configuration file expanding to take down thousands of Servers.
There's also the required situation to protect Servers and data from Cyber Attacks and Ransomware Threats.
It's important to understand that if a user has access to a network volume, ransomware can propagate, encrypt or delete data, and potentially gather and disseminate sensitive information.
Also consider that the Ransomware can sit dormant for months, and of course be within your backup versions of your databases.
Example: A client invested $50,000 in external penetration tests - six months later, an employee clicked a link in an email, which resulted in all their files being locked. Consequently, the IT team spent four days restoring servers and data from offsite backups.
Maintenance.
Regular checking the health of your LIVE and backup database files 'before' FileMaker Server reports damage ensures - that on that day in the future - your backup is actually in good shape and ready for action.
It's not only worth configuring your FileMaker Server backups to verify backups as a secondary check of the files - this can be the first sign of damage.
I'd also recommend creating schedules for Clone Backup, and storing a good history of these files. A good history of DDR Reports will also aid in this process.
It's also worth considering the practice of duplicate copies of your backup files. Unique data, even backup files, are subject to damage rending unsuitable for return to Production.
Example: One client was only keeping one copy of their backups, which were stored in DropBox. On that one faithful day, when the backups were required to be returned to the Server - only to be found corrupt and useless.
This is where your Development Server, Staging Server and/or a DR Server can also be one of the location options to host and therefore confirm the stability and quality of your LIVE and back up files. This data should also include any External Container Data.
Consider the required steps to move the databases of the LIVE Server to a DR Server, and the time required to make this change over - and more importantly, coming back out of DR - this must be communicated back to the Business as part of the DR Policy.
Prevention Take Away.
The overall concept is that these processes will minimise your risk of damage . . .
Comments