DigitalOcean Snapshots Guide 2026 — Backup and Clone Droplets

A practical guide to DigitalOcean Droplet Snapshots covering pricing, manual and scripted creation, restoring, and cloning Droplets with doctl.

Snapshots are a fundamental tool developers use to store system images of Droplets before making risky changes, or to clone environments for testing and scaling systems. This article explains how Snapshots differ from Backups and Custom Images, how actual pricing is calculated, and real doctl command methods to create, restore, and clone Droplets that work immediately.

How Snapshots Differ from Backups and Custom Images

DigitalOcean offers three types of Droplet image storage that often confuse users: Snapshots, Backups (a separate automatic feature), and Custom Images, each designed for different purposes. A Snapshot is a complete disk image copy of a Droplet at a specific point-in-time, created on-demand by the user via Control Panel, doctl, or API, covering the entire operating system, configuration, and all data files on the Droplet's disk at that moment. It's stored in the account until manually deleted, with no automatic expiration, and can be used both to restore the original Droplet or create new Droplets immediately. Backups, on the other hand, is a separate feature that must be enabled per Droplet, where the system automatically creates backup images at intervals set by DigitalOcean, not times chosen by the user, and stores only the latest set of backups according to platform policy. It suits a basic set-and-forget safety net approach, but doesn't fit cases where you need a snapshot at a specific point in time, such as before a major deployment. This feature incurs additional monthly costs separate from regular Droplet pricing and should be reviewed on the DigitalOcean pricing page before enabling. Custom Image is different again—uploading your own OS image files (formats like qcow2, raw, vhdx, vdi, or iso) into your DigitalOcean account to deploy Droplets with distributions or systems not available in the standard Marketplace. The key difference is that Custom Images are not derived from running Droplets in your account like Snapshots; they're files imported from outside. In short, choose based on your needs: use Snapshots if you want images at specific points in time under your control, Backups if you want basic automatic backup that requires no maintenance, and Custom Images if you want to bring your own OS into service. This article focuses primarily on Snapshots because it's the feature developers can control most granularly and use most frequently in real work.

• Snapshot = complete disk image at time of on-demand creation, stored until manually deleted
• Backups = separate automatic feature, enabled per Droplet, additional cost, stored at system-determined intervals
• Custom Image = upload your own OS image from outside, not derived from Droplets in your account
• Both Snapshots and Custom Images can be used to create new Droplets identically

Pricing: $0.06/GiB per Month

From multiple reviews, droplet Snapshot costs on DigitalOcean are charged at $0.06 per GiB per month, calculated from the space the snapshot actually uses after compression, not the full disk size the Droplet has. For example, a basic Droplet plan at $6/month (1 GiB RAM, 1 vCPU, 25 GB SSD), if the actual data used on disk after compression is about 10 GiB, the snapshot cost would be approximately $0.60 per month per single snapshot, not calculated from the full 25 GB SSD. Actual figures vary depending on data volume and compression ratio of each system, so you should check real numbers in your account's Billing page as the primary reference. An important point to watch is that costs are charged per snapshot. If you create multiple snapshots without deleting old ones, costs accumulate every month even if the source Droplet is already deleted, because snapshots are independent resources with completely separate billing from Droplets. One advantage is that DigitalOcean doesn't charge extra if you want snapshots ready to use across multiple regions simultaneously, making cross-region Droplet migration via snapshot cost-free. For teams using snapshots regularly, such as creating before every deployment or creating daily via cron, it's recommended to plan snapshot deletion alongside creation from the start, as it's a cost that often gets overlooked and resurfaces as an unexpected amount on monthly invoices. Check the total snapshots in your account via the doctl compute snapshot list command, which shows size and creation date of each one, helping you decide which to keep or delete. Note: All prices in this article reference DigitalOcean's pricing page as of July 2026. Always check the latest pricing on the provider's website before making actual usage decisions, as cloud providers adjust pricing periodically.

1. Rate $0.06/GiB/month calculated from actual space after compression, not full disk size
2. No additional charge for using snapshots across regions
3. Snapshots have separate billing from source Droplet—you still pay for snapshots even after Droplet is deleted
4. Use doctl compute snapshot list to check snapshot sizes and counts
5. Price data as of July 2026; check the latest pricing page before production use

Creating Snapshots Manually vs. Automatically

