Subject: Re: post-freeze damage control

From: Alvaro Herrera <[email-masked]>
Date: Tue, 9 Apr 2024 17:45:45 +0200

On 2024-Apr-09, Stefan Fercot wrote:

> At some point, the only way to really validate a backup is to actually try to restore it.
> And if people get encouraged to do that faster thanks to incremental backups, they could detect potential issues sooner.
> Ultimately, users will still need their full backups and WAL archives.
> If pg_combinebackup fails for any reason, the fix will be to perform the recovery from the full backup directly.
> They still should be able to recover, just slower.

I completely agree that people should be testing the feature so that we
can fix any bugs as soon as possible.  However, if my understanding is
correct, restoring a full backup plus an incremental no longer needs the
intervening WAL up to the incremental.  Users wishing to save some disk
space might be tempted to delete that WAL.  If they do, and later it
turns out that the full+incremental cannot be restored for whatever
reason, they are in danger.

But you're right that if they don't delete that WAL, then the full is
restorable on its own.

Maybe we should explicitly advise users to not delete that WAL from
their archives, until pg_combinebackup is hammered a bit more.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"I must say, I am absolutely impressed with what pgsql's implementation of
VALUES allows me to do. It's kind of ridiculous how much "work" goes away in
my code.  Too bad I can't do this at work (Oracle 8/9)."       (Tom Allison)
           http://archives.postgresql.org/pgsql-general/2007-06/msg00016.php

---

From: "Andrey M. Borodin" <[email-masked]>
Date: Tue, 9 Apr 2024 18:59:54 +0300

> On 9 Apr 2024, at 18:45, Alvaro Herrera <[email-masked]> wrote:
> 

As a backup tool maintainer, I always reference to out-of-the box Postgres tools as some bulletproof alternative.
I really would like to stick to this reputation and not discredit these tools.

Best regards, Andrey Borodin.

---

From: David Steele <[email-masked]>
Date: Wed, 10 Apr 2024 09:29:38 +1000

> I really would like to stick to this reputation and not discredit these tools.

+1.

Even so, only keeping WAL for the last backup is a dangerous move in any 
case. Lots of things can happen to a backup (other than bugs in the 
software) so keeping WAL back to the last full (or for all backups) is 
always an excellent idea.

Regards,
-David

---

From: Michael Paquier <[email-masked]>
Date: Wed, 10 Apr 2024 08:50:56 +0900

> always an excellent idea.

Yeah, that's an excellent practive, but is why I'm less worried for
this feature.  The docs at [1] caution about "not to remove earlier
backups if they might be needed when restoring later incremental
backups".  Like Alvaro said, should we insist a bit more about the WAL
retention part in this section of the docs, down to the last full
backup?

[1]: https://www.postgresql.org/docs/devel/continuous-archiving.html#BACKUP-INCREMENTAL-BACKUP
--
Michael

---

From: David Steele <[email-masked]>
Date: Thu, 11 Apr 2024 09:36:11 +1000

> retention part in this section of the docs, down to the last full

I think that would make sense in general. But if we are doing it because 
we lack confidence in the incremental backup feature maybe that's a sign 
that the feature should be released as experimental (or not released at 
all).

Regards,
-David