From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Kaixi Luo <kaixiluo(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: How safe is pg_basebackup + continuous archiving? |
Date: | 2016-06-30 13:15:54 |
Message-ID: | CAB7nPqRw=qhNbpZoo3SHiOYWjyQtnU3vN-m5tcx+21jLVM82Eg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Jun 30, 2016 at 9:00 PM, Kaixi Luo <kaixiluo(at)gmail(dot)com> wrote:
>> Before replaying a backup on a production system, you would need a
>> pre-production setup where the backup is replayed and checked.
>> Honestly, you can only be sure that a backup is working correctly
>> after reusing it. You could always do some validation of the raw
>> backup contents, but you need at the end the WAL applied on top of it
>> to be able to check the status of a server that has reached a
>> consistent point.
>
>
> Could you elaborate a bit more on this last part? If a PostgreSQL recovery
> from a pg_basebackup reaches a consistent point and is able to start up
> fully, that is not a guarantee that there hasn't been any underlying
> corruption, as far as I know. Am I correct on this?
You are correct, that's why you need a copycat of the production
system that is a pre-stage of the production stage, where the backups
are replayed and checked with an application that replays the patterns
of the production application. Applying extra checks on top of that is
good as well: pg_dump, data checksums, index consistency checks (this
makes regret that we don't have pg_amcheck in core yet actually), etc.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Morgan Lloyd | 2016-06-30 13:18:13 | Re: Stored procedure version control |
Previous Message | Nick Babadzhanian | 2016-06-30 13:15:17 | Replication with non-read-only standby. |