All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nataraj <incoming-redhat@rjl.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Q: LVM over RAID, or plain disks? A:"Yes" = best of both worlds?
Date: Mon, 29 Nov 2010 10:57:36 -0800	[thread overview]
Message-ID: <4CF3F7A0.2080108@rjl.com> (raw)
In-Reply-To: <AANLkTimGkMJGiJC+7L+Pu3+yf-J_s0Ex3hM2-g-0+UqQ@mail.gmail.com>

hansbkk@gmail.com wrote:
>  - - - - - - My abject apologies to all for improper addressing in my
> previous messages (thanks to all those who set me straight :)
>
> Hope you're all still willing to consider my request for feedback.
> Start with a bit of context:
>
> - SAN/NAS (call it FILER-A) hosting say a dozen TB and servicing a few
> dozen client machines and servers, mostly virtual hosts. Another,
> larger (FILER-B - still just tens of TB) host's drives are used for
> storing backup sets, via not only Amanda, but also filesystems
> comprising gazillions of hard-linked archive sets created by (eg)
> rdiff-backup, rsnapshot and BackupPC. We're on a very limited budget,
> therefore no tape storage for backups.
>
> - I plan to run LVM over RAID (likely RAID1 or RAID10) for IMO an
> ideal combination of fault tolerance, performance and flexibility.
>
> - I am not at this point overly concerned about performance issues -
> reliability/redundancy and ease of recovery are my main priorities.
>
>
> Problem:
>
> For off-site data rotation, the hard-linked filesystems on FILER-B
> require full filesystem cloning with block-level tools rather than
> file-level copying or sync'ing. My current plan is to swap out disks
> mirrored via RAID, marking them as "failed" and then rebuilding using
> the (re-initialized) incoming rotation set.
>
> HOWEVER - the use of LVM (and possibly RAID10) adds complexity to the
> filesystems, which makes disaster recovery from the detached disk sets
> much more difficult than regular partitions on physical disks.
>
>
> Theoretical solution:
>
> Use RAID1 on the "top layer" to mirror the data stored in an LVM (set
> of) disk(s) on the one hand (call it TopRAID1) to ***regular
> partitions*** on actual physical disks on the other (call this the
> TopRAID2 side).
>
>   
Your proposed solution is a bit confusing to understand, however raid1 
works for doing backups in the manner that you describe .  I use it 
myself and I have, over time read about others doing so as well.  Be 
sure to create your volumes with --bitmap=internal, that way when you 
swap in a drive, it won't need to replicate the entire drive, only the 
part that is changed.

If your not going to manage the drives yourself, you will need an 
operations staff that has a pretty good understanding of how raid works 
and/or possibly write a robust set of scripts to manage the drives, 
ensure that the correct volume is mounted, etc.  Also, I don't 
personally feel that disks are a suitable media for long term data 
archival, so if that is really your purpose, as opposed to a quick way 
to recover from a disk failure, then you might consider doing periodic 
tape or optical media backups as well.

Nataraj

  parent reply	other threads:[~2010-11-29 18:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-28 15:30 Q: LVM over RAID, or plain disks? A:"Yes" = best of both worlds? hansbkk
2010-11-28 15:31 ` [linux-lvm] " hansbkk
2010-11-29 16:27   ` Lars Ellenberg
2010-11-29 17:00     ` hansbkk
2010-11-29 18:57   ` Nataraj [this message]
2010-11-30  5:20     ` hansbkk
2010-11-30  7:14       ` Nataraj
2010-11-30  7:34         ` hansbkk
2010-11-30  7:34           ` hansbkk
2010-11-30 13:13           ` Phil Turmel
2010-11-30 13:13             ` Phil Turmel
2010-11-30 15:39             ` hansbkk
2010-11-30 15:39               ` hansbkk
2010-11-30 16:56               ` Phil Turmel
2010-11-30 16:56                 ` Phil Turmel
2010-12-01  4:45                 ` hansbkk
2010-12-01  4:45                   ` hansbkk
2010-12-01 12:50                   ` Phil Turmel
2010-12-01 19:47                     ` hansbkk
2010-12-01 19:47                       ` hansbkk
2010-11-30 15:41           ` Andrew Gideon
2010-11-30 15:53             ` hansbkk
2010-11-30 15:54               ` hansbkk
2010-11-28 18:34 ` Leslie Rhorer
2010-11-29 11:01   ` [linux-lvm] " hansbkk
2010-11-29 11:01     ` hansbkk
2010-11-29 15:29     ` [linux-lvm] " Keld Jørn Simonsen
2010-11-29 15:29       ` Keld Jørn Simonsen
2010-11-29 16:00       ` hansbkk
2010-11-30  0:42         ` Neil Brown
2010-11-30  5:35           ` hansbkk
2010-11-30  6:47             ` Neil Brown

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=4CF3F7A0.2080108@rjl.com \
    --to=incoming-redhat@rjl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.