Use Offsite Backups as a build source?

OttoFMS
1

I realized I wanted to do a deployment to get live data back dev or actually to another test server.

Would be nice to just use last nights backup as a build source to be able to use that vs having to make a new build, as the data is new enough.

2

We are looking at something like for the future.

Todd

3

In addition to offsite backup I realized I have a 10am and 2pm backup on the main server, what if we could selectively target one of these backups and use that as a build, all Otto would have to do is zip the directory, if you were replacing files on the target.

1 Like
4

see above response.

Todd

1 Like
5

I’d like to follow up on this feature request from last year. This feature is of great interest to me as I have several use cases where deployments would be significantly optimized by its implementation. Not having to create a new backup for large systems (and select an existing local backup) to refresh a staging or dev environment would be huge.

Could you please provide an update on the status of this request? I would greatly appreciate any information you can share.

Thank you!

6

Hey @dube ,

We haven’t started this request yet. I can see how it would be highly useful for grabbing copies from a production environment.

-Kyle

1 Like
7

I will call out here that if you are using offsite backups you can do something similar. Let me lay out a scenario as an example:

Let’s say I have 3 servers: Dev, Staging, Prod. On my Prod server I have nightly backups that push to an Ottomatic Storage Location (or other S3 compatible storage) using Offsite Backups. I want to run a deployment that will get a recent copy of my files on the Prod server and deploy them to the Staging server.

You could do this one of three ways:

  1. You run a simple deployment with a Just in Time build. This will make a build at the time you run the deployment on the current version of the files and it will deploy those fresh copies to Staging. Downsides are it takes a bit and may introduce load to the production server. Upside is you have the freshest data (probably not all that necessary for this deployment tbh)
  2. You connect your Staging server to the same offsite location as the Prod server. You can restore the files from a recent backup from the File Browser and it will deploy them from S3 down to your server without ever having to touch the production server. Both servers have to be connected to the same offsite location, but otherwise the only downside is that the data might be slightly stale.
  3. Instead of running a nightly backup that you publish offsite, you can have a scheduled build that runs nightly that creates a build and publishes it offsite. This has some advantages over option 2 as you can keep only 1 copy of the build offsite (saving storage) and you don’t need to go to the file browser to choose the right folder, as the path should be set by the scheduled build. It has all the same advantages as option 2 (not touching the production server, etc), but with the added advantage of being able to run the deployment from OttoDeploy still and set it up with other sub-deployments.

I would probably go with option 3 if you find yourself needing a recent copy of your production files relatively often. You can essentially keep a nightly build offsite to use wherever you like. @dube @OceanWest Does that fit your use case?

-Kyle

1 Like