| From: | Vladimir Borodin <root(at)simply(dot)name> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Dinesh Chandra 12108 <Dinesh(dot)Chandra(at)cyient(dot)com>, "Madusudanan(dot)B(dot)N" <b(dot)n(dot)madusudanan(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net> |
| Subject: | Re: Backup taking long time !!! |
| Date: | 2017-01-20 16:44:17 |
| Message-ID: | 17D95770-42B6-4FF5-80FF-465C77119A27@simply.name |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> 20 янв. 2017 г., в 18:06, Stephen Frost <sfrost(at)snowman(dot)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.
> 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).
> pgbackrest recently added the ability to
> check PG page-level checksums during a backup and report issues.
Sounds interesting, should take a look.
--
May the force be with you…
https://simply.name
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2017-01-20 16:59:22 | Re: Backup taking long time !!! |
| Previous Message | Stephen Frost | 2017-01-20 15:06:46 | Re: Backup taking long time !!! |