Hi everyone,
I’m happy to share that the ability to create snapshots without having to power down your Droplet is now live via the cloud control panel as well as through the API. There are no changes to the API and you may simply hit the end-point to create a snapshot without having to first power down the Droplet.
For workloads with high disk I/O, you are still encouraged to shutdown your Droplet before taking a snapshot to maintain data consistency as the data may still be in memory and not fully flushed to disk. From a technical perspective this is similar to how backups are taken as described more in depth here: https://www.digitalocean.com/community/tutorials/understanding-digitalocean-droplet-backups#when-digitalocean-backups-may-not-be-the-best-solution
All feedback, comments, questions and concerns are welcome. Please feel free to email me directly at bschaechter@digitalocean.com.
Ben Schaechter
Product Manager, Droplet
+1 Nobidy wants *downtime*, esp. when the reason is making a backup!
Temporarily running another droplet is no easy option because... you need fresh data (a snapshot?) for that.
Attachments Open full size
There is no queuing system to the snapshots the issue with the variable amount of time it takes is due to the difference in amount of content that users may have placed on the server.
The more files, smaller files, etc that a server has the longer the snapshot takes to complete.
Thanks
Attachments Open full size
We're going to be working towards that in the future so that all snapshots and backups are processed from running droplets with minimal impact and while still retaining disk consistency on the taken snapshots.
Thanks
Attachments Open full size
I want to give you my business but can't until this happens... shutdown for snapshots != production ready.
Attachments Open full size
Agree that this should be top priority! Especially today where I find myself coming up on 2 hours of downtime waiting for a snapshot to process due to scheduler issues. Refunding downtime is one thing, but there is no way to refund time wasted when your customers are supposed to be working and can't bring their site back up or even cancel the snapshot!
Attachments Open full size
Shutting down, seriously? Wow, I did not expect to find so much reefs in Digital Ocean :)
Attachments Open full size
FWIW, I've noticed that my EC2 instance always reboots after I snapshot to AMI. I don't have to shut down beforehand, but I assume they are making that happen automatically as part of the AMI snapshot process.
Attachments Open full size
Michael Hicks: You're combining two separate operations. On AWS you can snapshot an EBS volume or create an AMI. Snapshotting is a low-level storage operation that doesn't affect the machine.
Creating an AMI _can_ reboot the machine in the process, but it isn't required. They recommend it but give you the option to do it w/o reboot if you're prepared to deal with possible data inconsistencies yourself.
Attachments Open full size
It takes like 5 minutes... why worry?
Attachments Open full size
Because I have clients who pay me to not bring down their websites multiple times a day. Because my DB server hasn't seen 5minutes of downtime in the last 6 months.. never mind 6x/day for 4hr snapshots.
Attachments Open full size
thats a hiccup please solve this...
Attachments Open full size
That is a MUST HAVE option.
Attachments Open full size
I am pleased you're looking into this - luckily my current project only has a couple of megabyte files, nothing major - still I will run bigger projects with Gigabytes of data... I can't have hours of downtime....
Attachments Open full size
+3 waiting for this functionality, because backups pricing is terrible (20% of total doplet cost!). So if you have 160GB droplet you are going to pay 192$ instead of advertised 160$ not fair.
Attachments Open full size
Need this ASAP
Attachments Open full size
Achieving this would require the use of a crash-safe filesystem in guests and a volume manager between the RAID stack and hypervisor. That is being done in FreeBSD right now with ZFS, Bhyve and UFS SU+J.
Doing this with KVM is possible, but the guest filesystem will need to change to support this, the backend stuff would need modification to support placement of the guest on a volume manager that supports instantaneous snapshots (my vote for ZFS) and the VMs would need to be migrated to it.
Digital Ocean would likely need to hire a Linux kernel hacker familiar with storage stacks to implement this. Incidentally, I am such a hacker, although I suspect my knowledge of the subject gives that away. Seeing something like this implemented in Linux would be really cool.
Attachments Open full size
Or i could put postgres into backup mode, sync the (which ever) FS, snap the FS, take postgres out of backup mode and go about my merry way.
Point is there are ways to mitigate the danger involved and for many those calculated risks are preferable than the downtime involved in having to turn off a machine and then wait for it to snap.
The ability should be there. Perhaps it should come with warnings that data integrity is the responsibility of the user, but it should be there.
Attachments Open full size
It would be a useful option, but as others have said, will require a lot of changes to implement. If your production servers are that vital you can't risk having scheduled downtime to do a snapshot during non-peak hours. Then you should be doing some sort of load-balancing / replication setup to begin with. I would be more worried about a hardware failure on the node your droplet resides on, before i would worry about scheduled downtime to take a snapshot.
Attachments Open full size
Replicas are not backups any more than RAID is, as any data-layer screw-ups/corruptions/compromises/etc.. will be propagated across the cluster.
Now tell me, is it quicker to to PITR recovery from a snapshot 4 hours ago or from one during these imaginary off-peak hours of which you speak?
This is not some far-out pipe-dream of a technology I'm asking for. Live snapshots are not a new thing. I should _not_ have to take a server down to snapshot the filesystem. I haven't had to in 4 years of working on AWS and as much as I like DigitalOcean and the people who work there, that feature, or lack thereof, is a showstopper for much of my workload.
Feel free to armchair-quarterback how I "should" be running my infrastructure, but I prefer not to shut down my servers unless the kernel needs updating or the hardware fails. If i wanted something I had to reboot all the time I'd run windows.
Attachments Open full size
Thankyou sis for the monopod n ipega bluetooth remote,.its super nice to make selfie pic end make easy to do,.for the next time shipment,.thankyou n Godbless
Attachments Open full size