Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 6F00A633EEE for ; Wed, 23 Jun 2010 00:36:43 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 65474-06 for ; Wed, 23 Jun 2010 03:36:34 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from bay0-omc2-s26.bay0.hotmail.com (bay0-omc2-s26.bay0.hotmail.com [65.54.190.101]) by mail.postgresql.org (Postfix) with ESMTP id A14D2633577 for ; Wed, 23 Jun 2010 00:36:34 -0300 (ADT) Received: from BAY149-W20 ([65.54.190.125]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 20:36:33 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_37603ea1-c634-4ccc-9889-dd83b3e133c7_" X-Originating-IP: [208.123.162.2] From: Balkrishna Sharma To: , , Subject: Re: db recovery after raid5 failure Date: Tue, 22 Jun 2010 23:36:32 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jun 2010 03:36:33.0114 (UTC) FILETIME=[46649BA0:01CB1285] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.01 tagged_above=-10 required=5 tests=BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201006/180 X-Sequence-Number: 34958 --_37603ea1-c634-4ccc-9889-dd83b3e133c7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > average about two drive failures a monthYou must be having a real huge po= stgres 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=2C as long as it h= ad strong encryption.I didn't expand but that's what I meant. The copy in c= loud 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=2C 22 Jun 2010 09:46:46 -0500 > From: Kevin.Grittner@wicourts.gov > To: b_ki@hotmail.com=3B pgsql-admin@postgresql.org=3B qcor@vp.pl > Subject: Re: [ADMIN] db recovery after raid5 failure >=20 > Balkrishna Sharma wrote: > =20 > > If the database is not extremely huge=2C makes you wonder what does > > a RAID actually give us. > =20 > Well=2C RAID5 gives you a situations where you must have a second > drive fail before recovery for the first failure is complete=2C 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=2C and probably > average about two drive failures a month=3B having any down time from > them is rare because of RAID (and that's with us primarily using > RAID5). > =20 > > 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. > =20 > You've totally lost me there. "The cloud" still uses similar > techniques=2C just out of your sight and control. If you assume that > whoever is running it can do it better than you can=2C that's one > thing=3B 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=2C with > continuous testing that all backups actually restore. If we were to > float data off into a cloud somewhere=2C I can guarantee we wouldn't > count on it without an alternative. As a place to put "one more > copy" it might make sense=2C as long as it had strong encryption.=20 > (Again=2C you've lost all control over who has what access once you > send it into the cloud.) > =20 > -Kevin >=20 > --=20 > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin =20 _________________________________________________________________ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with H= otmail.=20 http://www.windowslive.com/campaign/thenewbusy?tile=3Dmulticalendar&ocid=3D= PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5= --_37603ea1-c634-4ccc-9889-dd83b3e133c7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B average about two dri= ve failures a month
You= must be having a real huge postgres setup with several hundreds of drives = to have such high frequency of failure.


=
>=3B As a place to put "one more
>=3B copy" it might make sense=2C as long as it had strong encr= yption.
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.<= br>



>=3B Date: Tue=2C 22 Jun 2010 0= 9:46:46 -0500
>=3B From: Kevin.Grittner@wicourts.gov
>=3B To: b_k= i@hotmail.com=3B pgsql-admin@postgresql.org=3B qcor@vp.pl
>=3B Subject= : Re: [ADMIN] db recovery after raid5 failure
>=3B
>=3B Balkrish= na Sharma <=3Bb_ki@hotmail.com>=3B wrote:
>=3B
>=3B >=3B = If the database is not extremely huge=2C makes you wonder what does
>= =3B >=3B a RAID actually give us.
>=3B
>=3B Well=2C RAID5 giv= es you a situations where you must have a second
>=3B drive fail befor= e recovery for the first failure is complete=2C versus
>=3B being inst= antly dead on a single-drive failure. RAID6 requires
>=3B three drive= s to fail in close succession (assuming a hot spare which
>=3B initiat= es recovery on failure). RAID10 requires that two paired
>=3B drives = fail. We have about 100 database servers=2C and probably
>=3B average= about two drive failures a month=3B having any down time from
>=3B th= em is rare because of RAID (and that's with us primarily using
>=3B RA= ID5).
>=3B
>=3B >=3B A robust near-realtime replication setup= (say PITR + cloud)
>=3B >=3B may be good enough against once in a f= ew years of disk
>=3B >=3B failure.atleast you don't add another poi= nt of failure that you
>=3B >=3B (your database/OS) can't do anythin= g about.
>=3B
>=3B You've totally lost me there. "The cloud" s= till uses similar
>=3B techniques=2C just out of your sight and contro= l. If you assume that
>=3B whoever is running it can do it better tha= n you can=2C that's one
>=3B thing=3B just don't assume it's magic. T= he machines in my shop are
>=3B what I *can* do something about. Mana= gement here insists on near-
>=3B real-time backup using at least two = completely independent
>=3B techniques to multiple machines in multipl= e buildings=2C with
>=3B continuous testing that all backups actually = restore. If we were to
>=3B float data off into a cloud somewhere=2C = I can guarantee we wouldn't
>=3B count on it without an alternative. = As a place to put "one more
>=3B copy" it might make sense=2C as long = as it had strong encryption.
>=3B (Again=2C you've lost all control o= ver who has what access once you
>=3B send it into the cloud.)
>= =3B
>=3B -Kevin
>=3B
>=3B --
>=3B Sent via pgsql-ad= min mailing list (pgsql-admin@postgresql.org)
>=3B To make changes to = your subscription:
>=3B http://www.postgresql.org/mailpref/pgsql-admin=

The New Busy think 9 to 5 is a cute idea. Com= bine multiple calendars with Hotmail. Get busy. = --_37603ea1-c634-4ccc-9889-dd83b3e133c7_--