Feedback-ID: ia2694551:Fastmail
Date: Tue, 9 Apr 2024 17:45:45 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Stefan Fercot <stefan.fercot@protonmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, 
	Tomas Vondra <tomas.vondra@enterprisedb.com>, Michael Paquier <michael@paquier.xyz>, 
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: post-freeze damage control
Message-ID: <202404091545.7zont3umry74@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <sMEDEzhBYSazAxBNRq7vVauI0lOz7Bd4z82zG93vMHGGy2GO-DaQ3kuP2hb-DrpAWIHcigTOeA3_3RFiUSzKmsnH8ZPyhuf7IEjXpxsNO2s=@protonmail.com>
Archived-At: <https://www.postgresql.org/message-id/202404091545.7zont3umry74%40alvherre.pgsql>
Precedence: bulk

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