Thread: Lost database
<div class="WordSection1"><p class="MsoNormal">While prepping a second server today the /var/lib/postgres/ directory gotdeleted. Yes, everything. We’re running on Ubuntu 10.4 and Postgres 8.4. We immediately shutdown everything but nowneed to recover the directory tree. No, the customer did not do any backups – the database was just under 1 TB and theydidn’t want to take the time.<p class="MsoNormal"> <p class="MsoNormal">We’re looking into using extundelete or ext4magicto try to recover the files and, if successful, are there any further steps we need to take to bring up the databaseagain? <p class="MsoNormal"> <p class="MsoNormal">If we’re unsuccessful, we do have a filesystem backup from severalmonths ago that we can apply and then go through the tedium of trying to fill in the missing blanks for those months. Since there are so many rows, is there a tool or procedure we can use to verify the integrity of the data once Postgresis back up and running?<p class="MsoNormal"> <p class="MsoNormal">I don’t expect any miracles, but want to be surethere isn’t less intensive alternative out there.<p class="MsoNormal"> <p class="MsoNormal">Thanks,<p class="MsoNormal"> <pclass="MsoNormal">Steve Erickson</div>
On Tue, Dec 10, 2013 at 11:08 AM, Steve Erickson <serickson@digitiliti.com> wrote:
While prepping a second server today the /var/lib/postgres/ directory got deleted. Yes, everything. We’re running on Ubuntu 10.4 and Postgres 8.4. We immediately shutdown everything but now need to recover the directory tree. No, the customer did not do any backups – the database was just under 1 TB and they didn’t want to take the time.
We’re looking into using extundelete or ext4magic to try to recover the files and, if successful, are there any further steps we need to take to bring up the database again?
If we’re unsuccessful, we do have a filesystem backup from several months ago that we can apply and then go through the tedium of trying to fill in the missing blanks for those months. Since there are so many rows, is there a tool or procedure we can use to verify the integrity of the data once Postgres is back up and running?
I don’t expect any miracles, but want to be sure there isn’t less intensive alternative out there.
Thanks,
Steve Erickson
Dinesh
On 12/9/2013 10:17 PM, Dinesh Kumar wrote: > > If we’re unsuccessful, we do have a filesystem backup from several > months ago that we can apply and then go through the tedium of trying > to fill in the missing blanks for those months. Since there are so > many rows, is there a tool or procedure we can use to verify the > integrity of the data once Postgres is back up and running? > if the postgresql server was running when that file backup was made(*), its pretty much worthless, it will have data corruption and errors throughout. (*) unless pg_start_backup() was called before the backup, and pg_stop_backup() afterwards, which I sort of doubt would have been done based on what was written. -- john r pierce 37N 122W somewhere on the middle of the left coast
John R Pierce wrote: > if the postgresql server was running when that file backup was made(*), > its pretty much worthless, it will have data corruption and errors > throughout. Well, it would be better than nothing. You can pg_resetxlog and manually clean up the inconsistencies. That's better than nothing at all. Yours, Laurenz Albe