|
If somebody is seriously looking into these suggestions, I like to bring another point for the development of pgdump log.
In pgdump while displaying backedup table names, the same row in the log can include the number of rows backedup for each table.
Thank you,
Sarwar
Working on the project where I do not know the application 🙂
From: richard coleman <rcoleman.ascentgl@xxxxxxxxx>
Sent: Monday, May 1, 2023 11:34 AM
To: Rui DeSousa <rui@xxxxxxxxxxxxx>
Cc: Ron <ronljohnsonjr@xxxxxxxxx>; pgsql-admin@xxxxxxxxxxxxxxxxxxxx <pgsql-admin@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: pg_dump why no indicator of completion
Rui,
Thanks for those suggestions, and your earlier ones.
It would be helpful though if the dev included a completion status message in pg_dump, even if it was only included when you specified the -v flag.
rik.
As
I've asked Ron, if pg_dump isn't fit for purpose, then what do you believe is?
If you need a logical backup then pg_dump is the right tool; as noted before but with better options to improve performance.
For backups; I would recommend physical backups which there are many solutions for. I have personally used snapshots and believe that is the best solution. It is the fastest and best solution to meet recovery time objective (RTO). For example, I’m able
to make a backup of a multi-terabyte database in under a second and multiple backups are cheap. This allows me to do a backup of the system every 6 hours. The most expensive part of a database restore is going to be applying the WAL files when doing a point
in time recovery (PITR). This means that at most, I would only have to apply around 6 hours of WAL files; which can still take a long time given a high volume system.
In my opinion snapshots are the best solution but it will depend on your infrastructure and requires knowledge of the infrastructure and setting it up correctly.
If I could not use snapshots; I would look into either pgBackRest or pgBarman.
|
