(Illustration by Gaich Muramatsu)
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. ShafeeqReceived on 2000-01-14 18:32:52