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] Data deduplication in LVM?
Date: Thu, 11 Jun 2009 10:35:09 -0500	[thread overview]
Message-ID: <4A31242D.5090501@gmail.com> (raw)
In-Reply-To: <4A30F8E3.5090508@gmail.com>

Les Mikesell wrote:
> Roy Sigurd Karlsbakk wrote:
>> On 11. juni. 2009, at 00.30, Stuart D. Gathman wrote:
>>
>>> One OSS backup product that does
>>> deduplication is BackupPC (written in Perl).  In the backup server, 
>>> every file
>>> gets hard linked to a name in a special directory that is its md5 
>>> checksum
>>> (plus some fiddly logic to handle metadata)
>>
>>
>> This sounds like file-level deduplication. Most storage systems sing 
>> dedup, uses block-level dedup. NetApp is one example; they dedup 
>> everything with 4k blocks, doing the actual deduplication at night.
> 
> Yes, it is a different concept.  However it does work very well when you 
> are storing your backups on a filesystem without block-level dedup.  And 
> that is probably the place where you have the most redundancy - or if 
> you don't already, you'll be able to store a much longer history.

Apologies for following up my own post, but this does remind me of a 
slightly related problem that someone here might have solved.  The 
backuppc archive ends up containing such a large number of directory 
entries and hardlinks that it is typically impractical to copy by any 
file-oriented means or even rsync.   A recurring topic on the backuppc 
mail list is how to make a copy for offsite storage.

Personally I use a RAID1 created with 3 mirror members and periodically 
swap one out and resync, but that's not very elegant.  Is there a better 
way or one that could be incrementally updated across a WAN?  Does LVM 
have a mechanism like zfs's incremental snapshot send/receive? (Not sure 
if that would work either but it sounds promising).  Is there any other 
way to do a block-oriented remote copy?  Would LVM mirroring work as 
well or better than md-device raid?  The partition can stay mounted 
while the raid rebuilds but realistically not much else can be happening 
because of the performance impact, and I unmount momentarily while 
removing the member to get a clean filesystem.

Are there tricks with drbd or perhaps raid over iscsi that would let a 
periodic sync work incrementally - well enough to use over a WAN?

-- 
   Les Mikesell
     lesmikesell@gmail.com

      reply	other threads:[~2009-06-11 15:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-10 18:41 [linux-lvm] Data deduplication in LVM? Roy Sigurd Karlsbakk
2009-06-10 18:48 ` Ray Van Dolson
2009-06-10 18:54 ` Les Mikesell
2009-06-10 18:59   ` Roy Sigurd Karlsbakk
2009-06-10 19:30     ` Les Mikesell
2009-06-10 19:33       ` Brian J. Murrell
2009-06-10 19:34       ` Ray Van Dolson
2009-06-10 19:04 ` Roy Sigurd Karlsbakk
2009-06-10 22:30 ` Stuart D. Gathman
2009-06-11 10:19   ` Roy Sigurd Karlsbakk
2009-06-11 12:30     ` Les Mikesell
2009-06-11 15:35       ` Les Mikesell [this message]

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=4A31242D.5090501@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).