From: Stephen Frost <sfrost@snowman.net>
To: Vladimir Borodin <root@simply.name>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Backup taking long time !!!
Date: Mon, 23 Jan 2017 01:48:39 -0500
Message-ID: <20170123064839.GT18360@tamriel.snowman.net> (raw)
In-Reply-To: <D60EACF0-5D9B-4CCF-B526-A645319E7AF4@simply.name>
References: <b0748fe40949446283068a4d2d06c158@cyient.com>
<CAFj8pRBFDh=hsghE8v5F71KztyczR7iWBXGJBOLLhUQDwUh8MQ@mail.gmail.com>
<20170120122224.GF18360@tamriel.snowman.net>
<DE553F58-646E-49E8-94D1-31794C3E9040@simply.name>
<20170120134054.GH18360@tamriel.snowman.net>
<7696A57C-C871-4A45-9141-FFD5F75CCB65@simply.name>
<20170120150646.GP18360@tamriel.snowman.net>
<17D95770-42B6-4FF5-80FF-465C77119A27@simply.name>
<20170120165922.GS18360@tamriel.snowman.net>
<D60EACF0-5D9B-4CCF-B526-A645319E7AF4@simply.name>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
Vladimir,
* Vladimir Borodin (root@simply.name) wrote:
> > 20 янв. 2017 г., в 19:59, Stephen Frost <sfrost@snowman.net> написал(а):
> >>> How are you testing your backups..? Do you have page-level checksums
> >>> enabled on your database?
> >>
> >> Yep, we use checksums. We restore latest backup with recovery_target = 'immediate' and do COPY tablename TO '/dev/null’ with checking exit code for each table in each database (in several threads, of course).
> >
> > Right, unfortunately that only checks the heap pages, it won't help with
> > corruption happening in an index file or other files which have a
> > checksum.
>
> That’s fine for us because indexes could be rebuilt. The main idea is the guarantee that data would not be lost.
Fair enough, however, if you don't check that the indexes are valid then
you could end up with corruption in the database if you start operating
against such a recovered database.
Consider what happens on a 'primary key' lookup or insert- if the index
doesn't find a conflicting tuple (perhaps because the index is corrupt),
then it will happily allow the INSERT to go through, even though it
should have been prevented.
Indexes are a *really* important component to having a valid database.
If you aren't checking the validity of them, then you're running the
risk of being exposed to corruption in them, either ongoing or when
restoring.
If you *always* rebuild your indexes when restoring from a backup, then
you should be fine, of course, but if you're going to do that then you
might consider using pg_dump instead, which would do that and validate
all foreign key references too.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: sfrost@snowman.net, root@simply.name
Subject: Re: Backup taking long time !!!
In-Reply-To: <20170123064839.GT18360@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox