GCP Snapshots Explained: Backup, Restore, Scheduling, and Snapshot vs Image
A GCP snapshot is a point-in-time backup of a Compute Engine persistent disk. If a disk gets corrupted, accidentally wiped, or you need to copy data to a new environment, a snapshot is how you recover. They are incremental after the first copy, which keeps storage costs low even when you snapshot frequently.
This page covers how snapshots work, when to use them, how to create and restore them using gcloud, how to set up automated schedules, and how snapshots compare to VM images. That last distinction confuses almost every beginner, so it gets its own section and table.
Simple explanation
Think of it like a photograph
Your disk is a notebook full of data. A snapshot is a photograph of that notebook taken at a specific moment. If someone later tears out pages or scribbles over them, you can look at your photograph and recreate what was there. You do not have to stop writing in the notebook to take the photo. Each new photo only captures what changed since the last one, so you are not reprinting the whole notebook every time.
Restoring always creates a fresh notebook from the photograph rather than overwriting the one currently in use. The original disk is never touched during a restore.
What a snapshot actually is
A Compute Engine snapshot is a stored copy of a persistent disk at a particular point in time. A few things to understand before going further:
- Snapshots work on persistent disks (pd-standard, pd-balanced, pd-ssd, pd-extreme). You cannot snapshot a local SSD because local SSDs are ephemeral by design.
- A snapshot is not a VM image. It captures disk data, not a bootable OS template. You cannot create a VM directly from a snapshot without an extra step.
- Restoring a snapshot creates a new disk. The original disk is not touched or overwritten.
- Snapshots are stored in Google’s snapshot storage, completely separate from your disk. Deleting a disk does not automatically delete its snapshots.
- Snapshots are billed by storage consumed, not by the full size of the source disk.
How snapshots work
The first snapshot of a disk copies all data to Google’s snapshot storage. Each subsequent snapshot copies only the blocks that changed since the previous one. GCP tracks the delta chain automatically.
When you delete an intermediate snapshot, GCP merges that snapshot’s incremental data into adjacent ones. No data is lost and the chain stays intact.
Think of snapshots as tracked changes in a document. The first save is the full file. Each subsequent save records only what changed. To restore any version, GCP replays the changes from the base. Deleting a middle version collapses two change sets into one without losing history.
Snapshots are crash-consistent by default. GCP captures whatever bytes were on disk at that exact moment, similar to what you would see after a sudden power cut. For most file workloads this is fine. For databases with in-memory write buffers (PostgreSQL, MySQL, and similar), a crash-consistent snapshot may contain a partially-committed transaction. Flush writes or pause the database briefly before snapshotting to get a clean result.
When to use snapshots
Snapshots are the right tool whenever you need a safety net for a disk. Common scenarios:
- Before risky maintenance. Resize a disk, upgrade the OS, or run a potentially destructive migration script.
- Before deleting or replacing a VM. Especially if the disk holds data you might need later.
- Regular scheduled backups. Automated daily or hourly snapshots with a retention window give you recovery points without manual effort.
- Disaster recovery preparation. Cross-region snapshots let you rebuild a disk in a different region if a regional failure occurs. See disaster recovery strategies for how snapshots fit into a broader DR plan.
- Cloning an environment. Create a snapshot of a disk and restore it to a new disk to duplicate a configuration for testing or staging.
- Migrating a disk to a different zone or region. Snapshots are global resources and you can create a disk from a snapshot in any zone.
Creating and restoring snapshots
# Create a snapshot of a disk (date-stamped name is a useful convention)
gcloud compute disks snapshot my-data-disk \
--zone=us-central1-a \
--snapshot-names=my-data-disk-snap-$(date +%Y%m%d)
# List snapshots in your project
gcloud compute snapshots list
# Describe a specific snapshot to see its size and status
gcloud compute snapshots describe my-data-disk-snap-20260307
# Restore: create a new disk from a snapshot
gcloud compute disks create my-restored-disk \
--source-snapshot=my-data-disk-snap-20260307 \
--zone=us-central1-a \
--type=pd-ssd
# Attach the restored disk to a VM for inspection
gcloud compute instances attach-disk my-vm \
--disk=my-restored-disk \
--zone=us-central1-a
# Delete a snapshot when it is no longer needed
gcloud compute snapshots delete my-data-disk-snap-20260307Restoring a snapshot creates a new disk. It does not overwrite the original. Attach the new disk to a VM, mount it, verify the data is there, then decide whether to swap it in as a replacement or just copy out the specific files you need.
Full restore flow
A complete restore typically follows these steps in order:
- Identify the snapshot you want using
gcloud compute snapshots list. - Create a new disk from that snapshot with
gcloud compute disks create. - Attach the restored disk to a VM (new or existing).
- Mount the disk inside the OS and verify the data is intact before doing anything else.
- If replacing a boot disk: stop the VM first, detach the old disk, attach the restored disk, then reboot.
A snapshot you have never restored is not a verified backup. It is a guess. Periodically create a disk from a snapshot, mount it, and confirm the data is readable. Untested backups tend to fail at exactly the wrong moment.
Automated snapshot schedules
Manual snapshots are easy to forget, especially before maintenance or during an incident. Snapshot schedules attach a recurring backup policy directly to a disk. GCP creates the snapshots on a defined cadence and automatically deletes snapshots older than your retention window.
# Create a snapshot schedule (daily at 02:00 UTC, keep 7 days)
gcloud compute resource-policies create snapshot-schedule daily-backup \
--region=us-central1 \
--max-retention-days=7 \
--on-source-disk-delete=keep-auto-snapshots \
--daily-schedule \
--start-time=02:00
# Attach the schedule to a disk
gcloud compute disks add-resource-policies my-data-disk \
--zone=us-central1-a \
--resource-policies=daily-backup
# Remove a schedule from a disk (does not delete existing snapshots)
gcloud compute disks remove-resource-policies my-data-disk \
--zone=us-central1-a \
--resource-policies=daily-backupThe —on-source-disk-delete=keep-auto-snapshots flag retains
automated snapshots even if the source disk is deleted. The alternative,
apply-retention-policy, deletes them when the disk is gone. For
disaster recovery, keeping snapshots after disk deletion is the safer choice.
The whole point is that a snapshot outlives the disk it came from.
Snapshots created by a schedule are labelled automatically with the schedule
name. You can filter them in gcloud compute snapshots list using
—filter=“labels.goog-snapshot-schedule=daily-backup”.
A good starting point for production disks: daily snapshots with a 7-day retention window. For databases or high-change systems, try hourly snapshots with a 3-day retention window to get finer recovery points without excessive storage. Match the schedule to your actual recovery point objective (RPO), not just what sounds reasonable.
Snapshot vs image
Snapshots and VM images are both stored disk representations, but they serve completely different purposes. Confusing them is one of the most common early mistakes with Compute Engine.
| Property | Snapshot | Image |
|---|---|---|
| Primary purpose | Backup and recovery of an existing disk | Template for creating new VM boot disks |
| What it captures | A point-in-time copy of a disk (any disk) | A complete, bootable disk state intended for reuse |
| Can launch a VM directly? | No. You must create a disk from it first. | Yes. Specify the image and Compute Engine creates the boot disk. |
| Incremental storage | Yes. Only changed blocks are stored in each subsequent snapshot. | No. Each image is stored as a complete disk copy. |
| Typical use case | Before maintenance, daily backups, cloning, DR | Golden VM templates, consistent fleet builds |
| Can you convert between them? | Yes. Create an image from a snapshot. | Yes. Take a snapshot of a disk built from an image. |
The short version: use snapshots for backup and recovery. Use images when you want a reusable template to launch new VMs from. If you want to go from backup to template, create a snapshot first, then create an image from it.
# Create an image from an existing snapshot
gcloud compute images create my-golden-image \
--source-snapshot=my-data-disk-snap-20260307
# Now you can create VMs from that image directly
gcloud compute instances create my-vm \
--image=my-golden-image \
--zone=us-central1-aCross-region snapshots and disaster recovery
By default, GCP stores snapshots in a multi-regional location based on where the source disk resides. You can override this to pin snapshot storage to a specific region, which is useful for data residency compliance or for ensuring recovery is possible even during a full regional outage.
# Store a snapshot in the EU for compliance or DR
gcloud compute disks snapshot my-data-disk \
--zone=us-central1-a \
--snapshot-names=my-data-disk-dr-snap \
--storage-location=eu
# Create a recovery disk in a different region from the stored snapshot
gcloud compute disks create my-dr-disk \
--source-snapshot=my-data-disk-dr-snap \
--zone=europe-west2-a \
--type=pd-balancedCross-region snapshots cost slightly more than same-region storage, but they are significantly cheaper than running a live replica disk in a second region. They are not a substitute for a high-availability architecture with live replication. Snapshots have a recovery point based on when the last snapshot ran, not real-time. For a broader view of how snapshots fit alongside other recovery options, see disaster recovery strategies.
If you are also working on cost, the Compute Engine cost optimisation page covers snapshot storage costs alongside disk rightsizing.
Snapshot permissions
Creating and restoring snapshots requires IAM permissions on both the disk and
the snapshot resource. The built-in roles/compute.storageAdmin
role covers full snapshot management. For more restricted access, use
predefined IAM roles or a custom
role scoped to only the permissions you need.
Key permissions to be aware of:
compute.disks.createSnapshot: create a snapshot from a diskcompute.snapshots.create: write a snapshot to storagecompute.snapshots.useReadOnly: create a disk from a snapshotcompute.snapshots.delete: delete a snapshot
Common beginner mistakes
Snapshotting a database disk without quiescing writes. GCP can snapshot a disk on a running VM, but the result is crash-consistent. If the database had buffered writes in memory, the snapshot captures a partially-committed state. For PostgreSQL, MySQL, or similar systems, flush buffers or pause writes before snapshotting. For stateless file storage, a live snapshot is usually safe.
Never testing restores. A snapshot that has never been restored is not a verified backup. Create a disk from a snapshot, mount it, and verify the data is readable before you actually need it in an incident.
Confusing snapshots with VM images. Snapshots are disk backups. VM images are boot templates. You cannot create a VM directly from a snapshot; you need to either create a disk from it or convert it to an image first.
Setting no retention window on schedules. Without a retention limit, snapshots accumulate indefinitely. Storage is cheap, but unchecked growth adds up. Set a retention window that matches your actual recovery window. Seven days is a sensible default for most systems.
Deleting snapshots to cut costs without understanding the chain. It is safe to delete individual snapshots; GCP merges data into adjacent ones. But deleting your entire snapshot history removes your ability to recover from anything older than the most recent one. Keep a rolling window rather than a single snapshot.
Treating snapshots as a complete DR strategy. Snapshots give you a recovery point, not zero downtime. If you need rapid failover, you need a live replica or a multi-region architecture. See disaster recovery strategies for how to combine snapshots with other tools.
Forgetting that scheduled snapshots survive disk deletion by default. Unless you use
—on-source-disk-delete=apply-retention-policy, scheduled snapshots persist after the source disk is deleted. This is usually the right behaviour, but review your snapshot list periodically for orphaned snapshots from disks that no longer exist.
Summary
- A snapshot is a point-in-time backup of a persistent disk, stored separately from the disk itself
- After the first full copy, each subsequent snapshot is incremental and only stores changed blocks
- Restoring a snapshot creates a new disk. The original is never overwritten.
- Snapshot schedules automate regular backups with configurable retention periods
- Snapshots and VM images are different: snapshots are for backup, images are for creating new VMs
- For databases, quiesce writes before snapshotting to avoid capturing a partially-committed state
- Always test restores. Verify you can actually recover from a snapshot before relying on it.
Frequently asked questions
Are GCP snapshots incremental?
Yes. The first snapshot copies the entire disk. Every snapshot after that stores only the blocks that changed since the previous one. GCP manages the delta chain automatically and you do not need to label snapshots as full or incremental. If you delete an intermediate snapshot, GCP merges its data into adjacent ones so the chain stays intact and no data is lost.
What is the difference between a snapshot and an image in GCP?
A snapshot is a point-in-time backup of an existing disk, used for recovery and cloning. An image is a boot disk template used to create new VMs. You cannot boot a VM directly from a snapshot; you must first create a disk from it. You can convert a snapshot into an image if you want to turn a backup into a reusable boot template.
Can I snapshot a running disk or running VM?
Yes. GCP can snapshot a disk while it is attached to a running VM. The result is crash-consistent, meaning it captures whatever was written to disk at that exact moment. For most workloads this is fine. For databases with in-memory buffers (PostgreSQL, MySQL), you should quiesce writes first to ensure the snapshot does not contain a partially-committed transaction.
Do snapshots affect disk or VM performance?
In most cases, no. GCP creates snapshots in the background without pausing the disk. There can be a brief period of elevated I/O during the initial snapshot creation on very active disks, but for typical workloads this is not noticeable. Scheduling snapshots during off-peak hours is still a reasonable practice for busy disks.
How often should I schedule snapshots?
For production systems, daily snapshots with a 7 to 14 day retention window is a common baseline. For critical databases or systems that change frequently, hourly snapshots with a shorter retention window gives finer recovery points. For dev or staging environments, weekly is often enough. Always match the schedule to your actual recovery point objective (RPO).