All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: "Sergiusz Brzeziński" <Sergiusz.Brzezinski@supersystem.pl>
Cc: Adam Goryachev <mailinglists@websitemanagers.com.au>,
	linux-raid@vger.kernel.org
Subject: Re: mdadm --monitor: need extra feature?
Date: Wed, 22 Aug 2012 17:44:35 +1000	[thread overview]
Message-ID: <20120822174435.685d80d4@notabene.brown> (raw)
In-Reply-To: <503486C7.70503@supersystem.pl>

[-- Attachment #1: Type: text/plain, Size: 2647 bytes --]

On Wed, 22 Aug 2012 09:14:15 +0200 Sergiusz Brzeziński
<Sergiusz.Brzezinski@supersystem.pl> wrote:

> W dniu 21.08.2012 14:39, Adam Goryachev pisze:
> > On 21/08/12 21:51, Sergiusz Brzeziński wrote:
> >>
> >>
> >> W dniu 21.08.2012 12:44, David Brown pisze:
> >>> On 21/08/2012 12:41, Sergiusz Brzeziński wrote:
> >>>> Hi,
> >>>>
> >>>> I use Raid1 to make backup of the whole system.
> >>>
> >>> Raid is not a backup system. It is to improve uptimes, minimise
> >>> downtimes due to
> >>> disk failures, and possibly to improve disk speed and/or capacity.
> >>>
> >>> I would recommend you first think about what you are trying to
> >>> achieve here -
> >>> what are you trying to back up, how do you see restores being used, how
> >>> efficiently are you using your hardware, your bandwidth, your time
> >>> and effort?
> >>>
> >>> You would probably be better off with a normal fixed 2-disk raid1 to
> >>> minimise
> >>> the problems caused by a single disk failure, combined with an rsync
> >>> snapshot
> >>> style backup that can be fully automated and give quick and easy
> >>> recovery of
> >>> multiple old versions of files in the face of the most common cause
> >>> of data loss
> >>> - human error.
> >> [...]
> >>
> >> I know, I know. Raid is not a backup system :)
> > Aside from RAID is not a backup, perhaps the more useful suggestion
> > would be to use the right tool for the job...
> >
> > So, again, ignoring that you possibly should not be using RAID for a
> > backup... how about using udev scripts to see when you plugin a drive,
> > and that script can check the UUID against any md arrays, and if it
> > matches, add it to the array....
> 
> I wrote a script making this work. It runs once a hour. I pass the parameter 
> with md device to the script. It checks the state of the array with "mdadm 
> --detail". If there is something wrong (State : degraded) it reads UUID of that 
> array. Then it scans for /dev/sd* partitions and checks with "mdadm --examine" 
> if UUID matches. If so, the partition can be added with "mdadm --add". That is 
> why I asked abut this feature in mdadm - recognising if there is a new partition 
> belonging to monitored array. With mdadm this procedure would work on elegant 
> manner.
>

udev really is the right way to do this.  Just get udev to run
  mdadm -I /dev/newdev
whenever a device is discovered.  It can then be automatically re-added
depending on the policy set up in mdadm.conf.
"mdadm --monitor" will not gain this functionality.  It is for monitoring
active arrays, not for monitor new devices.

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2012-08-22  7:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-21 10:41 mdadm --monitor: need extra feature? Sergiusz Brzeziński
2012-08-21 10:44 ` David Brown
2012-08-21 11:51   ` Sergiusz Brzeziński
2012-08-21 12:39     ` Adam Goryachev
2012-08-22  7:14       ` Sergiusz Brzeziński
2012-08-22  7:44         ` NeilBrown [this message]
2012-08-22  9:50           ` Sergiusz Brzeziński
     [not found]             ` <5034B0A2.4080403@websitemanagers.com.au>
2012-08-22 10:50               ` Sergiusz Brzeziński
2012-08-22 10:57                 ` Sergiusz Brzeziński

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=20120822174435.685d80d4@notabene.brown \
    --to=neilb@suse.de \
    --cc=Sergiusz.Brzezinski@supersystem.pl \
    --cc=linux-raid@vger.kernel.org \
    --cc=mailinglists@websitemanagers.com.au \
    /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.