Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 4729363261F for ; Mon, 21 Jun 2010 19:28:05 -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 70928-05 for ; Mon, 21 Jun 2010 22:27:57 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from bay0-omc2-s18.bay0.hotmail.com (bay0-omc2-s18.bay0.hotmail.com [65.54.190.93]) by mail.postgresql.org (Postfix) with ESMTP id 1DEA1632340 for ; Mon, 21 Jun 2010 19:27:56 -0300 (ADT) Received: from BAY149-W42 ([65.54.190.125]) by bay0-omc2-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jun 2010 15:27:55 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c2f393bf-d0f6-4b72-b53f-fc59107396d7_" X-Originating-IP: [69.243.212.79] From: Balkrishna Sharma To: , , Subject: Re: db recovery after raid5 failure Date: Mon, 21 Jun 2010 18:27:54 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2010 22:27:55.0163 (UTC) FILETIME=[FE6BC6B0:01CB1190] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.01 tagged_above=-10 required=5 tests=BAYES_20=-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/147 X-Sequence-Number: 34925 --_c2f393bf-d0f6-4b72-b53f-fc59107396d7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the database is not extremely huge=2C makes you wonder what does a RAID = actually give us. A robust near-realtime replication setup (say PITR + clou= d) may be good enough against once in a few years of disk failure.atleast y= ou don't add another point of failure that you (your database/OS) can't do = anything about. > Date: Mon=2C 21 Jun 2010 15:30:45 -0500 > From: Kevin.Grittner@wicourts.gov > To: pgsql-admin@postgresql.org=3B qcor@vp.pl > Subject: Re: [ADMIN] db recovery after raid5 failure >=20 > wrote: > =20 > > I have serious problems recovering our db after recent raid5 > > failure. Long story short - no recent dumps=2C some missing files > > (like pg_control). > =20 > Been there -- at least on the end of helping with recovery for > people in that position with a different database product. It can > be very painful. :-( (I'm assuming from your post that a second > drive failed before recovery from failure of the first was > complete.) > =20 > First a word of advice -- don't discard anything. Keep any backups=2C > keep the bad drives=2C keep any logs=2C exports=2C reports=2C or anything > else which might contain fragments of the data. Make a backup of > what you have now=2C if you haven't already. Keep these things for a > long time. > =20 > Second=2C a word of encouragement -- given all these scattered > fragments and enough time and money=2C you'd might be surprised at how > much data can be recovered. But time and money is required -- > someone has to make the hard call of how much money it is worth to > recover how much of the data. > =20 > Based on your description=2C it sounds like you will probably need the > assistance of an outside company to recover very much. Possibly one > company specializing in recovery of data off of damaged disks=2C and > another for PostgreSQL internals expertise. > =20 > I don't suppose there's another source for the data to avoid > attempting this recovery? > =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 _________________________________________________________________ Hotmail has tools for the New Busy. Search=2C chat and e-mail from your inb= ox. http://www.windowslive.com/campaign/thenewbusy?ocid=3DPID28326::T:WLMTAGL:O= N:WL:en-US:WM_HMP:042010_1= --_c2f393bf-d0f6-4b72-b53f-fc59107396d7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the database is not extremely huge=2C makes you wonder what does a RAID = actually give us. A robust near-realtime replication setup (say PITR + clou= d) may be good enough against once in a few years of disk failure.
atle= ast you don't add another point of failure that you (your database/OS) can'= t do anything about.


>=3B Date: Mon=2C 21 Ju= n 2010 15:30:45 -0500
>=3B From: Kevin.Grittner@wicourts.gov
>=3B= To: pgsql-admin@postgresql.org=3B qcor@vp.pl
>=3B Subject: Re: [ADMIN= ] db recovery after raid5 failure
>=3B
>=3B <=3Bqcor@vp.pl>= =3B wrote:
>=3B
>=3B >=3B I have serious problems recovering = our db after recent raid5
>=3B >=3B failure. Long story short - no = recent dumps=2C some missing files
>=3B >=3B (like pg_control).
&= gt=3B
>=3B Been there -- at least on the end of helping with recover= y for
>=3B people in that position with a different database product. = It can
>=3B be very painful. :-( (I'm assuming from your post that = a second
>=3B drive failed before recovery from failure of the first w= as
>=3B complete.)
>=3B
>=3B First a word of advice -- don= 't discard anything. Keep any backups=2C
>=3B keep the bad drives=2C = keep any logs=2C exports=2C reports=2C or anything
>=3B else which mig= ht contain fragments of the data. Make a backup of
>=3B what you have= now=2C if you haven't already. Keep these things for a
>=3B long tim= e.
>=3B
>=3B Second=2C a word of encouragement -- given all the= se scattered
>=3B fragments and enough time and money=2C you'd might b= e surprised at how
>=3B much data can be recovered. But time and mone= y is required --
>=3B someone has to make the hard call of how much mo= ney it is worth to
>=3B recover how much of the data.
>=3B
&= gt=3B Based on your description=2C it sounds like you will probably need th= e
>=3B assistance of an outside company to recover very much. Possibl= y one
>=3B company specializing in recovery of data off of damaged dis= ks=2C and
>=3B another for PostgreSQL internals expertise.
>=3B =
>=3B I don't suppose there's another source for the data to avoid
= >=3B attempting this recovery?
>=3B
>=3B -Kevin
>=3B >=3B --
>=3B Sent via pgsql-admin mailing list (pgsql-admin@postgr= esql.org)
>=3B To make changes to your subscription:
>=3B http://= www.postgresql.org/mailpref/pgsql-admin

Hotmail has tools for the New Busy. Search=2C chat = and e-mail from your inbox. Learn more. = --_c2f393bf-d0f6-4b72-b53f-fc59107396d7_--