From: Stephen Frost <sfrost@snowman.net>
To: Vladimir Borodin <root@simply.name>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Dinesh Chandra 12108 <Dinesh.Chandra@cyient.com>
Cc: Madusudanan.B.N <b.n.madusudanan@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: David Steele <david@pgmasters.net>
Subject: Re: Backup taking long time !!!
Date: Fri, 20 Jan 2017 11:59:22 -0500
Message-ID: <20170120165922.GS18360@tamriel.snowman.net> (raw)
In-Reply-To: <17D95770-42B6-4FF5-80FF-465C77119A27@simply.name>
References: <23dc5b1ea9604ec3afdaabdd15491085@cyient.com>
<CAFj8pRAHx-Wt4fyJmF=YH-F2_S=mO2E+=JDx+qnunkDP5_FPGA@mail.gmail.com>
<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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
Vladimir,
* Vladimir Borodin (root@simply.name) wrote:
> > 20 янв. 2017 г., в 18:06, Stephen Frost <sfrost@snowman.net> написал(а):
> >
> > Right, without incremental or compressed backups, you'd have to have
> > room for 7 full copies of your database. Have you looked at what your
> > incrementals would be like with file-level incrementals and compression?
>
> Most of our DBs can’t use partitioning over time-series fields, so we have a lot of datafiles in which only a few pages have been modified. So file-level increments didn’t really work for us. And we didn’t use compression in barman before patching it because single-threaded compression sucks.
Interesting. That's certainly the kind of use-case we are thinking
about for pgbackrest's page-level incremental support. Hopefully it
won't be too much longer before we add support for it.
> > 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.
> > pgbackrest recently added the ability to
> > check PG page-level checksums during a backup and report issues.
>
> Sounds interesting, should take a look.
It's done with a C library that's optional and not yet included in the
packages on apt/yum.p.o, though we hope it will be soon. The C library
is based, unsurprisingly, on the PG backend code and so should be pretty
fast. All of the checking is done on whole pgbackrest blocks, in
stream, so it doesn't slow down the backup process too much.
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, pavel.stehule@gmail.com, Dinesh.Chandra@cyient.com, b.n.madusudanan@gmail.com, david@pgmasters.net
Subject: Re: Backup taking long time !!!
In-Reply-To: <20170120165922.GS18360@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