Thread

1. Postgres DB backup is taking too much time

   masheed ullah <masheedullah@gmail.com> — 2026-05-03T09:42:21Z

   Hi,
   
   We have a database of 20TB, and it's taking almost 24 hours to complete.
   While full restore takes 28 hours. Although we have HA enabled with primary
   and multiple replica's.
   *So we need a solution/tool to reduce the RTO, incase of disk failure/
   Human error for data/tables deletion.*
   
   We are using Barman for backup.
   My question is "Are there any tools like ZDLRA appliances for Oracle" to
   reduce the RTO to less than 10 hours".
   
   Best Regards,
   Khattak
   

2. Re: Postgres DB backup is taking too much time

   manish yadav <manishy174@yahoo.co.in> — 2026-05-03T17:16:36Z

   You may try barman with rsync option and adding parallelism i.e. parallel_jobs =6 (based on the CPU core available on the barman machine)
   
   
   Thanks and Regards,
   
   Manish Yadav
   
   
   
   
   
   
   
   On Sunday 3 May, 2026 at 03:12:45 PM IST, masheed ullah <masheedullah@gmail.com> wrote: 
   
   
   
   
   
   Hi,
   
   We have a database of 20TB, and it's taking almost 24 hours to complete. While full restore takes 28 hours. Although we have HA enabled with primary and multiple replica's.
   So we need a solution/tool to reduce the RTO, incase of disk failure/ Human error for data/tables deletion.
   
   We are using Barman for backup.
   My question is "Are there any tools like ZDLRA appliances for Oracle" to reduce the RTO to less than 10 hours".
   Best Regards,
   Khattak
   
   
   
   
   
   
   

