[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: tar backup - inconsistent snapshot of repository
From: |
Geoffrey Hird |
Subject: |
RE: tar backup - inconsistent snapshot of repository |
Date: |
Mon, 17 Apr 2006 17:53:39 -0700 |
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: address@hidden [mailto:address@hidden On Behalf Of
> Mark D. Baushke
> Sent: Thursday, April 13, 2006 12:48 PM
> To: Geoffrey Hird
> Cc: address@hidden
> Subject: Re: tar backup - inconsistent snapshot of repository
>
> -----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-----
>