Re: pg_dump why no indicator of completion

From: richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com>
To: Rui DeSousa <rui(at)crazybean(dot)net>
Cc: Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: pg_dump why no indicator of completion
Date: 2023-05-01 14:34:16
Message-ID: CAGA3vBvSQ7RxxQ3ELRR7qF=FobhkyhXU7Ncbw5xi+4VZi==dRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)crazybean(dot)net> wrote:

>
> On May 1, 2023, at 9:55 AM, richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)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
>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Ron 2023-05-01 14:40:32 Re: pg_dump why no indicator of completion
Previous Message Rui DeSousa 2023-05-01 14:31:18 Re: pg_dump why no indicator of completion