Check out these six ways to mitigate corruption and bounce back from a server crash.
The Windows Server Backup (WSB) utility built into Microsoft’s server operating systems is not a particularly robust tool for managing system backups. The no-frills design (and similarly stripped-down command-line inputs) makes it suitable only for system-level backups, leaving room for little else in terms of bells and whistles.
As an application that makes it easy to create backups, the utility is capable of, and when properly configured, provides a free and easy way to back up data to a server, supporting several different modes, including one that captures system state data and offers push-button restore. of this data, attributes and metadata through the use of catalogs (see XML files), which ensures that the data returns to its original location.
However, what do you do when an apparently successfully completed backup cannot be restored due to a failure or corruption in the catalog file that acts as a table of contents for the entire backup set? After all, if the utility can’t read the catalog, the whole restore fails, right?
SEE: Windows Admin PowerShell Script Kit (Tech Pro Research)
Not necessarily, and in the sections below we’ll discuss steps IT departments can take to mitigate corruption and bounce back from a server failure.
1. Save Backup
It might seem a little redundant, but if you’ve verified that the catalogs are corrupt, you might still be able to restore the data located in the archives with a few tweaks. But you don’t want to try a number of solutions on your backup archive alone, so make a copy of it before proceeding.
2. Retry the restore on another server
Sometimes, when creating a backup of a server, certain variables affect the performance of the backup utility, such as the type of operating system, updates performed on the server, or problems with the equipment.
Trying to perform the restore process on a different server may offer a solution, as any combination of factors listed above may be different enough to allow the process to run and complete successfully.
SEE: Cross-site scripting attacks: A cheat sheet (TechRepublic)
3. Mount the VHDX file in the archive
In the archive itself, you should find the hostname of the device you were backing up. Digging deeper, a VHDX file (or Virtual Hard Disk) will be present. This file will contain all data that was successfully backed up. WSB uses VHDX file format to store data as it is easily transported and can be mounted by most modern Windows operating systems.
An added benefit of this format is that it can be imported into a virtual machine for easy recovery if a server goes offline. This helps tremendously in getting the server back online. For the purpose of data restoration, the VHDX file is versatile enough to be mounted on any desktop to extract the actual hardware data from the archive. Again, since catalog files are corrupted, file specifics such as permissions and metadata may be unrecoverable, but the next steps explain how to work around this problem.
4. Audit your file/share/security permissions
Since the catalog and XML files are susceptible to corruption, it is important to have a fallback after restoring the data so that the proper ACL permissions can also be restored and the data can be accessed once the server is back online.
Using commands such as ICACLS, IT can preemptively export critical data ACLs to files, which can then be re-imported after the data is restored to ensure proper permissions are restored. Although the best time to perform these audits is before discovering that a restore did not work on corrupted catalogs, it is still recommended to document the permissions settings just in case.
5. Check integrity of critical file data
File this entry under “should be done before”. Running an integrity check or checksum on files, especially critical data, is an optional but very important step for IT to perform as it attests to the integrity of the data and creates a unique hash value for each file. As data is restored from backup, it can be checked against the generated hash values to determine if the original file has been modified (in which case it is likely corrupt and untrusted) or has retained its integrity and remains unchanged.
6. Perform Backup Restore Tests Regularly
This last suggestion does not directly protect against data corruption, but it can help mitigate it by performing backup restores in a test environment. IT can detect potential issues during these simulations. If a problem is detected, corrective actions can be implemented to ensure that data backup and restore procedures go as planned.
If the tests verify that backups and restores work as expected, corruption and data loss issues can be reassured until the next phase of testing. After all, the last thing you want to encounter when you need to restore data is to find out that the backup is corrupt and as a result the data is lost or unrecoverable.
Key points to remember if you suspect backup catalog corruption
- Never work on the original save file. Make a backup of the archive first.
- Try restoring to another workstation or server.
- Backup data stored on a virtual hard disk simplifies recovery or mounting as a virtual machine.
- Keeping a copy of ACLs can help restore them in the event of a catastrophic loss.
- Comparing file hashes confirms if files have been modified/data loss has occurred.
- Regularly testing backups/restores ensures that data loss is kept to a minimum.