Linux Disaster Recovery

[Malcolm McLeary]

I'd like to build a Disaster Recovery CD for my Sun Cobalt Qube3 appliances. These appliances do run a compatible version of RedHat Linux and the Retrospect Linux client does work, but due to their "appliance" design they present some challenges for Disaster Recovery.

 

 

 

These appliances come with an OS Restore CD which is used to boot a PC. The Qube3 then does a netboot from the PC, formats and partitions its disk, and finally installs the OS and all applications, etc.

 

 

 

What I'd like to do is change the netboot and restore process such that instead of installing the OS etc it loads the Retrospect Linux Clients so that I can use Retrospect Multi Server to restore from backup.

 

 

 

The issue is likely to be whether the Restrospect Linux Client will run on a netbooted Qube3?

 

 

 

Apart from the requirement for RedHat etc, etc, etc ... what does the client REALLY need to run?

 

 

 

"Plan B" is to have a Qube3 Pro Ed running a Bus Ed OS and simply mounting the partitions of a 2nd (i.e. non RAID) disk. I then restore onto the 2nd disk given that the primary disk is running a full version of Linux. Naturally this process requires additional hardware. I'm looking for a solution which is similar in operation to the current OS Restore process but which allows Retrospect to do the actual restore from a backup set.

 

 

[natew]

A net boot disaster recovery cd for clients would be great! However, at this point Retrospect requires a fully functional Red Hat system in order to do any restore operations.

 

 

 

In a disaster recovery situation you would restore the client machines in the following manner:

 

 

 

1)Do a full install of the operating system on the client machine from the system disks that came with your Qube3.

 

2)Reinstall Retrospect client on the Qube3.

 

3)Perform a "restore entire disk" restore from the backup server machine

 

 

 

Your suggestion for plan B might work but you can have unpredictable results when restoring an OS on to another device (i.e. /dev/hdd rather than /dev/hda).

 

 

 

I would guess that the install CDs that came with the Qube3 can actually perform most of the install unattended. It may add a bit more time to the restore process but doing the full reinstall of the system should be easier in the end

[Malcolm McLeary]

The process you describe is how I have done it while testing the beta client. Although it worked, I'm concerned about overwriting open files like the databases used by the Cobalt GUI.

 

 

 

Hence "Plan B", but I'm not sure why /dev/hdd vs /dev/hda should be an issue when the restored disk is returned to its original interface after restore. Doesn't a restore simply put files back?

 

 

 

The Qube3 doesn't really come with an "Install" CD in the traditional sense as it does not have a keyboard, monitor or mouse or a CD ROM for that matter. What it has is an OS Restore CD which is used to boot a PC and then the Qube3 does a netboot from the PC and proceeds to install its OS and applications across the network. What I was looking to do is "adjust" this existing process such that instead of installing everything it loads the Linux clients such that a Restrospect client restore can happen.

 

 

 

It is entirely likely that the current process only loads enough Linux to do what it currently does wrt OS Restore and will not support the Linux Client.

[natew]

At this time the only way to restore a Linux system via the Retrospect Client is to reinstall the OS and Retrospect client software first. This is due to the fact there are a few directories that are never backed up from the client. These directories need to be reinstalled in order to create a bootable system. These directories (/dev /proc and so on) are omitted because they can cause problems when performing a live restore. As a result, mounting a secondary drive and doing a restore to that drive will not provide you with a bootable system.

 

 

 

The netboot restore via Retrospect client would be a great feature I agree, but given the fact that we need a fully functional system to restore over, it won't work without some serious software modifications.

 

 

 

Can you be more specific about your concerns with open files?

 

 

 

 

 

 

 

 

 

 

 

 

[Malcolm McLeary]

Well I guess we are talking about the same issues. Certainly the directories which are not backed up as they would cause problems during a live restore are the sort of thing I'm concerned about. I was unaware that the client didn't backup everything. I'd like to backup everything even if it didn't restore some directories "normally".

 

 

 

I'd like to to have the capability to do a complete disk backup and then be able to restore it to a different disk without first doing an OS Restore. Essentially I want to duplicate a complete disk without resorting to disk imaging software. I appreciate that the disks will need to NOT be the boot device.

 

 

 

To date I have used the factory OS Restore process first, done a basic configuration, applied all the patches and updates and then done a Retrospect Restore to bring the configuration back. This way the Retrospect Restore should only add data files and replace configuration files.

 

 

 

I'm looking for a quicker process.

 

 

 

Some of the patches and updates replace major components including the kernel ... I'd prefer the machine not to be running from the disk if Retrospect was to replace these components. Hence applying all the updates etc, but booting off a different "system" would be preferred.

 

 

 

I have not explored the process fully yet wrt Retrospect, but the Veritas, Arkiea, and Legato clients for the Qube3 have some pre-backup scripts to dump various configuration databases. As the databases themselves will be open and may change during a backup. The scripts/process goes further such that after a restore on restart if these dump files are present then they are imported again. This is important as the the Administration GUI is database driven and it creates/updates the various configuration files in /etc. It is important to keep these two views of the system in syc.

 

 

 

The other requirement I have is Linux machines running a different processor. Since the Retrospect client will not run on these machines I'd like to drop the disk into a supported machine so I can occassionally backup the whole disk and possibly do a restore. With these machines I currently just backup SAMBA shares as they can be mounted by the Backup Server. The "complication" with these particular machines is that they were sold as appliances and in the infinite wisdom of the supplier, never made any OS Restore CDs available.

 

 

 

Given that the client does not do a full backup, I'll have to rethink things to be appropiately prepared.

[natew]

I apologize for not being clear on this point.

 

 

 

Retrospect client allows you choose to back up all files and directories on a client machine. By default, some files and directories are excluded for the following reasons:

 

 

 

1. they contain files that if restored could make the system non-bootable

 

2. they are temp files that do not need to be backed up

 

3. the are cache files that do not need to be backed up

 

 

 

You may be able to do what you are suggesting (remove the disk from the Qube3 machines and mount them on a linux client machine) if you make sure that you have chosen to back up all files on that mounted volume. In the event of a restore you would have to make sure that the target drive for restore was partitioned exactly as the original drive was at the time of backup. you will probably have to do some work with the boot loader too. To be honest, this has not been tested and is likely to not work.

 

 

 

The worst you can do is try it and see. If it fails you could always make a disk image of the Qube3 drive and store it on your linux client machine. That way you could back up the disk image with the Retrospect client. It adds a step but you could then copy the disk image back with no OS install.

 

 

 

Retrospect client is not designed for doing a complete disk backup and then restoring to a different disk without doing an OS restore. Reinstalling the OS prior to a restore is indeed time consuming but is required for restoring any Retrospect client regardless of the operating system. You also need to do all updates on the target system before you do the restore, otherwise the restore will fail. This is especially important in regard to kernel and system updates.