Re: Pgbackrest backup is too slow - Mailing list pgsql-general

From Ajay Pratap
Subject Re: Pgbackrest backup is too slow
Date
Msg-id CABi=8qxMk=1_xvXZXSxZeHvQ4xHR3kddnKga4AkSprwpMtjAJA@mail.gmail.com
Whole thread Raw
In response to Re: Pgbackrest backup is too slow  ("Brad Nicholson" <bradn@ca.ibm.com>)
List pgsql-general
Thanks for your previous replies.
It turns out my machine was having kernel Issues, which made it slow.
I setup another cluster in different machine now I could able to backup 42G in 6 min(s).
<EOM>

On Fri, Oct 11, 2019 at 7:23 PM Brad Nicholson <bradn@ca.ibm.com> wrote:

Stephen Frost <sfrost@snowman.net> wrote on 2019/10/11 08:50:53 AM:

> From: Stephen Frost <sfrost@snowman.net>

> To: Ajay Pratap <ajaypratap@ameyo.com>
> Cc: Postgres General <pgsql-general@postgresql.org>
> Date: 2019/10/11 08:51 AM
> Subject: [EXTERNAL] Re: Pgbackrest backup is too slow
>
> Greetings,
>
> * Ajay Pratap (ajaypratap@ameyo.com) wrote:
> > I have a Centos 7 server which runs Postgresql 10.7. I am using pgbackrest
> > to take db backup.
> > Problem is backup is too slow.
>
> Have you tried running 'top' to see what's going on?
>
> > My data dir size is 9.6G and full backup runtime is 22 mins
> > I also tried using process-max=3, full backup runtime = 21 mins
>
> Erm, those numbers don't make any sense to me- as an example, we
> regularly back up a 12GB database, from Dallas to San Fran, in 5
> minutes.


How many database objects do you have?  For databases with a lot of tables and/or indexes (think tens of thousands), backup performance will slow down.  This has improved a lot in newer versions, but still impacts performance of the backups.

Brad.


Disclaimer: The information in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Drishti is neither liable for the improper, incomplete transmission of the information contained in this communication nor any delay in its receipt. The communication is not intended to operate as an electronic signature under any applicable law. Drishti assumes no responsibility for any loss or damage resulting from the use of e-mails.

pgsql-general by date:

Previous
From: Morris de Oryx
Date:
Subject: Has there been any discussion of custom dictionaries being defined inthe database?
Next
From: Ajay Pratap
Date:
Subject: pgbackrest with PAF(corosync and pacmaker)