+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.

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

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

I want to give you my business but can't until this happens... shutdown for snapshots != production ready.

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!

Shutting down, seriously? Wow, I did not expect to find so much reefs in Digital Ocean :)

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.

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.

It takes like 5 minutes... why worry?

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.

thats a hiccup please solve this...

That is a MUST HAVE option.

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....

+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.

Need this ASAP

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.

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.

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.

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.

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