I have multiple servers and many GBs to migrate and manage. I can’t afford to retain even one set of backup files for long, once the migration has completed, so I need to delete them right away, as preparation for the next migration.
I noticed this “Maximum Deployment Backups to Keep” setting:
I set it to zero, thinking that might be the trick to automatically delete all backups, but after the latest migration I still found a backup in the “OttoFMS Deployment Backups” folder.
I looked through the API docs and can’t find an endpoint that can help me delete backups.
How can I best manage this task? My routine has been to keep OttoFMS open as a browser tab, and when it completes, the first thing I do is navigate to File Manager > OttoFMS Deployment Backups and delete anything in there.
Just thinking out loud… I think the backup could exist up until the moment the migration completed 100% successfully (then it gets automatically deleted). This seems like an acceptable risk to me.
If there is a better way to handle this (outside of increasing volume sizes by many, many GBs) I’m interested. Eventually I plan on integrating the OttoFMS API into our deployment hub file, so if it makes sense to just run a request to an endpoint, that’d be cool too.
The point of the backup is to be able to restore your data after the migration completes. It’s not even taken until just before the hosted files are replaced by the completed migration. If the migration fails, the primary file remains untouched since the process of the data migration actually creates a new file.
The data migration may complete successfully, but produce unexpected results, especially if you send the wrong settings such as for where to use the accounts, value lists, etc. This is at least one reason why Todd said it’s risky to go without the backup.
Yes, understood. I know backups are a good thing… until they clog up your disk and crash your server.
Another idea… we are starting to set up servers with an additional backup volume completely separate from the OS / FMS / live DB volume. Could we send these OttoFMS backups to the same backup folder that FMS uses?
For instance, here are the folders on an actual server:
This server has a 350 GB SSD and 1 TB HDD volume that that mounts as backups/. I wouldn’t mind so much having OttoFMS backups if we could send them to a different volume. I would prefer it, actually.
The OttoFMS backups are stored in the default backup location for FileMaker by default. OttoFMS creates a folder (helpfully called OttoFMS) in the backup directory. This folder has the deployment backup folder, the build outbox and inbox, the temp upload directory (as of version 4.3.3), and a couple of other folders. It will work if the backup directory is mounted on a different disk as well. So it should send to that larger disk already!
Just to be clear OttoFMS creates its backup folder in the location you select in the FileMaker admin console. So, our OttoFMS folder is nicely located on a separate backup drive. Yay!
Off topic note:
If you ever get hit by ransomsware you will learn that you can’t restore from backup because the ransomers have been encrypting your backups long before you got the $$$ notice. One potential way to slow the bots down is to name your actual folders something that doesn’t look like /data" or /backups" I’m not say it will work. But… For a while I actually used the folders /birds and /dinosaurs, but then developers complained about it so we went with something more developr-y.
