There are two basic ways of backing up ClearCase VOBs: by using snapshots, or by dumping the storage pools while the VOB is locked. I have a deep distrust of anything unnecessarily complicated, so I don't much like the snapshot approach.
Outlined here are two ways to safely and sanely back up VOBs using AMANDA.
Note that the platform I've been working on is Solaris with ClearCase 3.2.1 and 4.0, and only a single VOB server. This stuff will definately need modifying if you're using several VOB servers, though the first approach works OK (albeit a little slowly) over NFS.
The obvious question here is "what is a poor man doing trying to deal with ClearCase?". I'm not going to ask that, because I've been there and it wasn't so much fun.
First, you want to get the right bits of stuff together to do the dumps. Grab the following files:
You will need to modify these, of course, but they should give you a reasonable place to start. You also want to create a new Amanda dumptype called "ccase-vob" which looks like a tar dump and does not do incrementals nor indexes.
Finally, you want to get Amanda to call gnutar-wrapper.pl instead of the real GNU tar. I did this by putting gnutar-wrapper.pl in the right place (/opt/amanda/support, in my case), then rebuilding Amanda from source, pointing it at the wrapper.
How they fit together: You want gen-disklist.pl to run every night before amdump, and you want to get its stdout to end up in your disklist file. This generates a bunch of disklist entries, one per VOB. As amdump goes through and does the dumps, it will call gnutar-wrapper.pl instead of the real GNU tar, and that will (if you've got this set up correctly) call ccase-cpio.pl for the actual VOBs.
ccase-cpio.pl has two functions: if it is passed "--file /dev/null" (which is what AMANDA will do if it's after an estimate) then it produces an estimate of the dump size. Otherwise it locks the VOB, then uses cpio to create an archive of the VOB which is sent to stdout. When this is done, it resets the VOB lock state (so you won't lose VOB locks).
The main drawback to this approach is that the VOB is locked for as long as it takes to dump it. This can take a fair while for a multi-gigabyte VOB.
Doing the restore is reasonably simple. Find the dump you want on tape, then extract it back to disk using amrestore. Then use "cpio -icd" to extract the content of the archive, and make sure you recreate the d/ddft and c/cdft directories in the storage directory -- ccase-cpio.pl skips the cleartext and derived object storage pools.
This approach takes a bit more by way of resources, but the VOBs are offline for a few seconds only.
First, you need to do some preparation. The VOBs should be stored on a mirrored filesystem, and you need to seperate out the cleartext and derived object pools. For example, I have the VOB storage directories living in /export/vobs on the VOB server. I also have /export/vobs/discard, under which the real cleartext and DO pools live, symlinked back into the standard locations. This is done so that ufsdump will skip the cleartext and DO pools.
Next, you need to grab some bits. Specifically:
Now you want an AMANDA dumptype called "comp-vob". This dump type should use the standard dump utility, and should do neither incrementals nor indexes.
How this all fits together: run pre-dump prior to running amdump. This will lock all the VOBs, detach the mirror, reset the VOB lock states, mount the detached mirror, and finally run gen-disklist to create the disklist entries you need.
Then AMANDA will dump the VOB storage pools in the normal way using ufsdump. Finally, make sure that post-dump is run after amdump completes. This will re-attach the mirror.
Restores are dead simple: find the correct tape, extract the dump using amrestore, and take it from there.