Please read this article even if you think you're an expert. Backing up FileMaker Pro database files is not as simple as backing up ordinary document files like word processing files or spreadsheets.
Here's a quick review of the points discussed below.
More on each point below.
Need some motivation? Then consider the following. All kinds of things can and do go wrong that can cause you to lose your data. Databases by nature are a bit finicky. Something as simple as opening the files the wrong way can cause serious damage. That seems fairly easy to avoid - don't open the files wrong - but what if nobody remembers to tell the new guy how NOT to open the files? Other threats are more difficult to avoid. Consider:
True, the odds of one of these things happening to you next week are small. But they are not zero, in fact, it's nearly certain that one or more of these problems will strike you eventually. Every single one of the things above has happened to me personally in the twenty-four years since I started using desktop computers. If your files get hosed (for whatever reason) and you don't have a recent backup, we will not be able to do much for you but express our sincere sympathy.
In short, if your data matters to you, you must back it up regularly.
If you are the primary user - the person whose job depends on the database - then you are the one who's going to suffer if the files are damaged. So take the initiative here yourself. Don't wait for your office computer expert to volunteer to put a backup routine in place for you. And don't assume that your database files are being backed up. If you have control of your own files, then deal with this yourself, now. Otherwise, go to the office computer expect and ask if your files are being backed up. If the answer is no, arrange immediately for a backup system to be put in place. Be sure the files are being backed up often enough. And be sure you know how to access those backups in an emergency.
IT EXPERTS: You may be an ace at the general subject of backup, but please read at least this section to make sure you are handling your database files correctly.
Before I get to the ways you can back up your database files, I want to emphasize that backing up FileMaker Pro database files is not quite as simple as backing up your ordinary files. Backing up your database files, you need to be particularly careful about the following:
How often should you backup? The answer to that question is another question: how much data are you willing to lose forever? We recommend that users of our licensed solutions (CMAssistant, Goodbooks) backup whenever they make significant changes. For most of our users, this means backing everything up once a week, at a minimum, and more often than that would probably be better.
Remember, the single most important thing about your backup strategy isn't which method you use, it's DOING IT. A lousy backup method that you actually use every day is better than a brilliant strategy that's so difficult that you never use it. So make it a habit.
There are three different ways to keep your data safe. First, you can duplicate your files right on the same hard disk where they're stored. Second, you can copy the files to a "remote" (that is, different) hard disk in your office, or to removable media like CDs or DVDs. The third type of backup is off site backup, that is, a backup that is physically stored outside your office. You can use the Internet to backup your files to a remote computer (often located somewhere else in the world completely) or you can make the backups in your office but carry them out of the office to another location.
Here is the paradox of backing up your computer. On the one hand, the ideal backup plan is one is one that uses at least two of the three methods described above, namely, that backs up data both to remote media and also to store backups at a remote location. But on the other hand, any backup plan at all is better than an ideal plan that you don't actually follow.
The simplest form of protection and the one that is needed most often is achieved by simply duplicating the folder that contains the active database files.
If you are using FileMaker Server to host your files, this is easy. FileMaker Server creates on-disk backups. Use the FileMaker Server Admin Console to determine how often your files are backed up and how many backups to keep. By default, Server creates backups in a folder named Backups that is in the neighborhood of the Databases folder. You need to know where that backups folder is located.
If you are using FileMaker Server, you can still duplicate database files on your hard disk. Here's how.
Be sure to close the files on any and all computers before archiving or duplicating them. Duplicating open files can in itself cause them to become damaged!
This procedure is especially useful if the files reside on the circ manager's personal computer and are not being backed up automatically. We recommend that you do this at the end of every single work session. Then, if one of the database files gets damaged, you have a recent copy of your entire solution that you can revert to quickly and without needing to find the IT guy.
On-disk backups are easy and very convenient. But there's a downside as well as an upside. Actually, on-disk backups have two problems.
The first problem with duplicates made on the same hard disk should be obvious. What happens if the computer is stolen or the hard disk is catastrophically damaged and you're unable to recover anything on it? Relying completely on duplicates made on the same hard disk as the active files is like storing a duplicate of your house key in your sock drawer: it may help in certain situations (if you lose your keys when you're inside the house) but not in others (if you lose your keys while you're outside the house).
The other problem with backing up on the same computer is that you may get confused about which files are the masters and which are the backups. That's why it is critically important to take our advice about renaming the backups (step 2, above).
The second option is to make a copy of your files on another hard disk or some other external storage medium like a CD, DVD or tape. Your computer person should be able to arrange this for you.
If you backup to a CD or an external hard disk, you should still rename the backups so it's clear that they are backups. We also strongly recommend that you dismount secondary hard disks from the computer when you're not backing up. If the backup hard disk is mounted all the time, there's an increased possibility that it will be damaged itself, say, by a power surge, or a virus (or by theft).
Are you using FileMaker Server? As I said earlier, FileMaker Server normally creates on-disk backups. If you are serious about your data security, you will periodically copy those backup files from the FileMaker Server Backups folder to a CD or some other external storage medium.
The third form of backup is off-site backup. Periodically -- once a week, or once a month -- you should copy your files to a Zip disk or burn them to a CD, then take that disk home, or FedEx it to your mother in Nebraska. Then if your building is hit by a tornado, you won't have lost everything. Of course, this isn't fool proof, either. A tornado could hit your mom's house in Nebraska just before you lose power and your files are damaged. But the odds of that are low.
The biggest problem with off-site backups is that they are not very convenient. If your computer crashes while you're trying to print an important report, and the only backup you have is the CD you mailed yesterday to your mom, well, you're in a tight spot and you're probably going to be late getting that report done.
That is why the best compromise is to use one of the commercial services that backs up your files over the Internet. (Obviously, this is useful only if you have broadband access to the Internet.) These give you safety and convenience both. We use Carbonite for automatic backup over the Internet and I recommend it if you keep your database files on your computer AND if your computer has a constant connection to the Internet. Carbonite backs up my main development workstation in the middle of the night. I'm careful to close all my database files when I'm done for the day so that Carbonite isn't copying open files. I did once need to restore a single file from Carbonite's backup store and it turned out to be quite easy to do.
This is an important question, too. Many computer users think that it's sufficient to mirror their hard drive to another hard disk, that is, to have a second hard disk that is an identical copy of your computer's internal hard drive. This can be extremely useful if your computer crashes. But mirroring your drive should not be considered a solid backup strategy for your mission-critical databases. Why not? Because there's a good chance that, sooner or later, you'll end up backing up a damaged database. Say somebody works on the database Monday afternoon and accidentally deletes all the records. Monday evening the computer's hard disk is mirrored to the remote disk. The database is backed up, that is, the previous backup (with all the records in it) is replaced by the latest version of the same file, which now has no records in it. When you come to work Tuesday and discover all the records missing, what are you going to do?
For this reason, we strongly recommend that you keep multiple, dated backups. FileMaker Server does this for you automatically. If you're managing the backups yourself, devise a system that allows you to keep multiple files. If you backup to CDs, write the date on the CDs ("2/14/2009 backups", "2/21/2009 backups", 2/28/2009 backups", etc.) and keep the old CDs. This way, if you discover that that 2/28 backups were made from files that were already damaged, you can go back to the 2/21 CD.
The most important thing after backing up in the first place, is knowing how to restore files from the backups. W.C. Fields deposited money in banks all over the USA, often using fictitious names that he could not later remember. His money was secure. But he could not get to it. A lot of our CMAssistant users are at the office late on Tuesday and Wednesday evenings printing route sheets, after the IT staff has left the building, and this is almost always when disaster strikes. Having a backup on a network backup server is pretty useless if you do not know how to get to it. Make sure you know where your backups are, how to get to them, and how to restore files from the backup should you ever need to.
If one or more of your solution files get damaged and you need to turn to a duplicate or backup, be sure that you use the entire backup file set. In other words, if your history or delivery file is damaged, you should consider all the files damaged. Do not simply throw away the damaged file and put the duplicate in its place!
Finally, restoring files from a backup should be a very rare occurrence, sort of like making an insurance claim. If you wreck your car on a regular basis, you probably need to do more than pay your insurance bills on time: You probably need to take a driving course. Same with restoring from backup. You backup because there is a possibility of disaster. But disasters by definition should be rare. You should not feel the need to restore from backup very often. If you do, there's some other problem somewhere that should be investigated. (A few possibilities to consider: you've got a back hard disk, faulty memory, bad power supply, you're restoring damaged backups, you're routinely opening the files incorrectly or the files are improperly installed.)