Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Pavel Hofman <pavel.hofman@ivitera.com>
To: Phil Turmel <philip@turmel.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: Raid auto-assembly upon boot - device order
Date: Tue, 28 Jun 2011 21:18:33 +0200	[thread overview]
Message-ID: <4E0A2909.5030501@ivitera.com> (raw)
In-Reply-To: <4E09F5A5.3020903@turmel.org>

Dne 28.6.2011 17:39, Phil Turmel napsal(a):
>> 
>> It took me several years to find a reasonably fast way to
>> offline-backup that partition with tens of millions of backuppc
>> hardlinks :)
> 
> I've heard of hardlink horrors with backuppc.  I don't use it myself.
> I prefer to use LVM on top of MD, then take compressed backups of LVM
> snapshots.

One of my goals was to be able to stick the offline backup drives to any
PC, boot from a debian netinstall CD, chroot to the mirrored root, mount
the large data partitions, and be ready to start recovery in a
matter of minutes. Therefore I prefer the whole filesystems mirror.
> 
> Mirror w/ bitmap would make 1:1 backups faster.  I understand why you
> are doing this, but I'd be worried about filesystem integrity at the
> point in time you disconnect the backup drive.  Have you performed
> any tests to be sure you can recover usable data from the offline
> copy?  If I recall correctly, an LVM snapshot operation incorporates
> a filesystem metadata sync.

Yes, I am using a rather complicated automatic procedure. When the
resyncing finishes, the script waits until backuppc finishes the
currently running jobs (while starting new ones is disabled), shuts
backuppc down, kills all other processes accessing the partition,
umounts the filesystem, removes the offline drives from the md5/md6
arrays, mounts the backup raid again, restarts the backup processes, and
then checks the offline copy: mounts the offline drives as partition and
tries to read a random file from it. Only after that are the offline
drives unmounted, their array disassembled and the drives put to sleep,
until the operator removes them from their external bays and takes away
from the company premises.

The offline drives have saved my butt several times :)

Regards,

Pavel.

      reply	other threads:[~2011-06-28 19:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-27 14:15 Raid auto-assembly upon boot - device order Pavel Hofman
2011-06-27 14:47 ` Phil Turmel
2011-06-28 10:18   ` Pavel Hofman
2011-06-28 11:03     ` Phil Turmel
2011-06-28 12:01       ` Pavel Hofman
2011-06-28 15:39         ` Phil Turmel
2011-06-28 19:18           ` Pavel Hofman [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=4E0A2909.5030501@ivitera.com \
    --to=pavel.hofman@ivitera.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=philip@turmel.org \
    /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