Trigger full backup from cli / scripted migration
-
Maybe something like this already exists, but I could not really find it.
Story:
I am currently planning to migrate my Cloudron to a more powerful machine. The system is in use (although not busy) so I want to have the least possible downtime. What I could manually do is the following:- login on old server
- go to backups and trigger a new backup
- wait
- immediately once the backup completed, get the backup id and then shutdown the server
My backups are written to an instance of Minio.
Once I have the id I can start the installation and restore on the new server.
What I am now looking for are ways to automate this whole process. So maybe directly from the terminal of the new server trigger the backup, poll for completion and then trigger the shutdown.
Or maybe it would even be nice if you could do that even in the browser based part of the Cloudron installation on the new host?
-
I don't have a script but if you want to keep the downtime low, we added this dry run feature last release - https://docs.cloudron.io/backups/#dry-run . This way you don't need to shutdown the old server while things are restoring on the new server. Of course, you have to be careful not to add new data in the old server since it won't be part of the backup but atleast the site will be up.
-
I don't have a script but if you want to keep the downtime low, we added this dry run feature last release - https://docs.cloudron.io/backups/#dry-run . This way you don't need to shutdown the old server while things are restoring on the new server. Of course, you have to be careful not to add new data in the old server since it won't be part of the backup but atleast the site will be up.
-
I don't have a script but if you want to keep the downtime low, we added this dry run feature last release - https://docs.cloudron.io/backups/#dry-run . This way you don't need to shutdown the old server while things are restoring on the new server. Of course, you have to be careful not to add new data in the old server since it won't be part of the backup but atleast the site will be up.
@girish the only problem with the Dry Run (or more accurately just something else that needs to be considered) is email. Email at least on my server is heavily used and messages received every few minutes. This means for me I usually need to end up shutting down the mail container manually on the old server to avoid it accepting mail during backups in order to ensure the backup is 100% complete of data and not missing data added to an account just after it’s backed up.
There may be a better way to do this, but that’s my current routine. I suppose the best way may be to do a dry run first, then migrate DNS to the new IP, then user rsync or something to bring over any other mail that may have been missed by the backup if accepted mail after the last backup occurred. I probably need to nail down this routine a bit better to avoid the current downtime (which I believe for me is about 45-60 minutes total between shutting down mail on old server, waiting for backup to complete, and spinning up the new server using the latest backup via object storage services).
--
Dustin Dauncey
www.d19.ca -
@girish the only problem with the Dry Run (or more accurately just something else that needs to be considered) is email. Email at least on my server is heavily used and messages received every few minutes. This means for me I usually need to end up shutting down the mail container manually on the old server to avoid it accepting mail during backups in order to ensure the backup is 100% complete of data and not missing data added to an account just after it’s backed up.
There may be a better way to do this, but that’s my current routine. I suppose the best way may be to do a dry run first, then migrate DNS to the new IP, then user rsync or something to bring over any other mail that may have been missed by the backup if accepted mail after the last backup occurred. I probably need to nail down this routine a bit better to avoid the current downtime (which I believe for me is about 45-60 minutes total between shutting down mail on old server, waiting for backup to complete, and spinning up the new server using the latest backup via object storage services).
@d19dotca yes, I think zero down time fail over will be quite complicated.
I guess one approach is to do an rsync of the mail data directories (manually by running the rsync command) after the migration and then immediately switch the DNS.
But, out of curiosity, is there any (public) reason for the repetitive migrations ? I have to admit we consider the whole migration thing as "pretty rare" and it's only done when you want to switch providers which for most users is once in many years. But we could be overseeing some use case here.
-
@girish the only problem with the Dry Run (or more accurately just something else that needs to be considered) is email. Email at least on my server is heavily used and messages received every few minutes. This means for me I usually need to end up shutting down the mail container manually on the old server to avoid it accepting mail during backups in order to ensure the backup is 100% complete of data and not missing data added to an account just after it’s backed up.
There may be a better way to do this, but that’s my current routine. I suppose the best way may be to do a dry run first, then migrate DNS to the new IP, then user rsync or something to bring over any other mail that may have been missed by the backup if accepted mail after the last backup occurred. I probably need to nail down this routine a bit better to avoid the current downtime (which I believe for me is about 45-60 minutes total between shutting down mail on old server, waiting for backup to complete, and spinning up the new server using the latest backup via object storage services).
@d19dotca said in Trigger full backup from cli / scripted migration:
email
Yes, email would be my main concern as well, as this comes from unknown third parties. Other cases would be systems where customers could upload data.
In my original case I wanted to see if I can reach minimal disruption for my own migration. I made a small writeup of my my approach in https://blog.9wd.eu/posts/cloudron-migration/.
-
@d19dotca yes, I think zero down time fail over will be quite complicated.
I guess one approach is to do an rsync of the mail data directories (manually by running the rsync command) after the migration and then immediately switch the DNS.
But, out of curiosity, is there any (public) reason for the repetitive migrations ? I have to admit we consider the whole migration thing as "pretty rare" and it's only done when you want to switch providers which for most users is once in many years. But we could be overseeing some use case here.
@girish said in Trigger full backup from cli / scripted migration:
But, out of curiosity, is there any (public) reason for the repetitive migrations ? I have to admit we consider the whole migration thing as "pretty rare" and it's only done when you want to switch providers which for most users is once in many years. But we could be overseeing some use case here.
Totally valid question. So for me it’s more of a migration reason than a restore because of any disaster. It’s taken me quite a while over the last two years or so to find a VPS provider that meets my somewhat unique needs.The main reasons are usually down to costs and performance.
For more context/background: I’ve probably been with OVH the longest because they bill me in CAD$ which is great (I’m Canadian and the USD$ conversion fees on Canadian credit cards really sucks, lol), also required to have my servers reside in Canada for various legal reasons for some of my customers (mostly medical clinics and real estate agents and such that have some government oversight).
Though every now and again I also get an itching to further improve website performance and unfortunately OVH performance kind of sucks compared to the competition (but it’s decent given their lower costs too), so then I’ll switch around to Vultr, then to DO to try and see how they compare to Vultr, then to Linode for the same comparison reasons. Then I’ll settle down on one for a while but then a complaint may come in about webmail taking too long and if I can’t resolve it by throwing more memory at it (since there’s no errors), I’ll use it as an excuse to upgrade a server to a more powerful one for my clients needs, which starts the rotation again. Lol. That was my latest reason for the migration I did a few days ago. Also onboarded some new customers so have a bit more to reinvest in the business for better servers now and maybe even eat the currency conversion stuff, etc.
I think in my 3 or 4+ years of using Cloudron now, I’ve only needed to restore due to a catastrophic issue (caused by a massive server failure at OVH where it was down for over 12 hours) only once. Every other migration has been me just trying to find the sweet spot of a good host that meets my evolving needs for my clients.
Hope that helps give the story there to explain why I restore so often. Haha.The good part of me restoring so often is I’ve found and reported many bugs related to it as a result
lol -
N necrevistonnezr referenced this topic on
