All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Brett Maton <Brett.Maton@simplyhealth.co.uk>
Cc: linux-raid@vger.kernel.org
Subject: Re: mdadm break / restore soft mirror
Date: Thu, 13 Dec 2007 17:45:09 -0500	[thread overview]
Message-ID: <4761B5F5.3000505@tmr.com> (raw)
In-Reply-To: <05ED21952E28E94E8352836547A6BA37042318B3@achmsx001.hsa.co.uk>

Brett Maton wrote:
> Hi, 
>
>   Question for you guys. 
>
>   A brief history: 
>   RHEL 4 AS 
>   I have a partition with way to many small files on (Usually around a couple of million) that needs to be backed up, standard
>
>   methods mean that a restore is impossibly slow due to the sheer volume of files. 
>   Solution, raw backup /restore of the device.  However the partition is permanently being accessed. 
>
>   Proposed solution is to use software raid mirror.  Before backup starts, break the soft mirror unmount and backup partition
>
>   restore soft mirror and let it resync / rebuild itself. 
>
>   Would the above intentional break/fix of the mirror cause any problems? 
>   

Probably. If by "accessed" you mean read-only, you can do this, but if 
the data is changing you have a serious problem that the data on the 
disk and queued in memory may leave that part on the disk as an 
inconsistent data set. If there is a means of backing up a set of files 
which are changing other than stopping the updates in a known valid 
state, it's not something which I've seen really work in all cases.

DM has some snapshot capabilities, but in fact they have the same 
limitation, the data on a partition can be backed up, but unless you can 
ensure that the data is in a consistent state when it's frozen, your 
backup will have some small possibility of failure. Database programs 
have ways to freeze the data to do backups, but if an application 
doesn't have a means to force the data on the disk valid, it will only 
be a "pretty good" backup.

I suggest looking at things like rsync, which will not solve the 
changing data problem, but may do the backup quickly enough to be as 
useful as what you propose. Of course a full backup is likely to take a 
long time however you do it.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 



  parent reply	other threads:[~2007-12-13 22:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-12 22:08 mdadm break / restore soft mirror Brett Maton
2007-12-12 22:27 ` Richard Scobie
2007-12-13  1:19 ` Neil Brown
2007-12-13  4:00   ` Jeff Breidenbach
2007-12-13  4:16     ` Neil Brown
2007-12-14  7:40       ` Jeff Breidenbach
2007-12-14  9:08         ` Neil Brown
2007-12-14 19:13           ` Jeff Breidenbach
2007-12-14 19:52             ` Jeff Breidenbach
2007-12-13 22:45 ` Bill Davidsen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-12-13  7:02 Brett Maton
2007-12-14  0:04 ` 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=4761B5F5.3000505@tmr.com \
    --to=davidsen@tmr.com \
    --cc=Brett.Maton@simplyhealth.co.uk \
    --cc=linux-raid@vger.kernel.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 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.