Greetings, * Peter (pmc@xxxxxxxxxxxxxxxxxxxxxxx) wrote: > This professional backup solution also offers support for postgres. > Sadly, it only covers postgres up to Rel.9, and that piece of software > wasn't touched in the last 6 or 7 years. Then it certainly doesn't work with the changes in v12, and probably has other issues, as you allude to. > Actually, I am getting very tired of reading that something which can > easily be done within 20 lines of shell scripting, would need special This is just simply false- you can't do it properly in 20 lines of shell scripting. Sure, you can write something that has probably next to no error checking, uses the deprecated API that'll cause your systems to fail to start if you ever happen to have a reboot during a backup, and has no way to provide verification that the backup was at all successful after the fact, but that's not what I'd consider a proper solution- instead it's one that'll end up causing you a lot of pain down the road. Even the shell-script based solution (which I've never used and personally wouldn't really recommend, but to each their own) called 'pitery' (available here: https://github.com/dalibo/pitrery) is thousands of lines of code. > Does nobody know anymore how to do proper systems management > scripting? Using just the basic system tools which have proven to > work for more than 50 years now!? I've not met anything I'd call 'proper systems management scripting' that's 20 lines of code, shell script or not. > ! Not sure about pg_probackup. > > Okay, I had a -very short- look into these. Just scanning the > introductory pages. > > The only really interesting thing there is the pg_probackup. These > folks seem to have found a way to do row-level incremental backups. pg_probackup doesn't do row-level incremental backups, unless I've missed some pretty serious change in its development, but it does provide page-level, with, as I recall, an extension that didn't get good reception when it was posted and discussed on these mailing lists by other PG hackers. I don't know if those concerns about it have been addressed or not, you might ask the pg_probackup folks if you're considering it as a solution. > This is fine as long as you do not run any computers, and the only > application you are using is Postgres. > But, if you have other applications as well, or have computers, then > you will need a different backup solution, something that will cover > your site-wide backup demands, in a consistent fashion (think > something in the style of ADSM, or nowadays called Spectrum Protect). > > And then 90% of the things offered here become superfluous, because > they are already handled site-wide. And then you will have to > consider integration of both pieces - and that will most likely be > more work and more error-prone than just writing a few adapters in > shell. pgbackrest's repo can be safely backed up using the simple file-based backup utilities that you're referring to here. I suspect some of the other solution's backups also could be, but you'd probably want to make sure. PG generally isn't something that can be backed up using the simple file based backup solutions, as you might appreciate from just considering the number of tools written to specifically deal with the complexity of backing up an online PG cluster. Thanks, Stephen
Attachment:
signature.asc
Description: PGP signature
