Enabling backups for a Droplet adds 20% to the cost of the Droplet.
Backups are available for all Droplets across all regions.
Backups are taken once per week, and each backup is retained for four weeks.
DigitalOcean uses a snapshot-based backup system that will create a point-in-time image based on the current state of a Droplet. This process happens automatically within a pre-determined scheduling window, and is completed in the background while the Droplet is running. This provides system-level backups of your server without powering down.
The following process occurs on your Droplet when a backup occurs:
A crash-consistent backup allows the system to capture all of the data on disk exactly as it was at a single point in time. This means that the data will be backed up in a consistent state.
This is called a crash-consistent backup because it saves every piece of data that was committed to the disk at the moment that the snapshot occurs. The data saved is consistent with the data that would be available if the system crashed at that exact point and had to recover on boot.
Once you’ve enabled backups, they will be scheduled to occur weekly during a specific time window which is automatically assigned by DigitalOcean. To view the time window when your backups will start, navigate to your Droplet in the DigitalOcean Control Panel, and click the Backups link.
In the Backups block, there will be a line like this:
Backups are currently enabled. They are scheduled to start weekly Sunday 3 PM to Monday 2 PM.
Backups for your Droplet will start sometime during the specified time window, but depending on when the backup is started and how large of a disk is being backed up, it may not complete by the end of the window listed.
Backups are not encrypted at rest, but they are not externally accessible.
DigitalOcean’s automated backups do not include block storage volumes, but you can take manual backups with volume snapshots.
DigitalOcean backups are optimized for systems with low write activity. For systems with active database writes and other high I/O workloads, application-level backup may be more appropriate.
The snapshots that are taken to create the point-in-time data set use a copy-on-write mechanism. Copy-on-write allows for instant snapshots which make them a good choice for data consistency. There is almost no overhead for the actual creation of the snapshot that will be backed up.
However, copy-on-write implementations do take a performance hit on new writes that occur after the snapshot is taken until the backup process is complete. This happens because, for every new write, a system using copy-on-write must read the original data, write it to a new location, and then write the new changes to the original data location. This can significantly impact performance on busy, I/O bound workloads. The performance impact disappears when the snapshot is automatically deleted after the backup operation.
Databases are especially affected by this. Most database operations are heavily reliant on disk I/O, which can cause the application or the backup process to bog down and sometimes fail. In addition to the performance impact, operations that reside in memory or cache that has not been flushed to disk will be lost. Crash-consistent backups will always save what is on the disk, but never what is in memory or cache.
If you are running a database or another application that produces high I/O load, choosing an application-level backup method may be a better alternative, as many databases have backup solutions designed specifically to work with those systems.