You noticed data missing. Or you need to roll back a bad migration. You open the DigitalOcean console, go to your Managed Database, click Backups, and see the oldest available restore point is from six days ago. The incident happened nine days ago.
That's the situation this article covers: the backup window has already closed.
The short version, before you read further: if the data is more than 7 days old, it is gone from DigitalOcean's native backup system. Support cannot get it back. What follows is how to confirm that, what else you might still find, and how to make sure this doesn't happen again.
Why 7 days is the hard limit
DigitalOcean Managed Database backups are automatic, daily, and included in the cluster price. That's genuinely convenient. The trade-off is a fixed retention window of 7 days, with no option to extend it through the dashboard or the API.
Every new daily backup rotates out the oldest one. Once a backup is 8 days old, it no longer exists on DigitalOcean's side. There is no archive tier, no cold storage, no "just this once" exception.
PITR (point-in-time recovery) is available on higher-tier Postgres and MySQL clusters. It gives you finer granularity within the window, letting you restore to a specific minute rather than just a daily snapshot. What it does not do is extend the window itself. PITR still operates within the same 7-day boundary.
Here is where each engine stands today:
| Engine | Plan tier | Backup schedule | Retention | PITR available |
|---|---|---|---|---|
| PostgreSQL | All | Daily | 7 days | Yes (higher tiers) |
| MySQL | All | Daily | 7 days | Yes (higher tiers) |
| MongoDB | All | Daily | 7 days | No |
| Redis | All | Daily | 7 days | No |
| Kafka | All | Daily | 7 days | No |
The 7-day rule applies to every engine, every plan. There is no exception documented in DigitalOcean's Managed Database offering.
For more background on how this backup mechanism works end to end, see how DigitalOcean native backup works.
What DigitalOcean support can do (not much)
The hard truth
7 days is the hard limit. No exceptions are documented. DigitalOcean support cannot extend retention or recover a backup that has already been rotated out.
Opening a support ticket is worth doing for one reason: to rule out edge cases. If there was a billing problem, a cluster migration, or a platform issue that affected how backups were stored, support can confirm that. They can also tell you exactly which restore points are still available.
What they cannot do is produce a backup that no longer exists. The documentation does not describe any internal archive or extended retention tier that support can access. If you're expecting them to pull a backup from the week before last, they won't be able to.
Open the ticket anyway. Describe the incident date and what you're looking for. If there's anything recoverable on DigitalOcean's end, they'll tell you. If not, you'll have a definitive answer quickly and can move on to other options.
Check if you have a logical dump somewhere
Before you accept that the data is gone, check for logical dumps you might have forgotten about. These are the most common places teams find something usable:
Application servers. If your app runs migrations, seeding scripts, or scheduled exports, some of those processes might have written a dump file to disk. Check /tmp, /var/backups, or any directory your deploy scripts touch.
CI/CD pipelines. Some teams run database tests against a copy of production. That copy might still be sitting in a CI artifact store, depending on your retention settings. Check your pipeline provider's artifact storage.
Developer machines. If someone ran pg_dump or mysqldump locally during debugging two weeks ago, that file might still be there. It's worth asking the team.
Staging environments. If staging is periodically refreshed from production, check when the last refresh ran and whether it predates your incident.
Monitoring and analytics tools. Tools like Datadog, New Relic, or custom dashboards sometimes read from the database and cache results. Not a substitute for a real dump, but occasionally useful for reconstructing what the data looked like.
Check if you have an old pg_dump or mysqldump sitting on a server, a dev machine, or a CI artifact somewhere. Even a stale dump from two months ago is better than nothing.
This search is worth doing thoroughly, even if you think the answer will be no. In our experience, teams discover usable dumps in unexpected places more often than they expect.
What's actually lost
If you've confirmed that no logical dump exists and the native backup window is closed, here's what's gone:
The data itself. Any rows, documents, or records that existed only in the database and were not captured in a dump, export, or event stream.
The ability to restore to a specific point in time before the window. Even PITR has a floor at whatever the oldest available backup is. Once that's gone, there's no anchor point for point-in-time recovery.
DigitalOcean's copy. There is no secondary storage tier to ask support to check. When the rotation happens, the backup is deleted.
What might not be lost, depending on your setup:
- Application logs that recorded the data in transit (useful for partial reconstruction).
- Event streams or message queues that captured database changes (Kafka, Debezium, or similar).
- Replicas with binary logs, if you configured one manually outside the native backup system.
If you're running a Managed Database with replication configured, check whether any replica captured the relevant state. This is uncommon in default setups but worth confirming.
The what DigitalOcean native backup doesn't cover article goes into more detail on the structural gaps, including why the same-host architecture makes recovery harder in this kind of scenario.
Preventing this next time: off-site dumps with longer retention
7-day retention means the backup from 8 days ago is gone. If you're reading this because you needed it, the answer is to set up off-site dumps with your own retention policy. Link to off-site compliance considerations for a broader picture of what that involves.
The approach that works for most teams has three parts.
Automated logical dumps. Schedule pg_dump, mysqldump, or mongodump to run on a separate server (not the database host itself). Run it daily at minimum. For production databases with active writes, run it more frequently.
Here is a minimal cron-based Postgres dump to a local file, as a starting point:
# Run daily at 02:00 UTC from a separate server
0 2 * * * pg_dump
--host=your-db-hostname.db.ondigitalocean.com
--port=25060
--username=doadmin
--format=custom
--file=/opt/backups/pg-dump-$(date +%F).dump
defaultdb
Replace the host, port, and database name with your actual values. Store the password in a .pgpass file or an environment variable, not in the cron line itself.
Off-site storage with your own retention. Upload the dump to a storage location outside DigitalOcean. DigitalOcean Spaces works, but an S3 bucket in a different provider adds a layer of separation. Set a retention policy that matches your recovery requirements: 30 days, 90 days, or longer.
A restore you've tested. A dump you've never restored from is not a backup. Run a restore into a staging database at least once a month. Confirm the row counts match, and that the application connects and behaves normally.
For a step-by-step walkthrough of the dump-and-restore cycle for MySQL specifically, see back up your DigitalOcean Managed MySQL database.
A full guide to setting up scheduled dumps with off-site storage for all Managed Database engines is in backup DigitalOcean Managed Databases. That article covers scripting, storage options, and how to handle large databases where a naive pg_dump | gzip pipeline can silently truncate on non-zero exit.
If you've read this far, you probably already know whether native retention is enough for your project. If it isn't, SimpleBackups gives you cross-region off-site backup, automated verification, and a restore you can actually test.
Keep learning
- Back up your DigitalOcean Managed MySQL database
- DigitalOcean backups explained
- Backup DigitalOcean Managed Databases
- Restore a DigitalOcean Managed Database
- What DigitalOcean native backup doesn't cover
FAQ
Can DigitalOcean extend managed database backup retention?
No. DigitalOcean's Managed Database backup retention is fixed at 7 days for all engines and all plan tiers. There is no dashboard option, API parameter, or support escalation path that extends it. The only way to get longer retention is to run your own logical dumps and store them off-site.
Is 7-day retention the same for all database engines?
Yes. Postgres, MySQL, MongoDB, Redis, and Kafka all operate on the same 7-day retention window. The only difference is that Postgres and MySQL offer PITR on higher-tier plans, which gives finer granularity within those 7 days. PITR does not extend the window.
Can I recover data older than 7 days from a Managed Database?
Not through DigitalOcean's native backup system. Once the backup is rotated out, DigitalOcean support cannot retrieve it. Your only options are a logical dump you made yourself before the incident, or data reconstructed from application logs, event streams, or replicas.
Does PITR extend the backup retention window?
No. PITR lets you restore to a specific minute within the existing 7-day window rather than just to a daily snapshot. The floor of PITR is still the oldest available daily backup. Once that backup ages out, PITR has no anchor point for that date.
How do I set up longer retention for my DigitalOcean database?
Run scheduled logical dumps using pg_dump, mysqldump, or mongodump from a separate server, and upload the output to off-site storage with a retention policy you control. Set the retention to match your recovery requirements (30, 90, or 365 days are common thresholds). Test restores periodically to confirm the dumps are valid.
This article is part of The complete guide to DigitalOcean backup, an honest, practical reference from the team that backs up DigitalOcean every day.