FYI - 20GB in AMS1 took 9mins

Before taking snapshots, I’d recommend getting rid of as much rubbish as possible, just due to how ridiculous the waiting times can be. Not only is your server down, money is being taken out of your pocket too. But yeah, fairly normal for it to sometimes take ages, particularly at peak times.

Same in 2016… It’s still really slow…

I started looking for this answer after I started taking a snapshot which is a shame. 100g android build environment SGP1. 45 min so far. Cancel would be a really useful option.

This is worrying, I started a snapshot of a 2.5TB drive. I guess I should come back here in a week…

It sounds like something is stuck. The control panel may be out of sync as well. If you have logged out of the control panel and logged in with no change, it is time to submit a support ticket.

Same thing. It’s down for 15 minutes already and still spinning.
They should have an option to cancel the process.
It’s not the first time this happens to me.

21G in LON1 took 50 minutes!

Same in 2015, didn’t know the snapshot is going to take so much time.

30GB, 40mins

With such fast disks (ssds all over the place), why does it take so long to create the snapshots? Are you using qemu snapshots?

Maybe using some cow storage technology (Netapp or any ZFS enabled provider) would greatly improve the snapshotting experience ;-)

Really liking this new snapshot update. Now I can see a snapshot of 47.26GB took 39m53s to be created in the AMS3 region. :D

Not too bad for testing and such, I suppose. They really ought to add in the option to make your droplet automatically destroy itself after having an image taken instead of just booting up again since it’s no doubt common to take a snapshot before getting rid of a droplet. Would save me a few hours sleep waiting just to save a few pennies for the snapshot to finish being taken.

I have a staging server with around 15G (14GB of musics) (400MB (3,000 files) pictures), it took 19 minutes 56 seconds! May be cause music files copy are faster.
Anyway Good job DO Teams, that’s great even for Production.

BTW: Droplet is $5/month -> 512MB and 20GB

Same here, I wish I read this before I clicked Create snapshot…

Joining the surprised here. Creating a snapshot of 512 MB Memory / 20 GB Disk / AMS2 took 27 minutes.

I just finished an online snapshot on SGP01 and it took 17 minutes (20GB).

Well I was taking the snapshot in order to copy the image and spin up another server with it… but after waiting and then seeing this thread (with no DO response!) I’ll just setup the new box w/ Linode instead.

23.3GB in NYC1 took 25 minutes.

30.62 GB AMS3 - 20 minutes

27 GB AMS2 - 22 minutes
Red notification “Sorry! Something went wrong” shows every two minutes.
Progressbar stucks on 50% until almost end of process.

Hi Digital Ocean team.

12,17GB AMS2 tok almost 1 hours.

Progressbar stucks on 50% until almost end of process.

This has to be fix ASAP guys.

Dealing with the same issue here. Just a simple notice “this may take 30-60 minutes” would be very helpful, because then I wouldn’t have clicked to create a snapshot.

30Gb on AMS2 took 20min

Agree with @stu6b631e4394491e98c39429e should be a warning.

Making a snapshot should be snappy, as the word implies. Otherwise, I would have waited for a normal backup to have run and proceeded after that.

It took 14 minutes for 22 GB - 4GB Ram/60GB disk server

55gb in SFO2 has taken hours :-( Stuck at 50% and doesn’t seem to be moving.

30Gb in SFO2 has taken more than 1.5 hrs, and still stuck at 50% as well…

Really wish I’d seen this thread before creating my first snapshot (of a production server, no less). Just moved all my servers over from a different host and was looking forward to the convenience of snapshots & backups, only to find my server down for who knows long… “Progress” bar also just stuck at around 50% (it actually started at 50%)

grgrgrgr same here… I wish I had seen this before!!! WTF

Took us ~10 min to do 20GB snapshot in AMS3

March 2018 - No specific progress is shown while taking a snapshot. We need some kind of estimate rather than being glued to the screen, being unsure, waiting for it come back up.
Taking longer than 30 minutes, I wish there was some sort of warning about the time it would take!
33 minutes in - It moved from 50% - 90%

Absolutely absurd. 10GB of disk space and still waiting after 35 minutes. AWS is looking more and more inviting.

22.18GB in 14 minutes

9.4GB in 6 minutes.

46GB in 36 minutes. Still way too slow.

TOR1 2.18GB 1.5hours

5.9 GB took 15 minutes. Looks like they have improved snapshoting time.

TOR1 10.9GB 1 hour 43 minutes

7.47GB Took around 10 minutes for me, New York server.

AMS3 ~160GB
1.5 hours and still processing. Support team said that it takes around 1 to 3 minutes per GB…

FRA1 - 15.8G - 9 minutes

SGP1 - 19GB 1hour 58minutes

FRA1, 8Gb, 40 minutes

Which translates to about 0.2Gb per minute.

FRA1, 4GB data, 2+ hours and still runs at “50%”. It’s an important production server and no ticket reply, no cancel snapshot button… I’m very disappointed and upset.

I’m irritated too by the time it takes to do the snapshot. I have a 320GB instance with maybe 50 gigs to snapshot so I can see its gonna take awhile :(

But.. To the guy who said AWS is looking inviting… Man I have my whole business on Amazon and its costing me $1200/month and I’m exploring moving over to DigitalOcean.

DigitalOcean still has Amazon beat. Amazon absolutely slaughters you with pricing. I’ll just keep more on the elastic volumes here and snapshot that so i dont need to snapshot my whole instance often.

So far, I am enchanted with DigitalOcean. Man the servers are FAST. Screw Amazon man I can’t tell you how many times I ended up holding the bag because something failed and they said ‘Failure is a feature’. Worst support I ever seen. Don’t be so quick to knock DigitalOcean, its easy as pie to use and nice and simple. I will be recommending it to all my customers who sometimes like to get their own servers and I been using Amazon s3 but will be exploring the Spaces option here also. Theres… Something about this service I really like. Maybe is that damn fish that’s swimming to keep me busy while that slow console loads lol.... :)

A satisfied DO customer here… we have several droplets, spending over a thousand bucks monthly here.. and we love it.

But snapshot creation speed is a thing here.
FRA1, 160GB disk.. snapshot started more than an hour ago… the progress bar is misleading … quickly reached 50% (in approx 20 minutes) then being stuck there ever since.

I kind of expected the long running time.. but a more informative, more accurate status report, progress bar would be very helpful.
And, as others stated, better speed would be expected… to minimize server downtime.

Thank you DO for listening to us, looking into this issue.

Few days ago it took almost 45 minutes to back up a 3.42GB droplet.
Doing another with even less storage used; still taking forever. It’s absurd, really.

I’m using a mounted CephFS drive for storage, as Volumes alone cannot be multi-mounted. Don’t know if it’s processing all files in network storage or what, but it’s slow.

Edit: This one “only” took around 30 minutes. For 2.95 GB.

One thing that doesn’t seem to be clear to everyone (I include myself in this, as the DO documentation is not that explicit) is what a snapshot is. a snapshot, as the name implies is an exact copy of your server at the moment you take it.

This means if you want to take a snapshot of a system when it’s switched off, you can do it, then you can immediately restart the system while you wait for it to complete.

There’s no need to leave it switched off, unless for some reason the work you are about to do post-snapshot requires it.

For example, if you want to make a change, you might want confirmation that the snapshot was successful before making the change, but there’s no need to leave the system switched off during that period unless the live system may have changes made that you can’t roll back in case of a failure. But in that case you might just put any apps in read only / maintenance mode rather than leaving it switched off.