i/o errors backing up hdd (corrupt disk?)

This is a different type of corruption than I've seen in recent posts. I am trying to backup my "Macintosh HD" to a new external FW drive, so that I can "safely" install Leopard. I bought SuperDuper! for the backup, but it failed to backup winxp.hdd due to several i/o errors. I can't copy the contained .hds file using Finder to another folder on the same drive, so it's not the new external drive. It's a 30GB file. But, I can boot from this image and it mostly works.

Next, I tried to backup the Windows XP Pro VM from within Windows using Backup. It fails on a number of files that it can't read. I've tried deleting the ones that it fails on, but it just finds others that have troubles. I have tried to do a manual copy of the important stuff, but I really want to avoid reinstalling everything in the Windows VM. Oracle and the associated application I am working on is a bitch to install...

I'm guessing the i/o errors are coming from files that are written to a bad spot on the disk.

So, I tried running Disk Utility Repair, then fsck, but they don't seem to see anything wrong. I thought about getting DiskWarrior, but wanted to get feedback from this group if they think it could "recover" the hdd file?

What does the Parallels team recommend in my case? I want to have a backup of the VM on the external drive in case of situations like this. I'm not quite completely out of the water, but pretty soon a critical file will be written to a bad spot on the disk.

Any advice on any of the following from anyone would be welcome:

* backup strategies of Parallels VMs
* real disk repair utilities that can check the disk for physical errors and mark those areas as unusable
* DiskWarrior (will it help me in my case?)

BTW, I have a one year old Macbook Pro 17", 2.16 GHz

TIA

 

Oh boy, that sounds painful...
Firstly, thank you for the detailed description of your problem, it makes the 'helping' part fun.

***Back-up Any Critical Data You Can Before Proceeding***

Alrighty, the first thing I am wondering is if the problem is with the .hdd file or your actual Hard Disk. I would get DW and see if it finds any errors. As to recovering your .hdd file, if there is an error with the directories that the filesystem makes, than yes, there is a chance. If the error is in your .hdd file being corrupted, going this route won't fix the issue.

Next up, recovering the .hdd file if it turns out that it is the one corrupted. Seeing you can't copy it, view the package contents of the .hdd file, you should see a bunch of those images, copy and paste them out... See if any one of them will work. If you find one that will not copy and paste out, but the rest will, try deleting it and see if that helps you out.

