From: Karl Denninger <karl@denninger.net>
To: pgsql-admin@lists.postgresql.org
Subject: Re: Incremental Postgres database backup
Date: Mon, 7 Mar 2022 10:09:49 -0500
Message-ID: <03bcf09f-31ee-014a-b552-72c9a25eb206@denninger.net> (raw)
In-Reply-To: <9e647c64-7b77-565b-7780-b60439966560@gmail.com>
References: <CAK_Ha4y5d8bRb4QwaaQh3ayB9bcjVE665dA4jWjnv_zPOu=6Ow@mail.gmail.com>
<6405c132-283e-98b7-5447-b68eee447cf0@gmail.com>
<9962e5ba-a910-0226-56ed-245fcfc0ac3f@denninger.net>
<9e647c64-7b77-565b-7780-b60439966560@gmail.com>
On 3/7/2022 09:57, Ron wrote:
> On 3/7/22 08:30, Karl Denninger wrote:
> [snip]
>>
>> The other obvious option is online replication.
>>
>
> Replication is not a backup solution!!!!!
>
That's true, but once you have replication set up you have a local
staging source against which to take backups that does not require
Internet bandwidth, and thus makes solving the problem MUCH easier.
Getting the I/O from the backup process /off the production machine(s)
/is frequently a good decision. Online replication does this and moves
the locus of your backup away from the online production environment.
If that's not material simply using existing tools (e.g. pgbackrest)
does the job all by itself, but if so using replication to get the data
where its convenient to use a tool such as pgbackrest absolutely works,
separates the I/O load away from the production environment and opens up
using block-level or filesystem-level backup tools (e.g. ZFS) as well
since even if the database spans a snapshot atomic coherence boundary
(which otherwise makes doing that unsafe) you can shut the replicated
slave down, take said snapshots and restart it without implicating
accessibility to the database.
--
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
Attachments:
smime.p7s (application/pkcs7-signature, 4.8K) 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-admin@postgresql.org
Cc: karl@denninger.net, pgsql-admin@lists.postgresql.org
Subject: Re: Incremental Postgres database backup
In-Reply-To: <03bcf09f-31ee-014a-b552-72c9a25eb206@denninger.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