Re: how to backup git

Daniel Barkalow [off-list ref] writes:

On Mon, 12 May 2008, bill lam wrote:

quoted

Johannes Schindelin wrote:

quoted

quoted

I'd rsync just the .git directory.

Thanks to all responders for quick reply. I still have a related question. svn
has a hotcopy command to ensure integrity so that it is possible to backup
without shutting down the svn server. If someone update the .git while I am
performing backup using tar or rsync? Will the atomicity of that commit still
preserve in my backup copy?

There's the risk that the backup will start, it will copy all of the 
objects, then a git commit happens, which adds more objects (after rsync 
has passed) and updates a "refs" entry to refer to one of them, and then 
rsync copies the "refs" directory.

It's likewise possible to have part of the information for a commit copied 
and part of it not. This commit will be clearly broken, however (one or 
more objects not found). 

So, essentially, every commit goes through the stages of not at all 
written, partially written but invalid, and valid and correct. 
Independantly, which commit is the latest is updated atomically. It's 
possible for an ill-timed backup to get a branch updated to a commit 
that's not yet valid in the backup. In you restored from this, you'd need 
to use one of several methods (mainly reflogs) to get back to the last 
valid commit that got backed up.

On the other hand, git will never, even in this sort of backup, end up 
with a commit that's valid but not completely correct.

I think suggestions from old timers on this thread to first "git fetch" is
to handle that concern.  It may not get the commit that is being created
simultaneously when such a fetch to backup repository is running (but that
will be backed up during the next round), but at least the contents of the
backup repository would be self contained and correct.  So a nightly fetch
(perhaps with --mirror) into a backup repository, and then after the fetch
finishes, copying the backup repository to tape, would give you one copy a
night.  Copying out from the central repository to backup repository would
be incremental, and until you repack the backup repository, the tape
backup of that backup repository could also be made incremental, as fetch
will be append-only into its objects/ part with updates to refs/ part.

On Mon, 12 May 2008, Junio C Hamano wrote:

Daniel Barkalow [off-list ref] writes:

I think suggestions from old timers on this thread to first "git fetch" is
to handle that concern.

Yeah, "git fetch" is the right solution (although it's a pain to do a 
backup of "every repo under <path>" or "every repo anywhere under <path>" 
that way, which I suspect of being the real issue). I just wanted to get a 
note into this thread of what problems using rsync can and cannot have, 
since it's different (both more and less reliable) from what the original 
poster asked about.

It may not get the commit that is being created simultaneously when such 
a fetch to backup repository is running (but that will be backed up 
during the next round), but at least the contents of the backup 
repository would be self contained and correct.

And simultaneous commit isn't really an issue; nothing will back up work 
you do right after the backup runs, and users can't tell whether they did 
the commit before or after the backup if it's close.

	-Daniel
*This .sig left intentionally blank*