How to restore Windows Server backups from corrupt catalogs

Check out these six ways to mitigate against corruption and bounce back from a server failure.

istock-855752978.jpg
Image: fizkes, Getty Images/iStockphoto

The Windows Server Backup (WSB) utility built-in to Microsoft's server OSes isn't a particularly robust tool for managing system backups. The no-frills design (and similarly bare-bones command-line entries) makes it suitable only for system-level backups, leaving room for little else in the way of bells and whistles.

As an application that facilitates the creation for backups, the utility is capable and when configured properly offers a simple, free way to back up data on a server, supporting several different modes, including one that captures system state data and offers push-button restoration of this data, attributes, and metadata through the use of catalogs (see XML files), which ensures data returns to its original location.

However, what do you do when a backup that seemingly completed successfully cannot be restored due to a failing or corruption within the catalog file that acts as a table of contents for the entire backup set? After all, if the utility cannot read the catalog, the entire restore fails, right?

SEE: Windows administrator's PowerShell script kit (Tech Pro Research)

Not necessarily, and in the sections below we'll tackle things IT can do to mitigate against corruption and bounce back from a server failure.

1. Back up the backup

This may seem a bit redundant, but if you've verified that the catalogs are corrupt, you may still be able to restore the data located within the archives with some finessing. But you don't want to try any number of solutions on your sole backup archive, so make a copy of it before proceeding.

2. Retry the restore on another server

Sometimes when a backup is created of a server, certain variables affect the backup utility performance, such as OS type, updates performed on the server, or hardware-related issues.

Trying to perform the restore process on a different server may offer a solution, given that any combination of factors listed above may be different enough to allow the process to execute and complete successfully.

SEE: Cross-site scripting attacks: A cheat sheet (TechRepublic)

3. Mount the VHDX file within the archive

Within the archive itself, you should find the hostname of the device, which you were making a backup of. By drilling down further, a VHDX file (or virtual hard disk) will be present. Contained within that file will be any data that was successfully backed up. WSB utilizes the VHDX file format to store data as it is easily transported and may be mounted by most modern Windows OSes.

An additional benefit to this format is that it may be imported to a VM for simple recovery if a server goes offline. This aids tremendously in getting the server back online. For the purposes of data restoration, the VHDX file is versatile enough to be mounted on any desktop to extract the actual hard data from the archive. Again, since the catalog files are corrupt, file specifics such as permissions and metadata may be unrecoverable, but the next couple of steps cover how to work around that.

4. Audit your file/share/security permissions

Since the catalog and XML files are prone to corruption, it's important to have a fall back after data is restored so that the proper ACL permissions can also be restored, and data is accessible once the server is back online.

Using commands such as ICACLS, IT can preemptively export the ACLs for critical data to files, which can later be re-imported after data restoration occurred to ensure that proper permissions are restored. While the best time to perform these audits is before finding out a restore didn't work out to corrupt catalogs, it is nonetheless a best practice to document permissions settings just in case.

5. Verify the integrity of mission-critical file data

File this entry under the "should be done before." Performing an integrity, or checksum on files--especially mission-critical data--is an optional, yet very important step IT should perform as it attests to the data's integrity and creates a unique hash value for each file. As data is restored from backup, it can be checked against the hash values generated to determine if the original file has been modified (in which case, it is likely corrupt and unreliable) or has maintained its integrity and remains unmodified.

6. Perform backup restore testing regularly

This last suggestion doesn't directly protect against corrupt data, but it can help to mitigate it by performing back up restores in a testing environment. IT can detect potential issues during these dry runs. If a problem is found, then corrective actions can be implemented to ensure that data backup and restore procedures occur as intended.

If testing verifies that backups and restores work as designed, then corruption and data loss concerns can be reassured until the next testing phase. After all, the last thing you want to encounter when needing to restore data is to discover that the backup is corrupt and therefore, data is lost or unrecoverable.

Major takeaways if you suspect backup catalog corruption

  • Never work on the original backup file. Make a back up of the archive first.
  • Try to restore on another workstation or server.
  • Backup data stored within a virtual hard disk simplifies recovery or mounting it as a VM.
  • Keeping a copy of ACLs can help restore them in the event of catastrophic loss.
  • Comparing file hashes confirms if files were modified/data loss occurred.
  • Regularly testing backups/restores ensures that data loss is kept to a minimum.

Also see