Maybe easier to create a new droplet and restore to it. You can get a floating ip,assign it to your old droplet until DNS propagates, build the new one and switch over when you like it.
Its actually faster if you create new droplet and set up discourse.
Its just system configuration, docker installation (simple apt-get) and rsync from old instance.
The DigitalOcean snapshot took ~20 minutes for a 40GB instance.
don’t forget running ./launcher cleanup before turning off your droplet and making a snapshot - it may a big difference in the snapshot size, sometimes up to 10GB
The do-release-upgrade took about 20 minutes for me (upgrading from 14.06 LTS to 16.06 LTS)
A few notes from the upgrade process I run through:
@mr8, I just ran the do-release-upgrade upgrade but got disconnected when it asked me to restart. Now I am getting the error message: Device "docker0" does not exist. Cannot connect to the docker daemon - verify it is running and you have access
How were you able to manually restart it once the upgrade was done? I am not trained as a programmer so everyone’s detailed instruction would be much appreciated!
I’ve used the same process on a number of Digital Ocean servers, so it is good to hear this works as expected.
One point, it looks like you are on an older Digital Ocean server, so it has not upgraded the Kernel. You can switch (in the Digital Ocean control panel) the Kernel to the Grug 0.2 kernel, and then Ubuntu will use the latest version (4.4 something).
BTW, the Snapshot is definitely essential - I just tried this process and it corrupted the harddisk and refused to boot properly - I’m lucky like that. I restored from the snapshot and everything was good again (tried again and the same thing happened so now I’ll see what the DO folks have to suggest).
So kids, always do the Snapshot (ideally from a powered off state, event if that means your server is down for an hour).
Those instructions already exist in the howto area unless you insist that the transfer has to be rsync, versus simple web download of backup, web upload of backup, then web restore.
Turns out my fstab had an incorrect UUID for the root disk which was the root cause (get it! ;- ) of the resulting disk corruption. Fixing that meant the update to Ubuntu 16 worked without further problems.