Date: Mon, 4 May 2026 14:11:33 +0300
From: Ilya Anfimov <ilan@tzirechnoy.com>
To: pgsql-performance@lists.postgresql.org
Subject: Re: Postgres DB backup is taking too much time
Message-ID: <afh+5RGX1pqHdYmP@azor.tzirechnoy.ru>
Mail-Followup-To: Ilya Anfimov <ilan@tzirechnoy.com>,
	pgsql-performance@lists.postgresql.org
References: <CAHr8x_sQww+XNAFoHkyjYKJYq3CVcQLxJL0yaY3GHNzO3YV+bw@mail.gmail.com>
 <afhm58YUGhbwCbNE@azor.tzirechnoy.ru>
 <CAHr8x_vygxU0onst=Fto8rGZjRHBz=mefospzziRVN5TXvJkwQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHr8x_vygxU0onst=Fto8rGZjRHBz=mefospzziRVN5TXvJkwQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/afh%2B5RGX1pqHdYmP%40azor.tzirechnoy.ru>
Precedence: bulk

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