DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
[Next] [Previous] [Top] [Contents] [Index]

VxFS System Administrator's Guide

Online Backup

Chapter 4


Introduction

This chapter describes the online backup facility provided with the VERITAS File System. The snapshot feature of VxFS can be used to create a snapshot image of a mounted file system, which becomes a duplicate read-only copy of the mounted file system.

The following topics are covered in this chapter:

Snapshot File Systems

The VxFS file system provides a mechanism for taking snapshot images of mounted file systems, which is useful for making backups. The snapshot file system is an exact image of the original file system, which is referred to as the snapped file system. The snapshot is a consistent view of the file system "snapped" at the point in time the snapshot is made. Selected files can be backed up from the snapshot (using standard utilities such as cp(1), or cpio(1)), or the entire file system image can be backed up (using the fscat(1M), volcopy(1M), or vxdump(1M) utilities).

The mount command (see mount_vxfs(1M)) is used to create a snapshot file system; there is no mkfs step involved. A snapshot file system is always read-only and exists only as long as it and the file system that has been snapped are mounted. A snapped file system cannot be unmounted until any corresponding snapshots are first unmounted. A snapshot file system ceases to exist when unmounted. While it is possible to have multiple snapshots of a file system made at different times, it is not possible to make a snapshot of a snapshot.

This chapter describes the creation of snapshot file systems and gives some examples of backing up all or part of a file system using the snapshot mechanism.

Snapshot File System Disk Structure

A snapshot file system consists of:

Figure 11 shows the disk structure of a snapshot file system.

Figure 11 The Snapshot Disk Structure

The super-block is similar to the super-block of a normal VxFS file system, however, the magic number is different and many of the fields are meaningless.

Immediately following the super-block is the bitmap. The bitmap contains one bit for every block on the snapped file system. Initially, all bitmap entries are zero. A set bit indicates that the appropriate block was copied from the snapped file system to the snapshot. In this case, the appropriate position in the blockmap will reference the copied block,

Following the bitmap is the blockmap. It contains one entry for each block on the snapped file system. Initially, all entries are zero. When a block is copied from the snapped file system to the snapshot, the appropriate entry in the blockmap is changed to contain the block number on the snapshot file system that holds the data from the snapped file system.

The data blocks used by the snapshot file system are located after the blockmap. These are filled by any data copied from the snapped file system, starting from the front of the data block area.

How a Snapshot File System Works

A snapshot file system is created by mounting an empty disk slice as a snapshot of a currently mounted file system. The bitmap, blockmap and super-block are initialized and then the currently mounted file system is frozen (see Chapter 6, "Application Interface," for a description of the VX_FREEZE ioctl). Once the file system to be snapped is frozen, the snapshot is enabled and mounted and the snapped file system is thawed. The snapshot appears as an exact image of the snapped file system at the time the snapshot was made.

Initially, the snapshot file system satisfies read requests by simply finding the data on the snapped file system and returning it to the requesting process. When an inode update or a write changes the data in block n of the snapped file system, the old data is first read and copied to the snapshot before the snapped file system is updated. The bitmap entry for block n is changed from 0 to 1 (indicating that the data for block n can be found on the snapped file system) The blockmap entry for block n is changed from 0 to the block number on the snapshot file system containing the old data.

A subsequent read request for block n on the snapshot file system will be satisfied by checking the bitmap entry for block n and reading the data from the indicated block on the snapshot file system, rather than from block n on the snapped file system. Subsequent writes to block n on the snapped file system do not result in additional copies to the snapshot file system, since the old data only needs to be saved once.

All updates to the snapped file system for inodes, directories, data in files, extent maps, etc., are handled in this fashion so that the snapshot can present a consistent view of all file system structures for the snapped file system for the time when the snapshot was created. As data blocks are changed on the snapped file system, the snapshot will gradually fill with data copied from the snapped file system.

The amount of disk space required for the snapshot depends on the rate of change of the snapped file system and the amount of time the snapshot is maintained. In the worst case, the snapped file system is completely full and every file is removed and rewritten. The snapshot file system would need enough blocks to hold a copy of every block on the snapped file system, plus additional blocks for the data structures that make up the snapshot file system. This is approximately 101 percent of the size of the snapped file system. Normally, most file systems do not undergo changes at this extreme rate. During periods of low activity, the snapshot should only require 2 to 6 percent of the blocks of the snapped file system. During periods of high activity, the snapshot might require 15 percent of the blocks of the snapped file system. These percentages tend to be lower for larger file systems and higher for smaller ones.


Note: If a snapshot file system runs out of space for changed data blocks, it is disabled and all further access to it fails. This does not affect the snapped file system.


Using a Snapshot File System for Backup

