Way to continue image backup? (Data error (cyclic redundancy check))

Hey All,

I am running urbackup server 2.3.7 and client 2.3.4, at home and at work, backing up about 30 hosts in all.

I am running both file and image backups periodically.

Every now and then, I find the image backups fail for one or two machines. The error is:

Error on client occurred: Error while reading from shadow copy device (1). Data error (cyclic redundancy check).

Now if I replace the hard drive, re-install windows, and restore files from the latest file backup all is fine. The problem is, that takes a lot of time. There probably is a bad spot on the drive, but it is not affecting client operations in any way. It would be great if urbackup could still create a backup image of the drive even with the bad spot.

FYI, I have enabled the option in settings: Do not fail backups in case of hash mismatches or read errors

It would be great if this could be a warning instead of a fatal error. Not sure if its even possible…


While possible, I’m not sure this would be sensible, because the backup would be clearly missing data.

The thing to do would be to force the disk to reallocate the sector, by identifying the bad sector, then overwriting it with random data (preferably after telling you which files are affected). I have googled for a Windows utility that does this before, but haven’t found any. Perhaps you have more luck, or someone else knows of one? (On Linux I’d use the non-descructive mode of badblocks).

True, but like I said, the client machine is running just fine, so yes the bit of data is missing, but it is not important to the operations of the machine.

Also the bit of data that is missing is not part of the user data, or the file backups would return a warning or fail.

I’m pretty sure simply re-imaging the disk will cause the disk to avoid the bad sector. The case I am looking at now, the disk is an intel SSD. I downloaded the intel disk utility and it also shows there is a bad sector. It doesn’t provide a way to correct it though.

So if urbackup would just complete an image of the disk, I could then write that same image to the same drive, causing the disk to avoid the bad sector. That bit of data would still be missing, but it doesn’t seem to matter in this case, and would save me time and money. (I wouldn’t replace the disk yet)

As another data point, I’ve seen another machine with this error and because consumer disks retry reading for up to 30min it had 30min Windows hangs.

Yeah, like described here: https://superuser.com/a/688764/89138 If you find an utility that only writes zeroes to the bad blocks (as I said), you wouldn’t have to re-image the whole thing.

Yes, a utility to write only zeros over bad sectors would be nice.

I suppose I can go into the settings and create an exception for this machine to skip image backups. It will only get file backups until I actually need to replace the disk.

You could always use the primitive old-school approach, CHKDSK /R which should mark the bad spot not to be used. I can’t say for UrB but every other imaging solution I’ve tried copes then.

Re-running CHKDSK afterwards with the /B switch (re-evaluate any sectors maked bad) may induce such a write.

Writing zeros to only one sector is doable with Linux, you’d use fsck or badblocks to identify the block then use dd with appropriate values for bs (blocksize) skip (how far up the drive) and count=1 (only write one block)

Personally I’d avoid the chance of errors in the above Linux operation, & simply sacrifice one write cycle per cell… use a drive wipe utility, one pass, and restore most recent backup, yes you write zeros to all sectors, but you get the one you need, assuming the two passes with CHKDSK didn’t sort it that is.

Client 2.4.x ( https://forums.urbackup.org/c/testing ) now contains a tool that reads in all disk sectors, prints out the unreadable ones and can overwrite them with zeros.

At “C:\Program Files\UrBackup\scrub_disk.bat”


See this blog post for a detailed explanation and how to solve the problem: http://blog.urbackup.org/319/how-to-handle-data-error-cyclic-redundancy-check-system-error-code-23

I hate to revive an old topic, but it’s right on point. I’m having this issue, but the batch file doesn’t seem to cope with writing zeros to the bad blocks.

2021-01-27 15:09:26: Reading volume. 99% finished
2021-01-27 15:09:26: Re-reading blocks with errors with smaller block size (4096 bytes)...
2021-01-27 15:09:26: Error block position 73560729 error 0/1
2021-01-27 15:09:35: ERROR: Reading from device at position 301304745984 failed. System error code 23
2021-01-27 15:09:35: ERROR: Block 73560729 has read error
2021-01-27 15:09:35: Volume has 1 read errors
Search through all file extents to find out which files are damaged? Y/n
Overwrite damaged blocks with zeros? y/N
2021-01-27 19:38:55: Zeroing sector of volume C at position 301304745984...
2021-01-27 19:38:55: ERROR: Error writing to volume C at position 301304745984. Last error: 5
2021-01-27 19:38:55: Zeroing complete.
Press any key to continue . . .

I’m guessing it means this disk can’t be zeroed here… Can you decode Last error: 5?

If it’s a standard Win32 error code, 5 would be “access denied”, did you run the batch as Administrator? Though reading it it should error out if you didn’t … That said, windows is kinda testy about users trying to lock volumes for that sort of access, particularly the system volume.

I’d attempt doing chkdsk /scan /r as administrator, if that detects the faulty sector (it should) it will force a reboot for repairs if it’s on the system drive, since even it can’t do them on the system drive with Windows running.

1 Like

Thanks @Bearded_Blunder, that did the trick. Now I am able to get a full image backup :slight_smile:

Running as administrator or chkdsk? It’d be weird if a non-admin user could read the whole volume…

@uroni, I ran the batch as admin when it errored. The chkdsk was what worked, and it had to schedule an offline / reboot to fix the bad spot. You’re right, would have been kinda odd to have that sorta access.

I’m having the same issue. My SSD can’t read few sectors but they don’t contain any data. Acronis does image backup just fine while UrBackup does not. Yeah, I know I need to replace this SSD but for now I’m OK with what I have. It would be great to have an option to skip bad sectors during the backup process. UrBackup may log which sectors were skipped and which files were affected and that would be totally fine and I thing UrBackup must have such option.

It might be worth you trying chkdsk /b on the affected ssd, that should cause the SSD firmware to map any bad cells out & windows to map replacements back in. Might not work, but the only thing lost trying is the time while it reboots & scans even if it doesn’t help.

It does map bad sectors (all unallocated) but UrBackup still fails to create disk image with “Error on client occurred: Error while reading from shadow copy device (2). Data error (cyclic redundancy check)”. There have to be an option to skip bad sectors!

The point is the /b switch tells chkdsk to retest those sectors, hopefully the drive firmware does a repair as it’s designed to in that situation, if this was a spinning disk rather than an ssd I’d be suggesting booting Linux & running badblocks in non-destructive read-write test mode instead, in order to write to the bad blocks, which should force a firmware replacement from the pool of spares, but that test is really heavy writing & not suited to solid state storage, although there doesn’t seem a lot to lose at this stage in using up some write cycles…

Short of breaking out a disk editor, or trying the batch job mentioned up this thread, I know of no native Windows tool to force a write to those sectors once they’ve been marked bad, but that’s what’s needed.

The idea being force the drive to repair itself, if it can’t be repaired it should be replaced.

I know other backup / imaging software has an option to ignore/continue on bad sectors, & yes a switch to do so in UrBackup would be handy, but that provision, even in the others is intended to be used once only when transferring data to a new drive, not to dodge replacing one that needs it.