edzotti
asked on
Can't boot or retrieve files - oddball Norton GoBack 4.0 problem suspected
This one's complicated. Bear with me.
The family computer (I have a separate computer at home for work) is a Pentium IV-3GHz, 1GB RAM, 120GB HD, Windows XP Pro (PowerSpec model 9340). It contains the (large) family photo archive, music collection (also large), the kids' schoolwork, and the family checkbook. The kids use it to play online games, and over time operation had become erratic - the system locked up during gameplay, etc. I suspected malware and decided I'd offload all the data, reload the original files using the "emergency recovery" CDs that came with the system, then reload the files. That done, I installed Norton GoBack 4.0 ("GB"), thinking that if problems arose in the future, I'd simply revert to an earlier system state.
GB never worked right. In early January 2006 I tried to disable GB by pressing the spacebar during the GB splash screen on bootup. Something went wrong; after that the system wouldn't boot. During boot, GB would display a message saying the system was unstable (or something like that) and that it was restarting, a process that would repeat indefinitely. If I tried pressing the spacebar to disable GB, I'd get a message saying GB was already disabled. Frustrated, I decided I'd start all over again, reloading the the original files using the emergency recovery disks. This time I didn't load GB. However - important point - I also didn't precede all this by wiping the drive or using FDISK /mbr to reload the master boot record, which I now believe was a significant omission.
Anyway, the computer worked fine and was in regular use for most of 2006. I installed a second HD, thinking I might use it for backup, but never got around to actually doing this. Then last August my work computer's D drive ("work-D") died. While attempting to diagnose the problem I swapped work-D with the D drive on the family computer ("family-D"). To my surprise, the family computer would no longer boot, even though I'd done nothing to the bootable C drive ("family-C"). A splash screen would flash past, then I'd get a message saying "reboot and select proper boot device." I reinstalled family-D in its original location. That didn't help at first, but after a couple of restarts the system booted and everything seemed back to normal.
OK, I know now I should have realized the system was flaky and backed up all my data. I didn't do that. I know, I know, I'm an idiot.
The crashed work-D drive turned out to have mechanical problems and a data recovery firm after several attempts pronounced the data unrecoverable. Determined not to let this happen again, I bought a new work computer with dual HDs and RAID capability on the motherboard, and set up disk mirroring (RAID 1). This was easy, so I decided I'd do the same thing on the family computer. RAID capability wasn't built in, so I installed a RAID controller card, hooked up the cables from the family-C and family-D drives, booted the computer, got into the RAID BIOS, and proceeded to replicate family-C to the (previously empty) family-D. This concluded uneventfully, but afterward the system wouldn't boot. Instead something flashed past and I got the message "reboot and select proper boot device." I removed the RAID controller card and hooked up family-C and family-D the way they'd been pre-RAID. Same result, "reboot and select..." Looking more closely at the screen flashing past during boot, I was startled to realize it was the GB splash screen, telling me I should press spacebar to disable GB. Pressing spacebar produced no result, only the "reboot-and-select" message.
Realizing that GB (or a subset thereof) had somehow remained installed on family-C despite my reinstalling the original files from the recovery CD, I bought a new HD, installed Windows, then hooked up family-C as a slave. Family-C was accessible but there were no files on it other than (I think) an empty "TMP" directory. Using Recover My Files from getdata.com, I was able to extract thousands of files from family-C, but without the original filenames or folders. Not wishing to go through each file individually, I sent the disk to a data recovery firm. They were able to recover thousands of files, complete with filenames and folders. However - key point - no files later than December 2005. Instead, they found an 8GB file called GOBACKIO.BIN dated 12/14/05, the approximate date of the original GB install.
So that's where we are. To summarize:
1. Family-C is physically intact and data can be recovered from it, just nothing later than December 2005. Please understand that up till my unfortunate experiment with the RAID card a few weeks ago, the family computer was in regular use and all recent files were available. I'm pretty sure they're still there but GB has disguised them.
2. Whatever the "emergency recovery" CDs did, they didn't wipe family-C clean, since the pre-12/05 files are still there, as is GOBACKIO.BIN.
3. The only thing I have done to family-C is duplicate it to family-D while attempting to install the RAID card. I don't think this destroyed any data on family-C. I did not attempt to reinstall GB on it or mess with the master boot record. I did trying installing GB on my new drive and hooking up family-C as a slave, but could find no data.
4. All I did to stop family-C from working in the first place was mess around with family-D. I deduce from this that GB won't let the system boot if it detects any change to the hardware configuration. I was able to restore the original hardware configuration the first time GB acted up, but not the second time. I halfway believe if I could put things back exactly as they were pre-RAID, I could get family-C to boot, although repeated attempts to do that have failed.
5. GoBack apparently is resident on family-C, certainly in the form of GOBACKIO.BIN, probably also in the master boot record, and maybe elsewhere. The data recovery firm found a "Norton GoBack" directory under "Program Files"; this includes various executable files. You'd think a fresh install from the recovery disks would have rendered these files inoperable but maybe not.
6. I have been in touch with several people at Symantec customer support but they are baffled by my problem and do not seem to have a good grasp of how GB works (probably not surprisingly, since I understand the product was originally developed by another company).
So: how can I retrieve my critical files? I have found some online advice about using a bootable Win98 disk with gb_prog.exe loaded on it, and using that to rehook GB into the MBR. However, (a) this advice refers to earlier versions of GB than the one I have (4.0), and (b) my problem is so wacky, with GoBack apparently operational even though it's not officially installed, that I have low confidence rehooking GB will work. I'm also reluctant to do anything that involves writing to family-C for fear I'll hose things once and for all.
While we're on the subject, can anybody explain to me how GB works, and why my files are invisible? Does GB stash files in binary form in GOBACKIO.BIN? (Symantec tech support says no, but can't say where the files are.) Info online suggests GOBACKIO is where GB stores "snapshots" of the system at various points, but it's not clear why you'd need 8GB for that.
Any help greatly appreciated. At the moment family-C is at the data recovery firm; I can get it back in a couple days. I do have in my possession all the recovered files, including GOBACKIO.BIN, on DVD. Before proceeding I'd ideally like to get a coherent idea of what went wrong. -Ed
The family computer (I have a separate computer at home for work) is a Pentium IV-3GHz, 1GB RAM, 120GB HD, Windows XP Pro (PowerSpec model 9340). It contains the (large) family photo archive, music collection (also large), the kids' schoolwork, and the family checkbook. The kids use it to play online games, and over time operation had become erratic - the system locked up during gameplay, etc. I suspected malware and decided I'd offload all the data, reload the original files using the "emergency recovery" CDs that came with the system, then reload the files. That done, I installed Norton GoBack 4.0 ("GB"), thinking that if problems arose in the future, I'd simply revert to an earlier system state.
GB never worked right. In early January 2006 I tried to disable GB by pressing the spacebar during the GB splash screen on bootup. Something went wrong; after that the system wouldn't boot. During boot, GB would display a message saying the system was unstable (or something like that) and that it was restarting, a process that would repeat indefinitely. If I tried pressing the spacebar to disable GB, I'd get a message saying GB was already disabled. Frustrated, I decided I'd start all over again, reloading the the original files using the emergency recovery disks. This time I didn't load GB. However - important point - I also didn't precede all this by wiping the drive or using FDISK /mbr to reload the master boot record, which I now believe was a significant omission.
Anyway, the computer worked fine and was in regular use for most of 2006. I installed a second HD, thinking I might use it for backup, but never got around to actually doing this. Then last August my work computer's D drive ("work-D") died. While attempting to diagnose the problem I swapped work-D with the D drive on the family computer ("family-D"). To my surprise, the family computer would no longer boot, even though I'd done nothing to the bootable C drive ("family-C"). A splash screen would flash past, then I'd get a message saying "reboot and select proper boot device." I reinstalled family-D in its original location. That didn't help at first, but after a couple of restarts the system booted and everything seemed back to normal.
OK, I know now I should have realized the system was flaky and backed up all my data. I didn't do that. I know, I know, I'm an idiot.
The crashed work-D drive turned out to have mechanical problems and a data recovery firm after several attempts pronounced the data unrecoverable. Determined not to let this happen again, I bought a new work computer with dual HDs and RAID capability on the motherboard, and set up disk mirroring (RAID 1). This was easy, so I decided I'd do the same thing on the family computer. RAID capability wasn't built in, so I installed a RAID controller card, hooked up the cables from the family-C and family-D drives, booted the computer, got into the RAID BIOS, and proceeded to replicate family-C to the (previously empty) family-D. This concluded uneventfully, but afterward the system wouldn't boot. Instead something flashed past and I got the message "reboot and select proper boot device." I removed the RAID controller card and hooked up family-C and family-D the way they'd been pre-RAID. Same result, "reboot and select..." Looking more closely at the screen flashing past during boot, I was startled to realize it was the GB splash screen, telling me I should press spacebar to disable GB. Pressing spacebar produced no result, only the "reboot-and-select" message.
Realizing that GB (or a subset thereof) had somehow remained installed on family-C despite my reinstalling the original files from the recovery CD, I bought a new HD, installed Windows, then hooked up family-C as a slave. Family-C was accessible but there were no files on it other than (I think) an empty "TMP" directory. Using Recover My Files from getdata.com, I was able to extract thousands of files from family-C, but without the original filenames or folders. Not wishing to go through each file individually, I sent the disk to a data recovery firm. They were able to recover thousands of files, complete with filenames and folders. However - key point - no files later than December 2005. Instead, they found an 8GB file called GOBACKIO.BIN dated 12/14/05, the approximate date of the original GB install.
So that's where we are. To summarize:
1. Family-C is physically intact and data can be recovered from it, just nothing later than December 2005. Please understand that up till my unfortunate experiment with the RAID card a few weeks ago, the family computer was in regular use and all recent files were available. I'm pretty sure they're still there but GB has disguised them.
2. Whatever the "emergency recovery" CDs did, they didn't wipe family-C clean, since the pre-12/05 files are still there, as is GOBACKIO.BIN.
3. The only thing I have done to family-C is duplicate it to family-D while attempting to install the RAID card. I don't think this destroyed any data on family-C. I did not attempt to reinstall GB on it or mess with the master boot record. I did trying installing GB on my new drive and hooking up family-C as a slave, but could find no data.
4. All I did to stop family-C from working in the first place was mess around with family-D. I deduce from this that GB won't let the system boot if it detects any change to the hardware configuration. I was able to restore the original hardware configuration the first time GB acted up, but not the second time. I halfway believe if I could put things back exactly as they were pre-RAID, I could get family-C to boot, although repeated attempts to do that have failed.
5. GoBack apparently is resident on family-C, certainly in the form of GOBACKIO.BIN, probably also in the master boot record, and maybe elsewhere. The data recovery firm found a "Norton GoBack" directory under "Program Files"; this includes various executable files. You'd think a fresh install from the recovery disks would have rendered these files inoperable but maybe not.
6. I have been in touch with several people at Symantec customer support but they are baffled by my problem and do not seem to have a good grasp of how GB works (probably not surprisingly, since I understand the product was originally developed by another company).
So: how can I retrieve my critical files? I have found some online advice about using a bootable Win98 disk with gb_prog.exe loaded on it, and using that to rehook GB into the MBR. However, (a) this advice refers to earlier versions of GB than the one I have (4.0), and (b) my problem is so wacky, with GoBack apparently operational even though it's not officially installed, that I have low confidence rehooking GB will work. I'm also reluctant to do anything that involves writing to family-C for fear I'll hose things once and for all.
While we're on the subject, can anybody explain to me how GB works, and why my files are invisible? Does GB stash files in binary form in GOBACKIO.BIN? (Symantec tech support says no, but can't say where the files are.) Info online suggests GOBACKIO is where GB stores "snapshots" of the system at various points, but it's not clear why you'd need 8GB for that.
Any help greatly appreciated. At the moment family-C is at the data recovery firm; I can get it back in a couple days. I do have in my possession all the recovered files, including GOBACKIO.BIN, on DVD. Before proceeding I'd ideally like to get a coherent idea of what went wrong. -Ed
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Well ... I do hate to be the bearer of bad news ... but the additional info you provided is not good !!
First, the IDE cable issue. ALL 80-wire cables support cable select; but only special "cable select" 40-wire cables support it. I'm assuming you had a cable-select cable (since the system DID work with the drives set to cable select); but it's impossible to say without seeing the cable which drive was Master and which Slave. IF you did what you suspect, you're correct .. all of the data is gone forever :-)
GoBack does NOT do anything "unusual" to the files as it stores them ==> in fact, it does NOT "store them." GoBack simply injects itself into the disk I/O calls to the BIOS and keeps a record of the last 8GB (or whatever you set the GoBack buffer to) of disk writes ==> it can then do it's "magic" and restore the disk to any previous state within that buffer; or recover files that were stored within the same "window." No encryption; no "hiding"; etc. Because it changes the MBR, you cannot "see" the files if you look at a disk with GoBack installed ---> but that's because of the modifications it makes to the MBR; NOT because they're hidden or encrypted. In fact, most good recovery utilities will "see" the files on a GoBack-enabled disk anyway => I don't know about "RecoverMyFiles", but I do know GetDataBack (www.runtime.org) can "see" them; you might want to download the free demo and see if it detects them. But, unfortunately, I suspect you have simply lost all of your data ...
A word on GoBack (to expand on what I noted earlier): GoBack v3.0 was an outstanding product; and VERY reliable. I still use it on one PC (so I can install/test stuff to my heart's content without fear ... and backup to totally remove it when I'm done; GoBack has "saved my bacon" on multiple occasions over the years). BUT, as I noted above, GoBack 4 (which I purchased to take advantage of the larger buffer -- 8GB max vs 4GB for v3.0) has MAJOR issues => I returned it; and will NOT use it. I also no longer use GoBack on my primary PC. Instead, I have it set up basically like I noted in the writeup I linked to above; and have a simple "Image Now!" icon on the desktop along with a "Restore Now!" icon => they simply reboot the system, either image or restore the system partition; and then reboot. In addition, I have SyncBack set to automatically backup my data ever night. If my primary drive was to fail, it's about 5 minutes of "my time" to replace it and have everything back to normal => it would, of course, take a bit of "computer time" while the restore was being done (10 minutes) and all of the data was being copied to the 2nd partition (perhaps 15 minutes).
First, the IDE cable issue. ALL 80-wire cables support cable select; but only special "cable select" 40-wire cables support it. I'm assuming you had a cable-select cable (since the system DID work with the drives set to cable select); but it's impossible to say without seeing the cable which drive was Master and which Slave. IF you did what you suspect, you're correct .. all of the data is gone forever :-)
GoBack does NOT do anything "unusual" to the files as it stores them ==> in fact, it does NOT "store them." GoBack simply injects itself into the disk I/O calls to the BIOS and keeps a record of the last 8GB (or whatever you set the GoBack buffer to) of disk writes ==> it can then do it's "magic" and restore the disk to any previous state within that buffer; or recover files that were stored within the same "window." No encryption; no "hiding"; etc. Because it changes the MBR, you cannot "see" the files if you look at a disk with GoBack installed ---> but that's because of the modifications it makes to the MBR; NOT because they're hidden or encrypted. In fact, most good recovery utilities will "see" the files on a GoBack-enabled disk anyway => I don't know about "RecoverMyFiles", but I do know GetDataBack (www.runtime.org) can "see" them; you might want to download the free demo and see if it detects them. But, unfortunately, I suspect you have simply lost all of your data ...
A word on GoBack (to expand on what I noted earlier): GoBack v3.0 was an outstanding product; and VERY reliable. I still use it on one PC (so I can install/test stuff to my heart's content without fear ... and backup to totally remove it when I'm done; GoBack has "saved my bacon" on multiple occasions over the years). BUT, as I noted above, GoBack 4 (which I purchased to take advantage of the larger buffer -- 8GB max vs 4GB for v3.0) has MAJOR issues => I returned it; and will NOT use it. I also no longer use GoBack on my primary PC. Instead, I have it set up basically like I noted in the writeup I linked to above; and have a simple "Image Now!" icon on the desktop along with a "Restore Now!" icon => they simply reboot the system, either image or restore the system partition; and then reboot. In addition, I have SyncBack set to automatically backup my data ever night. If my primary drive was to fail, it's about 5 minutes of "my time" to replace it and have everything back to normal => it would, of course, take a bit of "computer time" while the restore was being done (10 minutes) and all of the data was being copied to the 2nd partition (perhaps 15 minutes).
ASKER
My fears confirmed. I looked for the files, and so did the data recovery firm using a couple different types of software. We both found old files but nothing after 12/05, so I think it's safe to say the data is gone.
Your recommended backup strategy has a lot to be said for it. The one drawback is that it's a little complicated to set up, although I admit the time spent pales in comparison to the time and money wasted if you lose data, as I just did. Anyway, I've already got the RAID arrays set up plus the external backup drive, so I'm going to leave well enough alone for now. Thanks for your help. -Ed
Your recommended backup strategy has a lot to be said for it. The one drawback is that it's a little complicated to set up, although I admit the time spent pales in comparison to the time and money wasted if you lose data, as I just did. Anyway, I've already got the RAID arrays set up plus the external backup drive, so I'm going to leave well enough alone for now. Thanks for your help. -Ed
With two computers you can do better fairly easily without bothering with the repartitioning: add a 2nd hard drive to each computer [your RAID array doesn't count --> it's really just ONE very reliable "drive"]; then simply have each computer backup all of the DATA automatically to both (a) the 2nd hard drive; and (b) the 2nd hard drive on the other computer. [I presume they're networked ... if not, they should be :-) ]
... You can also make periodic images and save them on either the 2nd hard drive (if it's large enough) or the external drive [the major thing you miss by not having segregated system and data partitions is that the system image is always fairly small if it's segregated ==> my VERY well "loaded" system with over 200 programs still images in less than 10GB].
... You can also make periodic images and save them on either the 2nd hard drive (if it's large enough) or the external drive [the major thing you miss by not having segregated system and data partitions is that the system image is always fairly small if it's segregated ==> my VERY well "loaded" system with over 200 programs still images in less than 10GB].
ASKER
All the computers in the house are networked, and while I hadn't been doing anything quite as systematic as you suggest, I had backed up key folders from one computer to the other every so often. My problem - one of my problems, anyway - is that I had multiple drive failures. First, irretrievable mechanical failure of work-D, which is where I backed up a lot of family-C. A month or so after that work-C started refusing to boot, although I could still access it as a slave. I had some backup files on it, too, so I copied them all off and put them on family-C, which I then proceeded to hose without first backing up to my new work computer, which now is up there on my lifetime top 10 list of stupid stunts. Work-C now is totally unreadable, but the data recovery firm has offered to take a look at it to see if anything can be retrieved without charging me a million bucks, so we'll see if I can salvage something from this fiasco.
Here's something else to confuse matters. In looking at an older PowerSpec computer I have around here, I notice it has an 80-wire ATA cable, not a 40-wire. I no longer have the original cable in the family computer (I took it into the shop to have the RAID card installed, and it came back without the original cable), but I have to think, given that it's a later model, that it probably had an 80-wire cable too. If so, that kiboshes my theory about mixing up the C and D drives - cable select should work OK on an 80-wire cable, with the end drive being the master, right? I've done so many stupid things during this nightmare, though, I could well have mixed up the drives some other way - it would explain a lot.
Here's something else to confuse matters. In looking at an older PowerSpec computer I have around here, I notice it has an 80-wire ATA cable, not a 40-wire. I no longer have the original cable in the family computer (I took it into the shop to have the RAID card installed, and it came back without the original cable), but I have to think, given that it's a later model, that it probably had an 80-wire cable too. If so, that kiboshes my theory about mixing up the C and D drives - cable select should work OK on an 80-wire cable, with the end drive being the master, right? I've done so many stupid things during this nightmare, though, I could well have mixed up the drives some other way - it would explain a lot.
Yes, the end connection on an 80-wire cable is Master when used as cable select. While I like the simplicity of cable select (just move drives around willy-nilly and they're assigned the correct status) ... I no longer use it. A Master/Slave setting overrides cable select => so I ALWAYS jumper my drives the way I want them. Simple enough as long as you keep a few jumper pins around :-)
ASKER
-> Did you install the 2nd hard drive before or after you reloaded the system? ... and before or after you had attempted to disable GoBack ??>>
When I initially installed GoBack, and then attempted to disable it, I had only one HD. I bought the second HD (which became family-D) after GB made family-C unbootable, and reinstalled the system on family-D. I don't recall exactly what I did after that, but I'm guessing I must have reinstalled the system on family-C and began using that as the boot drive, because it contains all my pre-12/05 files plus GOBACKIO.BIN. Family-D, being brand new in Jan. 06, wouldn't have those files.
<<-> Your abortive attempt to replicate family-C onto family-D may very well have caused a lot of data loss. You should NEVER built a new RAID array with disks that contain un-backed-up data !!>>
You're quite right, of course. However, here we are. I should point out that the attempt to replicate family-C onto family-D was not abortive ... to all appearances it was successful. Whether data was written to family-C in the process I don't know. I do know that if the replication caused data loss on family-C, said loss was highly selective. It affected only files created or modified after 12/05, none earlier, as far as I can tell.
<<-> A RAID array is a TERRIBLE "backup" strategy. A mirrored array protects you against a physical drive failure; but does NOTHING to protect against system corruption (bad updates; viruses; malware; etc.) or accidental deletion or modification of files (those events are simply replicated along with everything else). A MUCH BETTER strategy is to (a) separate your system and data onto different partitions; and (b) maintain a current IMAGE of the system; and current backups of the data on a 2nd hard drive. >>
The RAID array wasn't (and isn't) my only backup strategy. On my new work computer I have two drives set up as a RAID-1 mirror, and I also have a third (external) hard drive for manual backups. The work-D crash was a physical failure; had the drive been mirrored I would not have lost data. I absolutely agree RAID alone isn't an adequate backup strategy.
You know, it now dawns on me what my problem may have been. When I installed the second HD, I set the jumpers on both drives for "cable select." Reading up on the subject now, I see you're supposed to use a special ATA ribbon cable for this. I just used the regular cable, but everything seemed to work OK. However - and this may have been my fatal mistake - I assumed the drive at the END of the cable was the master and the drive in the MIDDLE of the cable was the slave. I see now that when using a 40-conductor cable (which is what I think I had), the drive at the end of the cable is the SLAVE and the one in the middle is the MASTER. In other words, I may have gotten the C and D drives mixed up. Thus, when I disconnected what I thought was the D drive in August, I was really disconnecting the C drive, so the system wouldn't boot. Likewise, when I thought I was mirroring the C drive to the D drive, I was really mirroring the D drive to the C drive. The D drive, as I think on it now, was probably the drive I originally had in the C position and loaded GoBack onto. After mirroring, both drives had GoBack in the master boot record and that's why I got the GB splash screen.
If all the above is what really happened, my data was irretrievably lost when I mirrored the drives. Gary, let me ask you this. When GoBack is installed and running normally, does it do anything unusual to the files as it stores them, i.e., encrypt them, hide them, or whatever? In other words, if GoBack becomes corrupted or the MBR is damaged, should any files stored while GoBack was functional still be detectable using RecoverMyFiles or similar software? If the answers are "no" and "yes," then the mystery is solved, my data is gone forever, and I'm a class-A dumbarse. -Ed