How to back up Google Compute Engine disks with snapshots

Standard, archive and instant snapshots

Instant snapshots don't protect against zonal or regional failures, and Google tells you to pair them with standard snapshots. They work with Persistent Disk and most Hyperdisk types, but not Hyperdisk ML or Hyperdisk Throughput.

How incremental snapshots work

The first snapshot of a disk is full. Each later one stores only the blocks that changed and references earlier snapshots for the rest. Google occasionally takes a full image on its own to keep the chain reliable; you don't choose. If nothing changed, a snapshot's size is zero, which is normal.

Deleting a snapshot moves any data later snapshots need into the next one and discards the rest. Snapshots copy every block that was written and not discarded, so deleted files can still inflate them. Mount with the discard option or run fstrim regularly.

Create a snapshot in the console

1. In the Google Cloud console, go to the Create a snapshot page.
2. Enter a name and choose a Snapshot type: STANDARD (the default) or Archive.
3. Under Source disk, pick the disk. It can stay attached to a running VM.
4. Under Location, keep the default from your snapshot settings, or choose Multi-regional (higher availability, higher cost) or Regional (lower cost) and a location.
5. Choose Create.

Create a snapshot with gcloud

gcloud compute snapshots create web-1-boot-20261003 \
    --source-disk=web-1 \
    --source-disk-zone=us-central1-a \
    --storage-location=us-central1

• --source-disk and --source-disk-zone name the disk. For a regional disk, use --source-disk-region instead.
• --snapshot-type is STANDARD (the default) or ARCHIVE.
• --storage-location overrides the default: a region such as us-central1 or a multi-region such as us.
• --description and --labels help you find and clean up snapshots later; --async returns without waiting.

Instant snapshots have their own command and stay in the disk's zone:

gcloud compute instant-snapshots create web-1-pre-upgrade \
    --source-disk=web-1 \
    --zone=us-central1-a

You can snapshot one disk at most 6 times in 60 minutes. Google suggests about once an hour, through a schedule, since scheduled snapshots don't count toward that limit.

Application-consistent snapshots on Linux

By default a snapshot is crash-consistent: it captures what is on disk, not writes still in memory. For Persistent Disk on Linux, Compute Engine can run your own scripts around the snapshot when you pass --guest-flush.

1. Update the guest environment on the VM.
2. Save a pre script as /etc/google/snapshots/pre.sh and a post script as /etc/google/snapshots/post.sh, on every VM that needs this.
3. Enable the feature in /etc/default/instance_configs.cfg and restart the guest agent.
4. Create snapshots with --guest-flush. If a script fails or times out, no snapshot is created.

#!/bin/bash
sudo fsfreeze -f /data

#!/bin/bash
sudo fsfreeze -u /data

[Snapshots]
enabled = true
timeout_in_seconds = 60

sudo systemctl restart google-guest-agent.service

gcloud compute snapshots create web-1-data-20261003 \
    --source-disk=web-1-data \
    --source-disk-zone=us-central1-a \
    --guest-flush

timeout_in_seconds accepts 0 to 300 (default 60). fsfreeze blocks every process writing to that mount, so keep the scripts short; for MySQL you might flush tables instead. Hyperdisk doesn't support guest-flush: pause the application yourself, and resume once the snapshot reaches the UPLOADING status. Windows VMs use VSS through the same flag.

Schedule snapshots

A snapshot schedule is a resource policy. You create it in the disk's region, then attach it to disks. It creates standard snapshots only. This one runs daily at 04:00 UTC and keeps 7 days:

gcloud compute resource-policies create snapshot-schedule daily-7d \
    --region=us-central1 \
    --start-time=04:00 \
    --daily-schedule \
    --max-retention-days=7 \
    --on-source-disk-delete=keep-auto-snapshots \
    --storage-location=us-central1

• --start-time is UTC and on the hour; snapshots begin within that hour.
• Choose one frequency: --daily-schedule, --hourly-schedule=N (1 to 23; pick a divisor of 24) or --weekly-schedule=DAY.
• --max-retention-days (1 or more) deletes older snapshots, but only once a newer snapshot of the disk exists.
• --on-source-disk-delete: keep-auto-snapshots (the default) keeps everything if the disk is deleted; apply-retention-policy keeps expiring them.
• --guest-flush makes scheduled snapshots application-consistent, as above.

