The Filesystem Snapshot Snapshot

A solution to this problem was found in taking a data snapshot and then making the backup. Original data is mirrored before the start of a backup, and then backed as the frozen mirrored data. In the meantime, the access to the original data remains unrestricted. The online backup can then ensue. The idea of performing a snapshot a very quick copying of the dynamic data is similar to the concept of taking a photograph of a moving object. Once the data is snapped, we can then make a time−consuming backup of its mirror — mirrored data is reliably consistent — it does not change. The only requirement is the prevention of any data change during the snapshot, which is easily met thanks to the short snapshot time period. LVM makes this approach feasible. There are two types of snapshots: the volume and the filesystem snapshot.

6.3.5.1 The Volume Snapshot

The volume snapshot is provided on the volume level, regardless of the upper−level data structures. The procedure is relatively simple: the snapstart operation creates a write−only backup in a separate volume, which gets attached to and synchronized with the original, snapped volume. Synchronized means that the original volume is mirrored to the newly attached backup volume. The synchronization takes some time, especially in the case of large volumes. However, in this period all activities on the system are continuing normally, without any restrictions. The end of the synchronization procedure is signified by a change in the snapshot mirror status, known as the snapdone state. Once the backup volume is synchronized with the snapped volume, it is ready to be used as a snapshot mirror. The synchronized snapshot mirror continues to be updated until it is detached. The detachment can be schedule for any convenient time. The snapshot volume, an image of the snapped volume, will be created in that moment. The detachment itself represents the snapshot of the volume. The previous synchronization is only an unavoidable process required for a successful snapshot. The snapshot typically takes a very short time, and during this brief period the use of the system should be strictly controlled and any change of the volume content prevented. Once the detachment is done, the content of the created snapshot volume remains unchanged as long as this volume lives. The main disadvantage of the volume snapshot is that the size of the snapshot volume must be the same or larger than the snapped volume. The same snapshot volume can be used to mirror multiple volumes at different times, but the required long−time synchronization actually restricts its multiple usage. The synchronization itself always takes a great deal of time: each volume block must be updated mirrored regardless of whether it was changed or not. Even the unused blocks in the volume are mirrored.

6.3.5.2 The Filesystem Snapshot

The advanced VxFS filesystem Vx origins from VERITAS provides a mechanism for taking a snapshot image of a mounted filesystem, which can then be used for a backup. The snapshot filesystem is an exact image of the original snapped filesystem — it is a duplicate read−only copy. The snapshot is a consistent view of the filesystem snapped at the point in time when the snapshot was made. Afterward all further data processing is referred to the snapshot filesystem. The basic idea is the following: Why copy mirror all filesystem blocks? The majority of blocks dont change frequently. It is enough to copy only the old content of the blocks that have been changed 164 The benefits of the filesystem snapshot are obvious: a required snapshot filesystem and the belonging volume is much smaller than the original one, and there is no need for time−consuming volume synchronization. However, the implemented filesystem type has to support the filesystem snapshot. A snapshot filesystem is presented in Figure 6.8. Super−Block Bitmap Blockmap Data Blocks Figure 6.8: The snapshot filesystem structure. The snapshot filesystem contains four parts: The superblock, a copied, slightly modified superblock of the regular snapped filesystem. 1. The bitmap, which contains one bit for every block of the snapped filesystem; initially, all bitmap entries are zero. 2. The blockmap, which contains one entry for each block of the snapped filesystem; initially all entries are zero. When a before−image is copied from the snapped filesystem, the appropriate entry is set to the block number on the snapshot filesystem; this is the local block allocation table. 3. The data blocks, which contain before−images copied from the snapped filesystem upon their first change. 4. The snapshot procedure starts with the mounting of an empty volume and the creation of the snapshot filesystem for the mounted snapped filesystem. As the first step, the superblock of the snapped filesystem is copied into the snapshot filesystem. After that, the visibility of the data in the snapped filesystem could be easily maintained through this superblock. All processes now access the snapped filesystem through the snapshot superblock rather than its own. The bitmap and blockmap are also initialized. The snapshot filesystem handles read requests by simply finding the data on the snapped filesystem and returning it to the requesting process. In the case of an inode update or a write request for any block for example, block N of the snapped filesystem, the before−image of the block N is first taken the block is read and copied into the snapshot filesystem and afterward the snapped filesystem is updated. The bitmap entry for the block N is changed from its initial value 0 to 1, indicating the taken before−image of the data block N. The blockmap entry for the block N is also changed from its initial value 0, to the actual block number in the snapshot filesystem where the before−image was copied. Any subsequent read request for the block N in the snapshot filesystem will be provided after checkup of the corresponding bitmap entry, and consequently by reading data locally, from the block indicated by the blockmap entry instead of the snapped filesystem. Subsequent writes to the block N in the snapped filesystem do not result in additional copies to the snapshot filesystem, 165 To start a filesystem snapshot, the mount command is used. It is fair to say this is a modified version of this command compatible with the implemented filesystem type. It is specified by the special option snapof=… that also includes a snapshot volume. The snapshot filesystem exists as long as it is mounted, and during this period its superblock controls the snapped filesystem too. By dismounting the snapshot filesystem, the snapshot process is terminated. For example, the following command creates a snapshot filesystem and mounts it into the snapdir directory: mount −F vxfs −o snapof= devvolgrfsvol devvolgrsnapvol snapdir where −F vxfs Defines the VxFS filesystem −o snapof = devvolgrfsvol Defines the mounted filesystem to be snapped devvolgrsnapvol Defines the snapshot filesystem snapdir Defines a mount−point for the snapshot filesystem other options are also possible To terminate a snapshot, simply dismount the snapshot filesystem: umount snapdir In the meantime, regular UNIX commands could be implemented on the snapshot and snapped filesystems without any restrictions. However, never forget the real nature of a snapshot filesystem — sometimes the command outputs could be very odd and confusing. For example, the df −kcommand implemented on the snapshot filesystem will show the size of the snapped filesystem. So, do not be confused when the snapshot filesystem is ten times larger than the actual size of the volume in which it was created. Simply, the df command sees the snapshot filesystem through the superblock of the snapped filesystem.

6.3.6 Virtual UNIX Filesystem