Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

forcing a raid recovery



I have done this too.  Even with a good disk backup, a tape copy is
not a bad idea,
and it could be your 'once a week to validate reads' too.

In one mainframe shop I had 3x the maximum disk needed, and did a round robin
copy into what were effectively 3 partitions on different drives.  It
re-organized the
database and gave me other maintenance space too.  copy c was erased,
giving work room,
copy A (this week) was copied into copy B, copy B was reorganized in place.
Copy B becomes 'live', copy 'A' becomes a static backup, copy 'C' is
the prior week
backup that will be erased before next weeks 'roll and update' procedure.

Just some thoughts from what has worked.

><> ... Jack



On Tue, Nov 3, 2009 at 1:12 PM, Stephen Adler <adler-wRvlPVLobi1/31tCrMuHxg at public.gmane.org> wrote:
> Hi all,
>
> I'm putting together a backup system at my job and in doing so setup the
> good ol' raid 5 array. While I was putting the disk array together, I
> read that one could encounter a problem in which you replace a failed
> drive, the rebuilding processes will trip over another bad sector in on
> of the drives which was good before starting the rebuilding process and
> thus you end up with a screwed up raid array. So I was thinking of a way
> to avoid this problem. One solution is to kick off a job once a week or
> month in which you force the whole raid array to be read. I was thinking
> of possibly forcing a check sum of all the files I had stored on the
> disk. The other idea I had was to force one of the drives into a failed
> state and then add it back in and thus force the raid to rebuild. The
> rebuilding processes takes about 3 hours on my system which I could
> easily execute at 2am every Sunday morning.
>
> Can anyone comment on this as a reliable way to exercise the disks in
> the array so that a bad sector doesn't get touched until a rebuild occurs?
>
> thanks. Steve.
>
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org