gcloud compute disks add-resource-policies web-1 \
    --resource-policies=daily-7d \
    --zone=us-central1-a

In the console, open the disk on the Disks page, choose Edit, and pick or create a schedule under Snapshot schedule, then Save.

• Up to 10 schedules per disk from gcloud or the API; the console attaches one.
• One schedule covers up to 1,000 disks; 1,000 in-use schedules per region.
• After creation you can change only the description, schedule, retention and labels.
• Start times can shift by an hour around US daylight saving changes. Avoid midnight, when snapshot demand peaks.

Where snapshots are stored

Unless you change it, Google stores snapshots in the multi-region closest to the source disk, such as us. Set another default in the project's snapshot settings, or pass --storage-location per snapshot. A snapshot in the disk's own region has no network charge for creating it or restoring it there; multi-regional storage survives a regional outage but costs more. You can't move an existing snapshot: a new location means a new, full snapshot. Snapshots are global by default, so you can restore them in any region.

Restore a snapshot

Restoring means creating a new disk; the source disk and the snapshot are untouched. The new disk must be at least the size of the original disk. If you make it larger, grow the file system afterwards.

gcloud compute disks create web-1-data-restored \
    --zone=us-central1-a \
    --source-snapshot=web-1-data-20261003

gcloud compute instances attach-disk web-1 --disk=web-1-data-restored --zone=us-central1-a

To rebuild a VM from a boot disk snapshot, pass --source-snapshot to instances create. --machine-type sets the size and --boot-disk-size can grow the disk. In the console: Create an instance, OS and storage, Change, the Snapshots tab.

gcloud compute instances create web-1-restored \
    --zone=us-central1-a \
    --machine-type=e2-medium \
    --source-snapshot=web-1-boot-20261003 \
    --boot-disk-size=20GB

You can create zonal disks from one snapshot at most 6 times an hour per zone. For many copies, make an image from the snapshot and create disks from the image.

Machine images for whole VMs

A snapshot covers one disk. A machine image captures a whole VM: configuration, metadata, permissions and every disk, crash-consistent across disks. Later machine images store only differences. Use one before a risky change to a VM with several disks.

gcloud compute machine-images create web-1-image-20261003 \
    --source-instance=web-1 \
    --source-instance-zone=us-central1-a

gcloud compute instances create web-1-clone --zone=us-central1-a --source-machine-image=web-1-image-20261003

What Compute Engine snapshots cost

Snapshots are billed on their compressed, incremental size, per second, with a 1-hour minimum for standard snapshots. As of October 2026, Google lists these rates for regional snapshots in us-central1 (Iowa):

Multi-regional storage costs more and adds upload and download charges within the multi-region. Creating or restoring a snapshot across regions adds network charges. Other regions have their own rates.

What Compute Engine snapshots don't protect against

Every snapshot, schedule and machine image belongs to your Google Cloud project.

• Project access. Anyone with the right IAM role can delete snapshots. Google warns that anyone holding compute.snapshots.useReadOnly can restore your snapshot data into a project they control.
• Deletion. Deleting an archive or instant snapshot is irreversible. A recycle bin for standard snapshots (in Preview) keeps deleted ones 3 days by default, configurable from 1 to 7.
• Losing the project or billing account. If you lose access to either, the snapshots go with the servers.
• Bad data. Snapshots copy corruption and ransomware faithfully. A restore test catches it.

Frequently asked questions

Can I snapshot a disk while the VM is running?

Yes. The snapshot is crash-consistent. For application consistency on Linux Persistent Disk, use pre and post scripts with --guest-flush, or pause the application yourself.

Are snapshots deleted when I delete the disk?

Standard and archive snapshots are not; instant snapshots are. Scheduled snapshots are kept indefinitely after the disk is deleted unless the schedule uses apply-retention-policy.

Can I restore a snapshot in a different region?

Yes, for the default globally scoped snapshots. Network charges apply when the restore crosses regions.

What is the difference between a snapshot and a machine image?

A snapshot backs up one disk. A machine image backs up a whole VM: every disk plus its configuration and metadata.