…A long title for a weeks-long problem!
Well, it has been a long time since I have updated this blog. But, that doesn’t mean nothing has been going on! :-)
For the past couple of weeks, I have been troubleshooting a problem with my backups. I use BackupExec, so that shouldn’t really surprise anyone! But, in this case, the problem (as best as I can tell) turned out to lie elsewhere.
Here’s the skinny…
I do all of my backups to tape, except for my Exchange backups. They go to disk. I have a 3TB disk on my MD3000i that I use for this. That way, I can make the most efficient use of BackupExec’s GRT technology. It was working fine for a while until (as is often the case in Windows environments) it just stopped working.
My backup-to-disk jobs started failing with the error code: E00084AF
Symantec’s KB had a number of articles that spoke to the issue, but nothing seemed to work. I spent about a week on my own trying to solve the problem, running updates, tweaking the registry, deleting/recreating jobs… Nothing worked, so it was then time to call Symantec Tech Support.
Now, like most people, I DO NOT like calling tech support, especially for large companies. This has nothing to do with my ego and everything to do with the fact that, in most cases, the first-level support is likely a guy just like me… someone who kinda-knows the product, is sitting in front of a computer either reading from a ‘tech-support script’ or just searching their own KB as you describe your problem to them. I know they are trying to be helpful, but you end up spending most of your time re-hashing everything you have already tried! </rant>
I will say this, however… the Symantec guys were willing to ‘spend the time’ with me on this. I never felt rushed by them or brushed aside. I appreciated that.
Anyway, none of this troubleshooting helped and we all went into the weekend scratching our heads, wondering what we were going to try/look at next. Then, over the weekend, I had an idea…
As a Windows guy I have learned that, sometimes, you just need to start over. For example, if a distribution list in Outlook isn't working right, you may have to just delete it and re-create it (or add then remove someone). I have come across similar situations many, many times... Situations where 'touching' an object somehow resets things and gets it working again. Sometimes it's just a matter of changing a setting, saving, and then changing the setting back.
This is essentially what I did with my virtual disk on my MD3000i. I went into the management console of my MD3000i and changed the 'ownership/preferred path' of the virtual disk from one controller module to the other. Then, after a server reboot I ran a test job and it worked. The backups have been running fine ever since.
I have no idea what initiated this issue, or where it originated. That is the most frustrating part. I am just glad that things are working again!
9 comments:
Hi Derek, I've just read your last post about your disk corruptions on this page (http://www.phwinfo.com/forum/ms-virtualserver/366247-very-large-disks-hyper-v-vms.html) and I just wanted to let you know I'm having the exact same problem.
Parent OS: 2008 Server
Guest OS: 2003 Server (although SP2 only not R2 I think)
3TB IDE connected passthrough disk. Has been working fine for about a year but have started to get disk corruptions last couple of weeks. One set 2 weeks ago and some just today.
I moved my passthru disk to a SCSI controller on the VM and things work fine. From the research I have done, it seems to be preferred to use SCSI on VMs rather than IDE.
Ok thanks for the info, that's really useful.
Incidentally, I'm working on this at the moment and that was the solution I was working towards.. but after running some Dell diagnostics and rebooting the server the whole 3TB partition has become uninitialised :(
I'm just in the process of reformatting.. and hoping the last backup is going to do the trick.
Incidentally, I tried to format the disk (RAID 5 array) from the guest OS and it keeps reporting it can't complete. Power the guest down and put the disk online on the parent and it will format just fine. I don't suppose you had any similar experience with that?
When the disk was on IDE, I was getting file corruption... but the disk was accessible. When I switched it to SCSI, there was no new corruption, but the files that were corrupted during the 'IDE' incident were still messed up. I just had to restore them from backup as we ran across them. But, the disk never when totally south.
Ok, thanks for all the prompt wisdom. I shall let you know how it goes in the end.
Just thought I would report back and let you know that since changing the Hyper-V disk to a SCSI we've had no further repeat of the corrupt files... thank goodness!
Thanks for all your help.
Glad to hear that!
Post a Comment