A pool snapshot is a metadata copy of a storage data pool that preserves a point-in-time view of a data pool. The pool snapshot function uses copy-on-write technology to enable the instantaneous block-level snapshot of a pool, while requiring only a fraction of the storage space of the original data pool. A pool snapshot does not save an exact copy of the original data pool. Instead, the snapshot is a metadata-based copy that stores only the blocks of data that change subsequent to the instant of the snapshot. The snapshot combines the metadata and stored block data with the unchanged data on the original pool to provide a virtual image of an exact copy of the data at the instant the snapshot was taken, plus any end-user modifications made to that snapshot.
Before the snapshot can occur, the snapshot function must quiesce the original pool by briefly halting all data transaction activity when current transactions complete. It temporarily prevents new writes to the pool and flushes the file system cache to make the pool current with existing writes. Any open files are seen by the snapshot feature as being closed after these outstanding writes occur. Then, it snapshots the now-stable pool, and allows data transaction activity to resume.
The quiescence process provides a transactionally consistent image at the instant the snapshot is made. Because the snapshot is consistent, it is not necessary to check the consistency of the file system or database if you activate the snapshot for access.
When the pool is active, each of its snapshots is active. For each write, the snapshot function determines which blocks in the original pool will change. It temporarily suspends the write activity while it copies the original block data to each snapshot's stored-on partition, then it writes the changed data to the blocks on the original pool. This copy-on-write process keeps the snapshot metadata consistent in time with the exact instant the snapshot was taken.
The snapshot grows as more blocks are changed on the original pool. Theoretically, if all of the original blocks changed, each snapshot's stored-on partition would need to be as big as the original pool. Typically, the disk space needed for each pool snapshot is 10 percent to 20 percent of the original pool size. The amount of space required depends on the snapshot retention policy and the turnover rate for data in the original pool. A snapshot should never be allowed to completely fill its stored-on partition.
The number of snapshots is limited only by the kernel memory required to create the snapshot and buffers. Each additional snapshot incrementally consumes more kernel memory and degrades I/O performance. On Linux, each snapshot functions independently of the others. The copy-on-write process must copy the block content to every snapshot before it can write the modified block data to the pool.
Pool snapshots save time and preserve data. They provide an instant copy of a pool that can help expedite routine maintenance procedures to back up, archive, and protect data on that pool. Because traditional methods of duplicating large amounts of data can be expensive and time-consuming, the efficiency of snapshots can be an important benefit for your enterprise. You can make snapshots as frequently as needed to meet your data availability and resilience requirements.
You can use pool snapshots in a variety of ways to enhance your current storage infrastructure, including the following scenarios.
A pool snapshot facilitates non-disruptive backups because the snapshot becomes the source of the backup. When you back up volumes in a pool from a pool snapshot, your backup can capture every file in the pool, even those that are in use at the time. You can create, manage, and delete a pool snapshot for any pool on your server.
As contrasted to a traditional, full-data copy of the pool, the metadata copy only takes a moment to create and occurs transparently to the user. With traditional backups, applications might be shut down throughout the backup routine. In comparison, the pool snapshot process makes the original pool available with almost imperceptible delay.
You can archive pool snapshots to maintain a point-in-time history of the changes made to the original data pool.
Pool snapshots can serve as a source for recovering a point-in-time version of a file. After you take a snapshot, you can activate it at a later time to access the original pool’s data as it existed at the time of the snapshot. Both the pool and its snapshots can be active and available concurrently. You access data on the active pool snapshot just as you would do on any other pool, even while data is changing on the original pool you snapped. To restore data, manually copy the old version of the file from the online snapshot volume to the original volume. For information, see Section 18.8, Onlining or Offlining a Pool Snapshot using NSSMU or iManager.
Two common reasons to restore information are user error and application errors.
A user might inadvertently make changes to a file that need to be reversed. Files can become corrupted or deleted. The pool snapshot provides a quick and easy way to locate and reinstate selected files.
An application might be infected by a virus or be corrupted by other problems, causing the application to store erroneous data throughout the pool. With a pool snapshot, you can easily restore all or part of the original pool to a point in time before the virus or problem was known to exist in the system.
You can also write to the pool snapshot, just as you would any pool. You can work with and modify the snapshot version of the data. For example, in a software development environment, engineers might want to repeat builds and tests of data within a given snapshot.
Snapshots can provide a convenient source for testing and training environments and for data mining purposes.