Disaster Recovery / Error 1115

[Mike2112]

Hello,

 

As a test, we made a full backup of a system, then formatted the hard drive, then attempted a disaster recovery. The drive was about 5GB occupied, with about 1GB free space left.

 

The problem is, when the disaster recovery starts, it runs off a temporary Windows installation, which takes about 1GB. Therefore, the recovery fails with an error -1115, because the hard drive can't handle the temporary Windows folder along with what it was trying to restore.

 

I would think Restrospect should have given a message at disaster recovery CD creation time, indicating that this would happen.

 

In any case, how can one get around this problem?

 

Thank you,

 

Mike

[rhwalker]

Mike, you are very wise to test out your disaster recovery ahead of time. Many people don't do that, and have to do the test while they are hyperventilating from a server crash, under time pressure, with a critical deadline looming and users standing around the server asking when it will be back up.

 

Quote:

---

In any case, how can one get around this problem?

 

---

Have you tried on a disk bigger than 6 GB? I didn't know that you could even buy disks as small as 6 GB in size (although I did build an emergency boot disk for our server on an 8 GB iPod once just to see if it could be done).

 

The real size needed for the disk will also include some space for the VM paging store, so the real minimum would seem to be closer to 10 GB or so.

 

Russ

[Mike2112]

I see. Thank you for responding.

 

Well, the problem is, that's the original size of the hard drive (yes, it's old). But I can't imagine that the user would be expected to swap their drive out for a larger one whenever they attempt to do a disaster recovery on a drive that was almost full?

 

When I get the error 1115, I was considering moving as many non-critical folders off the hard drive (say, to a large pendisk) in order to free more room, then copy them back after the system was restored and running off the real Windows install, but since the disaster recovery would have already failed with the disk full error, I'm not sure it would continue restoring...

 

Mike

[rhwalker]

To be candid, I question the value of a "Disaster Recovery" disk because, as things get updated, it means forever making a new disaster recovery disk, and if there is a real disaster, the recovery would be happening on different hardware.

 

Our plan is to do a ground zero install of the OS, bring it up to current patch level, install Retrospect, restore from last backup on top of that.

 

We also keep a bootable RAID 1 mirror (firewire) of our server's drive, made with all services quiescent so that it's a good mirror before we split the mirror off, in a cabinet as the emergency boot disk.

 

Would either of these work for you?

 

Russ

[Mike2112]

It appears to me that the way Retrospect's disaster recovery works is, it just loads a minimal XP install off the disaster recovery CD, then runs the machine off that until it gets a chance to copy everything off the backup set (in this case, a USB hard drive). So I'm not too worried about "things" changing, because if a scheduled incremental occurs on a fairly normal basis, the system should be restored to what it was.

 

This test is on an old cheesy laptop, but there are over a dozen machines (some desktops, some PC's) that have their own distaster recovery CD's / USB hard drives. I want to ensure that we are not going to have this problem on those machines when they fail. Odds are we won't, as their hard drives aren't so full, but this is rather alarming. I don't want to rely on odds.

[rhwalker]

You are exactly right how the disaster recovery works. However, if hardware interfaces change, etc., then your disaster recovery disk needs to be updated to support those changes. That's the sort of stuff I was talking about.

 

That is why I use the approach that I do - you end up at the same point by doing a bare metal install, applying patches, installing Retrospect, as you do by going forward from the disaster recovery disk. It's a bit faster if you create an install "slipstream" disk with all the patches applied.

 

As an example, on our Macs, I just create an image from the most recent installer DVD, put Retrospect on that together with drivers for some unique hardware that we have, and reburn an installer DVD that could be booted either for install on any machine or for Retrospect disaster recovery on any machine. That way, I only have one disaster recovery DVD for all machines, and I have to do it this way because the Retrospect Mac install DVD won't boot on recent hardware, anyway.

 

The RAID 1 mirror approach lets me get our server back up and running quickly in the event of a disaster that causes our server's RAID 5 set to be unusable, with the ability to run Retrospect from that, too, and the bootable install DVD lets me bring the client machines back to life quickly by an OS and client install, followed by full restore from last backup.

 

I do agree with you, though, that laptops and most desktops won't have changing configurations that would warrant having to change the disaster recovery disk, though. I tried to create a Retrospect PC disaster recovery disk once and gave up because Retrospect could not create a small enough image to fit on the disk. Perhaps you have seen the posts on that subject.

 

What about, as a workaround, having a 10 GB or so disk that you could carry around to a failed machine and onto which you could do the disaster recovery boot, and then, booting from that, restore the "real" disk from backup?

 

Russ

[Mike2112]

Not sure how the drive swap idea would work, but in any case, it wouldn't be convenient at all for PC's. There is at least one PC I'm concerned about having enough free space. I can't imagine Retrospect is going to work for us if we can't get this issue resolved. The concern here too is getting Retrospect to work for us, not figure out another solution. I mean, yes, I could boot Knoppix off a CD and create a compressed drive image and ship that off to a server/NAS/USB drive, but it's hardly convenient. But then again, neither is this disaster recovery scheme that doesn't appear to work. Hmm.

[Mike2112]

OK, here was the painful procedure I had to go through to get this to work.

 

Booted off the disaster recovery CD. It loaded the temporary Windows install into DRWINNT.TMP. Retrospect ran and asked for where my snapshot was located, but unfortunately couldn't see the USB drive it was stored on, so I had to exit Retrospect and let it do the rest of its install of Windows to DRWINNT.TMP. Retrospect ran again and was asking for the snapshot to use. Knowing that it could now see the USB drive (after two dozen or more reboots), I minimized it without starting the restore, then ran Windows Explorer and compressed the drive (I had reformatted it as NTFS in the early stages in order to do this). Then allowed the restore to continue, and everything fit. Rebooted. Error: NTLDR is compressed, press CTRL+ALT+DELETE to restart. Joy. Booted off a real XP CD, got into the repair console, and turned off the compression attribute on NTLDR via the "attrib -c ntldr" command. Also uncompressed several other "important-looking" files. Would have done more, but XP tries to protect me from myself by not allowing wildcards. Tried "set allowwildcards = true" but it gave me some other message about requiring some snap-in, because I'm obviously too dumb to work with wildcards. Rebooted. Hung. Repair console again. Figured that since the kernel wasn't loading, it had no knowledge of NTFS, so it couldn't deal with compressed files. Uncompressed C:\winnt\system32\ntoskrnl.exe. Boom bam.

 

Another solution would have been to boot with Bart's P.E. (live XP CD-ROM) and uncompress the drive, but out of curiosity I wanted to know exactly which files it was hanging on.

 

That was fun. I'd rather have all my teeth pulled than go through that again.