You can create Persistent Disk and Google Cloud Hyperdisk snapshots at any time, but you cancreate snapshots more quickly and withgreater reliability if you use the following best practices.

Security considerations

To prevent unintended privilege escalation, ensure that you only grantsnapshot-relatedIAM permissions to principalsthat you trust to read and restore snapshot or instant snapshot data. Thefollowing permissions enable users to read and restore data from snapshots orinstant snapshots:

• compute.snapshots.useReadOnly
• compute.instantSnapshots.useReadOnly

Any principal that has one of the preceding permissions can restore data fromsnapshots or instant snapshots in your project to a project that they control,including a project that is in a different organization. For example, if a badactor were to obtain a snapshot IAM role in your project, they could restore thesnapshot in their personal project and access the data contained in thesnapshot.

To learn how to check the permissions a principal has, seeDetermine which principals have certain roles or permissions.

Preparing for consistent snapshots

If you create a snapshot of your Persistent Disk or Hyperdiskwhile your application is running,the snapshot might not capture pending writes that are in transit from memory todisk. Because of these inconsistencies, the snapshot might not reflect the exactstate of your application at the time you captured the snapshot. In thisscenario, the snapshot is consideredcrash consistent because it captures thestate of the application as if the machine crashed at the time the snapshot wastaken.

Optionally, you can pause the application, so that all applicationtransactions complete and the system can flush all pending writes from memoryto disk before the snapshot is captured. In this scenario, the snapshot isconsideredapplication consistent.

Creating crash consistent snapshots

When you take a snapshot of a Persistent Disk or Hyperdisk, you don't need totake any additional steps to make your snapshot crash consistent. In particular,you do not need to pause your workload.

If your workload cannot tolerate a temporary pause, consider the followingprocess for creating crash consistent snapshots:

1. Capture a snapshot while applications are running, assuming there will besome application data inconsistencies.
2. Verify that you canrestoreyour workload to an acceptable application state from the snapshot.
3. Based on the previous step, either retain or delete the snapshot.

Crash-consistent snapshots will likely require replaying file system andapplication-level journals before use. Thus the quality of your snapshotdepends on your application's ability to quickly recover from a crash-consistentstate back to serving.

Creating application consistent snapshots

• Windows Server users: For disks that are attached to WindowsServer instances, useVSS snapshots.
• Linux users: To achieve application consistency for snapshots of disksattached to Linux instances, create pre and post snapshot shellscripts to prepare your system for application consistency. Then create asnapshot with theguest-flush option enabled. This runs the pre andpost scripts before and after the snapshot is captured. For instructions, seeCreating Linux application consistent snapshots.

Manually creating application consistent snapshots

In some scenarios, you might need to manually pause your applications to achieveapplication consistent snapshots.

For example, use this option if you require application consistency betweenmultiple Persistent Disk or Hyperdisk volumes. In this case, you mustfreeze all of the file systems on each disk and complete all of the snapshotsfor those disks before you resume your apps.

You don't need to stop your VMs. The application pause can involve,for example, freezing and unmounting your file system. After you manually pauseyour applications, resume your workloads only after the snapshot resourcereaches theUPLOADINGstatus.

When you request a snapshot, check the status of the operation by calling theglobalOperations.get method.The following table shows the relationship between the status of the snapshotoperation and the status of the snapshot resource.

Snapshot frequency limits

There are limits to how frequently you can take a snapshot of a disk.

Creating snapshots from Persistent Disk or Hyperdisk

You can snapshot an individual disk at most 6 times every 60 minutes.

If the limit is exceeded, the operation fails and returns the following error:

"code": "RESOURCE_OPERATION_RATE_EXCEEDED","message": "Operation rate exceeded for resource 'projects/project-id/zones/zone-id/disks/disk-name'.Too frequent operations from the source resource."

This limit applies to the following operations:

• Creating snapshots of a Persistent Disk
• Creating snapshots of a Hyperdisk volume
• Creating images from a Persistent Disk
• Creating standard or archive snapshots from instant snapshots

This limit doesn't apply to the following operations:

• Create schedules for disk snapshots.Scheduled snapshots have separatefrequency considerationsand don't contribute to the snapshot frequency limit.
• Manually importing boot disk images

As a best practice, take a snapshot of the disk once per hour. Avoid takingsnapshots more often than that. The easiest way to achieve this is to set up asnapshot schedule.

Creating new zonal disks from snapshots

