Choose from the following topics:
Related Topics:
QSnap/Open File Handler 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. QSnap/Open File Handler is an installable, licensed software module.
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.
QSnap provides the following functionality:
For all Agents, QSnap/Open File Handler must be installed prior to configuring the software. If your Agent supports integration with QSnap or Open File Handler, an install procedure that includes the steps for installing QSnap/Open File Handler 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:
QSnap/Open File Handler 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 QR Volume creation, incremental updates, and data protection 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.
Note: 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 OFH or QSnap 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.
QSnap/Open File Handler 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 Initial Sync phase for Data Replication, as well as persistent snapshots for Recovery Points. The following information should be considered in the context of disk space requirements for your particular environment and configuration.
For a client computer that serves as both a source and a destination for data replication, all of the points outlined above must be considered for that computer, both for the snapshots created during Initial Sync, as well as those created for Recovery Points.
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 QSnap 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 nSPACECHECK_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.
For Unix, the mount point for the copy-on-write (COW) cache is specified during installation. After installation, you can assign any UFS volume/partition to this mount point so long as it is one of the supported configurations below:
| Source Volume | Supported COW Cache Location | Notes |
| UFS |
|
|
| EXT2, EXT3 |
|
|
| VxFS |
|
Not all agents support all source volume types and file systems. See the Supported Data Types in the Product Overview for your agent.
The mount point for the COW cache is specified during installation. This is the location of the COW cache. For instructions on mounting a partition to the COW cache mount point, see Mount the COW Cache Partition.
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
NOTE:
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 (4096 bytes) with the following command: mke2fs -b 4096.
Through the use of a block-filter driver, QSnap (or Open File Handler (OFH)) 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 or a differential operation rather than 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 QSnap or OFH is installed, its block-filter is deactivated for all volumes by default. (This does not apply to clustered environments.) But if you are upgrading QSnap, all volumes that had the block-filter activated in the previous version will have it activated after upgrade.
During subclient creation for an Agent, the QSnap/OFH block-filter is activated on volumes for the following Agents:
The QSnap block-filter is also activated on volumes that are added to the QR scratch volume pool. (The Quick Recovery Agent is only used with QSnap.)
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. To manually deactivate the QSnap/Open File Handler block-filter driver on specific volumes, use the QSnapConfigTool. See Disable QSnap/OFH Block-filter Driver on Specific Volumes for step-by-step instructions.
NOTE:
QSnap with the Quick Recovery Agent: Block-filter functionality is automatically turned on for volumes that are added as subclient content or as QR scratch volume content. But the system does not deactivate a volume's block-filter functionality if the volume is later deleted. You must manually deactivate the volumes as indicated above.
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, QSnap/Open File Handler 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
In order to help avoid unwanted full backups, you can configure QSnap/Open File Handler bitmap persistence on a volume. 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, Incremental and/or Differential backups. | ||
Persistence is enabled on volumes with the QSnapConfigTool. The QSnapConfigTool is located in <Install Directory>\Base on the client and is installed with QSnap/Open File Handler.
See Enable Persistence on a Volume for step-by-step instructions.
See Enable Persistence and Configure QSnap/Open File Handler on a Cluster for step-by-step instructions.
Persistence is disabled with the QSnapConfigTool.
See Disable Persistence on Volumes for step-by-step instructions.
See Disable Persistence on a Cluster for step-by-step instructions.
The bitmap location is specified during the installation of QSnap/Open File Handler. Only NTFS volumes are supported for the bitmap location. You can change the bitmap location using the QSnapConfigTool. See Change the QSnap/Open File Handler 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 or differential job by using the TrackIncrIOWin2 tool. This tool looks at the bitmap information to determine the amount of changed blocks. See Use TrackIncrIOWin2 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.
Note the following:
On a Unix platform, a CXBF device is a volume or partition that is monitored by the CXBF block-filter driver. CXBF devices can be created using the Configure cxbf device right-click option in Volume Explorer on any volumes available to the client.
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 (for example, /dev/cxbf/dsk/c2t1d1s1).
Linux disk devices are named as follows:
/dev/hdx for an IDE disk
/dev/sdx for SCSI disk
where x is a letter a,b,c,d... etc.
The CXBF devices for these disks will be created in the paths of:
/proc/cxbf/cxbfx/
where x is a number from 0 to 256.
They are selected by their device name in the CommCell (for example, /proc/cxbf/cxbfx/dsk).
In order to find the relationship between the Linux CXBF device and original device, you can go to /proc/cxbf/cxbfx and type cat hdd_name. This will report the original device name.
The naming convention for CXBF devices is as follows:
cxtxdxsx
Where the system assigns integer x as follows:
After installing the software, you must create CXBF devices for the volumes you want to back up/protect. Once the devices have been configured, they can be added to subclient contents.
See the following procedures for step-by-step instructions:
For Oracle Volumes:
Using the CVSnap Tool:
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 2 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)
When used with the Quick Recovery Agent (QR) on Windows or with ContinuousDataReplicator (CDR), an additional feature is available for QSnap 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.
To perform a data protection operation using this Agent a specific Product License must be available in the CommServe.
Review general license requirements included in License Administration. Also, View All Licenses provides step-by-step instructions on how to view the license information.
If you did not enable Unix QSnap when you installed it (see Install QSnap - Unix), then you must allocate the QSnap license and activate the functionality using the instructions in Enable QSnap for Unix. Instructions for deactivating the license are provided in Disable QSnap for Unix.
If you will be using Unix QSnap with the Quick Recovery Agent, and you plan to install QSnap before installing the Quick Recovery Agent, then you must enable QSnap when you install it (or before installing the Quick Recovery Agent). Quick Recovery Agent installation will fail if QSnap is installed but not enabled. To enable QSnap when you install it, type Yes or Y when asked whether you want to activate the snapshot functionality of CXBF. (See Install QSnap - Unix.)
This feature requires a Feature License to be available in the CommServe.
Review general license requirements included in License Administration. Also, View All Licenses provides step-by-step instructions on how to view the license information.
Windows File System iDataAgent
SAN and Volume Level Agents on Windows
SAN and Volume Level Agents on Unix
Additional Tools for Windows
CVSnaptool for Unix