SUMMARY: Cluster root backup to a local tape drive - why?

From: Reed, Judith (JReed@NaviSite.com)
Date: Thu Feb 20 2003 - 11:17:38 EST


I asked why (in opinion of wise folks out there) a Compaq rep recommended to us
that we should do local vdumps to tape of our cluster-wide root disk, even though
we had backups done regularly to a remote Legato backup server.

Many thanks to all those who responded, I'll summarize relevant points below.

Bluejay Adametz points out the following, which makes sense:

"An issue you'll run into if you re-install Tru64 and then restore all your files is that you'll need to be real careful not to replace any of the newly-installed stuff, especially the device database files, when you do your Legato restore. Whereas you might get away with this on a non-clustered system, clusters are much more sensitive to this. For example, the config files on each boot disk contains the device major/minor numbers for the cluster common root. If that root device has changed (because you're on new hardware, you replaced the database or config files, using a different disk, etc...), the members won't even get to single-user mode and you'll have to go through a number of steps to recover."

Selden Ball notes the following, which could also present problems:

"I suspect it has to do with being able to backup and restore open writable files properly. Remember that Tru64 caches the filesystem in local memory. Modified data doesn't get written coherently to the disk drives. It's one of many reasons why
high-performance cluster interconnects are so important: the in-memory file
system caches have to be kept coherent. A multi-computer system designed to keep
the on-disk data coherent has *much* poorer performance than is provided by
coordinated in-memory caches. "

A number of people commented on the very relevant issue that rebuilding OS
and then restoring from tape (as you must with Legato's Networker) is slow,
tedious, and fraught with possible complications and places to insert errors.

Thanks again!



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:08 EDT