I have a ~100GB build I’m trying to do a dev refresh with prod data with. It takes approximately 45 minutes to perform the build of the prod server and upload it to the dev servers inbox. It takes another 30 minutes to unzip the build and copy the files over to the database folder on the dev server. At this point, I’m already an hour and a half into the process, and the migration itself hasn’t even started.
Unfortunately for me, the dev servers database folder ran out of space, so the sub-deployment failed. Double unfortunate for me, Otto deletes the entire build from my inbox if the sub-deployment fails, so I have to re-migrate the entire build from the prod server to kick off the migration again.
Why does Otto delete the build in the dev inbox if the sub-deployment fails? I feel like this is unnecessary…
OttoFMS deletes the build because if it does not delete the build and you try to run the deployment again after fixing a problem with the build, it will use the build from the inbox rather than fetching a new one. We originally decided that this would cause a fair bit of confusion if you made a build, found a problem, fixed it, made a new build, and ran the deployment again, only to discover that the issue was not fixed on your destination.
We are planning on adding an opt in toggle that would let you keep builds in the inbox or outbox without being automatically deleted, this will probably come with a few other build features we’re planning.
True story just happened last week. I was asked to do a reverse migration (schema from production to data in staging) on just one 38GB file. Well, my first attempt failed because there wasn’t enough room, so I went in blew out any leftover files in the Otto Backup folders, and and the oldest backup of everything (about 350GB). Great…Then the migration failed because I had the wrong (old) password. DOH. Fixed that, and proceeded.
Then OttoFMS got through the entire migration. A new file was right there in the inbox waiting to hosted. Then…it failed. The original file was put back and the file I really wanted was zapped. This caused great sadness, wailing and gnashing of teeth.
It turns out that during the migration the daily backup started and BOOM. It blew out any extra room. So, I had to go back and delete TWO full backups, and try again. This time it worked. But it would have been easier if I could have manually used the fully migrated file, that was right there, instead of starting again.