> Well there is already cfs checkpointml which creates a 'level 1' tarball
> of disconnected changes in /usr/coda/spool.

True.  I was just having Grand Unified Thoughts.

> Sounds difficult to do reliably, there are definitely security related
> issues, is anyone allowed to create such a snapshot? And losing a client
> cache isn't that big of a deal, except for the disconnected changes,
> as everything could be refetched from the server.

Only 'operator', i.e. some group that has privs.  Just like only group
operator can run dump on regular disks.

I don't see what's hard: 'volutil dump' consists of fs metadata, file
metadata, and file data.  These could be encoded with __METADATA,
__METADATA_filename, and filename, respectively.  It would really the
same data, but reformatted so that a vanilla restore could get at the
file contents for an emergency or when reading dusty decks.

> On the other hand we already have "volutil dump", which has the
> advantages that it already captures all of the available data and
> metadata from a volume on the server. No special metadata files needed,
> and no chance that someone could accidently try to restore the dump that
> was made of /dev/ad0s1e (i.e. a regular partition).

But the key property that it doesn't have is that if I take a tape
with dumps to someone who has never heard of coda, I can't expect to
get my files back.  Right now bsd dump, tar and ufs/ext2fs are
ubiquitous, and it's a good bet we can read them in 5 years.  I only
have one coda server, and if it blows up badly I might want to put the
bits on a regular disk for a few weeks before I can set it up again.

> Ofcourse there are missing things with our existing volume dumps. You
> need a server to restore the dump to. So having a 'restore'-like program
> that can extract files from or a complete Coda volumedump to a regular
> filesystem, or a voldump2tar application, to convert it into a regular
> tar archive, would definitely be a big plus.

Sure, that would help greatly.

> [stagingserver]

That sounds cool.

> [amanda with coda's dump]
>
> The changes currently consist mostly of a wrapper script for calcsize,
> which creates the backup clone and sends back the size estimates, and
> some source changes to amdump to introduce a "CODA" backup type that
> uses volutil dump instead of BSD dump or GNU tar.

Are these patches available?  Are they in amanda-current someplace?
But until there is either voldump-restore or what I suggested, I
wouldn't be comfortable using coda's dump facility.


I didn't mean to complain that this should be done for me - I just
thought it might be helpful to spew my vision.