Wim Decorte, Nov 29, 2012, Soliant Consulting Blog
Source: https://www.soliantconsulting.com/blog/filemaker-backups-network-share/
I like simple rules. Like the 3-2-1 rule for backups which tells us to keep 3 backups of anything that is important, store them on at least 2 different backup media, and keep at least 1 backup in a different place.
Applying that rule to your FileMaker backups, it is only natural that the question comes up: “How do I make backups to somewhere different than the FileMaker Server machine?”
FileMaker Server lets us specify a path where the backups will be saved to, and it defaults to its own backups folder, on the same drive as where FileMaker Server itself is installed.

So can we specify a path here that would point to a network location? The short answer is no. There is an article in the FileMaker Knowledge base that addresses this. While the article is about OSX, the same applies to Windows.
At the bottom of this very short entry they specify a few reasons why backing up remotely using a backup schedule is not supported or not a good idea.
- Network backups will always take longer than local backups.
- Network connections can break for various reasons.
- There are fewer variables to deal with, in the event something should fail.
I agree with this completely. Let me expand a bit on those reasons.
It would take longer: copying across the network is always going to be slower than what the server can do with its own disks. That’s pretty obvious. Keep in mind that FileMaker Server pauses the hosted file at the end of the backup process to synchronize any changes that were made to the files since the start of the backup. That’s when the users will see the most impact. That’s what you want to minimize. So, backing up locally is going to have a smaller impact on the users. In addition, the backup will consume much less CPU time and network bandwidth when the backup is done locally.
The setup would be fragile: the completion of the backup depends on more factors now: the destination being available, the privileges having been set correctly and maintained that way. Remember that FileMaker Server – and by extension its schedules – runs as “local system” on Windows and the “fmsadmin” account on OSX. These accounts do not have write privileges to network resources. So you’d have to elevate their rights and document that in case a reinstall is required sometime in the future. If any of these factors breaks down the net result is that the backup run would fail and you would be without backup.
So am I not contradicting myself here? If local backups are preferred, what about the “1” in the 3-2-1 rule? We can still push out a backup to another location, using the FileMaker Server tools. We can schedule an OS-level script to run after our local backup is done to copy the backup set over to a network location. This can be done in batch files or VBscripts on Windows and shell scripts or AppleScripts on OSX.

When you set up an system script you can specify OS credentials that already have the proper privileges without having to modify the FileMaker Server defaults.

We can even avoid having to have two schedules and getting the timing just right, by doing everything in just one OS-level script. The FileMaker Server command line allows us to trigger a backup.
So with just one OS-level script we would have two backups; one local and one remote, without undue hardship on our users and without making our deployment more fragile that it needs to be.
