 | |||
|
|
||
| |||
| |||
| |
|
Home > Backing up Exchange Server with Microsoft VSS |
| |
|
|
|
|
| Crash Course: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||
Part 1: Microsoft VSS advantages Microsoft VSS allows files to be backed up, even if they are open. Traditionally, most lower-end Exchange Server backup utilities simply pass over open files because of the complexity involved in manipulating file locks. VSS also provides file versioning through frequent, non-disruptive backups. The Exchange Server backups are non-disruptive because it no longer matters whether or not files are open. This means that you are no longer limited to running backups late at night when nobody is in the office. Instead, you can run multiple backups over the course of the day. If a file changes during the day, it is possible to capture various versions of the file. For example, if you were performing hourly volume shadow copy backups, then you could perform a restore in which you tell your backup software to restore a particular file to the state in which it existed at, say, 2 p.m. Part 2: Limitations of Microsoft VSS Before implementing Microsoft VSS backups on your Exchange Server, you should consider the following limitations: The NTBACKUP utility fully supports the use of VSS backups. However, when you toss Exchange Server into the mix, things get a little complicated. NTBACKUP can back up an Exchange server, and it does support VSS backups -- but it does not support VSS backups for Exchange. For that, you need a relatively high-end, third-party backup application. You cannot perform Microsoft VSS backups of individual Exchange Server databases. You can only back up entire storage groups, because all the databases within a storage group share a common set of transaction log files. You can restore an individual database within a storage group, but to do so, you have to dismount the entire storage group. Another limitation has to do with Exchange servers that contain multiple storage groups. Microsoft VSS allows you to create backup jobs that back up multiple storage groups. However, you cannot simultaneously run multiple VSS backup jobs even if you create a separate job for each storage group. When you perform a VSS backup of an Exchange server, your existing backup hardware might not be up to the job. A normal, non-VSS backup works by streaming data from the server to a tape drive or disk-based backup. Microsoft VSS works by taking a snapshot of the Exchange information store and placing it onto a network volume. The reason for this process is that the database must not be modified during the Exchange server backup process. At the same time though, VSS tries to keep the database accessible to the users. To accomplish this, it places a lock on the databases and transaction logs within the information store that is being backed up. Once these resources are locked, VSS creates the snapshot as quickly as possible and unlocks the storage group. Users are never forced to disconnect from Exchange Server and usually don't ever realize that anything has happened. Messages that are sent or received during this time are held in a queue until the storage group is unlocked. The snapshot itself is a read-only image of the storage group. Because the image is read-only, the backup software doesn't have to worry about changes being made to it while it is being backed up to tape. The point is that you aren't going to be able to perform a VSS-based Exchange backup directly to tape. You need a high capacity, high performance disk volume to which you can write the snapshot. Microsoft recommends using a Storage Area Network (SAN) for this purpose. From there, the information can be dumped to tape -- but that part is optional. Part 3: Data integrity issues affect VSS Exchange backups There is nothing related to the VSS backup process, per se, that will cause database corruption (short of a virus, hardware failure, etc.). However, if your Exchange organization already contains corrupt data, then performing VSS backups can lead to problems down the road. When you run a normal Exchange Server backup, the backup software individually reads each page of the database that's being backed up. Older versions of Exchange simply streamed these database pages to the backup tape, but Exchange Server 2003 computes a checksum of the data contained within each database page and compares that value to the stored checksum value. If the two values match, the data is considered good and is written to tape. If the checksum values do not match, the page is considered damaged; the backup software will take steps to purge the damaged data so it's not backed up. With Microsoft VSS backups of Exchange Server, things work differently. The backup consists of a snapshot of the storage group. Since the backup software is simply making a snapshot, rather than streaming database pages to tape, the backup software never gets the chance to confirm the integrity of the data within the database. As a result, damaged database pages could be backed up. If the problem is left uncorrected, over time, all of your backups might contain some corrupt data. So what are the consequences of backing up corrupt Exchange server data? In Exchange 5.5, it was almost impossible to restore a database that contained corrupted pages. Exchange Server 2003 makes the restoration process a lot easier, but you still have to use ESEUTIL to repair the database before mounting it. If you've ever used ESEUTIL to repair a database, then you know it involves significant downtime and at least some data loss (at a minimum, the pages with corrupted data are deleted). On the other hand, suppose that only your most recent backup contains corrupted data. You could easily get rid of the corruption by restoring the next most recent backup and then using the transaction logs to roll the database forward to a current state. Even though this operation takes some time, it is still usually a lot faster and less risky than trying to restore and repair a corrupt backup. According to Microsoft, it is the responsibility of the company that makes the backup software you are using to perform a database integrity check upon completion of the backup. However, rumor has it that some VSS Exchange backup applications skip this step. Part 4: Performing manual data integrity checks It is important to occasionally check the health of your Exchange Server databases if your VSS Exchange backup application does not do it for you to make sure you are not backing up corrupt data. You can perform a manual integrity check by running the ESEUTIL /K command against any Exchange database in question. The /K switch on the ESEUTIL tells the utility to verify the checksums of the database you've specified and the corresponding streaming file, checkpoint file, and log file. Keep in mind that if the database is in a "dirty shutdown" state, the checksum values cannot be verified. After running the ESEUTIL /K command, I recommend entering the echo %errorlevel% command to display all the error levels reported by ESEUTIL. If all error levels are positive numbers, then you are in good shape. But if some are negative numbers, it means that corruption exists within the Exchange server database and you need to repair it.
|
|
|
|
|||||||||||||||||||||||||||
Part 1: 
Brien M. Posey, MCSE
|
|
 |  |  | |  | |  | |  | |  | |  | |  | |  | |
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
