June 13th 2011

Well, with apologies to Emilia De Poret, this adaptation of her hit song’s title pretty well describes the system and process of FileMaker Pro file backups.

Most all developers and IT Administrators who design or manage FileMaker solutions and deploy them in conjunction with FileMaker Server understand that a good backup system is absolutely one of several major requirements to assure the integrity and availability of business data the files contain.

But a significant number of developers and administrators do not understand what best practices are for making backups and for managing the backups once they are created. This article focuses on these two elements: making backups and managing backups.

Almost without exception, the best way to make a backup of a FileMaker Pro file is to have FileMaker Server create a verified backup of the file. Such backups should usually reside on the local server itself. This is the primary backup of the file. More on this later. While there are at least two other good methods for making backups, this is probably the one most used by, and most familiar to, FileMaker developers and IT Administrators who support FileMaker solutions.

Understanding why backups are made is important in understanding how to make them and how to manage them. The purpose of making a backup is not to have one or more copies of a file. The purpose of making a backup is to be able to restore a production file to its previous state in the event of some incident. Administrators must test backups regularly to assure that such restoration can actually occur.

The primary FileMaker backup is your Golden Asset. It forms the basis for any needed restoration. As a result, it should be treated with care and respect. What does such careful treatment entail?

First, do not open or tamper with these files, or open them up to see what might or might not be in them. Second, make a copy of them to some separate location. That second copy, the secondary backup, can then be pushed out to, or swept up by, other enterprise backup systems for either on-site or off-site storage.

Third, do not run anti-virus scanning software on the primary backup files. FileMaker Tech Info #5807 (http://thefmkb.com/5807) does a good job of explaining the damage such anti-virus software can do to the FileMaker files. But the regimen it suggests is not strict enough in my view. While the article notes that the backup destination can be scanned after the backup occurs, I would never do this to the primary backups. If such scans are really needed, it is a better and a safer practice to do them either on the secondary backup or on the copy that the enterprise backup software archives.

Fourth, the Golden Asset nature of the primary backup files argues forcefully in my view against doing anything to or with them other than copying them. If you need to restore a production file from a backup, use a copy of the primary backup. Don’t use the primary backup itself. Protecting the primary backup assures that it is available and unsullied.

Fifth, leave the primary backup files in the place where FileMaker Server put them when it created them. If they are needed elsewhere, make a copy of them. Administrators need to manage the retention frequency of the files to assure that there is always adequate hard drive space for them, while at the same time maintaining sufficient differential backup history. FileMaker Server allows managing this retention frequency by a setting in the Administration Console.

I mentioned there were at least two other good methods for creating backups and managing the backup process. The first of these is the Pause-Copy-Resume process. In this operation a Pause command is issued to the hosted files, in turn causing a cache flush and a suspension of the ability of users to write data to the files. While they are in this state, the files may be safely copied by an OS level action to a directory. When the copying is completed, a Resume command can return the files to their normal working state. This allows users to resume their work.

Such a process is complex to manage; it requires a good knowledge of a scripting language appropriate to the particular Operating System that manages the server, either Windows Server or Macintosh Server. It also requires a knowledge of the FileMaker Server Command Line Interface. Rob Russell of SumWare in New Zealand has posted one example of how to do this. (http://www.sumware.net/robfm2/?p=27) Wim Decorte of Connecting Data in Bermuda (http://www.connectingdata.com) has another example as well. A PDF of that is attached directly to this article. Thanks, Wim and Rob. The Command Line reference information can be found on the FileMaker, Inc. website at http://www.filemaker.com/support/product/docs/fms/fms11_help.pdf at pages 166-188, especially at pp. 179 and 182.

Another backup process uses an incremental approach to updating a master backup once that master backup is made (usually in the overnight hours when activity is minimal). This technique employs the fmDataGuard™ system from WorldSync, Inc. in Berkeley, California (http://worldsync.com). In this process the fmDataGuard system records all the changes made to the FileMaker files after the master backup runs. FileMaker Server then makes frequent backups of the much smaller audit log file where the changes are recorded. If a restoration is required, the audit log is used to update the master backup and to bring the files back to any given point since the master’s creation. This process is known as roll-forward. A case study describing its actual use is found at http://worldsync.com/fmDataGuard/case_linear_blue.html.

So, to summarize about FileMaker backups:

1. Let FileMaker Server be FileMaker Server and do the work of creating the primary backup.

2. Don’t take out, move, or use the primary backup. Make copies of it instead.

3. Manage the retention frequency of backups to assure that adequate space for a series of backups is available on the hard drive where the primary backup directory resides.

4. The primary backup is your Golden Asset needed to implement a restoration if one is required. Protect that Golden Asset.

MoreBackups_v3.pdf