You triggered the restore. The DigitalOcean dashboard shows it completed. Then you SSH in and something is wrong: the app won't start, the config is from the wrong date, or the IP you had in DNS is gone. The restore "worked" and you're still in trouble.
Restoring a Droplet is not complicated, but it has four or five gotchas that catch people at the worst possible moment. This article walks you through both restore paths (in-place and to a new Droplet), tells you exactly what changes after a restore, and gives you a validation checklist to run before you switch any traffic.
By the end you'll know how to restore a Droplet from a native backup or snapshot, what to check before calling it done, and how to handle the cases where the restore itself fails.
Why trust this article
We back up DigitalOcean every day. The failure modes we describe below are ones we see in practice, not ones we reconstructed from docs. If something here doesn't match what you're seeing, flag it. The environment changes and we keep these articles updated.
Restore in-place vs. create new Droplet
DigitalOcean gives you two ways to get your data back from a backup or snapshot. They are not the same operation, and the right choice depends on why you're restoring.
Restore in-place overwrites the current Droplet's disk with the backup image. The Droplet ID stays the same. The IP addresses stay the same. Everything on the current disk is gone. This is the right path when your current Droplet is broken (bad deployment, corrupted filesystem, failed OS update) and you want to roll it back to a known-good state without changing your network configuration.
Create a new Droplet from a backup or snapshot spins up a fresh Droplet using the backup as the source image. The new Droplet gets a new ID and new IP addresses. This is the right path when you want to test the restore before committing, when you need to restore to a different region, or when you're running the old and new environments side by side before a traffic cutover. If you're restoring as part of a cloud migration rather than a recovery event, the pre-migration backup guide covers what to lock in before you start the cutover process.
The decision tree is short:
- Current Droplet is broken and you want the same IPs: restore in-place.
- You want to test before committing, or you need a different region: create new Droplet.
- You need both environments running at the same time: create new Droplet, then destroy the old one when you're ready.
One thing to understand about DigitalOcean's native backup system: it stores backup images inside your DigitalOcean account, not on a separate platform. The restore paths below both pull from that same account-scoped storage.
If you're restoring from a snapshot rather than a scheduled backup, the process is identical from your side. The distinction is in how the image was created, not how it's restored. See DigitalOcean Droplet snapshots for the creation side.
What resets after a restore
This is where most people get surprised. A Droplet restore is not a transparent rollback. Certain things are rebuilt from the backup image; others are determined by the new Droplet or by DigitalOcean's infrastructure at the moment of creation.
The table below covers the elements that matter operationally.
| Element | In-place restore | New Droplet from backup |
|---|---|---|
| IPv4 address | Unchanged | New address assigned |
| IPv6 address | Unchanged | New address assigned (if enabled) |
| SSH host keys | Regenerated | Regenerated |
| Hostname | Unchanged | New (matches new Droplet name) |
SSH authorized keys (in ~/.ssh/authorized_keys) | Restored from backup | Restored from backup |
| Block storage volumes | Detached; must re-attach manually | Detached; must re-attach manually |
| DigitalOcean Firewall rules | Unchanged (rules are account-level) | Not applied; must assign manually |
| Floating IP assignment | Unchanged | Not assigned; must assign manually |
| DNS records | Not updated automatically | Not updated automatically |
| App-level data (databases, files, configs) | Restored to backup state | Restored to backup state |
| Droplet ID | Unchanged | New ID |
| Tags | Unchanged | Not applied; must assign manually |
A few things in that table deserve a closer look.
SSH host keys reset. When you restore a Droplet, the host keys are regenerated. If you have the old host key in your ~/.ssh/known_hosts on your local machine, your next SSH attempt will throw a host key mismatch warning. Clear the old entry with ssh-keygen -R <ip-address> before connecting.
Attached volumes are always detached. DigitalOcean does not include block storage volumes in Droplet backups or snapshots. The backup captures only the Droplet's root disk. After any restore, you'll need to re-attach any volumes that were previously connected. This is a known gap in native Droplet backup coverage, worth understanding before you assume your backup is complete.
Firewall rules and Floating IPs need manual reassignment on new Droplets. The rules still exist in your account; they just aren't applied to the new Droplet automatically.
IP address changes when restoring to a new Droplet. Update your DNS records, any firewall allowlists, and any client configs that hard-code the old IP before you switch traffic.
Step-by-step: restoring from a backup
This path covers native DigitalOcean backups (the weekly or daily automated images enabled as a paid add-on). You can trigger the restore from the dashboard or from doctl.
Via the dashboard
- Go to your Droplet's page in the DigitalOcean control panel.
- Click Backups in the left sidebar.
- Find the backup image you want to restore from. Each backup is labeled with the date and time it was taken.
- For an in-place restore: click the More menu next to the backup, then Restore Droplet. Confirm the dialog. The Droplet powers off, the disk is overwritten, and the Droplet reboots. Depending on disk size this takes a few minutes to ~20 minutes.
- For a new Droplet: click More, then Create Droplet. Configure the new Droplet (size, region, SSH keys), then create it. The new Droplet boots with the backup's state.
Via doctl
For scripted or automated restores, doctl is the right tool. First, get the backup image ID:
doctl compute snapshot list --resource-type droplet
That lists both snapshots and backups for your Droplets. Note the image ID for the backup you want. Then restore in-place:
doctl compute droplet-action restore
--droplet-id <your-droplet-id>
--image-id <backup-image-id>
--wait
Flag reference:
--droplet-id: the numeric ID of the Droplet to restore (find it withdoctl compute droplet list).--image-id: the numeric ID of the backup or snapshot image to restore from.--wait: blocks until the action completes and prints the final status. Without this flag the command returns immediately and you have to poll for status.
The doctl reference is at https://docs.digitalocean.com/reference/doctl/.
To create a new Droplet from the backup image instead:
doctl compute droplet create <new-droplet-name>
--image <backup-image-id>
--size s-1vcpu-1gb
--region nyc3
--ssh-keys <your-ssh-key-fingerprint>
Replace --size and --region with your actual target values. The --image flag accepts either the image ID or slug.
Step-by-step: restoring from a snapshot
Snapshot restores follow the same path as backup restores. The only difference is where you find the image. Snapshots live under Images in the DigitalOcean control panel, not under Backups on the Droplet page.
- Go to Images in the left-hand panel of the control panel.
- Click the Snapshots tab.
- Find the snapshot you want. Snapshots are labeled with the name you gave them at creation and a timestamp.
- For an in-place restore: click the More menu, then Restore to Droplet, and select the target Droplet. Confirm. The process is the same as a backup restore.
- For a new Droplet: click More, then Create Droplet.
With doctl, the command is identical to the backup restore (doctl compute droplet-action restore), because snapshots and backups are both image types in the DigitalOcean API.
Snapshots can be transferred between regions before restoring. If your target region is different from where the snapshot was taken, use More → Transfer on the snapshot first, wait for the transfer to complete, then restore. You cannot restore a snapshot in a region that doesn't have a copy of it.
If you're restoring a snapshot taken as part of an automated snapshot workflow, the snapshot list can get long. Use a consistent naming convention when you create snapshots (for example app-prod-2026-04-15) so you can identify the right one quickly under pressure.
Validating the restore before cutting traffic
Do not update DNS or switch load balancer targets before running these checks. A restore that looks complete in the dashboard can still have problems you'll only find by probing the service.
1. Confirm the Droplet is running
doctl compute droplet get <droplet-id> --format Status
The status should be active. If it's still off or new, wait and re-run.
2. Test SSH access
ssh-keygen -R <ip-address>
ssh root@<ip-address>
Clear the old host key first (the restore regenerates it). A successful SSH connection confirms the OS layer is intact and your authorized keys were restored from the backup.
Test SSH access before cutting DNS. If you update DNS first and SSH doesn't work, you're now locked out of a Droplet that isn't serving traffic correctly.
3. Check service health from inside the Droplet
Once you're in:
systemctl status <your-service-name>
journalctl -u <your-service-name> --since "10 minutes ago"
Look at logs, not just the active (running) status. A service can be "running" while failing every request because a config file or database connection string points to something that no longer exists in the restored state.
4. Check the date of the running config
Run a quick sanity check on the files you care most about:
ls -la /etc/your-app/
stat /etc/your-app/config.yaml
Confirm the modification time matches what you'd expect for the backup date. It's easy to restore from the wrong snapshot if your naming is inconsistent.
5. Smoke-test from outside
From your local machine or a separate server, hit the application directly by IP (before DNS is switched):
curl -I http://<new-ip-address>/healthz
Replace /healthz with whatever health or status endpoint your app exposes. An HTTP 200 here is the signal to proceed with DNS cutover.
6. Re-attach volumes and reassign Floating IPs
If the Droplet had block storage volumes attached before the restore, re-attach them now. Go to Volumes in the control panel, find each volume, and attach it to the restored Droplet. Then remount inside the Droplet:
mount /dev/disk/by-id/<volume-id> /mnt/your-mount-point
If you're using a new Droplet and it had a Floating IP, reassign it in the control panel under Networking → Floating IPs.
Only after all six checks pass should you update DNS or shift traffic.
When the restore fails
Most restore failures fall into a small set of patterns. Here's what to check.
The restore action errors in the dashboard. This usually means the backup image is corrupted or incomplete. Check whether the backup shows a warning in the Backups tab. If it does, that image cannot be used. Try the next oldest backup.
The Droplet comes back but the application won't start. The most common causes: (a) a config file references a database or external service that either doesn't exist at the backup's version or requires a credential that has since been rotated; (b) a volume that was mounted at backup time is no longer attached; (c) the restore captured the filesystem mid-write and a file is incomplete. Check journalctl for the exact error.
You can't SSH in after the restore. Clear your local known_hosts entry for that IP. If SSH is still refused, the restore may have left the Droplet in a bad network state. Use the DigitalOcean console (in-browser terminal in the Droplet's control panel page) to access the machine without SSH and diagnose from there.
The backup you needed is gone. Native Droplet backups are kept for four weeks and then deleted automatically. If the incident happened more than four weeks ago, the native backup won't be there. Snapshots persist until you delete them, so if you took a snapshot before a risky change, that's still available.
The restore worked but you're restoring to recover from an account-level incident. This is the hardest failure mode. If your DigitalOcean account is suspended, compromised, or the region you operate in has a major outage, the backup images inside that account may be unavailable at the same time as the Droplets they protect. If you can only restore from a snapshot inside your DO account, an account-level incident leaves you with no restore path at all. That's the argument for off-site backup outside DigitalOcean's infrastructure: storing a copy somewhere an account-level event can't reach. See same-host risk and compliance for a fuller treatment.
For a detailed troubleshooting flow specific to restore errors, see Droplet backup not restoring.
What to do next: if this was a production incident, run a post-restore review. Write down the backup date you restored from, which checks caught problems, and how long the whole process took. Then schedule a test restore for next month. The only way to know a restore will work under pressure is to have done it once when nothing was on fire.
If you've read this far, you probably already know whether native retention and in-account snapshots are enough for your project. If they aren't, SimpleBackups gives you cross-region off-site backup, automated verification, and a restore you can actually test.
Keep learning
- DigitalOcean backups explained: the full overview of what native backup covers and where it stops.
- How to automate DigitalOcean server and volume snapshots: scripting the snapshot workflow so you always have a recent restore point.
- What DigitalOcean native backup doesn't cover: gaps in Volumes, Spaces, and DOKS that the restore path above won't help with.
- The complete guide to DigitalOcean backup: the full hub, organized by backup type and use case.
FAQ
Does restoring a Droplet change its IP address?
It depends on the restore path. An in-place restore (overwriting the existing Droplet's disk) keeps the same IP addresses. Creating a new Droplet from a backup or snapshot assigns new IP addresses. Always verify which path you're taking before you rely on DNS staying correct.
Can I restore a Droplet backup to a different region?
Yes, but you need to transfer the snapshot or backup image to the target region first. From the control panel, go to Images, find the snapshot, and use the Transfer option. Once the copy exists in the target region, you can create a Droplet from it there. The transfer takes time proportional to the image size and is billed at the same rate as snapshot storage.
What happens to attached volumes during a restore?
Block storage volumes are not included in Droplet backups or snapshots. They are automatically detached when you restore a Droplet in-place, and they are not attached to a new Droplet created from a backup. After any restore, you need to re-attach volumes manually from the Volumes control panel and remount them inside the OS.
How long does a Droplet restore take?
It varies with disk size and current platform load. For small Droplets (25–50 GB root disk) the in-place restore typically completes in a few minutes. Larger Droplets (160 GB or more) can take 20 minutes or longer. Use doctl compute droplet-action restore --wait to block until the action completes rather than polling manually.
Can I restore a destroyed Droplet?
Only if you have a snapshot or backup image that was created before the Droplet was destroyed. Destroying a Droplet does not automatically delete its snapshots; they remain in your account until you delete them. Native scheduled backups, however, are tied to the Droplet and are deleted when you destroy it, unless you convert them to snapshots first. If you destroyed a Droplet and didn't have a snapshot, the data is gone.
This article is part of The complete guide to DigitalOcean backup, an honest, practical reference from the team that backs up DigitalOcean every day.