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
prev parent 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).