Topics | How To | Related Topics
The Block-Filter Driver and Bitmaps
The QSnap® Service is a software-based snapshot implementation that integrates with other Agents, providing all of the components necessary for basic snapshot functionality without requiring specialized hardware. The QSnap product is an installable, licensed software module. In this release, the QSnap service will still be automatically installed with CDR but will not be used as the default snap engine. QSnap® Services will be used as the source snapshot on Windows 2000 and Windows XP. It will not be used for creating Recovery Points, even with the aforementioned operations systems.
On Unix platforms, the driver name is Unix QSnap. You will often see "CXBF" in references to the Unix QSnap driver. For example, a CXBF device is a volume or partition that is monitored by the CXBF block-filter driver.
The QSnap service provides the following functionality:
For all Agents, the QSnap service must be installed prior to configuring the software. If your Agent supports integration with the QSnap service, an install procedure that includes the steps for installing QSnap software has been provided. See Installation for installation procedures.
QSnap configuration differs depending upon the Agent with which it is working; select your Agent from the following list for specific configuration information and procedures:
The QSnap creates a copy-on-write (COW) cache, to which it copies blocks that are being overwritten on the source volume during a snapshot creation. This preserves the original data, ensuring an accurate snapshot for data protection and recovery operations.
The COW cache contains only copies of blocks that have been overwritten. Any new data that is written to free space on a source volume is not cached. It is important to ensure there is enough space for the cached blocks.
By default on Windows platforms, the COW cache minimum size is 50MB, and the system expands the cache file as needed up to 90% of the total capacity of the volume. A snapshot will be terminated if it causes the cache file to go beyond this size.
You can override the default cache sizes by entering megabyte values for minimum cache and maximum cache in the General tab of the iDataAgent's Properties window. (See Change the COW Cache Size.)
But 90% of a volume's total capacity for maximum is a hard upper limit. Although the system will accept a megabyte value that represents more than this limit (e.g., 95 MB on a 100 MB volume), the snapshot will still terminate when the cache reaches 90% of total volume capacity (in the example: 90 MB).
Meanwhile, if you want to reset the minimum cache, note that 25 MB is the lower limit. If you try to set the minimum below this limit, the software will consider the limit to be 25 MB. And, when resetting the maximum and minimum values, be sure not to set the minimum value higher than the maximum value or limit.
Another factor is whether the data is written to free space on a volume. For example, if 550MB of new data is written to free space on a source volume, no blocks are overwritten and therefore no blocks are cached, and the default COW cache settings do not require adjustment. The snapshot driver does not need to cache data written to free space in order to create a snapshot. However, if 550MB of data is written over existing data and the 550MB represents more than 90% of total capacity, then the default maximum cache size will be exceeded and the snapshot will terminate.
Therefore, when determining the maximum size of the copy-on-write cache, consider the following, in order of importance:
Be sure to set the maximum cache high enough (not to exceed 90% of the volume's total capacity) to accommodate these factors.
| The COW cache must be located on a volume with a supported file system. |
By default, a copy-on-write (COW) cache is created on each source volume. Whether you are using NTFS or FAT/FAT32 for the source volume, any NTFS volume is supported for the COW cache location, with the following caveats:
On the Windows platform, the COW cache location can be changed through the Client level properties. Note that if you specify an alternate COW cache location, all of the COW caches for all of the volumes on the client will use that COW cache location. Be sure there is enough free space to account for the caches.
If you are using the QSnap services with the Windows File System iDataAgent in a cluster environment, and you want to change the COW cache location:
See Change the COW Cache Location for step-by-step instructions.
The COW cache size is adjustable through the Agent level properties. You can set the Minimum and Maximum cache sizes for the volumes associated with the Agent. By default, the minimum size is 50MB and the maximum size is 90% of the total capacity of the volume.
See Change the COW Cache Size for step-by-step instructions.
The QSnap enabler requires a short period of no disk activity to create the snapshot. You may require a longer write inactivity period due to slow disk performance. See Change the Write Inactivity Period (WIP) for step-by-step instructions.
Consider the following about the COW cache size, location, configuration, and use:
CDR creates non-persistent snapshots during the Baselining phase for Data Replication, on Windows 2000 and Windows XP computers. The following information should be considered in the context of disk space requirements for your particular environment and configuration.
To configure an alternate cache location, see Changing the Cache Location on Windows above.
When a cache volume becomes full (reaches its maximum allowed size) any current snapshot is terminated and all snapshots for that source volume are deleted. Even though the snapshots have been deleted, the Recovery Point entries remain in the system database, and thus appear during a Browse operation; however, if you attempt to mount, unmount, copy back, or delete those Recovery Points, you will receive an error message. At this point, you can check the Windows Event Viewer for an event that indicates all snapshots were deleted for a particular volume, indicating this is what happened; if so, you should delete those Recovery Points in the Browse window.
When using VSS or QSnap enabler with either the Quick Recovery Agent or ContinuousDataReplicator, it is recommended that you set the Disk Space Low alert to notify you when disk space is getting low; this can help you diagnose lack of cache space as a problem (or possibly avoid it). When configuring this Alert, include the <DISK SPACE INFO> Alert Token in the email notification, so that meaningful data is included in the emailed alert message. Also, consider configuring the nMACHINE_MAINT_INTERVAL_MINUTES registry key if the Space Check should be performed more often than the default of 24 hours. For more information, refer to Space Check for the Quick Recovery and ContinuousDataReplicator Agents.
To use a RAW volume as the QSnap COW Cache volume, the value of the registry key QSCacheVolume must be created. This value designates which RAW volume will be used for the cache. Furthermore, before using a RAW volume, the cache volume type must be set with the QSCacheVolumeType key. If cache values are manually set in the registry, they will take precedence over the values set in the CommCell Console.
For Unix, the mount point for the copy-on-write (COW) cache is specified during installation. For instructions on mounting a partition to the COW cache mount point, see Mount the COW Cache Partition. It is recommended that you use the local file system for COW cache.
|
The COW cache must be located on a volume with a
supported file system. The cache partition cannot be on a network share. |
After installation, you can assign any volume/partition to this mount point so long as it is one of the supported configurations below:
| Source Volume | Supported COW Cache Location | Notes |
| JFS2 - AIX |
|
|
| EXT2, EXT3, EXT4 - Linux |
|
|
| XFS - Linux |
|
|
| Reiserfs - Linux |
|
|
| UFS - Solaris |
|
|
| VxFS - Solaris |
|
New data does not use a Unix COW cache on Solaris volumes or on Linux ext2/ext3 volumes; only changed data on these volumes use the cache. However, both new data and changed data use the Unix COW cache on AIX volumes or Linux volumes using a file system other than ext2/ext3.
Not all agents support all source volume types and file systems. See Supported Data Types in the Product Overview for your agent.
The maximum size of the COW cache equals the size of the volume mounted to the COW cache mount point (which was specified during the software installation). If the COW cache size exceeds the size of this partition, then a larger partition must be mounted to this mount point.
The size of the cache partition should be determined as follows, based on the assumption that 25% of a volume is being modified between the times of snap-on to snap-off on each volume:
If m is the number of volumes for which the cache is being created with size s, and n is the number of snapshots that are expected to be copied, then the cache size should be:
(n x s)/4
For example, if there are 20 Volumes (m) of 10GB size (s) and we expect to run snapshots on 2 volumes (n) at a time then the cache partition size should be at least:
(2 x 10)/4= 5GB
Reformat the file system containing the CXBF cache to accept sparse files 3TB or bigger (XFS, EXT4, Reiserfs) in size.
Set the value of dSnapChunkSize registry key to 1048576.
The Red Hat Linux file system chooses a cache block size according to disk size. So if you are using a small disk for cache, the file system will use a small block size such as one kilobyte. A small block size and a source disk with many files can cause the CXBF driver scan to fail. For this situation, it is recommended that you manually specify a block size of 4k (4096bytes) with the following command: mke2fs -b 4096.
For the cache size, we use one bit per extent to mark if it is modified or not. The default extent size is 2MB.
547 GB = 280,064 extents
280,064 extents needs 35,008 bytes
So, for 547GB, we need only 35 KB of space in /etc/galaxy directory.
The cache size can be as large as the volume. A 547 GB file system completely modified from scratch will occupy 547GB of space. Also, please note that this is a sparse file. The size shown by ls -l is not an indication of the space consumed. "du -sk" on the file is the correct measure on the actual blocks used.
Through the use of a block-filter driver, the QSnap software creates bitmaps to track the block-level changes to a volume over time. These bitmaps are stored in memory and later written to disk. The bitmaps help ensure that the next data protection operation can be an incremental backup instead of a full backup. Unlike the COW cache, which is created and used only when creating snapshots, bitmaps are always maintained for devices monitored by the block-filter driver.
When the QSnap software is installed, its block-filter is activated for all volumes by default.
The block-filter may be active on volumes you do not want it to be active on — as may be the case after upgrading QSnap. You can manually activate/deactivate the QSnap block-filter driver on specific volumes, using the following:
- Qsnp2Config - See Enable/Disable QSnap Block-filter Driver on Specific Volumes for step-by-step instructions.
- QST2 - See QST2 Tool for step-by-step instructions.
- BFActivateAll registry key - An alternative method to enable or disable the block filter of all volumes on the machine.
After the first full backup, you can update the backup incrementally so that only the changed blocks on the source volume are backed up or copied. In order to keep track of the changes, the QSnap program creates a bitmap that records the changed blocks for each source volume.
If the system cannot verify the integrity of a bitmap, it will force the next backup to be a full backup, which may be undesirable in the following situations:
moving very large amounts of data
moving data across a slow LAN or WAN
(for the Quick Recovery® Agent) recreating off-site QR™ recovery volumes
To avoid unwanted full backups or QR™ Volume Creation jobs, you can configure QSnap® bitmap persistence on a volume, to capture a bitmap of the blocks that have not been read and copied before ungraceful restarts and failovers. When bitmap persistence is enabled, non-full QR Volume Creation or Image backup jobs remain non-full after both graceful and ungraceful restart or failover. If bitmap persistence is not enabled, non-full jobs remain non-full only after a graceful restart or failover; in the event of an ungraceful restart or failover, the system will force a full backup or QR Volume creation.
The following table summarizes the expected behavior of the Agents after graceful (planned) and ungraceful ("blue screen," crash, etc.) restarts and failovers, depending on how you configure the software:
| Non-Cluster | Cluster | |
| Default |
Allows non-fulls* after graceful restarts only.
Ungraceful restarts will force a full backup or QR Volume creation. |
Allows non-fulls* after graceful restarts or failovers
only.
Ungraceful restarts or failovers will force a full backup or QR Volume creation. |
| Configured for Persistence | Allows non-fulls* after both graceful and ungraceful restarts. | Allows non-fulls* after both graceful and ungraceful restarts and failovers. |
*Where non-full refers to QR Incremental Updates or Incremental backups.
By default, Persistence is enabled on all volumes. If required, you can also enable Persistence on volumes with the Qsnp2Config tool, which is located in <Install Directory>\Base on the client and is installed with QSnap® software. For step-by-step instructions, see one of the following:
Persistence is disabled with the Qsnp2Config. For step-by-step instructions, see one of the following:
The bitmap location is specified during the installation of QSnap functionality. Only NTFS volumes are supported for the bitmap location. For cluster installation, the default location for storing bitmaps is the corresponding shared volume but in case of an upgrade the shared location selected prior to upgrade will be the default location for the bitmaps. You can change the bitmap location using Qsnp2Config. See Change the QSnap Bitmap Location for step-by-step instructions.
Enabling the SAN Environment allows you to continue incremental operations after a device (SAN-attached disk) has been reconnected. This option is enabled by default. Disabling feature this will force a full QR Volume creation in cases where a disconnected device has been reconnected. See Enable SAN Environment for step-by-step instructions.
You can predict the size of your next incremental job by using the TrackBlockIO tool. This tool looks at the bitmap information to determine the amount of changed blocks. See Use TrackBlockIO to measure changed blocks for step-by-step instructions.
The Unix QSnap driver interfaces between File System (UFS) and sd (disk driver) on Unix. The Unix QSnap driver preserves all the properties of the underlying sd driver. For both applications and file systems, it is transparent. The driver intercepts I/O and keeps track of the blocks that have been modified. The bitmap file location is managed by the Unix QSnap® driver.
|
On a Unix platform, a CXBF device is a volume or partition that is monitored by the CXBF block-filter driver. Any volume that you add to a subclient is automatically configured as a CXBF device. You can also create CXBF devices using the Configure cxbf device right-click option in Volume Explorer on any volumes available to the client.
|
The CXBF devices for AIX disks must be Logical Volume Manager (LVM) devices with the JFS2 virtual file system. (The JFS virtual file system is not supported.) These devices will be created in the paths of:
/dev/cxbf/cxbfx/blk
where x is a number from 0 to 32256.
The devices are selected by their device name in the CommCell® Console (for example, /dev/cxbf/cxbf24/blk/dept).
|
The CXBF devices for these disks will be created in the paths of /dev/cxbf/dsk and /dev/cxbf/rdsk. They are selected by their device name in the CommCell® Console (for example, /dev/cxbf/dsk/c2t1d1s1).
The naming convention for CXBF devices is as follows:
cxtxdxsx
Where the system assigns integer x as follows:
If the server system is heavily loaded with I/O, multiple processes, or low memory, you may need to tune the buffer cache parameter in /etc/system. If the buffer cache is too low, backup processes may hang in heavily loaded condition.
The bufhwm variable, set in the /etc/system file, controls the maximum amount of memory allocated to the buffer cache and is specified in KB. The default value of bufhwm is 0, which allows up to two percent of system memory to be used. This may need to be increased to 10 percent for a dedicated file server with a relatively small memory system, and can be increased up to 20 percent. On a larger system, the bufhwm variable may need to be limited to prevent the system from running out of operating system kernel virtual address space.
The buffer cache is used to cache inode, indirect block, and cylinder group related disk I/O only. The following is an example of a buffer cache (bufhwm) setting in the /etc/system file that can handle up to 10 MB of cache. This is the highest value to which you should set bufhwm:
set bufhwm=10240 (the unit is KB)
Linux disk devices are named as follows:
/dev/hdx for an IDE disk
/dev/sdx for a SCSI disk
/dev/vg00/vol0 for a LVM disk
where x is a letter a, b, c, d, etc.
The CXBF devices for these disks will be created in the paths of:
/dev/cxbf/cxbfx/
where x is a number from 0 to 32256.
They are selected by their device name in the CommCell® Console (for example, /dev/cxbf/cxbf32/dsk).
To find the relationship between the Linux CXBF device and original device, go to /proc/cxbf/cxbfx and type cat hdd_name. This will report the original device name.
After installing the software, you must create CXBF devices for the volumes you want to back up/protect. When you add a volume to a subclient content, it is automatically configured as a CXBF device.
See the following procedures for step-by-step instructions:
|
For Oracle Volumes:
Using the CVSnap Tool:
When used with the Quick Recovery® Agent (QR) on Windows or with ContinuousDataReplicator (CDR) on Unix, an additional feature is available for the QSnap service to create Recovery Points, by creating a snapshot of the file system data on a QR™ Volume or Destination machine. For more information, see Recovery Points.
Note: When using QSnap functionality with CDR on Windows, you cannot create recovery points.
To perform a data protection operation using this Agent a specific Product License must be available in the CommServe® Server.
Review general license requirements included in License Administration. Also, View All Licenses provides step-by-step instructions on how to view the license information.
This feature requires a Feature License to be available in the CommServe® Server.
Review general license requirements included in License Administration. Also, View All Licenses provides step-by-step instructions on how to view the license information.