git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Hudec <bulb@ucw.cz>
To: Thomas Glanzmann <thomas@glanzmann.de>
Cc: GIT <git@vger.kernel.org>
Subject: Re: RFD Use git for off-site backups
Date: Sun, 13 May 2007 14:34:36 +0200	[thread overview]
Message-ID: <20070513123436.GE8983@efreet.light.src> (raw)
In-Reply-To: <20070513093417.GA18546@cip.informatik.uni-erlangen.de>

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

On Sun, May 13, 2007 at 11:34:17 +0200, Thomas Glanzmann wrote:
> I am thinking about using git for doing differential backups of a whole
> machines. And I would like to know what is necessary to obtain that. In
> such a scenario the machine to be backed up should have a local index
> file but sends its objects directly to the remote machine via git-via-ssh
> or git protocol. Is it possible to store extra information like extended
> attributes / acls in git? I don't care about named pipes, sockets and
> device files for the moment.

I don't actually think git is a good match for whole-machine backups. It's
strenghts are in distributedness and branching, but you don't need either of
those for large-scale backups (monitoring changes say in /etc is a different
thing -- git is sensible match there -- see http://www.isisetup.ch/).

I can suggest two solutions:

 - Use CVS on the client (machine to back up) and git-cvsserver on the
   server. You will probably be able to find some scripts that do backups to
   CVS. On server you will still have git for digging in history. Git is also
   very space efficient.

   CVS does not cache any data on the client. It only keeps metadata to
   detect which files were modified. Therefore it will have minimal overhead
   in storage, but needs to transfer the modified files in their entirety.

 - Use Subversion. There is summer of code project to create git-svnserver,
   so you might be able to use git on the server-side in future with
   subversion client too. But for backups you should not need any of the
   version control features subversion does not have, so subversion should be
   suitable.

   Subversion stores copy of the previous revision on the client, so all data
   under it's control will take twice as much space on client, but it will
   only transfer deltas over the network.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2007-05-13 12:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-13  9:34 RFD Use git for off-site backups Thomas Glanzmann
2007-05-13 11:16 ` Johannes Schindelin
2007-05-13 11:18   ` Thomas Glanzmann
2007-05-13 12:34 ` Jan Hudec [this message]
2007-05-13 23:42   ` Shawn O. Pearce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070513123436.GE8983@efreet.light.src \
    --to=bulb@ucw.cz \
    --cc=git@vger.kernel.org \
    --cc=thomas@glanzmann.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).