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 of 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.
DigitalOcean backups are good for many situations, but not every use-case is well served by the design of the backup system.
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.
This is especially of concern with databases. Most database operations are heavily reliant on disk I/O, which can cause either the application or the backup process to bog down and potentially fail. In addition to the performance impact, any operations that reside in memory or cache that have 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 your server is running a busy database, or any other application that is heavy on disk I/O, DigitalOcean backups may not be a good fit for you. Check out the section towards the bottom on how to backup these types of applications and workloads.
If you are running a database or another application that produces high I/O load, choosing an application-level backup method is usually a more desirable alternative.
There are a number of backup solutions designed specifically to deal with the transactional nature of databases. Generally, if you are running a database that is accepting writes, you should be using backup solutions specifically designed to work with those systems.
If you are using MySQL or MariaDB as your database solution, you have a number of options depending on your configuration. Check out our article on backing up MySQL databases to find out about your options. Another option is to leverage Percona XtraBackup utility to perform live backups.
For other types of databases, read the project’s documentation to find out the recommended way to backup the data in a consistent way.
If DigitalOcean backups aren’t appropriate for your server due to high I/O, non-database workloads, there are some other solutions you can explore. One way is to replicate the filesystem using a technology like GlusterFS. This will allow you to sync files between two servers so that you can keep one online for clients while you turn off replication and back up the other server with conventional methods.