linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Les Mikesell <lesmikesell@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM & snapshots
Date: Tue, 20 Feb 2007 07:47:20 -0600	[thread overview]
Message-ID: <45DAFBE8.2040009@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0702201132560.27267@lion.drogon.net>

Gordon Henderson wrote:
> 
> I tried LVM a few years back and "burnt my fingers" as it were - I found 
> it slow and unstable, but times are changing, progress being made, etc. 
> so does anyone have any input on it's current stability and usability?
> 
> Basically, I'm running out of steam on some backup servers I have - 
> trying to copy several TB of data using cp -al, then rsyncing on top of 
> it (and then copying the copy, etc. to give me 30 days of backups) has 
> been working well for some time, but the data-set is increasing all the 
> time, and the cp -al is currently taking 4-5 hours, so snapshotting via 
> LVM is looking like it's something I think I ought to be looking into 
> again.
> 
> The current data-set is 5TB, and having 150TB of storage isn't an option 
> right now... Essentially I need to be able to keep 30 cycles (days) of 
> snapshots on a server that is not a live server (ie. it's a huge disk 
> array, in a secure bunker backing up several remote servers every day, 
> and dumping the occasional snapshot to tape for archive. Data comes into 
> the server via a 100Mb line & rsync from the remote servers).
> 
> So is LVM(2) up to this task these days, or should I really be looking 
> at something else?

You might want to look at backuppc (http://backuppc.sourceforge.net/) to 
manage the on-line backups.  It uses a scheme of compression and 
hard-linking duplicate files to greatly reduce the storage space you 
need when keeping a long history - especially if many files are 
unchanged over that time.   With something that size you might still 
have to play some tricks with snapshots or break it down into smaller 
directory runs.  It uses tar, smb, or rsync to do the actual copies, 
then has some extra overhead for the compression and linking jobs.  If 
it is too slow, you might run it against your existing uncompressed copy 
so it has all day to make the long-term archive version.

-- 
   Les Mikesell
    lesmikesell@gmail.com

  parent reply	other threads:[~2007-02-20 13:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-20 12:58 [linux-lvm] LVM & snapshots Gordon Henderson
2007-02-20 13:40 ` Lars Ellenberg
2007-02-20 15:05   ` Gordon Henderson
2007-02-20 13:47 ` Les Mikesell [this message]
2007-02-20 15:02   ` Gordon Henderson
2007-02-20 19:12     ` Greg Freemyer

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=45DAFBE8.2040009@gmail.com \
    --to=lesmikesell@gmail.com \
    --cc=linux-lvm@redhat.com \
    /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).