public inbox for gentoo-server@lists.gentoo.org
 help / color / mirror / Atom feed
From: Tanner Danzey <arkaniad@gmail.com>
To: Brian Kroth <bpkroth@gmail.com>
Cc: gentoo-server@lists.gentoo.org
Subject: Re: [gentoo-server] Git as backup tool
Date: Tue, 01 Nov 2011 19:39:49 -0500	[thread overview]
Message-ID: <1320194389.6317.1.camel@Scythe> (raw)
In-Reply-To: <20111102001935.GM11848@gmail.com>

On Tue, 2011-11-01 at 19:19 -0500, Brian Kroth wrote:
Not to mention finding a previous snapshot.
"deffee46b0ef8c504498a002443ab23019ee0cc9" isn't really a very good
indicator of when said backup was taken. :P
> Tanner Danzey <arkaniad@gmail.com> 2011-11-01 18:50:
> > Generally, using git is a bad idea for backups (from what I've read)
> >
> > git stores it's data uncompressed and inefficiently. If you are backing
> > up things like configuration files or web pages that can change a lot,
> > sure, but for storing binary files with git, I'd recommend against it,
> > since binaries vary greatly from version to version (unlike text files)
> > and you'd just accumulate tons of useless binaries. programs like
> > duplicity and rsync are great for backups, though.
> 
> Agreed.  There are lots of other spin offs, each with their own pros and 
> cons: rsnapshot, rdiff, etc.  I personally use some homegrown perl, 
> rsync, and zfs snapshots (transparent compression, dedup, each snapshot 
> looks like a full backup, etc.).  I'm sure you could use something like 
> btrfs in that scheme as well.
> 
> However, using git, hg, svn, whatever, for storing your config file 
> repositories for something like cfengine, puppet, whatever is a good 
> idea, but that's a different issue than backups.
> 
> > in all, the drawbacks outweigh the benefits of using a code management
> > tool to back up entire systems...
> >
> > On Tue, 2011-11-01 at 23:16 +0200, Andrey Utkin wrote:
> >> Hi all! Long live the gentoo masters!
> >> I'd like to hear from anybody who uses (or tried) git on production
> >> servers for saving the points of possible restore. Please, share your
> >> practices, like commit patterns, .gitignore contents, etc. I've begun
> >> to use it a couple of days ago for that, and pointed out some issues.
> >> I control the whole root fs with git.
> >> The problematic part is bunch of files that update frequently, but i
> >> am not familiar with them and i'm not sure if system will load without
> >> them.
> >> Namely, these are files in /usr/lib64/portage/pym/
> >> Also wtmp, utmp files hurt - likely without them box won't boot, but
> >> they shouldn't be in git control, too, coz they update often.
> >> Thus, backup restoring requires not git repo only, but also some tar of base?





  reply	other threads:[~2011-11-02  0:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-01 21:16 [gentoo-server] Git as backup tool Andrey Utkin
2011-11-01 21:23 ` Dmitriy Petrov
2011-11-01 23:50 ` Tanner Danzey
2011-11-02  0:19   ` Brian Kroth
2011-11-02  0:39     ` Tanner Danzey [this message]
2011-11-02  2:06       ` Dmitriy Petrov
2011-11-02  3:29         ` Tanner Danzey
2011-11-02  1:21 ` Stefan Behte
2011-11-02  2:08   ` Tanner Danzey
2011-11-02  8:09   ` Andrey Utkin
2011-11-02 10:10 ` Ciprian Dorin Craciun

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=1320194389.6317.1.camel@Scythe \
    --to=arkaniad@gmail.com \
    --cc=bpkroth@gmail.com \
    --cc=gentoo-server@lists.gentoo.org \
    /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