This evening I needed to downgrade a droplet hosted with digitalocean.com, as I no longer needed all the space resources. So, thinking it’ll be a pretty straight forward affair (re-sizing the drive from the VM console) I headed over to DigitalOcean.com website. Boy was I mistaken… what followed is my experience with DigitalOcean.com.
It took me a while to figure out that the DigitalOcean.com console won’t let me resize the drive to any smaller droplet size. But after seeing this under Resize screen in droplet, I’ve decided to look on the internet instead.
I found a DigitalOcean’s own guide and it said that it’s possible to resize:
And answer in the support board confirmed it:
You can downgrade you droplet size! … it is slightly more involved than using the “Fast Upgrade” feature. If you take a snapshot of your droplet, followed by destroying original droplet, you’ll be able to restore it using any size plan.
So I said ok, let’s do this!
I’ve followed the process:
– First take a snapshot of existing droplet (server)
Only to realize that the server needs to be down in order to do so. So, I’ve turned off the server, then initialized snapshot taking process.
It took about 90 minutes to complete.
– Destroy existing droplet (server)
I’ve reluctantly killed (destroyed) my virtual server.
– Create a new droplet, using freshly created snapshot
So I went onto creating a new droplet using the snapshot I created.
Message that greeted me on this screen said: Cannot create a droplet with a smaller disk (60GB) than the image (80GB)!
At this point I thought I am going to flip. In order words it was telling me that the drive size cannot be smaller than the droplet’s original size.
So much time wasted for nothing?
This message basically read that I’ve destroyed my server for no good reason, because there is no way to go to a smaller drive, even that I am using only 10% of the capacity. This basically means, that if you have 80GB drive and only using 20GB on it, you still can’t resize it to anything smaller than 80GB. In DigitalOcean’s world you’re stuck with the size you’ve chosen. You can resize it upwards, but not downwards and thus: You’re stuck with the large drive and a lot of unused space! What a waste of resources!
Only option I was left with then, was to use exactly the same droplet size as I had before, or use only one of the more expensive droplets (pointless when you need to downgrade to save some cash).
So, not knowing what to do and having no server installed (and all domains and services down), I’ve decided to go back to where I was, praying it’ll work. So, I’ve chosen the same droplet size as I had before I started the process earlier and after approx. 2 hours, I was able to restore a snapshot back to droplet size I used to have before.
Entire process worked fine and I’ve started the server. However, nothing happened!
Server was running, but I wasn’t able to ping it, nor access any sites. I’ve used internal SSH console provided through DigitalOcean.com website and using SSH I’ve confirmed that server is up. So why can’t I ping it? Why can’t I access any site remotely?
Apache and mysql were running…
Having thousands of unique visitors accessing my sites, and being down for over 4 hours at this point, I’ve decided to contact their support with priority 1 ticked. After 45 minutes waiting and not a single response to my ticket, I’ve started to poke around, trying to figure out what could be the problem.
Luckily, I’ve tried one thing which shed the light on what’s causing the issue and I was able to resolve the problem myself:
I’ve tried to run apachectl start command from SSH console and got some message saying that apache apr_sockaddr_info_get() failed, and right below a short message referring to some kernel support issue. That message about kernel got me thinking…. I’ve realized, that DigitalOcean.com probably didn’t backup my droplet with a correct kernel but with some old kernel version. I’ve queried the kernel version through SSH and I was right, it was a very old one 2.6.32-358.6.2.el6.
I’ve briefly remembered that I was at least at kernel 2.6.32-431.17.1.el6.x86_64, so I’ve switched to this recent kernel using DO console:
Restarted server and “Voila”, my server came back!
The final result? After 5 hours of downtime, I am back to where I was before I started!
It’s pretty disappointing that company such as Digital Ocean doesn’t support such an essential feature, such as downgrading virtual servers!
Only later I’ve found that many people are complaining about it. There is almost 3,000 votes in their support board for them to enable downgrade option and it’s been there, ignored for years now. It’s obvious that this has nothing to do with implementation, it’s basically a money grab. If you care, please add your vote here: