Remember that FileMaker Server suspends user activity at the end of each backup to synchronize changes that have happened since the start of the backup. Network performance is always going to be slower than internal disk i/o, so a network backup is always going to take longer than an internal backup. This can be done in batch files or VBscripts on Windows and shell scripts or AppleScripts on OSX. 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. 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. If any of these factors breaks down the net result is that the backup run would fail and you would be without backup. So you’d have to elevate their rights and document that in case a reinstall is required sometime in the future. These accounts do not have write privileges to network resources. Remember that FileMaker Server – and by extension its schedules – runs as “local system” on Windows and the “fmsadmin” account on OSX. 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. In addition, the backup will consume much less CPU time and network bandwidth when the backup is done locally. So, backing up locally is going to have a smaller impact on the users. That’s when the users will see the most impact. 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. It would take longer: copying across the network is always going to be slower than what the server can do with its own disks.
0 Comments
Leave a Reply. |