3. Re: Postgres DB backup is taking too much time

   Greg Sabino Mullane <htamfids@gmail.com> — 2026-05-04T00:20:05Z

   (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
   

4. Re: Postgres DB backup is taking too much time

   Ilya Anfimov <ilan@tzirechnoy.com> — 2026-05-04T09:29:11Z

   On Sun, May 03, 2026 at 12:42:21PM +0300, masheed ullah wrote:
   >    Hi,
   >    We have a database of 20TB, and it's taking almost 24 hours to complete.
   >    While full restore takes 28 hours. Although we have HA enabled with
   >    primary and multiple replica's.
   >    So we need a solution/tool to reduce the RTO, incase of disk failure/
   >    Human error for data/tables deletion.
   > 
   >    We are using Barman for backup.
   
    First, you'd need engineers to measure -- what's going on.
    Who  is the slowest part? The network (most probable)? The post-
   gres replication process? The disk that postgres reads? The  bar-
   man  itself?  Receiver  disks/S3  daemon/etc?  TLS  of one of the
   above?
    Measures is the key. Then the solutions may be searched.
   
   btw, a modern postgres can definitely supply 1GB/s to barman on a
   modern  system.   This  is  not a much, and probably could be im-
   proved by special tricks like rsync or manual prefetch or  incre-
   mental  copies  --  however,  it's less than 6 hours estimate and
   therefore is fine for you.
   
   >    My question is "Are there any tools like ZDLRA appliances for Oracle" to
   >    reduce the RTO to less than 10 hours".
   >    Best Regards,
   >    Khattak
   
   
   
   

5. Re: Postgres DB backup is taking too much time

   masheed ullah <masheedullah@gmail.com> — 2026-05-04T09:58:54Z

   Thank you every one for your output.
   
   Although pgBeckRest has no more support.
   Should I suggest starting testing backup and restore with pgBectRest?
   I did not find any 3rd Party tool.
   
   On Mon, May 4, 2026 at 12:29 PM Ilya Anfimov <ilan@tzirechnoy.com> wrote:
   
   > On Sun, May 03, 2026 at 12:42:21PM +0300, masheed ullah wrote:
   > >    Hi,
   > >    We have a database of 20TB, and it's taking almost 24 hours to
   > complete.
   > >    While full restore takes 28 hours. Although we have HA enabled with
   > >    primary and multiple replica's.
   > >    So we need a solution/tool to reduce the RTO, incase of disk failure/
   > >    Human error for data/tables deletion.
   > >
   > >    We are using Barman for backup.
   >
   >  First, you'd need engineers to measure -- what's going on.
   >  Who  is the slowest part? The network (most probable)? The post-
   > gres replication process? The disk that postgres reads? The  bar-
   > man  itself?  Receiver  disks/S3  daemon/etc?  TLS  of one of the
   > above?
   >  Measures is the key. Then the solutions may be searched.
   >
   > btw, a modern postgres can definitely supply 1GB/s to barman on a
   > modern  system.   This  is  not a much, and probably could be im-
   > proved by special tricks like rsync or manual prefetch or  incre-
   > mental  copies  --  however,  it's less than 6 hours estimate and
   > therefore is fine for you.
   >
   > >    My question is "Are there any tools like ZDLRA appliances for Oracle"
   > to
   > >    reduce the RTO to less than 10 hours".
   > >    Best Regards,
   > >    Khattak
   >
   >
   >
   

6. Re: Postgres DB backup is taking too much time

   Gerald Drouillard <gerald@drouillard.ca> — 2026-05-04T10:10:45Z

   You could setup a replication to another PG server that is setup on a COW
   file system like zfs.
   Then you can take snapshots on the replica.
   
   
   On Mon, May 4, 2026 at 5:59 AM masheed ullah <masheedullah@gmail.com> wrote:
   
   > Thank you every one for your output.
   >
   > Although pgBeckRest has no more support.
   > Should I suggest starting testing backup and restore with pgBectRest?
   > I did not find any 3rd Party tool.
   >
   > On Mon, May 4, 2026 at 12:29 PM Ilya Anfimov <ilan@tzirechnoy.com> wrote:
   >
   >> On Sun, May 03, 2026 at 12:42:21PM +0300, masheed ullah wrote:
   >> >    Hi,
   >> >    We have a database of 20TB, and it's taking almost 24 hours to
   >> complete.
   >> >    While full restore takes 28 hours. Although we have HA enabled with
   >> >    primary and multiple replica's.
   >> >    So we need a solution/tool to reduce the RTO, incase of disk failure/
   >> >    Human error for data/tables deletion.
   >> >
   >> >    We are using Barman for backup.
   >>
   >>  First, you'd need engineers to measure -- what's going on.
   >>  Who  is the slowest part? The network (most probable)? The post-
   >> gres replication process? The disk that postgres reads? The  bar-
   >> man  itself?  Receiver  disks/S3  daemon/etc?  TLS  of one of the
   >> above?
   >>  Measures is the key. Then the solutions may be searched.
   >>
   >> btw, a modern postgres can definitely supply 1GB/s to barman on a
   >> modern  system.   This  is  not a much, and probably could be im-
   >> proved by special tricks like rsync or manual prefetch or  incre-
   >> mental  copies  --  however,  it's less than 6 hours estimate and
   >> therefore is fine for you.
   >>
   >> >    My question is "Are there any tools like ZDLRA appliances for
   >> Oracle" to
   >> >    reduce the RTO to less than 10 hours".
   >> >    Best Regards,
   >> >    Khattak
   >>
   >>
   >>
   >
   >
   >
   >
   

7. Re: Postgres DB backup is taking too much time

   Ilya Anfimov <ilan@tzirechnoy.com> — 2026-05-04T11:11:33Z

   On Mon, May 04, 2026 at 12:58:54PM +0300, masheed ullah wrote:
   >    Thank you every one for your output.
   > 
   >    Although pgBeckRest has no more support. 
   >    Should I suggest starting testing backup and restore with pgBectRest?
   
    1) Yes, it may be a good training to set up pgBackRest.
    And compare it to barman.
   
    I  don't  think  it  would magically solve any of your problems,
   however gaining experience seems beneficial overall.
   
    2) pgBackRest is in a kind of uncertain position right now.
    A week ago pgBackRest author and the  main  maintainer  said  he
   stops maintaining pgBackRest.
    Probably,  some time later the situation would stabilize somehow
   -- and probably, some fork would gain acceptance (or  the  author
   would  get back to maintaining) -- but now the situation is a bit
   clumsy.
   
   
   >    I did not find any 3rd Party tool.
   >    On Mon, May 4, 2026 at 12:29 PM Ilya Anfimov <ilan@tzirechnoy.com> wrote:
   > 
   >      On Sun, May 03, 2026 at 12:42:21PM +0300, masheed ullah wrote:
   >      >    Hi,
   >      >    We have a database of 20TB, and it's taking almost 24 hours to
   >      complete.
   >      >    While full restore takes 28 hours. Although we have HA enabled with
   >      >    primary and multiple replica's.
   >      >    So we need a solution/tool to reduce the RTO, incase of disk
   >      failure/
   >      >    Human error for data/tables deletion.
   >      >
   >      >    We are using Barman for backup.
   > 
   >       First, you'd need engineers to measure -- what's going on.
   >       Who  is the slowest part? The network (most probable)? The post-
   >      gres replication process? The disk that postgres reads? The  bar-
   >      man  itself?  Receiver  disks/S3  daemon/etc?  TLS  of one of the
   >      above?
   >       Measures is the key. Then the solutions may be searched.
   > 
   >      btw, a modern postgres can definitely supply 1GB/s to barman on a
   >      modern  system.   This  is  not a much, and probably could be im-
   >      proved by special tricks like rsync or manual prefetch or  incre-
   >      mental  copies  --  however,  it's less than 6 hours estimate and
   >      therefore is fine for you.
   > 
   >      >    My question is "Are there any tools like ZDLRA appliances for
   >      Oracle" to
   >      >    reduce the RTO to less than 10 hours".
   >      >    Best Regards,
   >      >    Khattak