Re: tar backup - inconsistent snapshot of repository

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Geoffrey Hird <address@hidden> writes:

> Suppose:
> 
> 1. We are making a tar of the CVS repository as
> 1. a backup.

You may wish to exclude ,*, files from the backup
tape as well sa the various kinds of CVS lock files. 

Or, you might consider using a LockDir= in the
CVSROOT/config to put the locks into a separate
directory. All of the ,v files should be
self-consistent in this case.

> 2. We do not lock users out from writing to CVS,
> as the process takes 3 hours and there are users
> in multiple time zones.

Sure. We actually use CVSup to create a read-only
clone of the repository that is able to be backed
up and find this to be a superior mechanism for
large repositories... it also gives us a
hot-standby copy in case the primary repository
location has a hardware failure.

CVSup creates a read-lock for each directory in
turn as it copies the deltas across, so each
directory is self-consistent which is a good
thing. It takes about as a much times as a 'cvs
checkout' or 'cvs update' might take to perform,
so it is fairly low overhead to your server.

> 3. A user commits a file during the tar so that
> the CVS bookkeeping is inconsistent with the
> committed contents.

Well, the CVSROOT/history file may not reflect the
contents of the ,v files, but that is not too big
a problem.

> 
> I'd like to know what are the consequences from
> the following point of view. Suppose our CVS
> server dies (irrecoverable disk failure), and we
> switch to a backup machine, and restore the
> repository from the tarball of the previous day.

You will have lost the writes to the ,v files for
new revisions, new tags, modified tags, deleted
tags, deleted revisions, that sort of thing.

> Obviously we've lost a day's work, but that's
> not the end of the world. If the snapshot fails
> badly, it *is* the end of the world.

Yup.

> 
> How bad can things get? 

Well, if you are backing up the ,*, files, then
your users will not be able to commit to those
files as they will be considered 'locked' by the
restored tree. Likewise, if you have the various
cvs.lock directories or the various transient
locks in the tarball, you will need to clean those
out before you can get back to a repository
suitable for commits.

There could be the odd case of a file living in
both the parent directory and being present in the
Attic in the case of a 'cvs rm' having occured.
So, you will need to look for that sort of thing.

> Can this make CVS crash?

No, it should not be a problem. Of course, if the
,v file itself was corrupted due to the root-cause
that is crashing your machine this may not be
true. In that case, you might need to restore that
particular ,v file off of a previous backup.

> Will CVS continue to function, 

Yes.

> but give error messages about just the directory
> in which the file in question was committed?

Probably not even that, depending on the nature of
the operation that was in progress during the
commit.

> Will CVS function with no error reporting, but
> simply show the repository incorrectly from
> users' perspectives?

Yes, this is possible. A 'cvs update' could see
the most 'recent' revision of the users tree being
lost.

> 
> I'd appreciate any help.
> 
> gh

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEPqr7Cg7APGsDnFERAs/aAJ9li34hjolnX6+A6gJ/5s3KSdVo4wCg6MBg
piDmVOonLGpIeswCxa81Mbk=
=tn8H
-----END PGP SIGNATURE-----