Re: Something else about Redo Logs disappearing - Mailing list pgsql-general

On Sat, 2020-06-13 at 05:24 +0200, Peter wrote:
> ! https://github.com/cybertec-postgresql/safe-backup
> 
> Ah, thank You, very nice.
> 
> I've never seen anybody coding bash - it is strongly shunned in the
> Berkeley community. 

Strange, but then I don't move in these circles.

> Some Questions:
>  1. There are explicit error messages in loc-82 and -92 of pgpre.sh.
>     To where are these written?

Standard error.  It is up to the caller of the script to route that
somewhere useful.

>  2. The result data from pg_stop_backup() are stored into the living
>     database. But, according to the docs, they should be placed into
>     the completed backup. Do I have a misunderstanding here?

Right, but these scripts don't know anything about that backup itself.
They are designed to be called before and after the backup.
In between, you back up the data directory however you think fit.

It is the responsibility of the caller of the post-backup script
to add the "backup_label" file to the backup.

>  3. The most common error cause of a backup might be tape-side
>     malfunction. So far as I see, the way to handle this is currently,
>     to provide a timeout for pgpre.sh (which is problematic, because
>     we might as well have just reached end-of-tape and have to wait
>     until monday for the operator to change it). May I suggest to add
>     a switch to pgpost.sh, in order to volutarily fail out of the job?

As said above, the backup itself is not the job of these scripts.

>  4. If, by misconfiguration and/or operator error, the backup system
>     happens to start a second backup. in parallel to the first,
>     then do I correctly assume, both backups will be rendered
>     inconsistent while this may not be visible to the operator; and
>     the earlier backup would be flagged as apparently successful while
>     carrying the wrong (later) label?

If you are using my scripts and start a second backup while the first
one is still running, the first backup will be interrupted.

This is specific to my scripts, PostgreSQL's non-exclusive backup
can perform more than one concurrent backup successfully.
I tried to keep things simple.

> BTW: what does, in general, happen, if a backup_label file gets
> accidentially swapped with one from a parallel, but slightly later
> backup? Do I correctly assume that such mistake gets somehow detected,
> as otherwise it would have just the same unwelcome effects
> (i.e. silent data corruption) as no backup_label at all?

If you have the wrong "backup_label", you end up with silent data corruption.

That should not happen with my scripts, though.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com