Re: pg_dump why no indicator of completion - Mailing list pgsql-admin

From richard coleman
Subject Re: pg_dump why no indicator of completion
Date
Msg-id CAGA3vBvSQ7RxxQ3ELRR7qF=FobhkyhXU7Ncbw5xi+4VZi==dRQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump why no indicator of completion  (Rui DeSousa <rui@crazybean.net>)
Responses Re: pg_dump why no indicator of completion
Re: pg_dump why no indicator of completion
List pgsql-admin
Rui, 

I'll be the first to admit that in this case some of the servers that were procured for PostgreSQL are way too underspeced for the databases they are now hosting.  I am guessing that it's a result of the databases outgrowing their servers.

As I've asked Ron, if pg_dump isn't fit for purpose, then what do you believe is?

Thanks, 
rik.

On Mon, May 1, 2023 at 10:13 AM Rui DeSousa <rui@crazybean.net> wrote:

On May 1, 2023, at 9:55 AM, richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Are you writing that pg_dump is unfit for purpose and that I should be using a commercial backup solution instead?


pg_dump is a logical backup.  If you need a fast logical backup; then it’s the right tool.  To get a fast logical backup use the directory format, multiple threads (jobs), and turn off compression.  You shouldn’t have to wait days to get a logical backup; if so, maybe your system is too small and/or disks are too slow.

i.e.  pg_dump --format=d --file=prod --compress=0 —jobs=16 prod

However, for database backups a binary solution is best as it is faster and allows for point in time recovery if archiving is enabled.

Relying on logical backups as a backup solution seems like a bad idea.

-rui

pgsql-admin by date:

Previous
From: Rui DeSousa
Date:
Subject: Re: pg_dump why no indicator of completion
Next
From: Ron
Date:
Subject: Re: pg_dump why no indicator of completion