How is a server snapshot different from a database backup job?

A DigitalOcean snapshot is a disk image kept in your DigitalOcean account. SnapShooter can schedule and retain supported snapshots. A separate backup job can copy chosen files or database data into compatible object storage.

A snapshot includes the disk it captures. A database on a separate service and uploads in another bucket need their own backup plan. Select a recipe that matches the resource you need to recover.

Where can you recover something from each kind of copy?

A restored DigitalOcean Droplet can start services from the copied disk as soon as it boots. Before creating it, verify that the new test server will be blocked from reaching live services on public and private networks from first boot and that live visitor traffic cannot be routed to it. If you cannot verify that boundary, keep the exercise on paper. DigitalOcean does not offer the snapshot itself as a download.

Recover files from a separately recreated resource after isolation is in place. A volume is a separate disk. Attach its recovered copy only to an isolated inspection server. A new name or a different web address does not prevent copied settings and scheduled jobs from reaching live services.

For a database backup job, locate the file in its storage and check the selected recipe’s restore format. Restore into an empty disposable database before planning a move. Keep any copy of the app disconnected from real customers, emails and payments.

What can you pay SnapShooter and your storage provider for?

Check the plan’s number of backup resources, frequency, retention and included storage. Backup jobs sent to your own object storage can add that provider’s costs. Native DigitalOcean snapshots are stored and priced separately by DigitalOcean.

Check the current account quote for the plan rather than assuming all jobs, backup sizes or schedules fit one allowance. Include the compute cost of creating an isolated restore copy.

Which copy would you choose for a lost server or a lost record?

Sketch one fictional server, its database and a separate upload bucket. Keep the entire walkthrough on paper with no connected cloud account.

Label each copy
Put a snapshot beside the server disk and a database job beside the sample records. Mark the upload bucket separately.
Plan the smallest useful restore
For one lost record, plan to inspect a database copy. For a lost disk, mark the public and private network restrictions and routing rules that keep a separate snapshot restore away from live services and visitors from first boot. Keep the restore on paper if you cannot verify that protection.
Write a check for each result
Name the file or record you expect to see. Draw how you would verify the network boundary and replace live app connections before allowing any restored service to reach the network.