On Wed, Jan 31, 2001 at 08:57:47AM -0500, Greg Troxel wrote:
> So what would be really cool, IMHO, is a 'venusdump' program that
> would read RVM and the container files and output a stream in BSD dump
> format that would have the following properties:
> 
>  * level 0 gets the whole cache.  level 1 the files that aren't on the
>    server.  other levels are probably not needed.

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

>  * one could simply run restore on it to get a filesystem hierarchy in
>    a normal fs containing all the files in the cache
> 
>  * one could run 'venusrestore' on it which would perhaps init rvm and
>    add the cached files and their metadata (version vectors) back into
>    the client cache

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.

> To do this, I'd imagine one would have to make some fake files
> containing metadata in the dump stream, and cope with collisions of
> those names with existing files by some sort of escape coding
> mechanism.
> 
> In addition, it would be nice to be able to run a similar program
> 'vicedump' on the server, getting essentially the same format, but
> perhaps with different metadata records.

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).

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.

The other problem is that a restored dump of a backup volume has all the
properties of a backup volume, i.e. it is not replicated and cannot be
used as a base for a new replicated volume. That is another issue.

In a way creating vicedump/vicerestore seems to be a lot more work (and
dirty hacks) compared to creating a vicerestore that can handle the
existing volume dump format.

> Together, this would enable moving client caches to new disks (very
> helpful when one has 100 Mb cached on a 28.8 line), doing the same for
> servers with a great degree of safety.  It could also enable a laptop
> user with no net to spit the contents of the cache out to a floppy/zip
> disk for safekeeping.

We've been experimenting with a so-called 'stagingserver', which is a
small footprint Coda server that can do nothing more than read-only
export a volume dump file. A client could run such a staging server
locally and use it to quickly initialize it's cache. It can then
reconnect to the actual VSG and fetch any files that have changes since
the volume dump was made.

> 				Perhaps most importantly for me, it would
> provide a nice backup strategy - running vicedump on the server would
> integrate with AMANDA, and also enable one to restore coda bits into a
> regular filesystem in an emergency.

I'm currently running shadow-backups of 2 of our machines with Amanda.
Not everything works that smooth yet, but it basically functions.

# amadmin DailySet1 info vivaldi d1000018

Current info for vivaldi d1000018:
  Stats: dump rates (kps), Full:  194.0, 207.0, 175.0
                    Incremental:   42.0,  88.0,  96.0
          compressed size, Full:  26.4%, 26.4%, 26.3%
                    Incremental:  26.3%, 26.4%, 25.3%
  Dumps: lev datestmp  tape             file   origK   compK secs
          0  20010130  CODA001            97   55151   14560   75
          1  20010131  CODA002            73     487     128    3

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.

Jan