You clicked Restore. The spinner appeared. Then: nothing, an error, a new Droplet that boots to a blank disk, or a job that stalls for thirty minutes before failing silently. You are here because the backup exists but you cannot get the data back.
This article is a diagnostic tree. Work through it in order. Most restore failures have a specific cause, and most causes have a specific fix. We see these failures in support regularly, so the table below is drawn from the patterns that actually come up, not hypotheticals.
Check these first
Before assuming the backup is broken, verify the basics. These three checks resolve more problems than you would expect.
Is the Droplet in the right state?
A restore attempt on a Droplet that is in a locked or queued state will fail immediately. Check the Droplet's status in the dashboard or via doctl. It should show active before you initiate a restore. If it shows archive, off, or a pending status from a previous action, wait for that action to settle or power the Droplet on and off cleanly before retrying.
Is the backup listed in the correct region?
Droplet backups are stored in the same region as the Droplet. If you are trying to restore a backup to a Droplet in a different region than where the backup was taken, the restore may not appear in the list at all, or it may appear but fail during provisioning. The official documentation for Droplet backups confirms that cross-region restore is only possible by first transferring the backup image to the target region.
Are there conflicting actions in the events log?
This is the most useful first step, and the one most people skip.
Check the Droplet events log first. The events panel in the DigitalOcean dashboard shows the exact error code, which narrows the diagnostic tree by half. Go to your Droplet, click the "History" tab, and look at the most recent entries. The error code in that log is more useful than any generic error message in the restore dialog.
You can also inspect the action history from the CLI:
# List recent actions for a Droplet
# Replace <droplet-id> with your numeric Droplet ID (found in the dashboard URL or via doctl compute droplet list)
doctl compute droplet-action list <droplet-id>
The output includes each action's type, status (completed, errored, in-progress), and a timestamp. An errored status with action type restore tells you the job attempted and failed. An in-progress status on a previous action means the Droplet is still busy. You cannot start a new restore while an action is in progress.
Known DigitalOcean restore issues
Some failures are not configuration problems. They are known limitations or platform-level behaviors. Knowing which category you are in saves a lot of time.
The Droplet size is smaller than the backup image
If the backup was taken from a Droplet with more disk than the target Droplet, the restore will fail. DigitalOcean does not resize down during restore. The backup image cannot be written to a disk smaller than the source disk size at the time the backup was taken.
The fix: resize the target Droplet upward before attempting the restore, or create a new Droplet with a disk size equal to or larger than the source.
The backup image is from a different kernel configuration
This one is subtle. If the original Droplet was running on a custom kernel or a legacy kernel managed via DigitalOcean's old kernel management system (pre-2018 Droplets), restoring the image to a newer Droplet may produce a machine that cannot boot. The disk contents are correct but the boot configuration does not match the hypervisor expectations for the target.
Simultaneous account actions
DigitalOcean serializes certain account-level operations. If another team member is concurrently provisioning Droplets, transferring images, or running account-level API calls, a restore may queue behind those actions or time out. Check the account activity log, not just the Droplet's history.
The backup window is exactly at the rotation boundary
Droplet backups rotate after four copies. The oldest backup is deleted when the fifth is created. If you are trying to restore from a backup that was listed in the dashboard an hour ago but is now missing, it may have been rotated out. This is not a bug: it is the retention policy working as designed. Four weeks of weekly backups, four days of daily backups on Premium Droplets. If the backup you need is older than that window, it no longer exists on the platform.
When the restore silently creates a broken Droplet
The most confusing failure mode is a restore that appears to succeed but creates a Droplet that does not work correctly.
This happens when the restore job completes without error but the resulting Droplet has one of the following problems:
- Boots to a minimal rescue environment or blank shell
- Fails to reach the network (no SSH access)
- Starts but the application cannot find its data
The first thing to check in this scenario: whether the Droplet's data actually lived on an attached volume rather than the root disk.
Droplet backups capture the system disk only. If your application stored data on a block storage volume mounted at, for example, /data, that volume was not included in the backup. The restore gives you back the operating system and whatever was on the root disk at backup time, but the volume is either missing or has data from a different point in time depending on whether you snapshotted it separately.
This is the most common cause of "restore succeeded but nothing works" reports. The backup is not broken. The backup did exactly what it was supposed to do. The coverage was not what the operator expected.
The second scenario: the backup was taken from a running Droplet without quiescing writes. If your database was active when the backup ran, the backup captured a crash-consistent state, not a clean shutdown state. On restore, the database may go through crash recovery, which usually succeeds, or it may come up with a corrupted write-ahead log if the crash-consistency capture caught a partial write.
If you need to verify whether a backup captured your application data: look at the backup timestamp and compare it to when the data you need was last written. If the data was on a mounted volume rather than the root disk, the backup does not contain it regardless of the timestamp.
The third scenario: the restored Droplet has the wrong IP address and your application is hard-coded to the previous IP. The restored Droplet gets a new IP unless you associate a Reserved IP and re-assign it. Services that connect using the old IP will fail after restore.
What's recoverable and what isn't
The table below maps the most common failure symptoms to their probable cause and the available fix.
| Symptom | Probable cause | Fix |
|---|---|---|
| Restore button greyed out in dashboard | Another action is in progress, or Droplet is in a locked/archive state | Wait for the pending action to complete; check the Droplet events log |
| Restore job errors immediately | Target Droplet disk size is smaller than the backup image | Resize the target Droplet upward before restoring, or create a larger Droplet |
| Restore job stalls then times out | Account-level action queue contention, or a transient platform event | Retry after a few minutes; check the DigitalOcean Status page for ongoing incidents |
| Restore completes but Droplet won't boot | Kernel mismatch between old Droplet and new hypervisor configuration | Boot into recovery console; chroot into disk and reconfigure bootloader, or contact DO support |
| Restore completes but application data is missing | Data was on an attached volume, not the root disk | Restore the corresponding volume snapshot, or recover data from application-level backups |
| Restore completes but the backup you needed is gone | Backup rotated past the 4-copy retention window | No recovery path via native backup; requires off-site copy if one exists |
| Restore appears successful but SSH is unreachable | Reserved IP not re-associated, or firewall rules not re-applied | Re-assign Reserved IP; check cloud firewall rules are targeting the restored Droplet |
The last row in that table is the hardest one: when the backup you needed has already rotated out.
If the native restore path is broken and you don't have an off-site copy, this is a dead end. That's why it matters. The off-site compliance article covers why every production DigitalOcean stack needs a copy that lives outside the platform.
If you deleted the Droplet and are trying to recover from that situation rather than a failed restore, recovering a deleted DigitalOcean Droplet covers the specific paths and hard limits for that scenario.
Preventing this next time
Most restore failures are preventable. The patterns that generate them are consistent, and the interventions are straightforward.
Test the restore path before you need it. The most reliable way to know whether a backup is restorable is to restore it. Spin up a new Droplet from the backup once a month, verify the application comes up, then destroy the test Droplet. This catches volume-coverage gaps, kernel mismatches, and application configuration issues before they matter. The guide to automating DigitalOcean backup verification covers how to script this so it runs without manual intervention.
Snapshot volumes alongside Droplets. If your application data lives on attached block storage, take volume snapshots at the same time as Droplet snapshots. Keep them correlated by timestamp so you can restore both to a consistent point. A guide to backing up DigitalOcean Droplets covers the coordination approach in detail.
Use Reserved IPs for stateful Droplets. If you restore a Droplet to a new instance, the IP changes. Reserved IPs prevent this: the Reserved IP re-associates with the restored Droplet and your downstream configuration stays intact. This does not prevent restore failures, but it prevents the class of problems where the restore works but the application is unreachable because everything pointed at the old IP.
Understand what the four-week window means for your RPO. Standard Droplet backups give you four weekly copies. If your recovery point objective is shorter than seven days, weekly backups are not sufficient. If you need recovery to a point more than four weeks ago, the native retention window does not support that. How DigitalOcean native backup works covers this in full detail, including the Premium Droplet daily backup option for tighter RPO requirements.
Keep an off-site application-level backup in parallel. Block-level Droplet backups are useful for full-machine recovery. They are not a substitute for application-level exports that you can access independently of the DigitalOcean platform. A database dump shipped to external object storage takes less than a minute to configure and gives you a recovery path that is not contingent on the native restore button working.
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
- DigitalOcean backups explained: the high-level overview of what native backup covers and where it stops.
- How to automate DigitalOcean server and volume snapshots: scripting snapshot workflows with the DO API.
- How DigitalOcean native backup works: the mechanics behind Droplet backups, snapshots, and the retention caps.
- Restore a DigitalOcean Droplet: step-by-step restore walkthrough for when the process works.
- Backing up DigitalOcean Droplets: coverage strategies for root disks and volumes.
FAQ
Why does my Droplet backup restore fail?
The most common reasons are: the target Droplet's disk is smaller than the backup image, another action is in progress on the Droplet, or the backup was taken from a Droplet with data on an attached volume that was not included in the backup. Check the Droplet events log for the specific error code, which narrows down the cause faster than anything else.
Can I restore a backup to a different Droplet size?
Yes, but only upward. You can restore a Droplet backup to a Droplet with the same or larger disk size. You cannot restore to a Droplet with less disk space than the original. DigitalOcean does not shrink disk images during restore. If the target is too small, the job will fail immediately.
Does DigitalOcean support open restore tickets?
Yes. If you have a restore failure that you cannot resolve through the standard dashboard or CLI path, you can open a support ticket via the DigitalOcean control panel. For serious data loss situations, priority support is available on business and enterprise plans. Have the Droplet ID, the backup ID, and the action history ready before contacting support.
How do I check if my backup is corrupted?
You cannot inspect a Droplet backup directly. DigitalOcean does not expose a download or checksum endpoint for native backups. The only way to verify a backup is to restore it to a test Droplet and confirm the system comes up correctly. If the restore fails with a disk error rather than a configuration issue, that may indicate image corruption; open a support ticket with the action ID from the events log.
What should I do if the restore button is grayed out?
A greyed-out restore button usually means one of two things: another action is currently in progress on the Droplet (visible in the events log), or the Droplet is in a state that does not allow modification (such as archive or a pending resize). Check the Droplet's history tab for an in-progress action and wait for it to complete. If no action is in progress and the button is still greyed out, try a browser refresh; the dashboard occasionally caches stale state.
This article is part of The complete guide to DigitalOcean backup, an honest, practical reference from the team that backs up DigitalOcean every day.