Re: In-order pg_dump (or in-order COPY TO) - Mailing list pgsql-general

From Álvaro Herrera
Subject Re: In-order pg_dump (or in-order COPY TO)
Date
Msg-id 202509041202.ml2xi5yp46yt@alvherre.pgsql
Whole thread Raw
In response to In-order pg_dump (or in-order COPY TO)  (Dimitrios Apostolou <jimis@gmx.net>)
Responses Re: In-order pg_dump (or in-order COPY TO)
Re: In-order pg_dump (or in-order COPY TO)
List pgsql-general
On 2025-Aug-26, Dimitrios Apostolou wrote:

> I am storing dumps of a database (pg_dump custom format) in a de-duplicating
> backup server. Each dump is many terabytes in size, so deduplication is very
> important. And de-duplication itself is based on rolling checksums which is
> pretty flexible, it can compensate for blocks moving by some offset.

Hello,

It's generally considered nowadays that pg_dump is not the best option
to create backups of very large databases.  You may be better served by
using a binary backup tool -- something like Barman.  With current
Postgres releases you can create incremental backups, which would
probably be more effective at deduplicating than playing with pg_dump's
TOC, because it's based on what actually happens to the data.  Barman
provides support for hook scripts, which perhaps can be used to transfer
the backup files to Borg.  (I haven't actually tried to do this, but the
Barman developers talk about using them to transfer the backups to tape,
so I imagine getting them to play with Borg it's a Simple Matter of
Programming.)

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"On the other flipper, one wrong move and we're Fatal Exceptions"
(T.U.X.: Term Unit X  - http://www.thelinuxreview.com/TUX/)



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Q: limit the length of log file entries?
Next
From: Adrian Klaver
Date:
Subject: Re: In-order pg_dump (or in-order COPY TO)