[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[[["\u003cp\u003eFilestore snapshots preserve the state of your file share data at the time of creation, allowing you to restore files to their previous state.\u003c/p\u003e\n"],["\u003cp\u003eSnapshots are stored within the Filestore instance, sharing in-common data and only consuming additional capacity when data on the instance is modified, and creation typically takes no longer than two minutes.\u003c/p\u003e\n"],["\u003cp\u003eWhile snapshots offer cost efficiency for data recovery, file modifications after snapshot creation continuously decrease available instance capacity.\u003c/p\u003e\n"],["\u003cp\u003eReverting to a snapshot state is irreversible, deleting all data written since the target snapshot's creation and all newer snapshots, with cleanup potentially taking six hours to ten days, and is limited to zonal, high scale SSD, regional, and enterprise instances only.\u003c/p\u003e\n"],["\u003cp\u003eSnapshots are not available for basic SSD and basic HDD service tiers and cannot be used with the multi-shares feature.\u003c/p\u003e\n"]]],[],null,["# Snapshots overview\n\nThis page describes what a snapshot is, how it works, and discusses limitations\nand best practices.\n\nTo see how to use snapshots, see the following guides:\n\n- [Preserve the state of your data with snapshots](/filestore/docs/create-snapshots)\n- [Restore a file from a snapshot](/filestore/docs/restore-file)\n- [Revert a file share to a prior snapshot](/filestore/docs/revert-snapshot)\n- [Schedule Filestore enterprise snapshots](/filestore/docs/schedule-filestore-enterprise-snapshots)\n\nWhat is a snapshot?\n-------------------\n\nA Filestore snapshot is the preserved state of your file share data\nat the time that the snapshot is created. The instance maintains the state of\nfiles that are modified after the snapshot is created. If you want to restore a\nfile to the preserved state in the snapshot, you can overwrite the current file\nwith the file from the relevant snapshot directory.\n\nSnapshots are stored within the Filestore instance and are child\nresources of the instance. They don't replicate any data or consume capacity\nuntil the data on the instance is modified. All snapshots of an instance share\nin-common data, meaning that the instance preserves only the differences between\nthe snapshots.\n\nWhile snapshots do offer cost efficiency when compared to other Filestore\ndata recovery operations, available instance capacity continuously decreases as\nfile modifications are made.\n\nSnapshot creation\n-----------------\n\nEvery directory of a file share contains a hidden `.snapshot` directory. Each\n`.snapshot` directory contains the snapshots of its parent directory that you\ncreate, for example: \n\n volume1/\n │ genomics-file.txt\n │\n └───.snapshot\n │\n ├───snap1/\n │ genomics-file.txt\n │\n ├───snap2/\n │ genomics-file.txt\n │\n └───snap3/\n genomics-file.txt\n\nThe snapshots contain a read-only view of all files and subdirectories that\nexist within its parent directory at the time of snapshot creation. All file\nattributes such as `atime`, `ownership`, and read and write permissions are\npreserved.\n\nSnapshot creation usually takes no longer than two minutes to complete because\nit doesn't involve the copying of data, and it doesn't affect instance\nperformance.\n\nYou can have up to 240 snapshots per instance at a time. The file share name and\nsnapshot name can have a combined length of up to 78 characters.\n\nSnapshot consistency\n--------------------\n\nFilestore snapshots have NFSv3 consistency semantics. Before a snapshot\nis initiated, any write that the Filestore instance acknowledges as\nwritten to stable storage or that is followed by an acknowledged `COMMIT` is\nincluded in the snapshot. For details, see\n[NFSv3 RFC-1813 section 3.3.7](https://tools.ietf.org/html/rfc1813#section-3.3.7).\n\nPrepare your file share for the best snapshot consistency\n---------------------------------------------------------\n\nThe quality of a snapshot depends on the ability of your application to recover\nfrom snapshots that are created during heavy write workloads. In most\nsituations, you can create snapshots that have good consistency even while your\napplications write data to the file share. However, if your applications require\nstrict consistency, we recommend doing one or more of the following:\n\n- Use the [**sync**](https://linux.die.net/man/5/nfs) mount option or open files with the [`O_DIRECT|O_SYNC`](https://linux.die.net/man/2/open). Either of these methods improves consistency but does not guarantee it.\n- 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)](https://linux.die.net/man/2/fsync).\n- 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.\n- If you require application level consistency, stop your applications and unmount the file share before creating a snapshot.\n\nNFS semantics of the `.snapshot` directory\n------------------------------------------\n\nThe `.snapshot` directories are special hidden directories that contains the\nsnapshots taken for its parent directory. All NFS and bash commands work for\nthese directories with the following exceptions:\n\n- You cannot create a file or directory named `.snapshot` because it is reserved for snapshots.\n- 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.\n- To change to a `.snapshot` directory, you must explicitly type out the `.snapshot` string. Example: `cd somedir/.snapshot/`\n- Auto complete for shell commands won't list `.snapshot` as an option.\n\nDelete files that are captured in a snapshot\n--------------------------------------------\n\nWhen a file is captured in a snapshot, deleting it does not increase free disk\nspace on your instance.\n\nRevert to a snapshot state\n--------------------------\n\nReverting an instance to a snapshot state is [generally available](/products#product-launch-stages)\nfor zonal, high scale SSD, regional,\nand enterprise instances only.\n\nWhen an instance is reverted to the state captured in a snapshot, all new data\nwritten since the creation of the target snapshot is deleted and can't be\nrecovered. Snapshots that are created after the target snapshot are also deleted\nby the revert process.\n\n### Feature limitations\n\n- The revert snapshot feature is an irreversible operation, deleting data from\n the live file system and deleting each subsequent, newer snapshot in the\n chain. Therefore, it has a higher risk of accidental data loss. This is\n significantly different behavior when compared to restoring from a backup,\n where the backup will remain in its present state after use, allowing you\n attempts to restore from multiple backups to find the best one. Use the revert\n feature carefully.\n\n- All data written after the creation of the target snapshot is deleted\n at the beginning of the revert process and cannot be recovered. All snapshots\n that are newer than the target snapshot are also deleted. For example,\n `snapshot1`, `snapshot2`, and `snapshot3` are created sequentially. Reverting\n the instance to the state captured in `snapshot2` means that all data written\n after `snapshot2`, as well as all snapshots taken after the creation of\n `snapshot2`, are deleted in the revert process.\n\n Cleanup of this deleted data can take between six hours to ten days. Instance\n capacity and performance may be impacted during this time.\n- Reverting an instance to a snapshot state updates the NFS file system ID (fsid). Attempts\n to access clients using existing mounts will return stale file handle errors.\n As a best practice, unmount all clients from the instance prior to the revert\n operation, and remount them after it is complete.\n\n- A revert operation can take up to two minutes to complete.\n\n - Any related cleanup associated with the revert operation, such as deleting subsequent snapshots in the chain, can take between six hours to ten days to complete, depending on the number of files involved.\n - You can run other operations while the revert operation is running and while cleanup is completing.\n - You must wait for the revert operation to complete before starting another revert operation.\n- Snapshots and their related `revert` operations are available for most service\n tiers. Snapshots aren't available in the basic SSD and\n basic HDD service tiers.\n\n- Only instances with a single share can revert to a snapshot state.\n\n- While snapshots are supported in the enterprise service tier,\n they can't be combined with the [Filestore multishares](/filestore/docs/multishares)\n feature.\n\nWhat's next\n-----------\n\n- Learn how to [create and manage snapshots](/filestore/docs/create-snapshots).\n- Learn about [backups](/filestore/docs/backups)."]]
