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 snap. 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 snap.
Before the snapshot can occur, the snapshot function must render the original pool quiescent 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 when you activate the snapshot for access.
After the snap, the snapshot function continues to track the transaction activity in the original pool. It determines which blocks in the original pool will change as data writes are made to the original pool. It suspends the write activity while it copies the original block data to the designated pool where it stores the pool snapshot, referred to as the “stored-on pool.” Then it allows a write to that block in the original pool. This keeps the snapshot metadata consistent in time with the exact instant the snapshot was taken.
As the original pool changes, the snapshot can grow to the size of the stored-on pool. The average disk space requirements for a pool snapshot are 10 percent to 20 percent of the original pool size. The actual space depends on how many writes are made to the original volume and the time period that the snapshot exists before it is archived or deleted. Currently, a combination of up to 500 snapshots can exist on any given stored-on pool. The more snapshots you must traverse to find data, the longer it takes to retrieve the data, and the slower the perceived response time to the user.