Snapshot creation has three main paths: via Control Panel, doctl (DigitalOcean's official CLI), and API directly. For Control Panel, go to the target Droplet page, select the Snapshots tab, click Take Snapshot, and give it a meaningful name that includes date and reason for creation. Via doctl, use the command doctl compute droplet-action snapshot 123456 --snapshot-name "web-01-2026-07-17" --wait, replacing 123456 with the Droplet ID (viewable via doctl compute droplet list). The --wait flag pauses until the process completes, making scripting easier. One critical caution is that you should power off the Droplet before creating a snapshot, especially Droplets running databases or files being written to continuously, because snapshots created while the Droplet is running risk capturing the filesystem in an incomplete state. Although DigitalOcean allows snapshots while running, powering off beforehand is the safest approach for workloads tolerating brief downtime. Regarding automation, DigitalOcean has no built-in custom snapshot scheduling feature. If you need automated snapshots at specific times, like every night at 2 AM, you must write scripts calling doctl or API via cron on a separate management server, or run via DigitalOcean Functions. A simple cron setup on a management server looks like: 0 2 * * * doctl compute droplet-action snapshot 123456 --snapshot-name "auto-$(date +\%Y\%m\%d)" --wait If you want convenience with no manual maintenance and can accept not choosing exact timing, use the Backups feature by toggling it on in the Droplet page instead, which incurs additional monthly charges as mentioned earlier.

• Create via Control Panel Snapshots tab, or doctl, or API
• Main command: doctl compute droplet-action snapshot <id> --snapshot-name "name" --wait
• Recommended to power off Droplet before snapshot, especially for database Droplets
• No built-in custom auto-snapshot scheduling—must use cron + doctl/API yourself
• Want automatic backup with no maintenance? Use the Backups feature instead

Restoring a Droplet from Snapshot

Restore from Snapshot works two main ways, depending on your goal. The first is restoring back into the original Droplet, which overwrites the entire disk with snapshot data while keeping the original IP address and network configuration. Do this via Control Panel on the Droplet page by selecting the Backups & Snapshots tab and clicking Restore, or via doctl with doctl compute droplet-action restore 123456 --image-id 987654321 --wait, where image-id is the snapshot ID (visible via doctl compute snapshot list). A critical limitation is that this restore type works only with snapshots created from that same Droplet—you cannot restore a snapshot from another Droplet over a different one. Additionally, the Droplet must be powered off before starting restore; the system will auto-shutdown if still on. During restore, the Droplet is unusable until completion, duration depending on snapshot size. The second approach is creating an entirely new Droplet using the snapshot as the base image, suitable when you want to keep the original Droplet alongside a new one before deciding, or want to change region/size at the same time. This is covered in the next section. Before deleting the original Droplet after restore completes, always verify the system works fully, such as checking services that should run, database data matching the snapshot's timeframe, and testing external connectivity, before declaring the system ready. Skipping verification is a common source of post-restore issues only discovered later.

• Restore to original Droplet = overwrites entire disk, keeps original IP, requires power off beforehand
• Command: doctl compute droplet-action restore <droplet-id> --image-id <snapshot-id> --wait
• This restore type works only with snapshots from that same Droplet
• Restore time depends on snapshot size

Using Snapshots to Create New Droplets (Clone/Scale)

From our hands-on testing — beyond restoring to the original Droplet, Snapshots can also serve as base images for creating entirely new Droplets, a more flexible approach since you can independently choose region, size (plan), and other settings from the source Droplet. Via doctl, use doctl compute droplet create web-02 --image 987654321 --region sgp1 --size s-2vcpu-4gb --ssh-keys <fingerprint>, replacing 987654321 with the snapshot ID and choosing region/size as needed. This fits three main real-world scenarios. The first scenario is cloning Droplets for staging or testing environments matching production exactly without rebuilding everything from scratch—simply snapshot production, then spin up a new Droplet from that snapshot to get identical environments instantly. The second is horizontal scaling using a pre-prepared golden image snapshot, spinning up multiple Droplets when traffic spikes, much faster than manual setup each time. The third is migrating Droplets across regions, such as from distant regions to sgp1 (Singapore), closest to Thai users, or blr1 (Bangalore) as a second choice, since normal resizing only works within the same region but can't cross regions—creating a snapshot and launching a new Droplet in the destination region is the standard method. After creating a new Droplet from snapshot, verify SSH keys, firewall rules, and VPC assignments are set correctly for the new Droplet, because not all of these auto-copy from the source—they need manual verification and reconfiguration per item before production use.

• Command: doctl compute droplet create <name> --image <snapshot-id> --region <region> --size <size>
• Clone environments for staging/testing identical to production
• Use as golden image for horizontal scaling multiple Droplets together
• Migrate Droplets across regions like to sgp1 (Singapore), closest to Thai users

When to Use This Feature (Real Use Cases)

Snapshots suit workloads needing rollback points you control timing on, more than serving as your sole backup system. The most common real use case is creating snapshots before risky changes: before OS version upgrades, before deploying large code changes that restructure databases, or before running migration scripts that modify large data sets. If problems occur, restore immediately to the pre-change point without debugging under time pressure. Another frequent case is preparing golden images for teams needing identically-configured new Droplets—install dependencies, adjust config, and complete security hardening once in a template Droplet, snapshot it, then use that as the base image for every new Droplet in the team, reducing setup time and environment inconsistencies. For teams cloning environments to test before actual production, such as testing security patches or testing scaling beforehand, Snapshots let you simulate production-identical environments without affecting live systems. For disaster recovery planning, Snapshots are part of the strategy but should pair with off-site backups, since snapshots stay within your DigitalOcean account—if account-level issues arise, they won't be your final fallback. Using Snapshots as your only backup long-term without manual retention management isn't suitable, as you must script cleanup yourself. In that case, the automatic Backups feature or application-level backup tools like pg_dump for databases are better fits.

• Before OS upgrades or risky code deployments
• Prepare golden images to reduce new Droplet setup time in teams
• Clone environments for testing before actual production launch

Common Mistakes and Solutions

In practice, the first common mistake is creating snapshots while Droplets running databases are still active and continuously writing, without stopping or flushing writes first, leaving snapshots in incomplete states. Restore may surface corrupted or incomplete database data. The fix is to power off the Droplet before every snapshot when possible, or minimally execute application-level flush/sync beforehand, such as temporarily stopping database services or using database-specific dump tools alongside. The second mistake is forgetting to delete old unused snapshots, especially in teams auto-creating snapshots daily via cron but without matching cleanup scripts, causing costs to accumulate silently month after month. The fix is writing retention policy scripts alongside creation scripts from the start, like keeping only the 7 most recent daily snapshots and auto-deleting older ones each cron run. The third mistake is misunderstanding Snapshots as a complete self-contained backup solution with automatic rotation and failure alerts like enterprise backup systems, when in reality Snapshots are basic mechanisms requiring all management yourself—frequency, storage, retention, and restore testing are all your responsibility. The fix is considering automatic Backups alongside Snapshots if you need some self-managing capability. The final common mistake is never testing restore from snapshots until a real emergency, only then discovering restore takes much longer than expected or that existing snapshots don't actually work due to unchecked problems. The fix is scheduling quarterly restore tests in test environments to confirm real RTO figures instead of guessed ones, giving confidence when actual recovery is needed.

• Snapshot while database is writing → incomplete data on restore—always power off or flush first
• Forget to delete old snapshots → costs accumulate—write retention scripts alongside creation scripts
• Mistake Snapshots for complete backup system—must manage retention/rotation yourself
• Never test restore beforehand—test quarterly to know actual RTO
• Forget SSH keys/Firewall/VPC verification after creating new Droplets from snapshots

Best Practices

The first practice is naming snapshots meaningfully with dates every time, using patterns like web-01-YYYYMMDD-reason so you can find and decide to keep or delete easily when many accumulate. Meaningless default names make it impossible to remember what each one is when reviewing later. The second practice is making snapshot creation application-consistent for Droplets running databases or critical state, not just basic power-off. Include steps to flush cache, sync disk, or temporarily stop services before every snapshot to guarantee data integrity after restore. The third practice is automating both creation and deletion via a single script with explicit retention policy via cron and doctl/API from the start, keeping daily snapshots for 7 days while separately preserving pre-event snapshots longer—not leaving it as manual work someone must remember to do. The fourth practice is always using Snapshots alongside other backup strategies, not as your sole safeguard. Critical data should be copied outside DigitalOcean too, like exporting to object storage in a different account or provider, to protect against account-level risks. The final practice is regularly testing restore and logging actual duration each time, so your team knows real RTO figures instead of guesses, and periodically checking total snapshots in the account via doctl compute snapshot list to control both costs and resource organization long-term.

• Name snapshots meaningfully with date + reason, like web-01-20260717-pre-upgrade
• Make snapshots application-consistent for database Droplets, not just power-off alone
• Automate both creation and deletion with clear retention policy via cron+doctl

Get $200 Free Credit →