How to avoid backup bad luck this Friday the 13th

Posted at May 12, 12:00h in backup Jack Mansfield, Marketing Categories: backup, viboot, winpe, winre, Verify backup, verification

Many things are associated with bad luck: black cats, breaking a mirror, Friday the 13th and data integrity errors, just to name a few. The superstitions around black cats, broken mirrors, or Friday the 13th are unfounded but data integrity errors are definitely something to be scared of. This is, perhaps, never truer than with a backup file. Since this day has been inextricably linked with bad luck, we’re sharing some tips so that you don’t have to roll the dice on your data’s integrity.

What causes data integrity errors

Unfortunately, storage is not infallible. All storage devices have the potential to break. From stress induced leakage for an SSD to a head crash and platter damage for a HDD, there are many problems that can affect our data on a storage device, even a faulty motherboard or memory can affect how our data is read and written.

When Macrium Reflect performs a backup, as the data is read from the source disk but before it is written to the destination, a hash is created for each block of data and stored in the index of the resultant image file. This hash is a unique string of characters that represents the data that is stored in that block. An image is considered corrupted if a new hash is generated for the block of data and it does not match the original hash that is stored in the index. This means that the data contained in the image is not the same as the data that was read from the source disk. This is known as a verification failure and the data has been corrupted.

The leading cause of a verification failure is a hardware fault. The most likely suspect is the storage media that the image is located on, however, memory and motherboard faults can also cause a verification error. For example, if your image is stored on a HDD, physical damage to the magnetic surface of the platter will affect how the data has been physically stored on the disk. This is similar to how a scratch on a CD may cause a song or part of a film to ‘skip’. When the CD player is unable to read from a broken track on the disk, it will skip to the next section of data it can read successfully. Unfortunately, due to the nature of backups, data integrity errors are much more problematic than for a song or film. We wouldn’t be happy with the restore process simply skipping unreadable data, as this data may contain important information to us or to the operating system and file systems we are restoring. This is why you will receive an error when attempting to restore an image where corruption is detected.

How to mitigate verification errors

The best way to mitigate the risk of verification errors is to have multiple copies of your backups stored on different media. In the event that one storage media experiences a hardware fault leading to a verification error, the image can be restored from a different storage media. This can be done by scheduling multiple images using different media as the destination. Alternative locations can also be used, if the primary backup location is unavailable, then the next destination in the list will be used, if that is unavailable then the third destination in the list will be used, and so on. This can be used to rotate the destination where the images are stored. If an incremental or differential has been specified, but the destination has rotated and a backup set cannot be found, a full image will be created instead and a new backup set will be started. The end result is that each destination that is being rotated will have its own backup set. In the event of a disaster, a backup can be restored from any of the media that are being rotated.

Macrium Reflect’s scripting features can be used to automatically synchronize two folders using Robocopy. This will ensure that you have a redundant copy of your backups in the event that one of the image sets becomes corrupted. 

Backups should be regularly verified to check the integrity of the backup. If the image verification succeeds then you can be confident that the data stored in the image is the same  as data that was read from the source disk. For a more visual representation that the image can restore successfully, Macrium viBoot can instantly boot a Hyper-V or VirtualBox virtual machine using one of your image files. If the image successfully boots as a virtual machine, then you can be confident that it can be restored to your hardware. 

We also recommend that the ‘Verify image or backup file directly after creation’ option is enabled in the Macrium Reflect Defaults and Settings. The integrity of the image will be verified immediately after creation, this will ensure that no errors occurred during the image creation. 

Note: Enabling ‘Verify image or backup file directly after creation’ in the Macrium Reflect Defaults and Settings will only enable this for newly created backup definition files. Existing backup definition files will need to be edited manually to enable this setting. Existing backup definition files can be edited in the ‘Definition Files’ tab of Macrium Reflect.

In the event that an image is corrupted and you have no other copies of the image to resore, the DiskRestore utility can be used in the Macrium rescue media to restore the corrupt image. The DiskRestore utility will continue the restore in the event that a corruption error is detected. It should be noted that due to corruption of the source image, some data loss may occur when the image is restored. If the data loss affects file system metadata or key operating system files, this may negatively impact system stability.

This knowledgebase article contains more information about verification failure and steps to troubleshoot the issue if a verification error occurs.

Final Thoughts

This Friday the 13th, a day forever associated with bad luck, take a moment to verify or viBoot your image files. Although the day may still be unlucky, we can avoid this bad luck when it comes to recovering from disasters.


Previous Post

How to implement the 3-2-1 backup strategy

Next Post

Imaging Windows Hyper-V Virtual Machines