MIME-Version: 1.0
References: <CAHr8x_sQww+XNAFoHkyjYKJYq3CVcQLxJL0yaY3GHNzO3YV+bw@mail.gmail.com>
In-Reply-To: <CAHr8x_sQww+XNAFoHkyjYKJYq3CVcQLxJL0yaY3GHNzO3YV+bw@mail.gmail.com>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Sun, 3 May 2026 20:20:05 -0400
Message-ID: <CAKAnmmLkUreQd3pkoiwZv1BFSc4WwAy5wQScUHuxKy7hxOhS_w@mail.gmail.com>
Subject: Re: Postgres DB backup is taking too much time
To: masheed ullah <masheedullah@gmail.com>
Cc: pgsql-performance@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000042d8a90650f2e620"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmmLkUreQd3pkoiwZv1BFSc4WwAy5wQScUHuxKy7hxOhS_w%40mail.gmail.com>
Precedence: bulk

--00000000000042d8a90650f2e620
Content-Type: text/plain; charset="UTF-8"

(This is more suitable for the pgsql-general list, you may get more/better
replies there)

There is nothing equivalent to ZDLRA in the Postgres world, but there are
certainly ways to reduce RTO. You are using replicas, and a tool that saves
WALs, so that really gets you 99% of the way there. Tools like pgBackrest
can do incremental backups, and parallel, delta-only restores, which can
wildly reduce both backup and restore times. RTO for Postgres can be
measured in seconds (e.g. Patroni handling a disk failure) to minutes (e.g.
someone dropped a table). Also see the recovery_min_apply_delay parameter.
If you give us a more specific use case / disaster scenario, we can give
more options and advice.

Cheers,
Greg

--00000000000042d8a90650f2e620
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">(This is more suitable for the pgsql-general list, you may=
 get more/better replies there)<br><br>There is nothing equivalent to ZDLRA=
 in the Postgres world, but there are certainly ways to reduce RTO. You are=
 using replicas, and a tool that saves WALs, so that really gets you 99% of=
 the way there. Tools like pgBackrest can do incremental backups, and paral=
lel, delta-only restores, which can wildly reduce both backup and restore t=
imes. RTO for Postgres can be measured in seconds (e.g. Patroni handling a =
disk failure) to minutes (e.g. someone dropped a table). Also see the recov=
ery_min_apply_delay parameter. If you give us a more specific use case / di=
saster scenario, we can give more options and advice.<br><br>Cheers,<br><di=
v>Greg</div><div><br></div></div>

--00000000000042d8a90650f2e620--