Home / Blog / When disk space is not disk space…

When disk space is not disk space…

A strange question pops up on the various FileMaker forums from time to time and it goes like this: “How can I exclude my externally stored container content from a backup run?”

The reason behind the question is usually a concern for the amount of disk space that is required for the backup.   Say that you have FileMaker solution that has hundreds or thousands of pictures, PDFs or other documents stored externally, totaling many gigabytes.  Let’s call it 100GB.  The FileMaker file itself is probably fairly small, let’s say 50MB.

If the container data is fairly static and you can exclude it from the backup then you could save roughly 100GB on each backup run and not fill up the hard drive, and that allows you to take and keep more backup sets, right?

Wrong.  Well… right of course but the underlying premise is faulty.  In the scenario described above, FileMaker Server does NOT actually consume 100GB of disk space for each backup set.  FileMaker Server is very clever that way. When it finds a file that has not been changed since the last backup; it just adds a hard link to that file.  The effect is easy to observe:  run a backup and check the free disk space in Finder / Windows Explorer.  Now run a new backup and check the free disk space again.  You’ll see that the free disk space was not reduced by the total size of your solution.  Magic, right?

So don’t jump through hoops trying to break up the backup: you are not actually achieving anything except making the restore process harder, restoring becomes a two-step process (restore the FM file, restore the container data).

Attached is a white paper that Steven H. Blackwell and I co-authored at the release of FileMaker Server 12 back in April of 2012.  It describes the backup process and the concept of hard links in great detail.

1 thought on “When disk space is not disk space…”

Leave a Comment

Your email address will not be published.