MR6 backup fails due to CRC errors, but DS succeeds!

This past week I installed MR6 Free Edition on one of our school's PCs. The first time I attempted to backup the C-drive (to external USB HD) it ran for a few hours and ultimately failed due to (reportedly) CRC errors. A 2nd attempt with MR 6 also ran for a few hours with the same failure. I then attempted the backup with Drive Snapshot and it succeeded (with verification) in less than an hour!

Since CRC errors could be indicative of a failing HD, a situation prompting a backup image ASAP, I find it curious (if not disturbing) that MR6 would not complete the backup by ignoring any unreadable sectors.

 

Wendi, MR6 will only ignore bad sectors if the option to do so is set in "Defaults/Advanced/Advanced Backup Options/Ignore bad sectors when creating images."

 

Froggie, thanks for that tip! Next week I'll try the MR backup again with the Ignore Bad Sectors option set. I still find it interesting that DS accomplished the backup without having to change its default settings.

 

I'm not sure that's "interesting" or really scary. If that disk is in really bad shape, DS shoulda said somethin'.

 

A quick look at their "Advanced options" shows no ability, one way or another, to deal with broken sectors... my guess, DS ignores faulty sectors as part of its design. If true, that's very scary!

 

I'm not so sure yet that the HDD is in 'really bad shape'.

 

Right you are Pete. I hope to do just that sometime next week.

 

Pete, along with that thought, I will be repeating the MR backup with the Ignore Bad Sectors option enabled (per Froggie's tip). If that doesn't result in a successful backup, I'll download and try an IFW backup before attempting the DS restore.

Good night.

 

Wendi,

If IFW detects bad sectors during the backup it will pause and say something like, "Read errors, ignore and continue?". I've seen that with a few HDs and a restore has been successful.

 

Of course the restore will be successful... bad DATA is being restored to the surface of a good disk with good written parity and disk error correction codes! Of course if that DATA is needed in a very important place (like in the middle of the $MFT or some very important System driver), your System will not be so attentive to your needs. If it winds up in the middle of some innocuous DATA file (an Adele song ), nobody will ever notice it (except for that scratch sound while listening).

A successful restore is not a measure of a good image... it's just a successful restore. I would much rather know that a problem exists while the image was being made and allow me the decision as to what to do... like Brian mentions above with IFW.

 

I don´t see any suggestion to run chkdsk, which I think is the first thing to do if the imager reports this kind of problems.

 

From the DS Devs on the issue...

we try to read bad sectors and, if possible, to continue the backup.
You will get a message in the log and in the GUI if a bad sector is
detected. All bad sectors are listed in the file "BadSectors_X.txt"
where X is substituted by the drive letter of the drive containing the
bad sector.

Hope this helps!

 

I can find out if needed. I assume the "BadSectors" file is probably at the ROOT of the drive being imaged (I know, a bad place for that kind of information). Other DS users can tell us where the LOG is (I don't use it at the moment) since there's one probably generated for each operation.

 

The "BadSectors" file is actually written into the same target folder as the image is (<whew!> I'm glad it's in the right place )

 

I have not used DS on a drive with bad sectors, but it does warn the user if there is a CRC error during verify (and if it can, it will ask the user if would like to correct it). It happened on a system with bad ram modules.

Panagiotis

 

Unless DS is writing some sort of multibit ECC correction code (not just a hashed verification code) with it's image, I'd sure like to know how they're able to do that (not having access to any direct drive-level detection/correction info).

 

I have no idea how they did it. At the time I thought that they use/add some kind of recovery record when creating the image similar to rar or par recovery settings.

I don't know. I always use "autoverify" in all the imaging aps and do not know how DS behaves if the image is not verified.

Panagiotis

 

Pete,

Do you restore the image to another HD and check if the OS boots?