Droplet backup restore error: Droplet must be powered off

Why the restore is rejected

The API returns Droplet must be powered off when a backup‑based restore is requested while the Droplet is running or when another backup/snapshot operation is still in progress. This is a safety guard because the restore overwrites the entire root disk; the platform cannot guarantee a consistent state while the system is active.

Confirmed facts

• The restore operation replaces the root disk with the exact image from the chosen backup.
• Any data written after the backup point is lost unless a separate snapshot exists.
• DigitalOcean does not perform automated checksum or consistency checks after a restore.
• Block storage volumes are independent resources; they are not included in the Droplet backup and are not automatically remounted.

Recommended procedure (in‑place vs. new Droplet)

1. Power off the source Droplet via the control panel or API (curl -X POST "https://api.digitalocean.com/v2/droplets/$DROPLET_ID/actions" -d '{"type":"shutdown"}' -H "Authorization: Bearer $TOKEN").
2. Choose a restore target:
   • If you can tolerate a brief downtime and want to keep the same IP, restore directly to the powered‑off Droplet.
   • If you need to validate integrity before cutting traffic, create a new Droplet from the same image/size and restore the backup to that new instance.
3. Initiate the restore (API example):

   curl -X POST "https://api.digitalocean.com/v2/droplets/$TARGET_ID/actions" \
         -d '{"type":"restore","image":"$BACKUP_IMAGE_ID"}' \
         -H "Authorization: Bearer $TOKEN"

4. Post‑restore verification (run on the restored Droplet, preferably via the recovery console):
   • Boot into recovery mode and run fsck -f /dev/vda1 (adjust device name as needed).
   • Compare checksums of critical files (e.g., sha256sum /etc/passwd /etc/group /var/www/html/index.php) against known‑good values from the backup.
   • For databases, run the appropriate consistency check (mysqlcheck --all-databases, pg_dumpall --schema-only, etc.) and verify that application can start without errors.
   • Check that services bind to the expected ports and respond to health‑check endpoints.
5. Block storage handling:
   • Detach the volume from the original Droplet (if still attached).
   • Attach it to the restored Droplet (curl -X POST "https://api.digitalocean.com/v2/volumes/$VOLUME_ID/actions" -d '{"type":"attach","droplet_id":"$TARGET_ID"}' -H "Authorization: Bearer $TOKEN").
   • Inside the restored Droplet, run fsck /dev/disk/by-id/scsi-0DO_Volume_volume-name and then mount it, verifying that /etc/fstab reflects the correct device.
   • Spot‑check files on the volume to ensure they match expectations.
6. Cut‑over:
   • If you restored to a new Droplet, update the floating IP or DNS record to point to the new instance’s IP.
   • Monitor traffic and application logs for a few minutes.
   • Once satisfied, power off and delete the original Droplet (or keep it as a cold standby).

Missing diagnostic detail

Do you already have a floating IP or DNS record configured for the service? If not, the recommendation to restore to a new Droplet may need to include steps for creating and assigning a floating IP before cut‑over.