To Snap or Not to Snap, That is the Question
NetApp has a robust data protection suite that can archive and replicate data as well as integrate with most primary applications like collaboration, database, web and virtualization technologies. The foundation for this data protection is the NetApp Snapshot. A Snapshot is a read-only point-in-time image of the active file system. The Snapshot technology is an integrated feature of WAFL (Write Anywhere File Layout), a block-based file system that uses inodes to reference files that are built into Data ONTAP, the micro kernel that runs on all NetApp storage. When a snapshot is requested, WAFL creates a new Snapshot by making an exact copy of the root inode. This copy of the root inode becomes the root of the data representing the Snapshot, just as the root inode represents the active file system. When the Snapshot inode is created, it points to exactly the same disk blocks as the root inode, so a brand new Snapshot consumes no disk space except for the Snapshot inode itself. Up to 255 snapshots can be taken for each NetApp volume with no performance degradation. This allows for the opportunity to take more frequent backups of primary data and maintain longer periods of retention. For example, in a home directory environment just by taking nightly snapshots and subtracting weekends and holidays, it is possible to have an entire year's worth of nightly Snapshots which can be maintained online, and recovered by the user or an administrator. Snapshots on Storage Foundation Cluster File System Performance considerations Mounting a snapshot file system for backup increases the load on the system because of the resources used to perform copy-on-writes and to read data blocks from the snapshot. In this situation, cluster snapshots can be used to do off-host backups. Off-host backups reduce the load of a backup application from the primary server. Overhead from remote snapshots is small when compared to overall snapshot overhead. Therefore, running a backup application by mounting a snapshot from a relatively less loaded node is beneficial to overall cluster performance. Creating a snapshot on a Storage Foundation Cluster File System A snapshot provides a consistent point-in-time image of a VxFS file system. A snapshot can be accessed as a read-only mounted file system to perform efficient online backups of the file system. Snapshots implement copy-on-write semantics that incrementally copy data blocks when they are overwritten on the snapped file system. Snapshots for cluster file systems extend the same copy-on-write mechanism for the I/O originating from any node in the cluster. Cluster snapshot characteristics 1. A snapshot for a cluster mounted file system can be mounted on any node in a cluster. The file system can be a primary, secondary, or secondary-only. A stable image of the file system is provided for writes from any node. 2. Multiple snapshots of a cluster file system can be mounted on the same or a different node in a cluster. 3. A snapshot is accessible only on the node mounting a snapshot. The snapshot device cannot be mounted on two different nodes simultaneously. 4. The device for mounting a snapshot can be a local disk or a shared volume. A shared volume is used exclusively by a snapshot mount and is not usable from other nodes in a cluster as long as the snapshot is active on that device. 5. On the node mounting a snapshot, the snapped file system cannot be unmounted while the snapshot is mounted. 6. A SFCFS snapshot ceases to exist if it is unmounted or the node mounting the snapshot fails. A snapshot, however, is not affected if any other node leaves or joins the cluster. 7. A snapshot of a read-only mounted file system cannot be taken. It is possible to mount snapshot of a cluster file system only if the snapped cluster file system is mounted with the crw option.