On Fri, Jan 14, 2022 at 8:27 PM Ron <ronljohnsonjr@xxxxxxxxx> wrote:
On 1/14/22 12:31 PM, Stephen Frost wrote:
> Greetings,
>
> * Issa Gorissen (issa-gorissen@xxxxxxx) wrote:
>> Thx a lot. I thought about it but was not so sure about having a complex
>> script (compared to the very simple version when using the exclusive backup
>> - but this this is deprecated...).
>>
>> I will test your option with the simpler version and post it back to it can
>> maybe land in PostgreSQL documentation.
> The PG docs show how the command works and that's it. The commands
> in the docs aren't intended to be actually used in production
> environments. Writing a full solution involves having a good
> understanding of the PG code and how WAL archiving, backups, et al, are
> done. If you're not familiar with this portion of the PG code base, I'd
> strongly suggest you look at using solutions written and maintained by
> folks who are.
Needing to read the PG source code to write a workable PITR recovery
solution is a serious flaw in PG documentation (and why I use PgBackRest).
The documentation of two other RDBMSs that I've worked with (Rdb/VMS and SQL
Server) are perfectly clear on how to do such backups and restores with
relatively small amounts of scripting.
So when I was writing my own backup solutions many years ago, I didn't generally read the code to do that. I think the problem is that there is a lot of stuff that goes on around the backup and recovery process where to make it safe you need to understand all the other things going on.
I can remember at least one case from those years ago when a needed backup suddenly wasn't PITR-restorable when I needed it to be and that took some urgent troubleshooting. I got it resolved but I also understand why those building,such tools read the code and more importantly understand implications of design choices in that context.
Backups are critical pieces of infrastructure and one wants to make sure that weird corner cases don't suddenly render your backup useless when your production system dies. And while I do think the docs could be improved, I agree they will probably never be good enough for people to just roll their own solutions.
> Trying to write documentation on how to develop a complete solution
> would be quite an effort and would certainly go beyond bash scripting
> and likely wouldn't end up getting used anyway- those who are developing
> such solutions are already reading through the actual code.
>
> Thanks,
>
> Stephen
--
Angular momentum makes the world go 'round.
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