You can create a new zonal Persistent Disk or Hyperdisk from agiven snapshot per target zone at most 6 times every 60 minutes. The target zonerefers to the storage location of the new disk created from the snapshot.Google Cloud doesn't guarantee that you will be able to create disks from asnapshot at a rate faster than that, though you might be able to create disksmore frequently if you haven't created any disks from the snapshot in thepast hour.

Note that multiple snapshots of the same disks are considereddistinct snapshots with respect to this frequency limit.

If this limit is exceeded, the operation fails and returns the following error:

"code": "RESOURCE_OPERATION_RATE_EXCEEDED","message": "Operation rate exceeded for resource 'projects/project-id/global/snapshots/snapshot-name'.Too frequent operations from the source resource."

This limit applies to the following operations:

• Creating newzonal Persistent Disks from a snapshot

This limitdoes not apply to the following operations:

• Creating newregional Persistent Disks from a snapshot.
• Creating new zonal or regional Persistent Disks using an image as the source.

To create multiple disks from a snapshot, use the snapshot to create an imagethen create your disks from the image:

1. Create an image from the snapshot.
2. Create disks from the image.

For non-boot disks, follow the instructions tocreate persistent disks from the image and use the following steps:

• In the Google Cloud console, selectImage as the diskSource type.
• With the gcloud CLI, use theimage flag.
• If using REST, use thesourceImage parameter.

Use existing snapshots as a baseline for subsequent snapshots

If you have existing snapshots of a disk (Persistent Disk orHyperdisk), the system automatically uses them as a baseline forany subsequent snapshots that you create from that same disk.

• Create a new snapshot from a disk before you delete the previoussnapshot from that same disk. The system can create the newsnapshot more quickly if it can use the previous snapshot and reads only thenew or changed data from the disk.
• Wait for new snapshots to finish before you take subsequent snapshots from thesame disk. If you run two snapshots simultaneously on the samedisk, they both start from the same baseline and duplicate effort.If you wait for the new snapshot to finish, any subsequent snapshots run morequickly because they only obtain the data that has changed since the lastsnapshot finished.

Schedule snapshots during off-peak hours

If you schedule regular snapshots for your disks (Persistent Disk orHyperdisk), you can reduce the time that it takes to completeeach snapshot by creating them during off-peak hours when possible.

• Schedule automated snapshots during the business day in the zone where yourdisk is located. Snapshot creation typically peaks at the end ofthe business day.
• Schedule automated snapshots early in the morning in the zone where yourdisk is located rather than immediately at midnight. Snapshotcreation typically peaks at midnight.

Organize your data on separate disks

If you create a snapshot of a disk (Persistent Disk orHyperdisk), any data that you store on thedisk is included in the snapshot. Larger amounts of data create largersnapshots, which cost more and take longer to create. To ensure that you createa snapshot of only the data you need, organize your data on separatedisks.

• Store critical data on a secondary, or data, disk rather than your boot disk.This lets you create a snapshot of your boot disks only when necessary or ona less frequent schedule.
• If you create snapshots of your boot disks, store swap partitions,pagefiles, cache files, and non-critical logs on a separate disk.These files and partitions change frequently, and the snapshot process islikely to identify them as changed data that must be included in anincremental snapshot.
• Reduce the number of snapshots that you need to create by keeping similar datatogether on one disk. Keep your operating system and volatile dataseparate from the data that you want to snapshot, but you don't need todistribute your critical data across multiple disks like you wouldfor a physical machine. One large disk is able to achieve the sameperformance as multiple smaller disks of the same total size.

Enable thediscard option or runfstrim on your disk

On Linux instances, if you didn't format and mount your disks(Persistent Disk or Hyperdisk) with thediscard option, run thefstrim command on the instance before you create asnapshot. The command removes blocks that the file system no longer needs, sothat the system can create the snapshot more quickly and with a smaller size.To learn how to configure the discard option on your disks, seeFormat and mount a non-boot disk on a Linux VM.

Create an image of a frequently used snapshot

If you are repeatedly using a snapshot in the same zone to create adisk (Persistent Disk or Hyperdisk), save networking costs by usingthe snapshot once and creating an image of that snapshot. Store this image anduse it to create your disk and start a VM instance. For instructions, seeCreating a custom image.

As a best practice, take a snapshot of the disk once per hour. Avoid takingsnapshots more often than that. The easiest way to achieve this is to set up asnapshot schedule.

Other best practices

• Usejournaling file systems likeext4 to reduce the risk that data is cached without actually beingwritten to the persistent disk.
• Create a snapshot of your data on a regular schedule to minimize data lossdue to unexpected failure.

What's next

• Learn how tocreate disk snapshots.
• Learn how toview, list, share, and delete snapshots.
• Learn how tocreate schedules for disk snapshots.