Snapshots incrementally back up data from your persistent disks. After you create a snapshot to capture the current state of the disk, you can use it to restore that data to a new disk. Compute Engine stores multiple copies of each snapshot across multiple locations with automatic checksums to ensure the integrity of your data.
You can create snapshots from disks even while they are attached to running virtual machine (VM) instances. The lifecycle of a snapshot created from a disk attached to a running VM instances is independent of the lifecycle of the VM instance.
Note that snapshots are different from custom images and machine images, which are useful for creating instance boot disks. To learn more, see the table comparing the use of images, snapshots, and instance templates.
Working with snapshots
To learn how to back up disks with snapshots, see Creating snapshots. You can create a snapshot of your disk before you attempt a potentially dangerous operation, so that you can revert the change in case your results are unexpected.
To learn how to restore the contents of a snapshot to a new disk, see Restoring snapshots.
If you no longer need a specific snapshot, you can reduce storage costs by deleting the snapshot.
To reduce the risk of unexpected data loss, consider the best practice of setting up a snapshot schedule to ensure your data is regularly backed up.
Accessing snapshots
Snapshots are global resources, so any snapshot is accessible by any resource within the same project.
You can also share snapshots across projects.
Restrictions
You cannot change the storage location of an existing snapshot. See Selecting the storage location for a snapshot.
You can snapshot your disks at most once every 10 minutes. If you want to issue a burst of requests to snapshot your disks, you can issue at most 6 requests in 60 minutes. For more information, see Snapshot frequency limits.
You cannot edit the data stored in a snapshot.
You cannot recover deleted snapshots.
How incremental snapshots work
Snapshots are incremental and automatically compressed, so you can create regular snapshots on a persistent disk faster and at a lower cost than if you regularly created a full image of the disk.
Incremental snapshots work as follows:
- The first successful snapshot of a persistent disk is a full snapshot that contains all the data on the persistent disk.
- The second snapshot only contains any new data or modified data since the first snapshot. Data that hasn't changed since snapshot 1 isn't included. Instead, snapshot 2 contains references to snapshot 1 for any unchanged data.
- Snapshot 3 contains any new or changed data since snapshot 2 but won't contain any unchanged data from snapshot 1 or 2. Instead, snapshot 3 contains references to blocks in snapshot 1 and snapshot 2 for any unchanged data.
This repeats for all subsequent snapshots of the persistent disk. Snapshots are always created based on the last successful snapshot taken.

Snapshot deletion
Compute Engine uses incremental snapshots so that each snapshot contains only the data that has changed since the previous snapshot. For unchanged data, snapshots reference the data in previous snapshots. Storage costs for persistent disk snapshots charge only for the total size of the snapshot.
When you delete a snapshot, Compute Engine immediately marks the
snapshot as DELETED
in the system. If the snapshot has no dependent snapshots,
it is deleted outright. However, if the snapshot does have dependent snapshots:
- Any data that is required for restoring other snapshots is moved into the next snapshot, increasing its size.
- Any data that is not required for restoring other snapshots is deleted. This lowers the total size of all your snapshots.
- The next snapshot no longer references the snapshot marked for deletion, and instead references the snapshot before it.
Because subsequent snapshots might require information stored in a previous snapshot, keep in mind that deleting a snapshot does not necessarily delete all the data on the snapshot. To definitively delete data from your snapshots, you should delete all snapshots.
If your disk has a snapshot schedule, you must detach the snapshot schedule from the disk before you can delete the schedule. Removing the snapshot schedule from the disk prevents further snapshot activity from occurring. You cannot delete a schedule that is attached to a disk. You have the option to manually delete snapshots at any time.
The following diagram shows this process:

