On Thu, 13 Jan 2000, Quinn Weaver wrote:

> Greetings,
> 
> In setting up Coda, I noticed that the backup scripts depend on dump.
> This is a problem for the use of Coda I have planned, since it requires
> a quiescent filesystem.  I was wondering whether anyone has experimented
> with backup methods that can be used while the filesystem is active, like
> tar.  This leads to two questions:

Coda backups involve generating a read-only clone of the volume to be
backed up. Writes to the volume are blocked during the short cloning
process, so the clone is a snapshot of the active filesystem. The cloned
volume is then dumped to a single file on disk, which can then be copied
to tape at leisure, in this case using dump.
 
> 1) Is this possible?  My understanding is that metadata are kept in the
> cache, not in regular files on the Coda filesystem, so I am afraid that
> tar (and any other file-oriented backup tool) will be unable to back up
> metadata.

On the client, the metadata is not stored in the container files, but in a
"recoverable virtual memory" file. Venus makes it available to any process
that needs it through the normal FS calls. So running tar on a _client_ 
will generate a correct backup of whatever directory tree you wish. The
exception is that tar doesn't know about ACLs, so those will not be backed
up. 

The servers also store metadata in their own RVM, and the sections of RVM
that pertain to the volume being backed up are written into the backup
file on disk during the backup process. The advantage is that this
captures everything the server knows about that volume.

 
> 2) Even if tar can back up metadata, there is the question of keeping the
> metadata consistent with the state of the filesystem.  I can imagine a
> case where the metadata have a record of an impending write, and you back
> up that record, and then the write occurs.  In that case, your backup
> would contain a copy of the file from after the write, but it would have
> a record that the write still needed to be made.  There would be an
> inconsistency.  I suppose that, if you restored such a backup, Coda would
> complain and you would have to fix a bunch of stuff.

Writes & cloning (and almost everything else that modifies permanent
state) are done transactionally, so the backup will never be able to take
a snapshot during the middle of a write. It also makes recovery easier
since the metadata will never be inconsistent. The downside of this is
that we have to wait for the log entry for each operation to make it to
disk before the server can report its completion.

Shafeeq