If you've read the DigitalOcean backup docs, you probably walked away feeling reasonably covered. Droplet backups: enabled. Managed Database backups: included. Looks good.
Here's the problem. The docs describe what DigitalOcean does back up. They don't describe what it doesn't. And the list of things that don't get covered is longer than most people realize until they need a restore.
We back up DigitalOcean every day, across hundreds of customer environments. The gaps we see are consistent and predictable. This article names them, explains why they matter, and tells you what to do about each one.
Gap 1: Spaces has no backup at all
DigitalOcean Spaces is the platform's S3-compatible object storage. It is one of the most widely used DigitalOcean products. And it has zero native backup.
There is no scheduled backup. There is no point-in-time restore. There is no built-in replication to another region. If you delete a file in Spaces, or a bug in your application overwrites it, or a mistake wipes a prefix, that data is gone. The DigitalOcean Spaces accidental deletion guide covers what recovery looks like in practice and how to reduce the risk before an incident happens.
Versioning exists. But it is off by default on every bucket, and enabling it does not constitute a backup. A versioned bucket lets you recover a previous version of an object, but only if:
- You remember to enable versioning before the deletion or overwrite happens.
- The deletion itself was a soft delete (not a permanent delete that removes all versions).
- Your bucket lifecycle rules haven't expired the version you need.
Three conditions. Any one of them can fail.
Versioning on Spaces is available but off by default. Enable it immediately after creating any bucket that holds important data. Even then, plan for a backup to a separate storage destination. Versioning is not a substitute for off-site backup.
If your application stores user-uploaded files, logs, build artifacts, or database dump files in Spaces, none of that is protected by native tools. That includes the dumps that applications like SimpleBackups send to Spaces as a storage target: the dumps arrive there, but the bucket itself has no backup.
For a dedicated guide to covering this gap, see the upcoming how to back up DigitalOcean Spaces article.
Gap 2: DOKS persistent volumes are unprotected
DigitalOcean Kubernetes (DOKS) has no native backup for persistent volumes. There is also no native backup for manifests, secrets, or ConfigMaps.
This is a significant gap. Stateful workloads running on DOKS, things like databases deployed via Helm charts, file-processing queues, or message brokers that write to block storage, are not backed up by anything DigitalOcean provides out of the box.
The cluster configuration itself can be reconstructed from infrastructure-as-code if you keep it in source control. But the data inside a PersistentVolumeClaim (PVC) is not the same as the spec that created it. If the PVC is deleted or its data is corrupted, no native tool recovers it.
The typical remediation path is Velero, a Kubernetes-native backup tool that snapshots PVCs and cluster state and ships them to an external object store. But Velero requires setup, tuning, and ongoing maintenance. It is not a one-click option, and the DigitalOcean docs don't guide you through it.
For the full setup guide, see the upcoming how to back up DigitalOcean Kubernetes article. For general Kubernetes database backup patterns, this guide to Kubernetes database backup covers the conceptual model.
Gap 3: Volumes are not in Droplet backups
This one surprises a lot of people. When you enable Droplet backups, you might assume you are backing up your Droplet and its attached storage. You are not.
Block storage volumes are separate infrastructure units in DigitalOcean. They are not included in Droplet backups. If your Droplet has a 200 GB volume attached for data storage, that volume is entirely unprotected unless you also create volume snapshots separately.
Volume snapshots are manual operations billed at $0.06/GB/month. They are not scheduled automatically. There is no native tool that watches your volumes and creates daily or weekly snapshots on a schedule. You either write that automation yourself (the doctl CLI makes it possible, and there is a script-focused guide here) or you leave your volumes unprotected.
The practical scenario where this matters: you run a Droplet with the root disk and a separate volume for your application data or database files. Droplet backup is enabled. A restore event happens. You restore the Droplet and get the OS and application layer back. Your application data directory is empty.
It is worth noting that Droplet backups themselves have a significant limitation even for what they do cover: you cannot download them, you cannot move them off DigitalOcean, and you cannot restore them to a Droplet in a different account. Those constraints matter more than most people expect, which the later sections in this article address directly.
Gap 4: No cross-region replication
None of DigitalOcean's native backup options replicate data to a different region automatically.
Droplet backups stay in the same region as the Droplet. Volume snapshots stay in the same region. Managed Database backups stay in the same region. You can manually copy a Droplet snapshot to a different region using the DigitalOcean console or doctl, but this is a manual step, not a scheduled process, and it does not apply to Managed Database backups or Spaces.
The absence of cross-region replication means that a region-level incident, whether an outage, a data center failure, or a severe infrastructure event, affects both your production workload and your backup simultaneously. For most teams running non-critical workloads, this is an acceptable risk. For teams with compliance requirements or service-level commitments, it is not.
SOC 2 Type II, GDPR, and ISO 27001 all have provisions around backup storage and geographic separation. The specifics depend on your implementation, but "backup lives in the same region as production" is not a configuration auditors look at favorably. For GDPR-specific requirements around data residency and storage location for EU data, see the DigitalOcean GDPR compliance guide. For a deep dive on what off-site and cross-region backup means for compliance broadly, see the upcoming DigitalOcean off-site compliance guide, and for the mechanics of replication, the DigitalOcean cross-region backup article.
Gap 5: You can't download native backups
This constraint deserves its own section because the implications are wider than they first appear.
Neither Droplet backups, nor Droplet snapshots, nor Managed Database backups are downloadable. There is no export button, no API endpoint that returns the raw backup file, no path to getting the bytes off DigitalOcean's infrastructure.
Here is what that means in practice:
You cannot verify restores independently. Testing a restore means spinning up a new DigitalOcean resource. You cannot download the backup, spin it up locally, and confirm it works. This makes it harder to build a real restore-testing habit. Teams that can't easily test restores tend not to test restores.
You cannot migrate away without downtime. If you decide to move infrastructure to AWS or Hetzner or a private data center, you cannot use your DigitalOcean backups as the migration path. You need to export the live data, which requires a maintenance window or careful coordination.
You cannot maintain an independent copy. Regulatory requirements sometimes call for backup copies held by the organization itself, not by the cloud provider. Native DigitalOcean backups cannot satisfy this. The backup lives on DigitalOcean, managed by DigitalOcean, accessible only through DigitalOcean tooling.
For contrast, a pg_dump or mysqldump that you ship to your own S3-compatible storage is a file you own. You can download it, inspect it, restore it locally, archive it, and use it as a migration artifact. The understanding DigitalOcean backups explained article covers the full architecture of what native backup is and isn't. The upcoming how DigitalOcean native backup works article goes deeper on the internal mechanics.
Gap 6: Retention is short and non-negotiable
The native retention windows are fixed. You cannot extend them. You cannot pay more for a longer window.
| Product | Schedule | Retention |
|---|---|---|
| Droplet backup (standard) | Weekly | 4 weeks |
| Droplet backup (Premium) | Daily | 4 weeks |
| Droplet snapshot | Manual | Until deleted |
| Volume snapshot | Manual | Until deleted |
| Managed Database | Daily | 7 days |
| Managed DB (PITR) | Continuous | 7 days |
| Spaces | None | N/A |
| DOKS | None | N/A |
Seven days of Managed Database backup retention means that if a data integrity issue goes undetected for more than a week, you have nothing to restore to. Silent corruption, a bad migration, a bug that gradually modifies data in the wrong direction: all of these can stay hidden for longer than seven days. When that window closes, what happens when your DigitalOcean managed database backup expires covers your remaining options. If the window is still open and you need to act, the Managed Database restore guide walks through the native restore, fork, and dump-reimport paths.
Four weeks of Droplet backup retention means the same thing at the OS and application layer. If a compromised package or a malicious dependency starts doing damage in week three, your oldest backup is from week one.
Snapshots are technically indefinite because they persist until deleted, but they are manual. An indefinite-retention strategy based on snapshots only works if someone is manually creating snapshots on a schedule, which is an operational dependency rather than a backup policy.
If your compliance framework requires 30, 60, or 90 days of backup history, native DigitalOcean tools cannot satisfy that requirement without additional tooling. Off-site backups with configurable retention are the only path.
This connects directly to the backups vs. snapshots comparison: snapshots are point-in-time and tied to the platform, while proper backups give you portable, configurable, retainable copies of your data.
The real gap: same-account storage
The individual gaps above are significant. Each one represents a product or feature that native tooling doesn't address. But there is a structural issue underneath all of them that matters more.
The biggest gap isn't a missing product. It's that every native backup sits in the same DigitalOcean account as the thing it protects.
Same-host risk
When your backup lives in the same account as your production workload, any account-level event takes both the production data and the backup simultaneously. A compromised account, a billing dispute, a DigitalOcean support action, or an administrative mistake doesn't just affect your Droplets: it affects every backup, every snapshot, and every volume within that account.
Think through the scenarios where same-account storage creates a single point of failure:
Account compromise. If an attacker gets access to your DigitalOcean account, they have access to your backups. A ransomware-style attack can delete your Droplets and your Droplet backups in the same API call sequence.
Account suspension. Billing disputes, terms-of-service violations, and payment failures can result in account suspension. When an account is suspended, DigitalOcean may restrict access to resources including backups. You cannot access the backup to restore to a different provider while the suspension is active.
Accidental deletion. A doctl compute droplet delete --force run on the wrong target, a Terraform apply with a misconfigured resource, or a script with an overly broad selector can delete resources across an account. Deletion of a Droplet does not automatically delete its associated backups in most cases, but the proximity increases the risk of an operator mistake that catches both. If you find yourself in that situation, recovering a deleted DigitalOcean Droplet covers what options remain and where they fall short.
Billing-linked data retention. DigitalOcean's retention of backups is tied to the account status and the continued existence of the original resource. A lapsed account may not retain backups indefinitely. The exact behavior depends on the specific terms and support escalation path at the time.
The mitigation is conceptually simple: store at least one backup copy in a location that is independent of the DigitalOcean account. This is what "off-site backup" means in practice. The DigitalOcean off-site compliance guide covers the detailed architecture. For a summary of what off-site means in the context of the broader DigitalOcean compliance posture, the digitalocean-backup#off-site-compliance section of the hub covers it.
What to do about it
None of these gaps are unfixable. The table below maps each gap to the mitigation approach:
| Gap | Native workaround | Off-site solution |
|---|---|---|
| Spaces has no backup | Enable versioning (partial) | Back up Spaces to another S3-compatible store or Backblaze B2 |
| DOKS persistent volumes unprotected | None built-in | Velero with external object store |
| Volumes not in Droplet backups | Manual volume snapshots + scripted schedule | Off-site file or block backup via agent |
| No cross-region replication | Manual snapshot transfer (Droplets only) | Automated off-site backup with configurable region |
| Backups not downloadable | None | Logical backup (pg_dump, mysqldump, rclone) shipped to owned storage |
| Short, fixed retention | None | Off-site backup with configurable retention policy |
| Same-account storage | None | Backup to a separate cloud account entirely |
The common thread is "off-site backup to storage you own." For Managed Databases, that means a pg_dump or mysqldump or mongodump on a schedule, shipped to a bucket in a different cloud account. For Spaces, it means an rclone sync or a dedicated tool that mirrors the bucket to another location. For Droplets, it means an agent-based backup that ships files or a filesystem snapshot off-platform.
The scripting path for each of these is feasible but time-consuming. You write the backup script, set up the schedule, handle credentials rotation, configure alerts for failed runs, and maintain the whole thing as your infrastructure grows. The how to automate DigitalOcean snapshots guide shows what the manual path looks like for Droplets and volumes. If you want to compare the full range of tools available, see the guide to the best DigitalOcean backup tools for a rundown of the options across each product surface.
The reason we built SimpleBackups for DigitalOcean is exactly the gap this article describes: native backup covers the easy part, and none of the hard part. If you want off-site coverage for Droplets, Managed Databases, Spaces, and DOKS without writing any of it yourself, that's what it does.
FAQ
Does DigitalOcean back up my Spaces bucket?
No. DigitalOcean Spaces has no native backup. Versioning is available but off by default, and enabling it doesn't provide a full backup. Versioning only helps with soft deletes and overwrites, not with permanent deletions or bucket-level events. You need to replicate or export your Spaces data to a separate storage destination to have a real backup.
What happens to my backups if my DO account is suspended?
When a DigitalOcean account is suspended, access to resources including backups is restricted. You may not be able to access or export your backup data during the suspension. The exact behavior depends on the reason for suspension and the support resolution path. This is one of the reasons storing at least one backup copy outside your DigitalOcean account matters.
Can I move DigitalOcean backups to another provider?
No. Neither Droplet backups nor Managed Database backups are downloadable or transferable. Droplet snapshots can be copied to another DigitalOcean region but cannot be exported outside DigitalOcean. If you need portable backups, you need to create logical backups (pg_dump, mysqldump, file exports) and ship them to storage you control.
Are DOKS persistent volumes backed up?
No. DigitalOcean Kubernetes has no native backup for persistent volumes, manifests, or secrets. Stateful workloads on DOKS require a third-party solution such as Velero to create and store backups. The cluster configuration can be reconstructed from IaC, but the data inside PersistentVolumeClaims is not protected by any native DigitalOcean tool.
What's the maximum backup retention on DigitalOcean?
For Managed Databases, retention is 7 days and cannot be extended. For Droplet backups, four rolling snapshots are kept (weekly on standard Droplets, daily on Premium Droplets), covering approximately four weeks. Droplet and volume snapshots persist until you delete them manually but require manual creation. There is no native option for 30-, 60-, or 90-day retention on any product.
This article is part of The complete guide to DigitalOcean backup, an honest, practical reference from the team that backs up DigitalOcean every day.