What I’m trying to achieve is something like this: Take a snapshot of my droplet (which is doing production work at the moment) Use the snapshot to spin up a droplet. Do some development on the new, non-production droplet. Take a snapshot of that NEW droplet and replace the existing PRODUCTION droplet with the snapshot.
I don’t see this as a documented use case, but I imagine there’s some sort of workaround.
Note that the users of the PRODUCTION droplet are using the droplet IP address, and it’s a burden on them to change how they access it – which I’m trying to avoid.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Click below to sign up and get $200 of credit to try our products over 60 days!
Yes. You can do this. It sounds like you have the process down but are just missing one piece. You can deploy any snapshot (as long as it exists in the same datacenter, you can copy a snapshot to new datacenters from the Images section of the control panel) to any droplet by using the Restore option in the control panel. If you click the “delete” section for your droplet you will see two options.
When rebuilding you can choose to rebuild using any image, OS, one-click app or snapshot.
This is correct, but for a new droplet, you have to create it first. Also you will probably have some fixing up to do later.
I think that something like this sequence answers the original question:
Take a snapshot of your existing droplet.
If your new droplet will not be in the same data centre, copy the snapshot over.
Create a new droplet. You can’t use your snapshot at this point. Just install any of the listed images, because in a few minutes you are going to re-install the OS anyhow.
I suggest that you avoid logging into your new droplet for now - see below.
Once the new droplet appears in the droplet list web page, get its IP address.
over at your DNS provider, create a DNS record for the new machine.
Back in the Digital Ocean UI, in the droplet list, click “More” on the right of the new droplet name and choose the scary Destroy option.
At the very bottom of the resulting page, in the Rebuild Droplet section, there’s a drop-down list of of images you can use, including your snapshot. Choose that one.
The OS is rebuilt using your snapshot. The machine keeps it IP address, so the DNS records are still correct.
The new droplet’s SSH fingerprint has changed, so if you logged into it after you created it, you will now have to convince SSH that nothing bad is happening.
Most of the files on the new droplet are the same as on the old one, except some system files such as /etc/hosts have been recreated to suit the new machine. If you installed a database server, it’s running on the new droplet, with the same tables and contents.
You may have some fixing up to do. If you installed Apache on the old droplet, it will be installed on the new one, but any of its files that contain the host’s domain name are wrong. You will need to fix them. Similarly, you will need to replace any digital certificates, because they will have the wrong name embedded. If any records in your database reference the host’s domain name, you must fix them, and so on.
At this point you realise that it would have been a very smart idea to keep track of everything you installed on the old droplet. If you used an automatic process to set it up then you are in a good place. You just need another automatic process to fix up any new machines built from that snapshot.
I’m working on this same problem, however I have noticed that snapshots from one droplet will not show up on another droplet.
From reading on some other threads, here are some ways I am exploring to get this done, because I don’t want to lose the IP address that I currently have, it creates a ton more work:
Potential Reasons for the Problem:
Setup Notes: The Floating IP Strategy
Edit: It appears that after doing a Destroy/Rebuild of your Droplet, you loose the IP address, so no matter what you do, you are going to have this, “loss of IP address” which is a problem inherent to Digital Ocean, which they try to solve with something called a, “Floating IP.”
So essentially, before you do the following, you should likely try enabling Floating IP. Note that I did not do this, so I am not 100% sure that this prevents the problem.
Once you have your floating IP, then everything in terms of your DNS setup and Nameserver setup should flow from that floating IP, which you can think of as your, “Internal Unchanging Digital Ocean IP” (in theory - I have not tested this).
Change Region Strategy:
From that link:
you can change region by going to Images -> Snapshots, find your image -> More -> Add to Region -> Select region of original droplet :)
However this is not very helpful. Instead you have to follow this guide, mentioning how to migrate droplets, which mentions a few strategies.
When you create a snapshot, it is available only in the region where it was created. If you want to use the snapshot to create Droplets in other regions, then you’ll need to add the snapshot to the regions where you want to use it.
Personally, I was able to use this strategy to successfully migrate the new “dev server” droplet to the old “production server” droplet - I had my dev server sitting in a different region. However, after migrating, the IP address was changed to the new “dev server” IP address, so it does not fulfill the original objective of the question.
Don’t See Anything Yet? Flush Your Cache.
Flushing the DNS Cache Windows: ? Mac: https://discussions.apple.com/thread/7126452
Download/Upload Local Strategy: Downloading a snapshot to a local computer for data portability (e.g. download a snapshot from one droplet, upload to another):
I was not able to try this out, this appears to be the more, “old school” way of doing it, and would require that download/upload time, but may be less fraught with problems in the production environment, thereby effecting users less.
Note that one person’s advice was, “use Docker containers.” Yes, that is good advice and we should all be doing that, unless you are looking for an extremely quick fix.