Re: pg_dump why no indicator of completion
От | richard coleman |
---|---|
Тема | Re: pg_dump why no indicator of completion |
Дата | |
Msg-id | CAGA3vBvSQ7RxxQ3ELRR7qF=FobhkyhXU7Ncbw5xi+4VZi==dRQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump why no indicator of completion (Rui DeSousa <rui@crazybean.net>) |
Ответы |
Re: pg_dump why no indicator of completion
Re: pg_dump why no indicator of completion |
Список | 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 prodHowever, 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 по дате отправления: