Snapshots overview

This page describes what a snapshot is, how it works, some common use cases, and best practices when creating and using snapshots. To learn how to create and manage snapshots, as well as how to restore Filestore data from a snapshot, see Preserve the state of your data with snapshots.

What is a snapshot?

A Filestore snapshot is the preserved state of your file share data at the time that the snapshot is created. The instance maintains the state of files that are modified after the snapshot is created. If you want to restore a file to the preserved state in the snapshot, you can overwrite the current file with the file from the relevant snapshot directory.

Snapshots are stored within the Filestore instance and are child resources of the instance. They do not replicate any data or consume capacity until the data on the instance is modified. All snapshots of an instance share in-common data, meaning that the instance preserves only the differences between the snapshots.

Snapshot creation

Every directory of a file share contains a hidden .snapshot directory. Each .snapshot directory contains the snapshots of its parent directory that you create, for example:

foo/
│   bar.txt
│
└───.snapshot
    │
    ├───snap1/
    │        bar.txt
    │
    ├───snap2/
    │        bar.txt
    │
    └───snap3/
             bar.txt

The snapshots contain a read-only view of all files and subdirectories that exist within its parent directory at the time of snapshot creation. All file attributes such as atime, ownership, and read/write permissions are preserved.

Snapshot creation usually takes no longer than two minutes to complete because it doesn't involve the copying of data, and it doesn't affect instance performance.

You can have up to 240 snapshots per instance at a time. The file share name and snapshot name can have a combined length of up to 78 characters.

Snapshot consistency

Filestore snapshots have NFSv3 consistency semantics. Before a snapshot is initiated, any write that the Filestore instance acknowledges as written to stable storage or that is followed by an acknowledged COMMIT is included in the snapshot. For details, see NFSv3 RFC-1813 section 3.3.7.

Prepare your file share for the best snapshot consistency

The quality of a snapshot depends on the ability of your application to recover from snapshots that are created during heavy write workloads. In most situations, you can create snapshots that have good consistency even while your applications write data to the file share. However, if your applications require strict consistency, we recommend doing one or more of the following:

• Use the sync mount option or open files with the O_DIRECT|O_SYNC. Either of these methods improves consistency but does not guarantee it.
• Pause applications or operating system processes that write data to the file share and cause them to flush their changes to the file share before initiating the snapshot. For more information, see fsync(2).
• If your applications require consistency between multiple shares, pause all applications on all instances that are writing to all file shares and create snapshots of all file shares before resuming your applications.
• If you require application level consistency, stop your applications and unmount the file share before creating a snapshot.

NFS semantics of the .snapshot directory

The .snapshot directories are special hidden directories that contains the snapshots taken for its parent directory. All NFS and bash commands work for these directories with the following exceptions:

• You cannot create a file or directory named .snapshot because it is reserved for snapshots.
• The .snapshot directory is not listed in the outputs of READDIR or READDIRPLUS commands, and is also not listed in the ls -a bash command.
• To change to a .snapshot directory, you must explicitly type out the .snapshot string. Example: cd somedir/.snapshot/
• Auto complete for shell commands will not list .snapshot as an option.

Delete files that are captured in a snapshot

When a file is captured in a snapshot, deleting it does not increase free disk space on your instance.

Reverting to a snapshot state

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Reverting an instance to a snapshot state is available as a Preview feature for high scale SSD and enterprise instances only.

When an instance is reverted to the state captured in a snapshot, all new data written since the creation of the target snapshot is deleted and cannot be recovered. Snapshots that are created after the target snapshot are also deleted by the revert process.

Feature limitations

• The revert snapshot feature is a destructive operation, both to the live filesystem and to the newer snapshots in the chain. Therefore, it has a higher risk of accidental data loss. This is significantly different behavior when compared to restoring from a backup, where the backup will remain in its present state after use, allowing you attempts to restore from multiple backups to find the best one. Use the revert feature carefully.

• All data written after the creation of the target snapshot is deleted at the beginning of the revert process and cannot be recovered. All snapshots that are newer than the target snapshot are also deleted. For example, snapshot1, snapshot2, and snapshot3 are created sequentially. Reverting the instance to the state captured in snapshot2 means that snapshot3 and all changes after snapshot3 are deleted in the revert process.

  Clean up of this deleted data can take up to three days. Instance capacity and performance may be impacted during this time.

• Reverting an instance to a snapshot state updates the NFS filesystem ID (fsid). As a result, attempts to access clients using existing mounts will return stale file handle errors. As a best practice, unmount all clients from the instance prior to the revert operation, and remount them after it is complete.

• A revert operation may take several hours to complete, depending on the number of files involved. You must wait for the revert operation to complete before starting another revert operation.

• No other operation, either to the instance or the snapshot, can run while the revert operation completes. All other operations are rejected or queued, depending on the configuration of the operation.

• Currently, only instances with a single share can revert to a snapshot state. The revert snapshot feature cannot be combined with Filestore multishares for GKE.

What's next

• Learn how to create and manage snapshots.
• Learn about backups.