cloudnative-pg / cloudnative-pg/plugin-barman-cloud

Backups are not restorable on low-activity databases due to missing final WAL segment

Open
#652 3 comments 7 reactions 0 assignees View on GitHub
bug
Dominant language
Go
Stars
191
Forks
72
Avg merge
2d 21h
Merged PRs (30d)
21

Description

## Problem Summary

When CNPG takes a backup using the barman-cloud plugin, the backup cannot be restored because the final WAL segment referenced in the
backup metadata is never archived to S3. This occurs on a databases with zero write activity after a successful backup.

## Root Cause

1. A backup completes and records its end position (e.g., LSN 3/26000060 in WAL file 000000330000000300000026)
2. The backup metadata states this WAL file is required for recovery
3. However, this WAL file is still active (currently being written to) and hasn't been closed
4. PostgreSQL only archives WAL files when they are closed via:
• Filling up completely (16MB)
• pg_switch_wal() being called
• Clean server shutdown
5. On low-activity databases, the WAL file may remain active for hours/days
6. archive_timeout = 5min (CNPG default) does not trigger if there's zero activity after the backup
7. Result: The backup cannot be restored because the required WAL file is missing from S3

## Reproduction

1. Create a CNPG cluster with barman-cloud backup configured
2. Take a backup on a zero-activity database
3. Attempt to restore the backup immediately after completion
4. Restoration fails with: FATAL: WAL ends before end of online backup

## Evidence

Backup metadata shows:

```
endLSN: 3/26000060
endWal: "000000330000000300000026"
```

PostgreSQL archiver shows:

```
last_archived_wal: 000000330000000300000025 (previous segment)
```

Current database state:

```
pg_current_wal_lsn: 3/26000060 (same position, no activity)
pg_walfile_name: 000000330000000300000026 (still active)
```

S3 bucket:

```
000000330000000300000025.gz ✅ EXISTS
000000330000000300000026.gz ❌ MISSING
```

## Expected Behavior

After a backup completes successfully, it should be immediately restorable without waiting for database activity to trigger WAL archiving.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.