Now to back-up strategies. The way that provides the best data integrity is to stop your VM (don't suspend), and copy the .hdd file to a safe location. I have successfully recovered from my live back-ups made via cron in the past though. The frequency you back-up is totally dependent upon how much space you are willing to sacrifice. I always keep a 'safely' made back-up from a week ago on an external.

 

after I ran low on space on my MacBook Pro HD I cloned my VM to an external LA Cie
and run it from there

each weekend I reclone the clone from the parallels file menu
and delete the older clone afterwards

data I keep in shared folders


Hugh W

 

a little bit more info

Thanks for the responses so far. I will *eventually* institute a regular backup plan as soon as I can get past this last hurdle. BTW, in the winxp.hdd package I only have two files - the .hds file and the D*.xml file, which appears okay.

Okay, so I go down to the Apple Store and have a "Genius" look at my MBP. I admit that I don't trust them all, but there are one or two respectable ones. The one who helped me needed to ask a question or two from one of the trusted ones... The one thing he did do was run DW on the drive and it pointed out a couple very minor items it thought it could help with. After a rewrite of the directory, an attempt was made to copy the corrupt file. Same thing - i/o error. This lends more evidence in my mind that it is a bad sector (or many) on the disk. The genius still is not convinced that it is a hardware issue. He still thinks it might be just a corrupt "wrapper" around the real data and that Parallels is possibly at fault. My argument is that if the OS level copy doesn't work, then it's not just corrupt data and I should be able to copy that bad data as many times as I'd like. He says that he's seen situations where he couldn't copy a file and it was due only to corrupt data - not the disk. I'm willing to say it's possible, but it goes against my instincts.

So, I told him I will try an experiment whereby I (after giving up on backing up from within Windows) will delete the bad file and try to fill up the drive with new data (by copying a very large file a few times) and see if I get i/o errors at some point when it tries to write to that spot on disk. If I can show that, then I will just end up reformatting the drive. I do have a bootable clone/backup of everything except that file, so the Mac side of the rebuild will be easy. Now, I just need to get the Mac to recognize my new FW drive again, so I can keep going on with this backup entertainment. If it ain't one thing, it's another.

I'll post the results in case it might be helpful to someone else.

Rich

 

I'll be interested to hear what the root of the problem is... Come to think of it, I have seen this problem before and it turned out to be a bad .hdd file.

 

yet more details (updated)

Well, some things aren't just what they seem. I could not do a single pass "backup all files" from within Windows that included the system state. So, I tried to backup just a single folder (with lots of files in the hierarchy) that had reported issues. It backed up without error! So, I did this for the remaining folders and then the system state. It "seems" I have a good backup of the Windows system, but it's in several backup files. I am not sure what to trust anymore.

Question 1: what is the recommended order in which I should restore these after rebuilding a basic Windows VM? I have data folders, development/tools folders, other application folders, Program Files, and System State backups. Should I start with all the data and dev folders, then go onto Program Files, then System State - or the other direction?

Next, I bit the bullet and deleted the winxp.hdd. BTW, it seems that deleting from Parallels puts it in the Trash, but I couldn't see it. I needed more permissions and had to go to Terminal to remove it for real. I then filled up the disk (had less than 1MB left) with lots of copies of a big file (actually a Linux hdd). I did NOT receive any i/o errors. So, my new theory is that the HFS+ file system is smart enough to figure out during a write that when it encounters a write error, it marks the spot on disk bad and tries a new spot.

I then made another bootable clone of the entire drive (no i/o errors reported) and booted from it, just to be sure.

Last night, I realized that I should have TechTools Deluxe because I bought AppleCare. The version that came with the AppleCare box crashed twice in it's surface scan, which might indicate the drive had issues or their product had issues. So, I upgraded to v3.1.1 and am running a Surface Scan test, which will take awhile.

I wonder if it will find any bad spots on disk? I'll post the results when it completes. If my theory is correct about HFS+, then it may not see any (they would have been remapped already) and I won't be able to absolutely know for sure.

Anyone know if my theory about HFS+ is bunk for valid?

Finally, it appears I am being bitten by the swollen battery problem. It is causing the case to rest awkwardly on the desk. I guess I'll be visiting the Apple Store again - or maybe they still do the ship replacement first option?

UPDATE: TechTools Surface Scan reported 0 errors. Anyone know if it scans ALL blocks or just the ones not marked as bad? [See prior theory] Anyone seen i/o errors in a file and learn later that it was not the hard drive? Please post details. If so, then I suspect Parallels is the culprit, which should be very interesting for other users - I am using Parallels 3.0, build 5160. In the meantime, I will ask the same questions over on the TechTools forum.

Any comments from the Parallels team?

Thanks for watching

 

Did you run 3.1.1 booted from the CD?

 

Ttd 3.1.1

Actually, I ran it from the external drive, which I had booted. So, I think the affect is the same. I also just found out that the drive itself will map bad blocks "on-the-fly", so there was almost no chance for me to reproduce the problem without having a very badly behaving disk. I must have just been lucky (*NOT*) to have had the bad spot show up in a Parallels VM. I have reformatted the original drive and am rebuilding the VM as I write this.

Any tips on the order of restoring individual Windows backups are welcome!

Thanks,
Rich

 

Rich,

Yep, same effect.

What form are your back-ups in?

 

I have more than one form of backup for the innocuous files - a direct copy and a backup. The one I was hoping to be the most trustworthy was the Windows Backup (.bkf) format. I went ahead and restored everything in this order:

* innocuous files (things that don't affect the registry - e.g. downloads, dev files, etc.)
* my documents (seems to affect the registry and causes a reboot)
* Program Files (affects the registry and causes a reboot)
* System State (affects the registry and causes a reboot)

The system boots, but I don't trust it. The first indication was that the Cisco VPN client was not restored properly. There was also a complaint by the OS that it couldn't find something during one of the reboots. This *could* be due to the fact I didn't restore everything at the same time - not sure on that, though. I could not restore from more than one backup file at a time, so I may be screwed on that or have to get the order right.

Rich

 

I would restore the system, then programs, then other files, but that is just me.