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
>
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 |