From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "'chris faber *EXTERN*'" <chris(at)techfaber(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: DATA Integrity & Recovery |
Date: | 2017-07-12 14:51:01 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B53A82084@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
chris faber wrote:
> Postgres 9.2
>
> We have a POSTGRES database that we have been backing up via Incremental backups.
You are talking of a physical base backup and WAL archives, right?
> We had an incident where we had to recover from backup. Our software vendor has completed
> a restore and we have lost 10 days of data. There is no explanation as to the reason we
> have sustained this loss.
Then press your software wendor for a reason.
They did the restore, so they should know.
> I would appreciate the communities help in the following:
>
> 1. Determine if data from the incremental backups can be restored or recovered.
If properly done, you can recover to any point of time after the backup with
a base backup and WAL archives.
> 2. Determine if data can be recovered from individual files backed up from main Postgres
> data directory.
That is more tricky. There is no straightforward way to extract such
information, particularly if the commit log is missing.
If that file is from a base backup, there is the additional difficulty
that the file could be in an inconsistent state.
You would have to hire a specialist for such work.
It sounds like you should consider letting somebody more reliable than
your software vendor manage your database backups.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | stevenchang1213 | 2017-07-12 15:34:13 | Re: DATA Integrity & Recovery |
Previous Message | Rich Shepard | 2017-07-12 14:37:57 | Re: DATA Integrity & Recovery |