Snapshot size and deleted blocks
Snapshots capture parts of the disk that were written to and not discarded.
Depending on the disk file system configuration, sometimes deleted files are not
discarded. If this happens, you might see that the size of your snapshot is
larger than the used space on the disk reported by the file system. To avoid
this, it is a best practice to enable the discard
option or run fstrim
on
your disk.
Snapshot chains
Using the gcloud CLI
or the Compute Engine API,
you can create snapshots in distinct snapshot chains by specifying a snapshot
chainName
. When you create multiple snapshots of a persistent disk using a
chain name, each snapshot is based incrementally on the last successful snapshot
created with that chain name. This is available in beta. Use this field only if
you are an advanced service owner who needs to create separate snapshot chains,
for example, for chargeback tracking.
Archive snapshots
When you create a snapshot, you have the option of creating a standard snapshot or an archive snapshot. Archive snapshots have the same benefits as standard snapshots including incremental chains, compression, and encryption. However, archive snapshots are lower-cost and are better suited for use cases related to compliance, audit, and long-term cold storage. If you require snapshot retention for many months or years and rarely need to access snapshots, consider using archive snapshots instead of standard snapshots. Each snapshot type is stored in separate incremental snapshot chains, and archive snapshots are listed separately in the Google Cloud console.
Snapshot storage location
When you create a snapshot, you can specify a storage location. The location of a snapshot affects its availability and can incur networking costs when creating the snapshot or restoring it to a new disk.
Snapshots can be stored in either one Cloud Storage multi-regional
location, such as asia
, or one
Cloud Storage regional location,
such as asia-south1
.
A multi-regional storage location provides the highest availability and resilience. A regional storage location gives you more control over the physical location of your data because you specify a single region.
A snapshot can be used to create a new disk in any region and zone, regardless of the storage location of the snapshot.
If you have an organization policy that includes the resource locations constraint, any snapshot storage location that you specify must be in the set of locations defined by the constraint. See Compute Engine resource locations for more information.
If you do not specify a storage location for a snapshot, Google Cloud uses the default location, which stores your snapshot in a Cloud Storage multi-regional location closest to the region of the source disk. If you need to choose regional storage, or if you need to specify a different multi-regional location, store your snapshot in a custom location.
Default location
If you do not specify a storage location, your snapshot is stored in the multi-region that is geographically closest to the location of your persistent disk.
For example, if your persistent disk is stored in us-central1
, your snapshot
is stored in the us
multi-region by default.
However, a default location like australia-southeast1
is outside of a
multi-region. The closest multi-region is asia
. Creating or restoring a
snapshot generates network costs.
Some example use cases for choosing a default location to store your snapshots include the following:
- The default multi-region location meets corporate or government data-placement policies.
- Your persistent disk is stored in a regional location that is part of a
default multi-region location. For example, your persistent disk is in
the
us-central1
region, so the default multi-region isus
. In this case, higher snapshot availability takes precedence at the risk of slower snapshot restoration performance. - You do not expect your snapshots to be frequently restored to disks that are located outside of the default snapshot storage location.
Custom location
Select a custom location to store your snapshot in a regional location, or if you need to specify a different multi-regional location.
Some example cases for selecting a custom storage location for your snapshots are:
- The custom multi-region location meets corporate or government data-placement policies.
- Your app is deployed in a region that is not included in one of the Cloud Storage multi-regional locations and you want to prioritize snapshot restoration performance over snapshot availability.
- You restore your snapshots multiple times from a disk located outside of the default snapshot storage location.
If you need to comply with corporate or government data-placement policies, store your snapshot in the nearest regional location that complies with these policies.
If your app is not deployed in part of a multi-region and you want to prioritize low networking costs over high snapshot availability, store your snapshot in the region where your source disk is located. Storing your snapshot in the region where your source disk is located minimizes networking costs for restoring and creating snapshots from that source disk.
However, unlike a multi-regional storage location, a regional storage location doesn't store your data redundantly across multiple data centers, so your data might not be accessible if a large-scale disruption occurs. To ensure the availability of your data, you might also want to store a redundant snapshot in a second location.
Network costs
Network charges apply for the creation or restore of all multi-regional snapshots when a disk is in a member region of the multi-region. If you don't require the additional replication and resilience of multi-regional snapshots, we recommend using regional snapshots by specifying a regional location when snapshots are created.
Selecting your snapshot storage location is vital to minimizing network costs. If you store your snapshot in the same region as your source disk, there is no network charge when you access that snapshot from the same region. If you access the snapshot from a different region, there is a network cost. Network costs are incurred when a snapshot is created in a different region from the source disk, and when a snapshot is restored to a disk in a different region from the snapshot.
There is a network charge for cross-region access. For example, if your source
disk is in asia-east1
and you store your snapshots in asia-east2
, you will
incur a network cost when you access your snapshot between those two regions.
Two regions, australia-southeast1
and southamerica-east1
, have a default
multi-region snapshot storage location that will incur network costs unless you
override the default when creating a snapshot:
- If your source disk is in
australia-southeast1
, the default snapshot storage location is in theasia
multi-region. To reduce costs, override this default location and store your snapshots in theaustralia-southeast1
region. - If your source disk is in
southamerica-east1
, the default snapshot storage location is in theus
multi-region. To reduce costs, override this default location and store your snapshots in thesouthamerica-east1
region.
If you restore a snapshot to a disk in a region that isn't included in the
snapshot's storage location you will incur a network cost. For example, if you
create a new regional persistent disk in australia-southeast1
from a snapshot
stored in asia
, a multi-regional location, you will incur network costs.
What's next
- Learn about working with snapshots.
- Learn about best practices for working with snapshots.
- Learn how to back up your disks regularly using scheduled snapshots.