DigitalOcean snapshots aren’t point-in-time backups, they’re disk images that can become backups.
Let’s see how this actually works. Imagine you have a Droplet, my-app-prod, running a critical web service. You want to automate taking daily snapshots and retaining them for a week.
First, you need to create a snapshot. You can do this via the API or the doctl CLI. Here’s how with doctl:
doctl compute droplet snapshot my-app-prod my-app-prod-2023-10-27 --snapshot-name "Automated Snapshot $(date +%Y-%m-%d)"
This command tells DigitalOcean to create a snapshot of the disk attached to the my-app-prod Droplet. The --snapshot-name flag ensures a unique, dated name for each snapshot, making it easy to track. The snapshot itself is a complete copy of your Droplet’s disk at that exact moment.
Now, for the automation. You’ll typically use a cron job for this. On your Droplet (or a separate management Droplet), you’d set up a cron entry like this:
0 2 * * * /usr/bin/doctl compute droplet snapshot my-app-prod my-app-prod-$(date +\%Y-\%m-\%d) --snapshot-name "Automated Snapshot $(date +%Y-%m-%d)" > /var/log/doctl_snapshot.log 2>&1
This cron job will run every day at 2 AM, executing the doctl command to create a new snapshot. The output is redirected to a log file, which is crucial for debugging.
Retention is where things get a bit more manual with DigitalOcean’s native snapshotting. You’ll need another script to clean up old snapshots.
Here’s a conceptual script to handle cleanup. You’d run this via another cron job, perhaps weekly:
#!/bin/bash
DAYS_TO_KEEP=7
SNAPSHOTS_TO_DELETE=$(doctl compute snapshot list --format "ID,Name" | grep "Automated Snapshot" | awk -v d=$(date -d "$DAYS_TO_KEEP days ago" +%Y-%m-%d) '$2 < d {print $1}')
if [ -n "$SNAPSHOTS_TO_DELETE" ]; then
echo "Deleting snapshots: $SNAPSHOTS_TO_DELETE"
for SNAPSHOT_ID in $SNAPSHOTS_TO_DELETE; do
doctl compute snapshot delete "$SNAPSHOT_ID"
done
else
echo "No old snapshots to delete."
fi
This script first lists all snapshots. It then filters for those with "Automated Snapshot" in their name and compares their date with a date calculated to be DAYS_TO_KEEP days ago. If a snapshot is older, its ID is collected. Finally, it iterates through the collected IDs and deletes them using doctl compute snapshot delete. The awk command is key here, comparing the date string in the snapshot name to the calculated cutoff date.
The surprising thing is that snapshots, while appearing like backups, are fundamentally disk images. Restoring from a snapshot creates a new Droplet, not an in-place recovery. This means your original Droplet continues to run while the new one is provisioned from the snapshot.
The core problem this solves is data loss prevention and disaster recovery. By automating snapshots, you ensure you have recovery points without manual intervention. The doctl CLI is the primary tool for interacting with DigitalOcean’s API programmatically, and cron jobs are the standard Unix way to schedule recurring tasks.
You control the frequency of snapshots (e.g., 0 * * * * for hourly) and the retention policy (e.g., changing DAYS_TO_KEEP). The naming convention is also a critical lever for automated management.
When you restore a snapshot, DigitalOcean creates a new Droplet. This new Droplet will have the same IP address as the original if you delete the original Droplet first. Otherwise, it will get a new IP. This distinction is crucial for any automated recovery process.
The next step is to explore creating Droplets directly from these snapshots, which is the actual disaster recovery mechanism.