Can snapshots be used when upgrading the host OS?

Apologies if this has been asked, I looked around but didn’t see the exact scenario I’m planning (or I missed it, but I want to make sure I get it right since i’ve never done it before).

I’m still on 18 (which is where I started at; I’ve never upgraded linux OS before just the security updates) so sometime soon I’m going to go up to 22. Everything I’ve read here suggests that migrating to a new install is much smarter than upgrading your existing one because there’s potentially a multitude of random issues that may or may not occur, but it’s not worth the risk because if they do occur then it’s just a pointless hassle.

I did read this guide Move your Discourse Instance to a Different Server but it’s referring to moving from some server to DigitalOcean (or vice versa) which makes the Snapshot not applicable, whereas I’m planning to move from an existing DigitalOcean Droplet to a new one (which I’ve seen multiple references to working fine and being ideal to an upgrade).

So my question for a DO>DO transfer is can I just spin down my droplet, take a snapshot, start a new Droplet on the updated Ubuntu I want, load in the snapshot, and voila (adjust the DNS record for the domain etc)? Basically sidestepping the “completely reinstall Discourse” that the guide details. It’s my understanding of snapshots that they’re supposed to be an identical 1:1 of the install on the Droplet vs. the backup which is specifically of your Discourse setup which requires an entire install to actually utilize this. Am I understanding this correctly? Any downside to this other than longer downtime?

tl;dr: can I just take a snapshot, make new upgraded droplet, load snapshot and be done?

A DO snapshot includes the OS version. Restoring a snapshot would roll back the operating system.

Your practical options are to move a backup, or rsync /var/discourse and manually reinstall docker.

2 Likes

Hopefully I’m not totally wrong, but restoring snapshot from 18 on 22 will reverse you back to 18, because snapshot is 1:1 copy of whole droplet.

For me spinning totally new droplet is always the last option, because I need to install everything that Ubuntu (or what ever OS) needs, including mailing system etc.

I’m totally sure that is just another trivial task for those who can, but after 10 years I’ve never learned how to start new functional droplet easily

2 Likes

Installing Discourse takes ~30 minutes if that?

Just take a back-up of your site and app.yml, create a new droplet on the new OS version, re-assign the IP to your new droplet (so domain is pointing to the right, new place), install Discourse (you can quit the wizard and update app.yml, then rebuild) and import your back-up.

That whole process should take under and hour.

This process never touches your existing droplet, so if all else fails, so easy to roll back?

2 Likes

If moving from one LTS version of the OS to the next version, I’d expect a fairly smooth process. So, I might take a backup - of course - and download it for safety - of course - and then try the OS update. If it didn’t work, I could then try a fresh OS.

But in doing this I would take more forum downtime.

I’m a little reluctant to migrate to a fresh instance mainly because I’d need to update the DNS and wait for it to propagate. Although I see the post above me says I could take my IP address with me, which is nice, and which takes this reluctance away.

In fact, changing my answer entirely, if I can take my IP address to a new instance that would be preferred. Possibly not all providers allow this. Possibly for some providers one would lose a no-cost IP and start paying for the IP, because it has moved even though it hasn’t changed.

1 Like

A super easy mitigation for this is just set a super low TTL (or swap name servers to one which supports this). That way records expire in less time than it takes to rebuild.

2 Likes

You can use a static ip (I can’t remember what digital ocean is calling them now). In networking you can get a new ip and then map it to the old droplet. Then you change the dns and let it propagate. When you’re ready to move to the new server, you just switch the ip to point it to the new server. It happens immediately and if something goes wrong, you can just switch back.

1 Like

That makes sense I wasn’t even thinking about it moving the OS over.

Starting a new droplet would be my last choice too as I’ve never moved droplets before (this is the first one I have) nor have I ever upgraded the OS before, but all the guides I see here pretty much across the board seem to recommend doing it that way vs. just upgrading the droplet you’re on so I figured might as well go with the majority if both ways have risks and I’ve done neither.

My thinking is also if the upgrade totally botches somehow now you have the downtime from attempted, you have the downtime while you’re forced to try and fix it (or give up and make a new one), vs the new one potentially not working while your original remains running and intact. I don’t know why it would botch but searching meta here has A LOT of people saying it botched, or leads saying they’d never recommend that way (plus the official guides here and digitalocean suggest it).

Guess I’ll give it a go this weekend

Reserved IP’s (formerly Floating IP’s apparently)

Just so I’m super clear, following the guide discourse/INSTALL-cloud.md at main · discourse/discourse · GitHub

After 5. Install Discourse, I’m fine to exit the wizard at that point instead of doing the configuration, swap in my app.yml, then

./launcher rebuild app

And it should be good? (Then go into Admin and make sure it’s updated/restore the backup)?

Correct: if you create an empty app.yml file (by e.g. touch app.yml in the containers directory) and paste in (carefully!) the contents from your other server, you don’t need to run ./discourse-setup at all.

One issue that bit me this week was my email setup: make sure your email service doesn’t require the exact IP you are calling from. If they do be sure to update that config (at your service provider)

2 Likes

It’s the safest thing to do, though. If you break it, your old site continues to work. There is zero risk.

There is a topic about that. You can copy over your yml file and the let’s encrypt stuff and even see that it works by changing your local dns to point to the new server.

And if you have your backups on S3 then you can sleep better knowing that if something goes badly wrong you can spin up a new server and restore a backup in about 30 minutes.

2 Likes

My only actual concern wasn’t so much just moving it, it was goingg through the entire setup and somehow botching some setting whether it’s the email service or letsencryp or what and only realizing it down the line once everything falls apart. Which obviously isn’t an issue if it can just reads my old app.yml so that’s fine

Not entirely sure what this means but I don’t think it does…I have Mailgun and checking all the records there/DNS in godaddy nothing seems to be linked to any specific IP

Alright sounds easy enough I’ll give it a try this week. Maybe upgrade to a better Droplet at the same time

1 Like

You are correct!

I can’t find the topic that I feel sure exists. In short, configure backups on s3 in your env settings, rsync over /var/discourse or maybe just the ssl and letsencrypt and containers directories, and then rebuild.