From: | Karl Denninger <karl(at)denninger(dot)net> |
---|---|
To: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Re: Incremental Postgres database backup |
Date: | 2022-03-07 15:09:49 |
Message-ID: | 03bcf09f-31ee-014a-b552-72c9a25eb206@denninger.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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(at)denninger(dot)net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
From | Date | Subject | |
---|---|---|---|
Next Message | Daulat | 2022-03-07 18:22:16 | Re: Steps to enable SSL Enable |
Previous Message | Firthouse banu | 2022-03-07 15:01:18 | Re: Incremental Postgres database backup |