Re: Something else about Redo Logs disappearing

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Peter <pmc(at)citylink(dot)dinoex(dot)sub(dot)org>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Something else about Redo Logs disappearing
Date: 2020-06-15 09:44:33
Message-ID: b31226eea04e6905b0ca2003cf230cfdae8ce5eb.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, 2020-06-13 at 19:48 +0200, Peter wrote:
> ! > 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 not what I am asking. It appears correct to me, that, on
> the database, the first backup will be interrupted. But on the
> tape side, this might go unnoticed, and on completion it will
> successfully receive the termination code from the *SECOND*
> backup - which means that on tape we will have a seemingly
> successful backup, which
> 1. is corrupted, and
> 2. carries a wrong label.

That will only happen if the backup that uses my scripts does the
wrong thing.

An example:

- Backup #1 calls "pgpre.sh"
- Backup #1 starts copying files
- Backup #2 calls "pgpre.sh".
This will cancel the first backup.
- Backup #1 completes copying files.
- Backup #1 calls "pgpost.sh".
It will receive an error.
So it has to invalidate the backup.
- Backup #2 completes copying files.
- Backup #2 calls "pgpost.sh".
It gets a "backup_label" file and completes the backup.

So the only way that something can go wrong would be if
backup #1 somehow does *not* invalidate the backup.

> ! 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.
>
> I understand. But the operator may not know that and/or accidentially
> start a second backup while one is still running. And this will then
> result in ...
>
> ! If you have the wrong "backup_label", you end up with silent data corruption.
>
> ... this.

Of course, if you do arbitrary nonsense like restoring a
backup without "backup_label", you will get arbitrary data
corruption.

It is a fundamental principle that, apart from "backup_label", there
is no way to tell a backup from a crashed data directory.
Any backup/recovery software must refuse to use a backup that lacks that file.

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Kristjan Mustkivi 2020-06-15 10:47:12 Re: TOAST table size in bytes growing despite working autovacuum
Previous Message Laurenz Albe 2020-06-15 09:31:29 Re: Oracle vs. PostgreSQL - a comment