Subject: could not find a valid record after in barman's backups

From: lejeczek <[email-masked]>
Date: Thu, 6 Nov 2025 11:06:14 +0100

Hi guys.

I know it's not strictly /barman/ list but I presume many 
here use it.
I do, but I only now realized that using barman's 
/recovery/ with PIT is faulty - apparently have been for a 
while.
So I wonder - besides the fault(s) - I must be missing 
something or doing something incorrectly for...
when I check backups /wals/ I get:

-> $ pg_waldump 
ubusrv-master-10-1-1-88/wals/00000B000000000D/00000B000000000D00000030
pg_waldump: fatal: could not find a valid record after 
D/30000000

and that is for every /wal/ in the backup - which has to 
wrong, no?
How & where do I start troubleshooting this?

many thanks, L.

---

From: "William Sescu (Suva)" <[email-masked]>
Date: Thu, 6 Nov 2025 12:03:28 +0000

The WAL files on the Barman Server might be compressed, depending on your Barman compression setting.
e.g. compression = gzip, or you are using a different PostgreSQL pg_waldump version, than the one on your
PostgreSQL host.

Cheers, William

Von: lejeczek <[email-masked]>
Gesendet: Donnerstag, 6. November 2025 11:06
An: [email-masked]
Betreff: could not find a valid record after in barman's backups
Hi guys.

I know it's not strictly barman list but I presume many here use it.
I do, but I only now realized that using barman's recovery with PIT is faulty - apparently have been for a while.
So I wonder - besides the fault(s) - I must be missing something or doing something incorrectly for...
when I check backups wals I get:

-> $ pg_waldump ubusrv-master-10-1-1-88/wals/00000B000000000D/00000B000000000D00000030
pg_waldump: fatal: could not find a valid record after D/30000000

and that is for every wal in the backup - which has to wrong, no?
How & where do I start troubleshooting this?

many thanks, L.

________________________________

Disclaimer:

Diese Nachricht und ihr eventuell angehängte Dateien sind nur für den Adressaten bestimmt. Sie kann vertrauliche oder gesetzlich geschützte Daten oder Informationen beinhalten. Falls Sie diese Nachricht irrtümlich erreicht hat, bitten wir Sie höflich, diese unter Ausschluss jeglicher Reproduktion zu löschen und die absendende Person zu benachrichtigen. Danke für Ihre Hilfe.

This message and any attached files are for the sole use of the recipient named above. It may contain confidential or legally protected data or information. If you have received this message in error, please delete it without making any copies whatsoever and notify the sender. Thank you for your assistance.

---

From: lejeczek <[email-masked]>
Date: Thu, 6 Nov 2025 15:01:07 +0100

across different OSes - which is my env - I should have 
thought of this, different versions yes.
thanks, L.

---

From: Ron Johnson <[email-masked]>
Date: Thu, 6 Nov 2025 09:49:30 -0500

On Thu, Nov 6, 2025 at 5:06 AM lejeczek <[email-masked]> wrote:

> Hi guys.
>
> I know it's not strictly *barman* list but I presume many here use it.
> I do, but I only now realized that using barman's *recovery* with PIT is
> faulty - apparently have been for a while.
> when I check backups *wals* I get:
>
> -> $ pg_waldump
> and that is for every *wal* in the backup - which has to wrong, no?

Can *barman* restore the instance?  For example, pg_waldump would barf on
WALs in a PgBackRest repo because it's encrypted in addition to being
compressed, even though pgbackrest does PITR restores without complaint.

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

---

From: lejeczek <[email-masked]>
Date: Fri, 7 Nov 2025 18:54:47 +0100

and yes /restore/ does restore - even though the host is 
with different pgsql' libs version, but it does not restore 
PITR.
So I wonder now - perhaps PITR not working is not due to the 
"well-know" issue, maybe it was but it's not any more, but 
it's in my case due to the fact that pgsql server(16) and 
barman(13) use different pgsql versions - I'll tamper some 
more some day.
thanks, L.