Re: Something else about Redo Logs disappearing

Greetings,

* Peter (pmc(at)citylink(dot)dinoex(dot)sub(dot)org) 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