DigitalOcean sells eight distinct products. Six of them appear in the navigation bar. Only three of them have any native backup at all. The other five ship with no scheduled backup, no restore point, and no recovery option built in.
If you assumed that "DigitalOcean backup" meant your whole account was covered, this article is for you. It maps exactly what each product does natively: what gets backed up, on what schedule, for how long, and what happens when the window closes. No marketing framing. Just the table you need before you decide whether native is enough.
Why trust this article
We back up DigitalOcean every day. The pattern we see is consistent: teams discover the gaps in native backup the hard way, usually at the moment they needed the data back. Everything in this article comes from operating the platform, not reading about it.
Droplet backups: what the 20% add-on gets you
Droplet backup is an opt-in paid feature. Enabling it adds 20% to your Droplet's hourly price. A $24/month Droplet costs an extra $4.80/month with backups on. It is not included by default.
When you enable it, DigitalOcean takes a disk image of the entire Droplet on a weekly schedule. You get four backup copies at any given time: the four most recent weekly images. After four weeks, each new backup replaces the oldest one. There is no way to keep more than four copies under the native feature.
The official documentation for Droplet backups confirms that backups are stored in your DigitalOcean account, in the same region as the Droplet. You cannot download a Droplet backup. You cannot transfer it to a different cloud provider. You can use it to restore the Droplet in-place or spin up a new one from it, but those are the only two operations. The Droplet restore guide covers both paths step by step, including what happens to your IP address and DNS after the restore completes.
What the backup captures: the Droplet's system disk at the time the backup runs. The backup is a full disk image, not an incremental. It does not capture attached block storage volumes. More on that in a moment.
What the backup does not capture: anything that changes between weekly runs. If you write three days of logs, database rows, and user uploads between Sunday night and the next Sunday night, a Droplet restore takes you back to Sunday. The intervening data does not exist in the backup. For stateful applications, a weekly backup window often does more to create a false sense of safety than to provide real coverage. The DigitalOcean backups explained guide covers this gap in plain terms.
Volumes are not included in Droplet backups. If your application stores data on an attached block storage volume rather than the Droplet's system disk, that volume has no native backup unless you snapshot it separately. This is probably the most common misunderstanding in the DigitalOcean backup space.
One important same-host note: every Droplet backup lives inside your DigitalOcean account. If the account is compromised, the backup goes with it. This is the defining limitation of all native DigitalOcean backup, not just Droplets. The off-site compliance article covers the full implications.
Premium Droplets and daily backups
Standard Droplets get weekly backups. Premium Droplets (the CPU-optimized, memory-optimized, and storage-optimized Droplets built on newer hardware) get daily backups at the same 20% add-on price.
The retention window stays the same: four copies. On a Premium Droplet with daily backups enabled, that means four daily backup images rather than four weekly ones. Your recovery point window shrinks from "up to a week ago" to "up to four days ago." That is a meaningful improvement for applications where a week of data loss would be unacceptable.
The 20% pricing and the four-copy retention cap apply equally. Premium Droplet backups are not more expensive per dollar of Droplet spend. You just get a tighter schedule for the same 20% premium.
If you are running a stateful application and a weekly backup window keeps you up at night, upgrading to a Premium Droplet tier to get daily backups is worth comparing against the manual snapshot approach below. The trade-off is cost (slightly higher Droplet tier) versus operational simplicity (automatic daily vs. manual on-demand). For a detailed cost breakdown of weekly versus daily backup pricing, see DigitalOcean weekly vs. daily backup costs. See backup DigitalOcean Droplets for a full walkthrough of both approaches and when to use each.
Droplet snapshots: the manual alternative
Snapshots are not the same as backups in DigitalOcean's terminology, though they are closely related.
DigitalOcean "backups" are the paid automatic weekly or daily disk images. DigitalOcean "snapshots" are manual on-demand disk images you trigger yourself. Both capture the full Droplet disk. The difference is scheduling, pricing, and retention. Backups are automatic, flat-priced at 20% of Droplet cost, and kept for four weeks. Snapshots are manual, billed at $0.06/GB/month, and kept until you delete them.
Snapshots give you more control. You trigger them when you need them: before a deployment, before a migration, after a significant data load. They do not expire automatically. You pay for storage as long as they exist.
The cost math matters. A 50 GB Droplet snapshot costs $3/month to store indefinitely. Four of them cost $12/month. Compare that to the 20% backup add-on: a $24/month Droplet pays $4.80/month for four auto-rotating backups. If you want more than four recovery points, snapshots let you keep as many as you are willing to pay for.
You can create a Droplet snapshot via the DigitalOcean dashboard or with the doctl CLI:
# Take an on-demand snapshot of a Droplet
# Replace DROPLET_ID with your numeric Droplet ID
doctl compute droplet-action snapshot DROPLET_ID
--snapshot-name "pre-deploy-$(date +%Y%m%d)"
--wait
The --wait flag blocks until the snapshot completes. Without it, the command returns immediately and the snapshot runs asynchronously. For scripted pipelines where the next step depends on the snapshot existing, always use --wait.
One constraint shared with backups: you cannot download a Droplet snapshot. You can transfer it to another DigitalOcean region, but you cannot pull it to external storage. It stays on the platform.
For a side-by-side comparison of when to use backups versus snapshots for Droplets, DigitalOcean snapshots vs. backups covers the decision in depth. The short version: use automated backups as your baseline, add snapshots at key moments, and treat both as an on-platform recovery layer rather than a complete strategy.
For teams automating snapshots across multiple Droplets or on a schedule, the guide to automating DigitalOcean server and volume snapshots covers the scripting approach using the DO API.
Volume snapshots: the part Droplet backups skip
DigitalOcean Block Storage volumes are independent of Droplets. They attach to a Droplet like an external disk. You mount them, write data to them, and they persist independently if you destroy the Droplet.
The catch: Droplet backups do not include attached volumes. If your database, your uploads directory, or your application data lives on a volume rather than the Droplet's root disk, the Droplet backup captured none of it.
Volume snapshots are the native answer. They work the same way as Droplet snapshots: on-demand, billed at $0.06/GB/month, kept until deleted, not downloadable.
You trigger a volume snapshot via the dashboard or doctl:
# List your volumes to find the volume ID
doctl compute volume list
# Take a snapshot of a specific volume
# Replace VOLUME_ID with the ID from the list above
doctl compute volume snapshot VOLUME_ID
--snapshot-name "vol-backup-$(date +%Y%m%d)"
Note that doctl compute volume snapshot does not have a --wait flag the same way Droplet snapshots do. The snapshot runs asynchronously. For scripted pipelines, poll the snapshot list to confirm completion.
The important implication: if your application writes to an attached volume, you need to coordinate two separate snapshot operations to get a consistent backup. The Droplet snapshot captures the system state, the volume snapshot captures the data volume. If those two operations run minutes apart, and your application was writing during the gap, you can end up with a Droplet image that references volume state that does not match the volume snapshot.
For consistency-critical applications, the correct approach is to quiesce writes before snapshotting, or to use application-level export rather than block-level snapshots. Backing up DigitalOcean Droplets covers the coordination approach in detail. When you need to recover a volume from a snapshot, the volume restore guide covers the exact steps and how to reattach the restored volume to a running Droplet.
Managed Database backups and PITR
Managed Databases are the strongest native backup story in the DigitalOcean catalogue. Daily backups are included in all Managed Database plans at no extra charge. Retention is seven days.
This applies to every Managed Database engine: PostgreSQL, MySQL, MongoDB, Redis, and Kafka. You do not pay extra for it. You do not configure a schedule. It runs automatically.
The backup mechanism is engine-dependent under the hood (DigitalOcean handles this), but from your perspective the interface is consistent: the last seven daily snapshots are available for restore via the dashboard or API.
What you cannot do: download those backups. You can restore to the existing cluster, restore to a new cluster in the same region, or fork the cluster from a point in time. You cannot pull the backup file to your own infrastructure.
# List available backups for a Managed Database cluster
# Replace DATABASE_ID with your cluster ID (found in dashboard or via doctl databases list)
doctl databases backups list DATABASE_ID
The output shows each backup with its creation time and size. You use a backup's timestamp in the restore command. Restoration is handled through the API or dashboard, not via a downloadable file you run locally.
Point-in-Time Recovery (PITR) is available on higher-tier PostgreSQL and MySQL clusters. PITR records the write-ahead log continuously, allowing recovery to any second within the seven-day window, not just the daily snapshots. The cost is higher: PITR-capable clusters sit at premium pricing tiers.
PITR does not extend the seven-day window. You can recover to any second in the last seven days, but not to day eight. If you need longer retention, you need to export your own backups in parallel. The managed database backup guide covers how to set up parallel exports alongside native retention.
Whether PITR is available on your cluster depends on the plan tier, not the database engine alone. If you upgraded to a plan after initial provisioning and the PITR toggle is not showing, check whether your cluster has been resized to a qualifying tier. The PITR documentation confirms which tiers qualify. [verify: confirm which specific Managed Database plan tiers include PITR before publish]
The seven-day retention cap is the main limitation. For regulatory or compliance requirements that call for 30, 60, or 90 days of backup history, native Managed Database backup alone does not satisfy the requirement. What DigitalOcean native backup doesn't cover covers this gap in detail. For the full walkthrough of how to initiate a restore, fork a cluster, and handle the connection string change that follows, see the Managed Database restore guide.
Spaces: the product with no backup at all
DigitalOcean Spaces is S3-compatible object storage. You use it to store files, media, static assets, and sometimes database exports. It is a common destination for off-site backup strategies. The irony is that Spaces itself has no backup of its own.
Spaces has no native backup. There is no scheduled copy, no automatic versioning, and no restore point. If you delete a file or overwrite it, it is gone.
This catches people because they often use Spaces as the destination for their backup jobs. The exports from their managed databases, their application archives, their off-site Droplet dumps: all of it lands in Spaces. So Spaces ends up holding the backup copies for the rest of the stack, while having no backup of its own. A bucket deletion event or a mistaken aws s3 rm --recursive wipes everything at once.
Versioning is available but off by default. Enabling versioning at the bucket level preserves previous versions of objects rather than deleting them on overwrite. But versioning is not backup: it does not protect against bucket deletion, and managing version lifecycles to prevent runaway storage costs requires additional configuration. You need explicit lifecycle rules to expire old versions, otherwise your storage bill grows indefinitely with every file update.
There is no cross-region replication built into Spaces. If your bucket's datacenter goes offline, your objects are unavailable until the datacenter recovers. There is no failover to a secondary region. DigitalOcean does not publish SLAs for Spaces durability in the same way AWS documents S3's eleven-nines figure. [verify: confirm whether DigitalOcean has published a Spaces durability SLA before publish]
The practical minimum for any production Spaces bucket that stores data you care about: enable versioning, configure a lifecycle rule that expires non-current versions after 30 days, and add an external replication job that copies the bucket to a separate cloud storage account. The replication step is the one most teams skip, and it is the only one that protects you from account-level events.
For teams storing critical data in Spaces, backing up DigitalOcean Spaces covers the available strategies: versioning configuration, cross-account replication using rclone or the AWS CLI, and when each approach is appropriate. The short version: if the data in your Spaces bucket would be painful to lose, versioning is a minimum, and off-account replication is the real protection.
DOKS: no native backup for persistent state
DigitalOcean Kubernetes (DOKS) has no native backup for cluster state, persistent volumes, application manifests, or Kubernetes secrets.
This is not a gap DigitalOcean is hiding. The Kubernetes model assumes you manage your own backup strategy. The platform provisions nodes and handles control plane operations, but stateful data on persistent volumes is your responsibility. The DOKS documentation does not promise any data protection for workloads running in your cluster.
The cluster's node configuration can be re-created via infrastructure-as-code if you manage your cluster definition in Terraform or a similar tool. But the data on persistent volumes, the values in Kubernetes Secrets, and the state of running workloads: none of that has a native recovery option. If a node pool is accidentally deleted or a namespace is wiped, there is no "restore from yesterday" button in the DigitalOcean dashboard.
The distinction between stateless and stateful workloads matters here. A stateless deployment (a web server, an API service, a batch job) can be restored by re-deploying its manifest and pulling its image. Stateless workloads on DOKS are resilient to cluster events if you have the manifests in version control.
Stateful workloads are different. A PostgreSQL StatefulSet, a Kafka cluster, an Elasticsearch index, a Redis instance with AOF persistence: these write data to PersistentVolumeClaims backed by DigitalOcean Block Storage. That data accumulates. After six months of production use, the PVC holds six months of state that cannot be re-created by re-running a deployment.
For teams running stateful applications on DOKS, Velero is the standard approach: it backs up Kubernetes resources and persistent volumes to an object storage backend you specify. Running Velero against DigitalOcean Block Storage persistent volumes requires the CSI driver and a configured snapshotLocation pointing to an S3-compatible destination. [verify: confirm Velero + DOKS PVC support for current DOKS version before publish]
The risk here is higher than it appears on a fresh cluster. A Postgres StatefulSet that has been running for six months holds six months of production data that has no backup unless you explicitly set one up. For a full treatment of the Kubernetes backup problem on DigitalOcean, backing up DigitalOcean Kubernetes covers Velero setup and the persistent volume considerations specific to DOKS.
For general Kubernetes database backup patterns that apply across any K8s environment, kubernetes database backup is a useful reference.
The retention table across the full catalogue
This table is the canonical summary. If you need to quote retention, pricing, or download capabilities for any DigitalOcean product to a colleague, a compliance auditor, or a post-mortem document, use this version.
| Product | Native backup | Schedule | Retention | Downloadable | Off-site |
|---|---|---|---|---|---|
| Droplet (standard) | Paid add-on (20% of Droplet) | Weekly | 4 weeks | No | No |
| Droplet (Premium) | Paid add-on (20%) | Daily | 4 weeks | No | No |
| Droplet snapshot | On-demand, $0.06/GB/mo | Manual | Until deleted | No | No |
| Volume snapshot | On-demand, $0.06/GB/mo | Manual | Until deleted | No | No |
| Managed Database | Included | Daily | 7 days | No | No |
| Managed DB (PITR) | Higher tiers | Continuous | 7 days | No | No |
| Spaces | None | N/A | N/A | N/A | N/A |
| DOKS | None | N/A | N/A | N/A | N/A |
Four things stand out in this table.
First, the "Downloadable: No" column is uniform. Every native backup mechanism in DigitalOcean's catalogue stores the backup on the platform and does not expose a download path. This is not an oversight: it is a design choice. It also means you cannot verify a backup's integrity without actually restoring it. If you want to test a restore, you have to spin up a new resource inside DigitalOcean to receive the restore. You cannot pull the backup file locally, run a checksum against it, or mount it on your own infrastructure.
Second, the "Off-site: No" column is also uniform. Every backup type in this article lives inside your DigitalOcean account. If the account is compromised, the backup goes with it. This is worth repeating because it affects every product on the list. What DigitalOcean native backup doesn't cover is the companion article that covers the full picture of native gaps including same-host risk.
Third, Spaces and DOKS have no native backup at all. If you use either product for production data, the native backup story is a blank cell. For Spaces, this means every object you store has zero redundancy against deletion unless you add external tooling. For DOKS, it means every PersistentVolume that accumulates data is unprotected unless you configure Velero or an equivalent.
Fourth, the retention window for Managed Databases (seven days) and Droplet backups (four weeks) are not configurable. You cannot ask DigitalOcean to keep Droplet backups for three months or database backups for sixty days. The retention caps are fixed at the platform level. If your compliance posture requires retention beyond those windows, you need to supplement native backup with your own export pipeline. This is the single most common reason teams find the native backup story insufficient in practice: they need 30 or 90 days, and the platform gives them seven or twenty-eight.
What to do with this information
You now have the full picture of what DigitalOcean's native backup provides. The practical question is whether it is enough for your specific stack.
For most teams, the native coverage is a starting point, not a complete strategy. Weekly Droplet backups and seven-day database retention are reasonable baselines. They protect against the most common scenarios: botched deployments, accidental deletions, application-level data corruption. For those scenarios, native backup is often fast enough and good enough.
The gaps open up when you ask harder questions. What happens if you need data from day ten? What happens if the account is suspended? What happens during a regional outage? What happens if a volume needs to be restored alongside its corresponding Droplet? These are the questions where native backup alone does not have a complete answer.
If you want to close those gaps without writing and maintaining the infrastructure yourself, that is the problem SimpleBackups for DigitalOcean was built to solve. The reason we built it is exactly the gap this article describes: native backup covers the easy part, and none of the hard part. It handles off-site exports for Droplets, Managed Databases, and Spaces, with alerts when a run fails and a tested restore path.
Keep Learning
- DigitalOcean backups explained: the high-level overview and a good starting point if this is your first time thinking through backup coverage.
- DigitalOcean snapshots vs. backups: the full decision framework for when to use each approach.
- What DigitalOcean native backup doesn't cover: the companion piece to this one, covering same-host risk, compliance gaps, and PITR retention limits in detail.
- How to automate DigitalOcean server and volume snapshots: scripting the manual snapshot process with the DO API.
- The complete guide to DigitalOcean backup: the hub page for this entire cluster.
FAQ
How often does DigitalOcean back up my Droplet?
It depends on the Droplet type. Standard Droplets with backups enabled receive one backup per week. Premium Droplets (CPU-optimized, memory-optimized, storage-optimized) receive one backup per day. In both cases, DigitalOcean retains the four most recent backups and discards older ones automatically. The backup add-on costs 20% of the Droplet price regardless of schedule.
Does DigitalOcean back up Spaces?
No. Spaces has no native backup feature. Bucket versioning is available and preserves previous object versions on overwrite, but it does not protect against bucket deletion and is off by default. There is no automatic cross-region replication. For production data stored in Spaces, you need to set up external replication or export jobs independently.
What's the difference between a DigitalOcean snapshot and a backup?
Both capture the full disk image of a Droplet. The differences are in scheduling, pricing, and retention. Backups are automatic (weekly or daily depending on Droplet tier), priced at 20% of the Droplet cost, and retained for four weeks before rotating. Snapshots are on-demand, billed at $0.06/GB/month, and kept until you delete them. Snapshots give you more control over timing and how many copies you keep; backups run automatically without intervention.
Can I download my DigitalOcean backup?
No. Neither Droplet backups, Droplet snapshots, volume snapshots, nor managed database backups are downloadable. They live on the DigitalOcean platform and can only be used for in-platform restores or to spin up new resources. This applies to all native backup types across the full DigitalOcean catalogue. If you need a backup you can download and store externally, you need to export your own dumps using tools like pg_dump or mysqldump and ship them to an S3-compatible destination.
Is PITR included with all Managed Database plans?
No. Point-in-Time Recovery is available on higher-tier Managed Database plans for PostgreSQL and MySQL. The specific qualifying tiers are documented in DigitalOcean's pricing pages. On plans that include PITR, recovery is possible to any second within the seven-day retention window. On plans without PITR, you can only restore to one of the daily backup snapshots. Retention is seven days regardless of whether PITR is enabled.
This article is part of The complete guide to DigitalOcean backup, an honest, practical reference from the team that backs up DigitalOcean every day.