Nightmare of downgrading Droplet

This evening I needed to downgrade a droplet hosted with, 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 website. Boy was I mistaken… what followed is my experience with

It took me a while to figure out that the 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.

Once done:
– 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 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 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:

9-11-2014 2-19-05 PM

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:


  1. Could you please spare a minute and explain what you did? I am not a first person with this experience and only a week ago I wasn't able to do this. Feature request on support board is still in unresolved state. I am still looking at the option of downgrading without re-installing entire server from scratch, so I'd be grateful if you could please let me know.

  2. Jozef Beljar I clicked my droplet in the panel, clicked "resize," and chose a different size. It took a few seconds, and then it let me back into the administration panel for my newly resized server. I did the same thing when I downgraded from the 80 to the 40. That was about a month ago though. I just deleted my server and restored from a snapshot (in order to get my updated SSD size allotment) just yesterday.

  3. Interesting, if you look at the screenshot in this article, option to re-size is not even there.
    Anyhow, it’s possible, that you were a part of some limited test and you had that option enabled, companies do that to test the feature by releasing it to a small group of customers.

  4. Response from DigitalOcean regarding downgrading droplet:

    At this time we do not have the ability to resize servers down via snapshots. The reason for this is because it impedes the progress of some of of our newer features we are intending to roll out such as: customer managed kernels, fast disk resize (up), multiple partitions.

    These are the steps I suggest you take:

    1) create a new smaller droplet in the same datacenter
    2) use rsync to sync the files between the two droplets (see link below)
    3) take a snapshot of the smaller server
    4) destroy the larger server to release the IP
    5) rebuild a new server in the same datacenter using the snapshot, and it should reclaim the same IP

    Rsync guide is here:

    • Hi, I am trying to wrap my head around your reasoning, but somehow I am failing to see the logic here. Process of adding hdd space, cpu and ram is supported. Makes sense, it means you’re getting paid every-time we do so.
      However, when we no longer need the additional resources, process of downgrading is not only not supported, but we have to go through some crazy process, taking server down, moving data, destroying original server and risking loosing our original IP address, not knowing if it will work at all. And this all knowing that this feature wouldn’t be hard to implement. I am working with VMs, hyper-visors, etc. all the time, and this would be as easy to implement as implementing an upgrade.
      Don’t take me wrong, I totally stand behind your company and I love your service. This is the only downside I can think of really. However, this is one of the most requested and yet most ignored features. And I have a droplet which I should be paying $40/month for, yet I am locked in paying $80. I am literally wasting $500/year, because this feature is being ignored.

        • Thanks, those instructions will be very useful for people running static websites or file servers. But those of us running webservers alongside MariaDB/MySQL (most of us do), rsync instructions are not going to be much helpful. Especially if you have many databases and multitude of user credentials. Same goes for FTP, mail server accounts, etc. This all will need to be setup from scratch. This also only partially addresses cron jobs. Rsync can move the cron or sh files, but it’ll not schedule my cron jobs, again that has to be done manually. Also how does it address installing something like EPEL repositories, or enabling needed PHP modules which are not part of the default PHP install (such as mcrypt), etc.
          So most of us with complicated setup, instead of dragging space requirement slider down a notch, end up reworking entire server. Like I had to do. It took me a week of my spare time, while it could be all done in under a minute if DigitalOcean just enabled a hard drive re-sizing in a down direction. It’s a simplest to implement, top 10 request from among their user base, yet completely ignored.

Leave a Reply

Your email address will not be published.