DigitalOcean home
  • Droplets
  • Spaces
  • Kubernetes
  • Tools & Integrations
  • One-click Apps
  • API Documentation
  • Community
  • Tutorials
  • Q&A
  • Projects
  • Meetups
  • Customers
  • Pricing
  • Docs
  • Support
  • DigitalOcean home
  • Products
    • Droplets

      Scalable compute services.

    • Spaces

      Simple object storage.

    • Kubernetes

      Run managed Kubernetes clusters.

    • Tools & Integrations

      Automate your infrastructure.

    • One-click Apps

      Deploy pre-built applications.

    • API Documentation
  • Customers
  • Community
    • Community Overview

      Connect, share and learn

    • Tutorials

      DevOps and development guides

    • Questions & Answers

      Development and systems Q&A

    • Projects

      Community-built integrations

    Get Involved
    Write for DOnations
    Join us at a Meetup
    Featured Post
    An Introduction to Kubernetes

    by Justin Ellingwood

  • Pricing
  • Docs
  • Support
    • Documentation

    • Contact Support

    • Network Status

  • Home /
  • DO-I-2398 /
  • New idea
414 Vote

Take a snapshot without shutting down

Find a way to enable snapshots to be taken without shutdown. It causes a lot of issues, especially with production projects.

  • Reese Jenner
  • Sep 11 2018
  • Shipped
DigitalOcean General
  • Sep 11, 2018

    Admin response

    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
  • Comments (32)
  • Votes (414)
  • Attach files
  • Dirk Postma commented
    11 Sep, 2018 06:41pm

    +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

  • Moisey Uretsky commented
    11 Sep, 2018 06:41pm

    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

  • Moisey Uretsky commented
    11 Sep, 2018 06:41pm

    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

  • Jeremy Price commented
    11 Sep, 2018 06:41pm

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

    ×

    Attachments Open full size

  • Alex Pole commented
    11 Sep, 2018 06:41pm

    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

  • Mikhail Emelchenkov commented
    11 Sep, 2018 06:41pm

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

    ×

    Attachments Open full size

  • Michael Hicks commented
    11 Sep, 2018 06:41pm

    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

  • Jeremy Price commented
    11 Sep, 2018 06:41pm

    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

  • Samuel Lewis commented
    11 Sep, 2018 06:41pm

    It takes like 5 minutes... why worry?

    ×

    Attachments Open full size

  • Jeremy Price commented
    11 Sep, 2018 06:41pm

    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

  • Ibrahim Benzer commented
    11 Sep, 2018 06:41pm

    thats a hiccup please solve this...

    ×

    Attachments Open full size

  • Heihachi commented
    11 Sep, 2018 06:41pm

    That is a MUST HAVE option.

    ×

    Attachments Open full size

  • Reese Jenner commented
    11 Sep, 2018 06:41pm

    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

  • Heihachi commented
    11 Sep, 2018 06:41pm

    +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

  • Anonymous commented
    11 Sep, 2018 06:41pm

    Need this ASAP

    ×

    Attachments Open full size

  • Richard Yao commented
    11 Sep, 2018 06:41pm

    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

  • Jeremy Price commented
    11 Sep, 2018 06:41pm

    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

  • Wayne Hartmann commented
    11 Sep, 2018 06:41pm

    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

  • Jeremy Price commented
    11 Sep, 2018 06:41pm

    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

  • rosanablao commented
    11 Sep, 2018 06:41pm

    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

  • Load older comments
  • +314
Log in / Sign up

Identify yourself with your email address

Subscribe

You won't be notified about changes to this idea.

Related ideas

Busy.b7e3690b94c43e444483fbc7927a6a9a
DigitalOcean home

© 2018 DigitalOcean, LLC. All rights reserved.
Proudly made in NY

  • Twitter
  • Facebook
  • Instagram
  • YouTube
  • LinkedIn
  • Glassdoor
Company
About
Leadership
Blog
Careers
Partner Network
Referral Program
Events
Press
Legal & Security
Products
Droplets
Spaces
Kubernetes
Tools & Integrations
One-click Apps
API
Pricing
Documentation
Release Notes
Community
Tutorials
Meetups
Q&A
Write for DOnations
Droplets for Demos
Hatch
Shop Swag
Research Program
Currents Research
Open Source
Support
Contact Support
FAQ
Network Status