Stay organized with collections
Save and categorize content based on your preferences.
This page provides an overview of the Google Cloud NetApp Volumes volume snapshots
feature.
About snapshots
NetApp Volumes helps you manage your data usage with snapshots
that can quickly restore lost data. Snapshots are point-in-time versions
of your volume's content. They are resources of volumes and are
instant captures of your data that consume space only for modified data.
Because data changes over time, snapshots usually consume more space as they
get older.
Considerations
Consider the following:
If you overwrite all of the data in a snapshot, then the snapshot consumes
significant volume capacity, which factors into
provisioning volume capacity.
Volumes with a typical rate of change of 1-2% daily and typical
snapshot schedules
generally need an additional 20% of capacity for storing snapshots.
Snapshot attributes
Snapshots have the following capabilities:
Instant capture: snapshots instantly capture data within a volume at an
exact point in time.
Space efficient: snapshots consume a small amount of data by only
overwriting modified or deleted data and maintain existing unchanged data.
Readable as a file system: all snapshots are easily accessible through
standard file system interfaces as read-only files for each point in time.
Creates clones fast: you can clone a volume within seconds. It takes the
same amount of time to create a new volume from a snapshot as it does to
create a new empty volume independent of volume or snapshot size. The clone is
a new volume and the storage pool needs sufficient free capacity to
accommodate it.
Fast restoration of snapshots: within minutes, you can restore a
volume to a snapshot version regardless of the volume size. Changes made to
volumes after snapshot creation are undone, which includes newer snapshots.
Types of snapshots
There are three types of snapshots:
Manual snapshots: snapshots you create and delete manually.
Scheduled snapshots: using scheduled snapshots, you can automatically
create or delete snapshots. You can recognize scheduled snapshots by their
name with the following format:
<schedule>-<timestamp>
<schedule>: hourly, weekly, or monthly
<timestamp>: appears in UTC (YYYY-MM-DD at HH:MM:SS UTC)
Internal snapshots: snapshots used by NetApp Volumes to
support replication and backup operations. Internal snapshots aren't manually
deletable. You can identify internal snapshots by their name. Depending on
how you view snapshots, internal snapshots can have different names:
In the Google Cloud console, Google Cloud CLI, and API responses, internal
snapshots use the replication-<timestamp> naming convention.
If you access a snapshot using NFS or SMB, internal snapshots use the
snapmirror.<uuid>.<timestamp>. naming convention.
Snapshot capacity
Consider the following about snapshot capacity before you use snapshots:
For most datasets, an additional capacity of 20% is enough to keep snapshots
for up to four weeks. As data gets older, its use for restorations becomes
less likely.
Overwriting all of the data in a snapshot consumes significant volume capacity,
which factors into provisioning volume capacity.
Snapshot schedules
Common snapshot schedules range from the following:
Hourly snapshots taken in a 48-hour time period
Daily snapshots taken during a 30-day time period
Weekly snapshots taken optionally during a 60-day time period
Hourly snapshot attributes
Hourly snapshots satisfy a recovery point objective of one hour.
Use cases for snapshots
The following section describes scenarios where you can use snapshots to address
data management challenges.
Application cloning: you can use the snapshot and application cloning
feature to allow more test iterations at faster speeds independent of clone
size and data structure.
Volume recovery: you can use snapshots with
NetApp Volumes backups
to recover individual files or directories if the data on the volume
is corrupted or deleted. Since snapshots only exist within the volume,
by themselves they don't offer complete protection from lost volumes.
Data versioning: snapshots help you keep multiple versions of the same
dataset accessible.
Application and data upgrades: before upgrading applications, you can use
NetApp Volumes to capture a snapshot of your data's current
state. Then if the upgrade fails, you are able to revert to the previous state
and recover your files.
Ransomware protection: NetApp Volumes helps defend against
data loss from ransomware attacks. Because snapshots are read-only and
not encryptable, they help defend against unwanted data encryption or deletion
from a compromised VM which might have the volume mounted. In the event
of a large data loss or compromise, you can use a snapshot to revert an
entire volume back to a previous state in seconds.
You can also create a usable volume clone from an older snapshot in order to
resume operations until your data is investigated for changes or corruptions
following a ransomware attack. Both options make all your data usable within
minutes.
Application-consistent recovery points: you can use
NetApp Volumes to take application-consistent snapshots, which
are snapshots taken after the operating system and application write the
current state of the data to storage. Application-consistent snapshots provide
a clear recovery point for the application and can be used to create a
consistent clone of the application. Because snapshots are read-only
accessible through the client, users can restore data immediately, which
provides a substantial recovery time objective improvement.
Crash-consistent snapshots: you can also use crash-consistent snapshots to
recover data, which works well for a majority of applications. However, some
data in storage might not be current at the time of recovery because it's kept
in operating system and application caches for some time before it's written
to storage.
Logical space use: NetApp Volumes space usage reflects
the data in the active file system and deleted blocks that snapshots retain.
NetApp Volumes frees the retained snapshot blocks as soon as
the latest snapshot that references the blocks is deleted. Your volume
continues to consume provisioned space, which includes deleted data your
snapshots retain.
Snapshot space use example
The following example provides details on how to manage a snapshot space
requirement:
A user provisions a 5 TiB volume and writes 3 TiB of data into the volume.
Result: The client sees 2 TiB of free space.
The client creates a snapshot and then deletes 1 TiB of data.
5 TiB volume - 2 TiB user data - 1 TiB snapshot data
Result: The client continues to see only 2 TiB of free space. This is
because the system needs to retain 1 TiB of deleted data that is referenced
by the snapshot. That capacity is counted against the allocated capacity.
NetApp Volumes deletes the snapshot.
Result: 1 TiB of snapshot data is freed, and the client sees 3 TiB of
free space.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[],[],null,["# About volume snapshots\n\nThis page provides an overview of the Google Cloud NetApp Volumes volume snapshots\nfeature.\n\nAbout snapshots\n---------------\n\nNetApp Volumes helps you manage your data usage with snapshots\nthat can quickly restore lost data. Snapshots are point-in-time versions\nof your volume's content. They are resources of volumes and are\ninstant captures of your data that consume space only for modified data.\nBecause data changes over time, snapshots usually consume more space as they\nget older.\n| **Important:** Snapshots aren't copies of your data. If you want to make copies of your data, consider using the NetApp Volumes backups or volume replication features. For more information, see [NetApp Volumes backups overview](/netapp/volumes/docs/protect-data/about-volume-backups) and [NetApp Volumes volume replication overview](/netapp/volumes/docs/protect-data/about-volume-replication).\n\nConsiderations\n--------------\n\nConsider the following:\n\n- If you overwrite all of the data in a snapshot, then the snapshot consumes\n significant volume capacity, which factors into\n [provisioning volume capacity](/netapp/volumes/docs/configure-and-use/volumes/overview#space_provisioning).\n\n- Volumes with a typical rate of change of 1-2% daily and typical\n [snapshot schedules](/netapp/volumes/docs/configure-and-use/volume-snapshots/overview#snapshot_schedules)\n generally need an additional 20% of capacity for storing snapshots.\n\nSnapshot attributes\n-------------------\n\nSnapshots have the following capabilities:\n\n- **Instant capture**: snapshots instantly capture data within a volume at an\n exact point in time.\n\n- **Space efficient**: snapshots consume a small amount of data by only\n overwriting modified or deleted data and maintain existing unchanged data.\n\n- **Readable as a file system**: all snapshots are easily accessible through\n standard file system interfaces as read-only files for each point in time.\n\n- **Creates clones fast**: you can clone a volume within seconds. It takes the\n same amount of time to create a new volume from a snapshot as it does to\n create a new empty volume independent of volume or snapshot size. The clone is\n a new volume and the storage pool needs sufficient free capacity to\n accommodate it.\n\n- **Fast restoration of snapshots**: within minutes, you can restore a\n volume to a snapshot version regardless of the volume size. Changes made to\n volumes after snapshot creation are undone, which includes newer snapshots.\n\nTypes of snapshots\n------------------\n\nThere are three types of snapshots:\n\n- **Manual snapshots**: snapshots you create and delete manually.\n\n- **Scheduled snapshots**: using scheduled snapshots, you can automatically\n create or delete snapshots. You can recognize scheduled snapshots by their\n name with the following format:\n\n - `\u003cschedule\u003e-\u003ctimestamp\u003e`\n\n - `\u003cschedule\u003e`: hourly, weekly, or monthly\n\n - `\u003ctimestamp\u003e`: appears in UTC (`YYYY-MM-DD at HH:MM:SS UTC`)\n\n- **Internal snapshots**: snapshots used by NetApp Volumes to\n support replication and backup operations. Internal snapshots aren't manually\n deletable. You can identify internal snapshots by their name. Depending on\n how you view snapshots, internal snapshots can have different names:\n\n - In the Google Cloud console, Google Cloud CLI, and API responses, internal\n snapshots use the `replication-\u003ctimestamp\u003e` naming convention.\n\n - If you access a snapshot using NFS or SMB, internal snapshots use the\n `snapmirror.\u003cuuid\u003e.\u003ctimestamp\u003e.` naming convention.\n\nSnapshot capacity\n-----------------\n\nConsider the following about snapshot capacity before you use snapshots:\n\n- For most datasets, an additional capacity of 20% is enough to keep snapshots\n for up to four weeks. As data gets older, its use for restorations becomes\n less likely.\n\n- Overwriting all of the data in a snapshot consumes significant volume capacity,\n which factors into provisioning volume capacity.\n\nSnapshot schedules\n------------------\n\nCommon snapshot schedules range from the following:\n\n- Hourly snapshots taken in a 48-hour time period\n\n- Daily snapshots taken during a 30-day time period\n\n- Weekly snapshots taken optionally during a 60-day time period\n\n### Hourly snapshot attributes\n\nHourly snapshots satisfy a recovery point objective of one hour.\n\nUse cases for snapshots\n-----------------------\n\nThe following section describes scenarios where you can use snapshots to address\ndata management challenges.\n\n- **Application cloning**: you can use the snapshot and application cloning\n feature to allow more test iterations at faster speeds independent of clone\n size and data structure.\n\n- **Volume recovery** : you can use snapshots with\n [NetApp Volumes backups](/netapp/volumes/docs/protect-data/about-volume-backups)\n to recover individual files or directories if the data on the volume\n is corrupted or deleted. Since snapshots only exist within the volume,\n by themselves they don't offer complete protection from lost volumes.\n\n- **Data versioning**: snapshots help you keep multiple versions of the same\n dataset accessible.\n\n- **Application and data upgrades**: before upgrading applications, you can use\n NetApp Volumes to capture a snapshot of your data's current\n state. Then if the upgrade fails, you are able to revert to the previous state\n and recover your files.\n\n- **Ransomware protection:** NetApp Volumes helps defend against\n data loss from ransomware attacks. Because snapshots are read-only and\n not encryptable, they help defend against unwanted data encryption or deletion\n from a compromised VM which might have the volume mounted. In the event\n of a large data loss or compromise, you can use a snapshot to revert an\n entire volume back to a previous state in seconds.\n\n You can also create a usable volume clone from an older snapshot in order to\n resume operations until your data is investigated for changes or corruptions\n following a ransomware attack. Both options make all your data usable within\n minutes.\n- **Application-consistent recovery points**: you can use\n NetApp Volumes to take application-consistent snapshots, which\n are snapshots taken after the operating system and application write the\n current state of the data to storage. Application-consistent snapshots provide\n a clear recovery point for the application and can be used to create a\n consistent clone of the application. Because snapshots are read-only\n accessible through the client, users can restore data immediately, which\n provides a substantial recovery time objective improvement.\n\n- **Crash-consistent snapshots**: you can also use crash-consistent snapshots to\n recover data, which works well for a majority of applications. However, some\n data in storage might not be current at the time of recovery because it's kept\n in operating system and application caches for some time before it's written\n to storage.\n\n- **Logical space use**: NetApp Volumes space usage reflects\n the data in the active file system and deleted blocks that snapshots retain.\n NetApp Volumes frees the retained snapshot blocks as soon as\n the latest snapshot that references the blocks is deleted. Your volume\n continues to consume provisioned space, which includes deleted data your\n snapshots retain.\n\nSnapshot space use example\n--------------------------\n\nThe following example provides details on how to manage a snapshot space\nrequirement:\n\n1. A user provisions a 5 TiB volume and writes 3 TiB of data into the volume.\n\n Result: The client sees 2 TiB of free space.\n2. The client creates a snapshot and then deletes 1 TiB of data.\n\n *5 TiB volume - 2 TiB user data - 1 TiB snapshot data*\n\n Result: The client continues to see only 2 TiB of free space. This is\n because the system needs to retain 1 TiB of deleted data that is referenced\n by the snapshot. That capacity is counted against the allocated capacity.\n3. NetApp Volumes deletes the snapshot.\n\n Result: 1 TiB of snapshot data is freed, and the client sees 3 TiB of\n free space.\n\nWhat's next\n-----------\n\n[Create a manual snapshot](/netapp/volumes/docs/configure-and-use/volume-snapshots/create-manual-snapshots)."]]
