Client computer backup drive I/O error - what to do

[BRM 0]

My backups have not been running for a few days.  It appears I have some sort of I/O error with the drive that holds client computer backups.  The error is showing in the event logs.  I have tried moving the CCB folder to a new drive and that process fails also presumably because of this error.  I have also tried to robocopy the CCB directory to the new drive and that fails as well.  It fails on a file called GlobalCluster.4096.dat.  I tried this a few times and it always fails at the same place.

 

So what should I do here?  If I could change the location of the CCB folder to a good drive that would probably fix the problem but I can't seem to do this.  Should I run something like SpinRite or DiskCheck?  As I understand it those would lock out bad sectors of the drive and maybe allow the folder to be moved but then the backups will probably be reported as corrupt.

 

The software version is Windows Storage Server 2008R2. I know I need to upgrade.

 

Thanks in advance for any advice. 

[ikon 438]

How big is the drive that has the CCB? If it's over 2TB, SpinRite is not an option. If it's less than 2TB, then you could use SpinRite on the drive.

 

You would have to shut down the server for the duration of the testing. If the drive is 2TB, that could take more than a week (it would take less time on Level 2, but I recommend Level 4 for repairing drives like this). However, it is likely it could repair the drive without corrupting the backups.

 

SpinRite would repeatedly read the bad sector(s) until it got a good copy and then it would force the drive to allocate a new sector from the spares and write the data to the new sector. WHS would be none the wiser. In the fairly unlikely event that SpinRite could not get a good copy of the bad sector(s) then it is possible the backups would be corrupt - not guaranteed, but certainly possible.

[BRM 0]

The CCB volume is 1TB.  I'll try SpinRite and see where that leaves me. Thanks for the reply.

[ikon 438]

Be sure sure the CCB drive is the only one attached to the system - it just makes things easier. Boot the system from a SpinRite CD or external drive.

[BRM 0]

I have SpinRite running now.  Will report back when that is finished.

[ikon 438]

Cool, and thanks

[BRM 0]

I ran SpinRite at level 4 on all of the drives in the server.  There were no reported errors.  However I am still getting the same I/O error.  The backups refuse to run and that same file appears to be the problem.  Could it be that the file system is corrupt?  I don;t believe that SpinRite looks at the file system, just the drive surfaces themselves so if this file was corrupt SpinRite may not catch this.

 

I suppose there are three options as I see it.

1. Move CCB to another drive.  This corrupt file has been preventing doing this from the dashboard but I think I saw somewhere a registry hack that would accomplish this. (edit: here is a link that describes this process http://techblurt.com/2012/02/01/moving-whs-2011-client-computer-backups/)

2. Take the drive that contains CCB out of the server and force the server to start over. I am not sure what Windows would do here.  Would it "calmly" allow me to establish another CCB folder or, since it thinks that there is already a CCB folder that it now sees as missing, would it not allow this - at least not easily.

3. Replace the drive, re-install the OS and basically start over.

 

Which do you recommend?

Edited July 10, 2014 by BRM

[ikon 438]

You are correct: SpinRite does not look at file systems. You would use CHKDSK to do that.

 

BTW, SpinRite is famous for fixing things but reporting no errors. It's Steve's engineering background - he has a very strict definition of what constitutes an 'error'.

[BRM 0]

Regardless of that, the problem persists even after running SpinRite.  CHKDSK reports no errors on that drive either.

 

I suppose I will try my option #1 above.  The worst thing that can happen is that everything breaks, but its broken now so I don't see how that is worse.

[ikon 438]

Might as well give it a shot. It's still strange that you're getting an I/O error like that though.