You can create snapshots from disks even while they are attached to running
instances. Snapshots are
global resources,
so any snapshot is accessible by any resource within the same project. You can
also share snapshots
across projects. Note that snapshots are different from
public images and
custom images,
which are primarily used to create boot disks for instances or to
configure the boot disks for instance templates.

Important: If you create a VM instance from a disk snapshot based on a
Shielded VM
image, the original
integrity policy baseline
is lost and the first set of boot sequence measurements on the new VM
instance is used as the new baseline. Because
this new set of measurements is not verified, validate the VM
instance's boot integrity after restoring from a snapshot. You can do this by
manually examining the boot log and verifying that the proper keys are loaded into
the SecureBoot database, and that the expected kernel version is running. Also,
secrets saved in the vTPM on the originating VM instance are not accessible on
VM instances restored from a snapshot of that instance.

Snapshots are incremental and automatically compressed, so you can create
regular snapshots on a persistent
disk faster and at a much lower cost than
if you regularly created a full image of the disk. Incremental snapshots
work in the following manner:

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.

Compute Engine stores multiple copies of each snapshot across
multiple locations with automatic checksums to ensure the integrity
of your data. Use IAM roles
to share snapshots across projects.

A multi-regional storage location provides higher availability and might reduce
network costs when creating or restoring a snapshot. For example, creating a
disk from a snapshot stored in a multi-regional location does not incur network
costs as long as the new persistent disk is created in one of the regions of the
multi-regional group.
A regional storage location gives you more control over
the physical location of your data because you specify a single region.

If you do not specify a storage location for a snapshot, GCP 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.

Note: You cannot change the storage location of an existing snapshot. If you
need to move a snapshot from one region or multi-regional location to another,
you must create a new snapshot and specify its location, and delete the
previous snapshot. When you create a snapshot, you can only specify one
multi-regional location or one regional location. If you need to store a
snapshot in more than one location, you must create a snapshot in each 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
will be 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 will generate network costs.

Some example use cases for choosing a default location to store your snapshots are:

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 is us. In this case,
you wish to prioritize higher snapshot availability over potentially 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 application is deployed in a region that is not included in one of the
Cloud Storage multi-regional locations and you wish 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 application 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. This will
minimize networking costs for restoring and creating snapshots from that
source disk.

However, unlike a multi-regional storage location, a regional
storage location will not 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

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.

If your source disk's geographic storage
location is the same as its multi-region, there is no network charge.

For example, if your source disk is in asia-east1-a you can store your
snapshot in the asia-east1 region or the asia multi-region. You will not
incur a network cost when you access your snapshots.

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 the asia multi-region. To reduce costs, override
this default location and store your snapshots in the australia-southeast1
region.

If your source disk is in southamerica-east1, the default snapshot
storage location is in the us multi-region. To reduce costs, override
this default location and store your snapshots in the southamerica-east1
region.

If you restore a snapshot to a disk in a region that is not
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.

Creating a snapshot

In preparation for creating persistent disk snapshots, do the following:

Caution: If you attempt to create a snapshot from a zonal persistent disk and
the snapshotting process fails, you won't be able to delete the original zonal
persistent disk until you have cleaned up the failed snapshot. This failsafe
helps to prevent the accidental deletion of source data in the event of an
unsuccessful backup.

Create a snapshot of a regional persistent disk

After you have prepared the disk,
you can create a snapshot. When creating a snapshot of a regional persistent
disk, you must indicate the region where the disk is located.

Caution: If you attempt to create a snapshot from a regional persistent disk and
the snapshotting process fails, you won't be able to delete the original
regional persistent disk until you capture a clean snapshot. This failsafe
prevents the accidental deletion of source data in the event of an unsuccessful
backup.