From: Goswin von Brederlow <goswin-v-b@web.de>
To: Neil Brown <neilb@suse.de>
Cc: Daniel Reurich <daniel@centurion.net.nz>,
linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Raid1 backup solution.
Date: Wed, 03 Mar 2010 11:59:28 +0100 [thread overview]
Message-ID: <87k4ttllgv.fsf@frosties.localdomain> (raw)
In-Reply-To: <20100302212202.061ffba1@notabene.brown> (Neil Brown's message of "Tue, 2 Mar 2010 21:22:02 +1100")
Neil Brown <neilb@suse.de> writes:
> On Tue, 02 Mar 2010 22:50:07 +1300
> Daniel Reurich <daniel@centurion.net.nz> wrote:
>
>> Hi Guys.
>>
>> I'm considering implementing a rotating offsite backup solution using
>> raid 1. This solution uses 1 or more internal drives and 2 external
>> e-sata harddrives. The raid setup would be a whole disk partitionable
>> raid1 volume.
>>
>> The idea is that by swapping the external drives, I can have a
>> boot-able ready to run offsite backup of the machine, as well as
>> redundancy on the machine itself. Backups of the important data would
>> be replicated via an incremental daily backup process onto the raid
>> volume itself.
>>
>> The part that concerns me is how to get a clean removal of the drive
>> being swapped out, and how will the raid handle having a stale drive
>> inserted/re-added.
>>
>> I have been considering a couple of ways to handle this:
>>
>> 1) Power the machine down to swap the drives. This has the advantage
>> that the backup is always in a clean bootable state with filesystem
>> consistency pretty much guaranteed.
>>
>> 2) Use mdadm to fail and remove the drives, and then re-add the newly
>> attached stale drive. (Perhaps a udev rule could be made handle the
>> re-add). The disadvantage is this will potentially leave the backup in
>> an inconsistent and possibly un-bootable state unless there is a way to
>> quiesce and sync disk activity before the removal. It will also mark
>> the drive as failed and require It's advantage is that the machine
>> doesn't need to be turned off.
>
> How could it fail to boot?
>
> If your machine crashes, it still boots - right?
> So if you fail the drive at any random time, then it is like a crash, and
> should still boot.
>
> I would:
> sync ; sync; mdadm /dev/mdX -f /dev/whatever
> unplug the device
> mdadm /dev/mdX --remove detached
You can improve on that with lvm and suspending the filesystems. That
ensures that nothing starts just between the sysnc and --fail. But if
you want to suspend / too (in case it isn't read-only) you will need an
tmpfs or ramdisk holding everything needed to suspend and fail the disk.
Having / and /usr read-only will basically garanty a bootable system
alraedy so suspending might be overkill.
> Also, if you want two rotating backups I would create two stacked raid1s.
>
> mdadm -C /dev/md0 -l1 -n2 -b internal /dev/main-device /dev/first-backup
> mdadm -C /dev/md1 -l1 -n2 -b internal /dev/md0 /dev/second-backup
> mkfs -j /dev/md1
>
> Then when you add either device back in, it will just resync the bits that
> have changed since that device was last attached. Make sure you add the
> device to the correct array of course.
>
> NeilBrown
MfG
Goswin
prev parent reply other threads:[~2010-03-03 10:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 9:50 Raid1 backup solution Daniel Reurich
2010-03-02 10:05 ` Daniel Reurich
2010-03-02 10:24 ` Michael Evans
2010-03-02 10:22 ` Neil Brown
2010-03-03 10:59 ` Goswin von Brederlow [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=87k4ttllgv.fsf@frosties.localdomain \
--to=goswin-v-b@web.de \
--cc=daniel@centurion.net.nz \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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