Offsite Backups

OttoFMS has the ability to backup your FileMaker databases to S3-compatible remote storage locations. This is a great way to ensure that your data is safe and secure in the event of a disaster.

The OttoFMS Settings page walks through the specifics of setting up offsite backups.

Walkthrough

How an Offsite Backup Runs

Every offsite schedule is attached to a FileMaker Server backup schedule. OttoFMS watches for that schedule to finish, then takes the folder FileMaker Server wrote the backup to and sends its contents to your offsite location, under the dbs folder in your remote path.

The important consequence is that whatever FileMaker Server puts in that folder is what gets sent. OttoFMS does not pick and choose files out of the backup.

Where Your Container Data Lives Matters

How much data each run sends depends entirely on how your external container data is stored and whether FileMaker Server includes it in the backup:

• Container data stored alongside the database (the RC_Data_FMS folder in the database folder) is part of the backup FileMaker Server creates. It is sent offsite with every run, so your offsite location ends up with one copy of every container file per backup.
• Container data in a FileMaker Server Container Data Folder is only in the backup if Back Up Container Data Folder is enabled for that folder on the FMS Admin Console's Configuration > Folders tab. FileMaker Server leaves this off by default. If you enable it, the same per-backup duplication applies.
• Container Data Folders with that option left off can instead be synced separately by OttoFMS, using the Include External Container Data Folder toggles on the offsite schedule. These folders go to container1 / container2 in your remote path, alongside dbs, and OttoFMS keeps a single copy of each container file there rather than one copy per backup.

The two approaches give you different things, so pick based on what you need to be able to restore:

How Files Are Transferred

OttoFMS uses rclone under the hood, specifically the rclone copy command. Understanding what that command does explains most of the behavior you'll see in your bucket and on your provider's request bill:

• It copies, it does not sync. Files removed from your server are never deleted from the offsite location. Lifecycle rules on your bucket (or Storage Life Times on Ottomatic Cloud Storage) are what clean up old data.
• It skips files that are already there and identical. Matching is done on size and modification time.
• To know whether a file is identical, it has to read the destination. rclone lists and inspects the objects at the destination path before transferring, rather than assuming a file at the same path is the same file. So a run over a folder with many small container files does work — and makes requests — proportional to the number of files, even when almost nothing is uploaded.
• A file missing from the bucket is uploaded again. If a lifecycle rule expires a container file that is still on your server, the next run sees it absent at the destination and re-sends it.

Database backups are new files with new names on every run, so they are always uploaded in full. The skip behavior is what makes the separate container data sync cheap.

Zipping

The zip option applies to the contents of the backup folder. Each .fmp12 file is zipped together with its folder in RC_Data_FMS, if that container data is present in the backup. That is a large reduction in file count — and therefore in requests — if your container data is being backed up by FileMaker Server, and it does nothing for container folders synced separately with the "Include External Container Data Folder" option, which are not part of the backup folder.

Zipping happens on the server after the backup completes, so expect added CPU and disk load during that window.

Choosing a "Backups to Keep" Value

If a backup schedule exists only to feed an offsite location, keep this number low. Setting it to 0 means the backup only occupies space on your server while it is being processed and sent. 1 is reasonable if you also want a recent non-live copy on the server to download or deploy from.

Because of the hard linking described above, extra retained backups are often cheaper on disk than their apparent size suggests. The exception is a file system without hard link support, such as Windows ReFS, where FileMaker Server writes a full copy of every file on every backup — there, retention is as expensive as it looks.

See Backup Schedules for where to set this.