To back up the Agent systems in my network, I had to create a policy for each machine. A wizard steps you through the policy creation process. Agent policies determine many aspects of LiveVault's behavior. Within a policy, you can configure characteristics such as file filters, bandwidth usage, registry and system-state backup intervals, database consistency detection, and the minimum frequency at which LiveVault saves open files to tape. (Figure 2 shows the bandwidth-usage options.)
You configure global settings, which affect how all policies function, at the server level. LiveVault's global settings include tape recycling and retention schedules and global file filters, which are useful for preventing backup of useless data (e.g., temporary directories). I used the default settings, which let each Agent consume all available bandwidth, for most of the policies. When the policy configurations were complete, the back-up jobs launched immediately.
LiveVault's first task was to synchronize the files on each client. This process uses the file-system filter to perform a block-level copy of the data you're protecting and send the data to the server. The Agent system captures and journals all changes to the data that occur during this process. After the copy process is complete, LiveVault uses the journal to update the copied data to a current state. This process can be a load on the network, so you might be wise to schedule the initial synchronization for off-peak hours.
For the first several hours of the synchronization process, the server showed a lot of activity, which I monitored through the server Management Console's Job Monitor object and the Tape Library Monitor, as Figure 3 shows. Alternatively, you can use alerts to keep tabs on LiveVault's activity. You can tell LiveVault to send SNMP traps or email, or use Net Send to notify you about specified conditions.
Restoration
After the initial synchronization, I randomly restored a couple of files to check the integrity of the backed-up data and ensure that LiveVault had transferred the data correctly. I then began the first 5-hour test cycle and watched the activity.
Midway through the first cycle, I began receiving alert notifications that the tape library needed attention. This notification marked the first of many times that I needed to address tape library problems, such as cleaning the drive and inserting blank tapes. Although these tasks are fairly routine for tape-library maintenance, LiveVault doesn't provide functionality to make these tasks easier.
Also, LiveVault's attempts to make tape management ultrasimple results in limited flexibility in library management. As long as things are running smoothly and you follow the instruction of the software's wizards, tape management is a breeze. However, if you have preferences for how the software labels your tapes, which slots they occupy, or what data they contain, you're out of luck. This lack of flexibility became apparent when LiveVault attempted to label a bad tape. The tape wasn't usable, but LiveVault's catalog still recorded the tape as active. Consequently, LiveVault held up queued jobs, requesting that I insert the bad tape. Deleting the tape wasn't an option, and several attempts to mark it as lost caused the LiveVault Backup Service to hang. A few reboots later, I was finally able to mark the tape as lost and move on.
After the test cycle was complete, I continued to monitor LiveVault's activity while I tested restore jobs and the product's ability to save multiple file versions. The Restore Wizard simplifies the restoration process, but I was disappointed that LiveVault's catalog contained fewer file versions than I'd expected. After more testing and working with LiveVault's technical support staff, I discovered that the combination of one drive tape library, the large amount of data being backed up, and the policy settings (which were mostly default settings) were creating long queues for the tape drive. Although LiveVault did a good job of backing up the most recent versions of files to the disk cache, many versions that would ordinarily have gone to tape didn't because of the long queue. (The ability to prioritize queued items isn't a LiveVault feature.) Nonetheless, I was able to restore the few versions in the catalog without a problem.
My first attempt to restore the 16GB Exchange Server priv.edb file failed as a result of disk space constraints on the server. Initially, I had a hard time believing that I'd consumed 50GB of disk space, then I discovered that LiveVault reads restore jobs to disk cache before sending the jobs to the target machine. As a result, I was loading a 16GB file into disk cache alongside 24GB of current Exchange Server data and several gigabytes from the other Agent systems. To work around this problem, I disabled the policies for the Exchange Server system to let the disk cache clear, then I restored priv.edb without problems. I asked LiveVault's technical support staff about the disk cache sizing problem, and they acknowledged that the disk-space calculator has some inaccuracies and explained that the company's sales engineers usually discuss server sizing requirements with customers before a purchase.
After I modified the Exchange Server system's backup policies, I ran another set of tests in which LiveVault wrote backups to tape once per day rather than four times per day. This modification decreased the load sufficiently to let LiveVault save multiple document versions. I then performed restores of several document versions, including versions of Sysmon logs that had been open throughout the test cycle. Figure 4 shows the time-slice restore versions that the Restore Wizard offered. Each restore accurately reflected the correct version. I also experimented with bandwidth throttling on some of the Agent systems. Reviewing their Sysmon logs after a test cycle, I found that the Agent systems transferred data within the limits I set. Finally, I successfully restored the system state on two of my Win2K Agent systems.
Evaluation
Although I ran into a few glitches, LiveVault's core functionality met my expectations. By backing up in realtime the fairly small amount of data that actually changes, LiveVault takes a unique and promising approach to backups. Yet this product has a lot of room for improvement (e.g., more flexibility and functionality with tape-library management).
In addition, this product requires ample hardware headroom. An undersized disk cache or tape library will cripple performance. However, a properly scaled LiveVault installation will provide up-to-the-minute backups of your crucial data. If you need that type of functionality, LiveVault is unquestionably worth the price.