Once a snapshot file system is created, it can be used to perform a consistent backup of the snapped file system. Backup programs that function using the standard file system tree (such as cpio) can be used without modification on a snapshot file system, since the snapshot presents the same data as the snapped file system. Backup programs that access the disk structures of a VxFS file system (such as volcopy(1M) and vxdump(1M) require some modifications to deal with a snapshot file system. The VxFS utilities understand snapshot file systems and make suitable modifications in their behavior so that their operation on a snapshot file system is indistinguishable from that on a normal file system.

Other backup programs that normally read the raw disk image cannot work on snapshots without modification. These programs can use the fscat command to obtain a raw image of the entire file system identical to that which would have been obtained by a dd of the disk device containing the snapped file system at the exact moment the snapshot was created. The snapread ioctl takes arguments similar to those of the read system call and returns the same results as would have been obtained by performing a read on the disk device containing the snapped file system at the exact time the snapshot was created. In both cases, however, the snapshot file system provides a consistent image of the snapped file system with all activity complete; it is an instantaneous read of the entire file system. This is a marked contrast to the results that would be obta If a complete backup of a snapshot file system is made through a utility such as volcopy and is later restored, it will be necessary to fsck the restored file system because the snapshot file system is only consistent and not clean. The file system may have some extended inode operations that must be completed, though there should be no other changes. Since the snapshot file system is not writable, it cannot be fully fscked. However, the fsck -n command can be used to report any inconsistencies.

Creating a Snapshot File System

A snapshot file system is created by using the -o snapof= option of the mount command. The -o snapsize= option may also be required if the device being mounted does not identify the device size in its disk label, or if a size smaller than the entire device is desired. The following commands create a snapshot file system:

	mount -F vxfs -o snapof=special,snapsize=snapshot_size \
	snapshot_special snapshot_mount_point

The snapshot file system must be created large enough to hold any blocks on the snapped file system that may be written to while the snapshot file system exists.


Note: If a snapshot file system runs out of blocks to hold copied data, it will be disabled and all further access to the snapshot file system will fail.


During a period of low activity when the system is relatively inactive (for example, on nights and weekends), the snapshot only needs to contain 2 to 6 percent of the blocks of the snapped file system. During a period of higher activity, the snapshot of an "average" file system might require 15 percent of the blocks of the snapped file system, though most file systems do not experience this much turnover of data over an entire day. These percentages tend to be lower for larger file systems and higher for smaller ones. The system administrator should manage the blocks allocated to the snapshot based on file system usage, duration of backups, etc.


Note: A snapshot file system ceases to exist when unmounted. If remounted, it will be a fresh snapshot of the snapped file system. A snapshot file system must be unmounted before the corresponding snapped file system can be unmounted. Neither fuser nor mount will indicate that a snapped file system cannot be unmounted because a snapshot of it exists.



CAUTION! Any existing data on the disk used for the snapshot is overwritten and lost.


Making a Backup

Here are some typical examples of making a backup of a 300,000 block file system named /home (which exists on disk /dev/dsk/c0b0t0d0s7) using a snapshot file system on /dev/dsk/c0b0t1d0s1 with a snapshot mount point of backup/home:

	mount -F vxfs -o snapof=/dev/dsk/c0bot0d0s7, \ 
	snapsize=100000 /dev/dsk/c0bot1d0s1 /backup/home
	cd /backup
	find home -ctime -7 -depth -print | \
	cpio -oc > /dev/rmt/c0s0 \
	umount /backup/home
	mount -F vxfs -o snapof=/dev/dsk/c0b0t0d0s7, \ 
	snapsize=100000 /dev/dsk/c0b0t10d0s1 /backup/home
	volcopy -F vxfs home /dev/rdsk/c0b0t1d0s1 \
	c0b0t1d0s1 /dev/rmt/c0s0 tape77
	umount /backup/home
	vxdump f - /dev/rdsk/c0b0t0d0s7 | \
	dd bs=128k > /dev/rmt/c0s0
	vxdump 3f - /dev/rdsk/c0b0t0d0s7 | vxrestore -xf -
	mount -o snapof=/dev/dsk/c0b0t0d0s7,snapsize=100000 \
	/dev/dsk/c0b0t1d0s1 /backup/home
	vxdump f - /dev/rdsk/c0b0t1d0s1 | \ 
	dd bs=128k > /dev/rmt/c0s0
The volcopy(1M) and vxdump(1M) programs will ascertain that /dev/dsk/c0b0t1d0s1 is a snapshot mounted as /backup/home and do the appropriate work to get the snapshot data through the mount point.

Performance of Snapshot File Systems

Snapshot file systems maximize the performance of the snapshot at the expense of writes to the snapped file system. Reads from a snapshot file system will typically perform at nearly the throughput of reads from a normal VxFS file system, allowing backups to proceed at the full speed of the VxFS file system.

The performance of reads from the snapped file system should not be affected. Writes to the snapped file system, however, typically average two to three times as long as without a snapshot, since the initial write to a data block now requires a read of the old data, a write of the data to the snapshot, and finally the write of the new data to the snapped file system. If multiple snapshots of the same snapped file system exist, writes will be even slower. Only the initial write to a block suffers this penalty, however, so operations like writes to the intent log or inode updates proceed at normal speed after the initial write.

Reads from the snapshot file system are impacted if the snapped file system is busy, since the snapshot reads are slowed by all of the disk I/O associated with the snapped file system.

The overall impact of the snapshot is dependent on the read to write ratio of an application and the mixing of the I/O operations. As an example, Oracle running an OLTP workload on a snapped file system was measured at about 15 to 20 percent slower than a file system that was not snapped.


VxFS System Administrator's Guide
[Next] [Previous] [Top] [Contents] [Index]