Thanks Mark. That's good information. A couple of questions. > You may wish to exclude ,*, files from the backup > tape as well sa the various kinds of CVS lock files.
What do you mean by ,*, files? I haven't seen either ,*, or ,foo, . > 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. Why would moving the lock files make a difference? Thanks again, gh > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Mark D. Baushke > Sent: Thursday, April 13, 2006 12:48 PM > To: Geoffrey Hird > Cc: [email protected] > Subject: Re: tar backup - inconsistent snapshot of repository > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Geoffrey Hird <[EMAIL PROTECTED]> 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----- > _______________________________________________ info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs
