QSnap can be used with the Image Level
iDataAgent to ensure that consistent
backups can be taken from the active live system with the point-in-time
snapshots created. Thus, all of the components necessary for basic Image Level
iDataAgent functionality are available
without requiring specialized hardware.
During an Image Level backup in a
QSnap environment, the following sequence of events
takes place:
The Image Level iDataAgent starts a
backup operation.
On Windows, QSnap snaps the data to be backed up to
free space on the source volume or another specified volume. On UNIX, QSnap
copies modified data on the cache partition during the snap window. The
cache partition can be linked for more information. (The cache partition
cannot be on the same volume.)
For Oracle, the production server must have one of the following installed:
Oracle 9.2 Database (Enterprise or Standard edition), or
Oracle 10g Database (Enterprise or Standard edition)
Windows
The following must be installed on the production server:
Windows File System iDataAgent
Image Level iDataAgent
QSnap
QSnap is installed automatically during installation of the Image
Level iDataAgent.
For a clustered environment, first install the
Windows File System iDataAgent
and QSnap on the physical nodes, and then reboot the nodes. After
rebooting the nodes, install only the Image Level
iDataAgent on
the virtual node. (The Windows File System
iDataAgent is
automatically selected when you install the Image Level iDataAgent.)
Unix
The following software must be installed on the
production server:
When working with file systems other than NTFS, you must set
an alternate COW Cache location on an NTFS volume. Increase the maximum size of the QSnap COW
Cache to accommodate your disk configuration and usage. See
Windows COW Cache for more information
on COW Cache configuration.
After installation, it is highly recommended that you configure persistence
for the volumes you are protecting. See Persistence
for more information.
Snapshot creation depends on finding,
within one minute,
a 3-second period of inactivity on the volume being snapped.
If the snap is unsuccessful during that one minute period, it must be retried. By default,
the number of retry attempts is 3, after which the job is failed. For Image
Level on Windows, to increase the
chance of finding a suitable write-inactivity period, you can specify a greater
number of retry attempts (up to a maximum of 10) by creating and configuring
the
nSnapRetry
registry key.
Unix
The COW Cache mount point is selected at the time of installation. See
Unix COW Cache in the Overview
- QSnap page for more information on
supported COW cache configurations.
When you add a volume to a subclient content, it is
automatically configured as a CXBF device. See
CXBF Devices in the Overview -
QSnap page for more information.
If you encounter errors while configuring or deconfiguring CXBF devices on
the client, go to /cvd.log on the client for
more detailed information concerning the error.
If you apply an update to an AIX, Linux, or Solaris platform where CXBF
drivers have been installed and CXBF devices have been configured, you must
reboot the system after the update is applied in order to activate the CXBF
drivers.
Use the Volume Explorer
to deconfigure a CXBF device, deleting a subclient does not deconfigure CXBF
devices for a client.
Raw volumes are not automatically configured as CXBF devices when added to
the subclient content. Use the Volume Explorer to configure raw volumes as CXBF
devices.
The Image Level iDataAgent
for Solaris works with VxVM version 3.1 or higher.
Unlike a File System iDataAgent,
the Image Level Agent backs up extents on the source drive. The extent size is
initially set to 512KB for Windows. The extent size can be configured to be
larger than 4GB using the
BackupExtSize
and BackupExtSizeHigh
registry keys. For
Unix, the default extent
size is 2MB (the Unix GUI will display
4096 because 4096 x 512 bytes equals 2MB).In most cases, the default
extent size effectively divides the source volume and is best for
performance.
But there may be reasons for increasing or decreasing extent size to improve
performance. Keep in mind, for example, that a 512KB extent with just 10KB of data is backed up
entirely, including its empty blocks of data. Again, this will work fine in most
cases, but factors such as the state of data fragmentation on the source,
network bandwidth, and server speed should be considered. These factors, along
with extent size, can impact both the speed and the size of backups. These
factors, along with extent size, can impact both the speed and the size of
backups. If for some reasons the extent size is required to be changed, see
Change extent size
for Backup Applications for
more information on changing extent sizes.
If performance is inhibited because of extent size issues, contact your
software provider for more information about tuning your software for maximum
performance.
Also consider the following implications of changing extent sizes:
Backup extent size must be uniform across source and destination
computers.
In a clustered environment, all the physical nodes must have the same
Backup extent size.
Backup extent size should not be larger than the size of the volume.
For Image Level on AIX, Linux or Solaris, the extent size can only be changed
when the CXBF device is configured. Thus, to modify the extent size of an
existing CXBF device, you must first deconfigure the CXBF device and then
configure again.
When configuring a CXBF device from
Volume Explorer
for Image Level on Linux, the
value entered must be a power of 2. Using a value which is not a power of 2
will cause the CXBF device configuration to fail. By default, the value is
4096; examples of acceptable values would be 128, 256, 512, 1024, 2048,
4096, 8192, 16384, 32768, etc.