From: Balkrishna Sharma <b_ki@hotmail.com>
To: kevin.grittner@wicourts.gov
To: pgsql-admin@postgresql.org
To: qcor@vp.pl
Subject: Re: db recovery after raid5 failure
Date: Tue, 22 Jun 2010 23:36:32 -0400
Message-ID: <BAY149-w20EA5F0BE979908ED30D5DF0C50@phx.gbl> (raw)
> average about two drive failures a monthYou must be having a real huge postgres setup with several hundreds of drives to have such high frequency of failure.
> As a place to put "one more> copy" it might make sense, as long as it had strong encryption.I didn't expand but that's what I meant. The copy in cloud to be your final resort incase the LAN and the WAN copy both fail. You get an extra copy in a different geographic location for some catastrophic event.
> Date: Tue, 22 Jun 2010 09:46:46 -0500
> From: Kevin.Grittner@wicourts.gov
> To: b_ki@hotmail.com; pgsql-admin@postgresql.org; qcor@vp.pl
> Subject: Re: [ADMIN] db recovery after raid5 failure
>
> Balkrishna Sharma <b_ki@hotmail.com> wrote:
>
> > If the database is not extremely huge, makes you wonder what does
> > a RAID actually give us.
>
> Well, RAID5 gives you a situations where you must have a second
> drive fail before recovery for the first failure is complete, versus
> being instantly dead on a single-drive failure. RAID6 requires
> three drives to fail in close succession (assuming a hot spare which
> initiates recovery on failure). RAID10 requires that two paired
> drives fail. We have about 100 database servers, and probably
> average about two drive failures a month; having any down time from
> them is rare because of RAID (and that's with us primarily using
> RAID5).
>
> > A robust near-realtime replication setup (say PITR + cloud)
> > may be good enough against once in a few years of disk
> > failure.atleast you don't add another point of failure that you
> > (your database/OS) can't do anything about.
>
> You've totally lost me there. "The cloud" still uses similar
> techniques, just out of your sight and control. If you assume that
> whoever is running it can do it better than you can, that's one
> thing; just don't assume it's magic. The machines in my shop are
> what I *can* do something about. Management here insists on near-
> real-time backup using at least two completely independent
> techniques to multiple machines in multiple buildings, with
> continuous testing that all backups actually restore. If we were to
> float data off into a cloud somewhere, I can guarantee we wouldn't
> count on it without an alternative. As a place to put "one more
> copy" it might make sense, as long as it had strong encryption.
> (Again, you've lost all control over who has what access once you
> send it into the cloud.)
>
> -Kevin
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
_________________________________________________________________
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL...
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: b_ki@hotmail.com, kevin.grittner@wicourts.gov, qcor@vp.pl
Subject: Re: db recovery after raid5 failure
In-Reply-To: <BAY149-w20EA5F0BE979908ED30D5DF0C50@phx.gbl>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox