ignite like backup and restore for linux servers

[Thomas Moersch]

Hi,
we are looking after close to 200 RHEL Linux servers.

We are using ignite to restore and clone our HP-UX servers.

We are currently collecting information which makes each server unique, such as name, IPs, SSH keys, passwd, shadow, etc.
We have complete backups of each server using legato.
I believe that since we already back of of these servers up nightly Mondorescue would be overkill.
We can quickly rollout new servers with our PXE Boot / Kickstart process (15 to 20 min. / server).
Giving the server its old identity back is what takes time.
The amount of information that makes one server different from another is actually very low.
So after rolling out a cookie cutter server I just need to apply that info to re-create the old server. Legato can then restore lost data if necessary. In most cases that data is stored on NAS devices anyway.
Sorry about the "verbosity" ;-).
Are there any solutions out there or should we develop inhouse?

[Matti_Kurkela]

The most Ignite-like solution would probably be Mondorescue:

http://mondorescue.org

However, after kickstarting a server to "generic" configuration and stopping all the processes that are not necessary for Legato restore, what prevents you from running a *full* Legato restore on it?

A full restore would replace the configuration files in /etc... but most configuration will only take effect when the appropriate processes are restarted or specific commands are run to make the configuration files take effect (like the system startup scripts do).

The only significant exceptions would probably be /etc/resolv.conf and /etc/hosts... but because these will be created by the Kickstart installation and the backed-up configuration is presumably a working one, you're basically replacing one good configuration with another.

If you want to be really safe, you could script it to restore everything else to their normal locations, then restore /etc to /var/tmp/restored-etc or similar. Once the restore is complete, move the contents of /var/tmp/restored-etc to real /etc, overwriting as necessary. (You might have to do the same thing with the Legato agent configuration directory, too... although a well-designed backup application should at least provide explicit instructions about how to deal with a case of the backup agent restoring a copy of itself, in my opinion.)

Then re-run "grub-install" (as the bootloader files may have been overwritten as part of the restore, and their physical location on the disk may have been changed), reboot and your system should take on its original identity.

Of course, this strategy requires the Legato client on the freshly-installed cookie-cutter server to be authorized to restore a backup that belongs to any "other" server. I'm not sure how easy it will be to arrange that with Legato: it might require backup administrator privileges. But it should definitely be possible in some way.

MK

[Thomas Moersch]

Thank you for your comments. In order to facilitate a rebuild fast I will stick with archived (tarred) essential files which I will then apply to the server after the kickstart build has finished.
Legato can then be used to restore missing apps, data etc.