When a ShadowProtect image fails to verify, please follow these instructions:

One of the primary roles of ImageManager is to run immediate verification on an image and subsequent verification according to a schedule. When ImageManager fails to verify an image, it does not necessarily mean that there is corruption, but a thorough investigation is recommended before simply applying a solution.

When ImageManager fails a verify, a log of failures is stored in a {base image name}bad.log file in the managed folder. The presence of a critical image in this log file will prevent ShadowProtect from creating future backups on that particular chain.

Corruption is of course a very scary word. It’s one that we hear very rarely at StorageCraft. When we have heard it, it has generally been related to hardware failure or other software failure. But when we created ShadowProtect, we have had several development rules that have prevented ShadowProtect images from suffering corruptions due to StorageCraft software.



  1. Backup Image Files can only be written to once. In other words, the image file is created, the backup data is written and then the image file is closed. The backup image file is never opened for write access again.

  2. Related to rule number one, any tool that must add data to an existing image must do it in an incremental file. For example, when mounting an image file for read-write access, all changes are stored in a separate file, the original image(s) is opened for read only access and a write buffer file is created to store all new writes.

  3. Only the backup data for a single volume is stored in a single file. For good or bad, our files represent only data for one volume. This is also related to rule 1. Each partition is backed up independently of each other and would require reopening an image file to add a different volume’s data.
    When backups images are saved to a local drive, like an internal or USB drive, the file system is very, very good at detecting any type of write failures during a backup. If Windows did not do this, Windows would quickly cease to exist.

The possibility of corruption during a backup to local drive is very low. Have we seen it? Yes, Western Digital MyBooks don’t work well with HP machines. This was tested with and without StorageCraft and it is very repeatable. We don’t recommend the combination. (This issue has now been resolved)

When saving backups to network shares, you are dependent on a few things, the transport and the file server. In a Windows environment network and server, we have seen very few corruption events. Windows again is very good at detecting failures. We have seen more in the NAS world. Not all NAS devices are equal. There are some very cheap NAS devices. If backups are important to you, avoid cheap storage. But if you do opt for the cheaper route, test it thoroughly with large files. There was one NAS that would only corrupt images that were between 2-4 GB, but not 5-6 GB, then again from 7-8 GB, but not from 9-10 GB. Test, test, test.

When saving to removable media such as DVD, we highly recommend you use good quality media and again, test, test, test. Cheap DVD media is cheap. Just because you’ve copied many DVD movies doesn’t mean it will work for data. Movies don’t care about corruption; they keep playing right through it. Backups do care.

If an image file is corrupt, it most likely will fail to restore. This depends a bit on where the corruption is in the file, but each part of the file is important and linked to one another so if there is corruption, ShadowProtect will probably fail to restore.

Important: ShadowProtect mounting tools are not so picky. Even if an image is corrupt, in most cases it will mount and you should be able to retrieve some data from it. Even some of the volume recovery tools will work against a mounted volume. Corruption either happens during the backup or long after the backup. If the Backup image file verified once correctly, nothing that ShadowProtect does would corrupt that file after it has been created.

Corruption after the fact is caused by disk issues or software issues. Disk issues include sector rot and general drive failures. Most common software issues would include file system corruption where applications are allowed to write over the top of sectors that are in use, but part of an image file.

Verify run from the system that is to be restored usually picks up any corruption that could occur during the restore. A verify from another machine may not pick up issues related to corruption by the transport during restore. But we rarely see corruption issues. If we have, it has 99.99% of the time been related and traced to the hardware with events to backup the hardware failures.

It is a good idea to verify your image files from time to time. Generally, corruption issues don’t come and go. They are either already there and haven’t been exposed yet or they come and don’t leave.

Always check your event logs. Don’t let any disk related events go unexplained or un-fixed.

Solution:
When an image fails to restore or fails to verify regardless of whether it passes a manual verify inside the ShadowProtect UI, an MD5 verification by Image.EXE or a thrid party MD5 checker is recommended.

To run a manual verify using image.EXE:

NOTE: If your image files are stored on a network location you will need to mount the network location to a local drive letter before proceeding.



  1. Open the Command Prompt (Run > CMD)

  2. Navigate to C:\Program Files\StorageCraft\ShadowProtect (C:\Program Files (x86)\.. on x64 machines)

  3. Run the following:

    >Image.EXE

    This will give you a list of proper command line usages for Image.EXE For this particular instance we will be using the following:

    In this example we will scan the .MD5 text file D:\Backups\C_VOL-B001-i001.md5 and verify that the text hash contained in this .MD5 file matches the calculated hash of the data file which is referenced by the .MD5 file.

    Example:

    >image v "D:\Backups\C_VOL-b001-i001.md5"

    At this point if the image verified successfully using this method, then it is safe to remove the newly verified image from the bad.log file. This will allow ShadowProtect to continue running backups on a given chain if it had been interupted and ImageManager will again run a verify on that image according to the schedule it is given

    If an image fails to pass the ImageManager Verification a second time, please perform a thorough investigation and diagnostic for all volumes involved. It is very likely that the image is indeed corrupt and should not be trusted for disaster recovery purposes.