Backup di Zabbix con PostgreSQL: pg_dump e pg_basebackup

4 July 2026

Un backup non testato non è un backup. La premessa è valida per qualsiasi sistema, ma per Zabbix ha un peso specifico: il database contiene non solo la configurazione del monitoraggio, ma anni di dati storici come metriche di performance, log degli eventi, trend calcolati, allarmi che rappresentano la memoria operativa dell’infrastruttura. Perderli significa perdere la visibilità su come si è comportata la rete nei mesi o anni precedenti, oltre alla configurazione di host, template e trigger.

La scelta della strategia di backup dipende da due parametri: quanto ci si può permettere di perdere in caso di disastro (RPO, Recovery Point Objective) e in quanto tempo si deve tornare operativi (RTO, Recovery Time Objective). In questo articolo vedremo due approcci diversi:

pg_dump esegue un backup logico: esporta schema e dati in un file ripristinabile su qualsiasi istanza PostgreSQL compatibile. È la soluzione più semplice e indicata per installazioni di piccole e medie dimensioni o per backup della sola configurazione
pg_basebackup con WAL archiving esegue un backup fisico con archiviazione continua del transaction log. Permette di implementare il Point-in-Time Recovery (PITR) con il vantaggio di ripristinare il database a un timestamp preciso, non solo al momento esatto del backup. È la scelta corretta per installazioni di grandi dimensioni dove la perdita di dati va minimizzata.

Backup con pg_dump

pg_dump produce un backup logico del database Zabbix, esportando lo schema e i dati in un file ripristinabile su qualsiasi istanza PostgreSQL compatibile. È la soluzione più semplice per installazioni di piccole e medie dimensioni.

sudo -u postgres pg_dump \
    --format=custom \
    --compress=9 \
    --file=/backup/zabbix_$(date +%Y%m%d_%H%M).pgdump \
    zabbix

sudo -u postgres pg_dump \
    --format=custom \
    --compress=9 \
    --file=/backup/zabbix_$(date +%Y%m%d_%H%M).pgdump \
    zabbix

Il formato custom (-Fc) produce un file binario compresso che supporta il restore parallelo e la selezione di tabelle ed è preferibile al formato SQL plain per database di dimensioni significative. Per automatizzare il backup con un job cron giornaliero, aggiungere la seguente riga al crontab

crontab -e

# Aggiungere
0 2 * * * postgres pg_dump --format=custom --compress=9 --file=/backup/zabbix_$(date +\%Y\%m\%d).pgdump zabbix

crontab -e

# Aggiungere
0 2 * * * postgres pg_dump --format=custom --compress=9 --file=/backup/zabbix_$(date +\%Y\%m\%d).pgdump zabbix

Backup fisico con pg_basebackup e Point-in-Time Recovery (PITR)

Per installazioni di grandi dimensioni o per chi ha bisogno di tempi di restore minimi e della massima granularità di ripristino, pg_basebackup combinato con la WAL archiving continua implementa una strategia di Point-in-Time Recovery (PITR).

Il modello concettuale è semplice: pg_basebackup produce la “fotografia” del cluster in un istante T e il WAL archiviato continuamente registra ogni modifica successiva. In caso di necessità, il restore consiste nel riprodurre tutto quanto avvenuto dalla fotografia fino al punto nel tempo desiderato, che può essere un timestamp preciso, una transazione specifica, o semplicemente “prima del problema”.

Senza WAL archiving, pg_basebackup da solo permette di ripristinare solo al momento esatto del backup e tutto quello che è successo dopo viene perso.

Configurare la WAL archiving

Prima di eseguire il primo backup fisico dobbiamo abilitare l’archiviazione continua del WAL.

Innanzitutto creiamo la directory di archiviazione. In questo esempio useremo un percorso locale, ma in produzione deve essere su un filesystem separato dal cluster come un mount NFS, un bucket S3 o un server remoto via rsync

mkdir -p /backup/wal_archive
chown postgres:postgres /backup/wal_archive
chmod 750 /backup/wal_archive

mkdir -p /backup/wal_archive
chown postgres:postgres /backup/wal_archive
chmod 750 /backup/wal_archive

ed ora possiamo aprire il file di configurazione

vi /var/lib/pgsql/17/data/postgresql.conf

vi /var/lib/pgsql/17/data/postgresql.conf

ed impostare i seguenti parametri

# Livello WAL minimo per l'archiving e la replica
wal_level = replica

# Abilita l'archiviazione continua dei segmenti WAL completati
archive_mode = on

# Comando eseguito da PostgreSQL per copiare ogni segmento WAL completato nell'archivio.
# %p = percorso completo del segmento sorgente
# %f = nome del file del segmento
# Il comando deve restituire exit code 0 solo se la copia è andata a buon fine.
archive_command = 'cp %p /backup/wal_archive/%f'

# Forza la rotazione del segmento WAL corrente ogni N secondi, anche se non è pieno.
# Garantisce che la perdita massima di dati (RPO) non superi questo intervallo.
# 300 secondi = perdita massima di 5 minuti in caso di disastro.
archive_timeout = 300

# Livello WAL minimo per l'archiving e la replica
wal_level = replica

# Abilita l'archiviazione continua dei segmenti WAL completati
archive_mode = on

# Comando eseguito da PostgreSQL per copiare ogni segmento WAL completato nell'archivio.
# %p = percorso completo del segmento sorgente
# %f = nome del file del segmento
# Il comando deve restituire exit code 0 solo se la copia è andata a buon fine.
archive_command = 'cp %p /backup/wal_archive/%f'

# Forza la rotazione del segmento WAL corrente ogni N secondi, anche se non è pieno.
# Garantisce che la perdita massima di dati (RPO) non superi questo intervallo.
# 300 secondi = perdita massima di 5 minuti in caso di disastro.
archive_timeout = 300

Infine, riavviare PostgreSQL per applicare le modifiche (necessario per archive_mode e wal_level)

systemctl restart postgresql-17

systemctl restart postgresql-17

Per verificare che l’archiving sia attivo e funzionante

SELECT
    archived_count,
    last_archived_wal,
    last_archived_time,
    failed_count,
    last_failed_wal,
    last_failed_time
FROM pg_stat_archiver;

# Output atteso
 archived_count |    last_archived_wal     |      last_archived_time       | failed_count | last_failed_wal | last_failed_time
----------------+--------------------------+-------------------------------+--------------+-----------------+------------------
              1 | 000000010000000300000062 | 2026-07-04 15:33:16.857609+02 |            0 |                 |

SELECT
    archived_count,
    last_archived_wal,
    last_archived_time,
    failed_count,
    last_failed_wal,
    last_failed_time
FROM pg_stat_archiver;

# Output atteso
 archived_count |    last_archived_wal     |      last_archived_time       | failed_count | last_failed_wal | last_failed_time
----------------+--------------------------+-------------------------------+--------------+-----------------+------------------
              1 | 000000010000000300000062 | 2026-07-04 15:33:16.857609+02 |            0 |                 |

archived_count deve essere in crescita e failed_count deve rimanere a zero. Se failed_count aumenta, controllare i permessi sulla directory di archivio e la raggiungibilità del server remoto.

Eseguire il backup base

Con l’archiving attivo, eseguire il backup fisico del cluster

sudo -u postgres pg_basebackup \
    --pgdata=/backup/pgbase_$(date +%Y%m%d) \
    --format=tar \
    --gzip \
    --wal-method=stream \
    --checkpoint=fast \
    --progress \
    --verbose

sudo -u postgres pg_basebackup \
    --pgdata=/backup/pgbase_$(date +%Y%m%d) \
    --format=tar \
    --gzip \
    --wal-method=stream \
    --checkpoint=fast \
    --progress \
    --verbose

L’opzione –wal-method=stream fa sì che pg_basebackup faccia lo stream in parallelo anche per i segmenti WAL prodotti durante il backup, garantendo che il backup base sia autonomamente consistente anche senza dover contare sull’archivio WAL per la finestra di tempo del backup stesso.

Possiamo automatizzare con un job cron il comando per il backup tramite crontab

crontab -e -u postgres

# Aggiungere
0 1 * * * pg_basebackup --pgdata=/backup/pgbase_$(date +\%Y\%m\%d) --format=tar --gzip --wal-method=stream --checkpoint=fast

crontab -e -u postgres

# Aggiungere
0 1 * * * pg_basebackup --pgdata=/backup/pgbase_$(date +\%Y\%m\%d) --format=tar --gzip --wal-method=stream --checkpoint=fast

Pulizia dei segmenti WAL archiviati

L’archivio WAL cresce indefinitamente se non viene gestito. I segmenti precedenti al backup base più vecchio che si intende conservare possono essere eliminati con il comando pg_archivecleanup

sudo -u postgres /usr/pgsql-17/bin/pg_archivecleanup /backup/wal_archive 000000010000000300000065

sudo -u postgres /usr/pgsql-17/bin/pg_archivecleanup /backup/wal_archive 000000010000000300000065

Il nome del segmento di riferimento si trova nel file backup_label all’interno del backup base

tar -xzf /backup/pgbase_20260704/base.tar.gz -O backup_label | grep "START WAL"

# Output atteso
START WAL LOCATION: 3/65000028 (file 000000010000000300000065)

tar -xzf /backup/pgbase_20260704/base.tar.gz -O backup_label | grep "START WAL"

# Output atteso
START WAL LOCATION: 3/65000028 (file 000000010000000300000065)

In un ambiente di produzione è consigliabile automatizzare la pulizia con uno script dedicato. Lo script seguente conserva gli ultimi N backup base (default: 2) e rimuove dall’archivio WAL tutti i segmenti precedenti al più vecchio backup base conservato

vi /usr/local/bin/pg_backup_cleanup.sh

vi /usr/local/bin/pg_backup_cleanup.sh

con il seguente contenuto

#!/bin/bash
# pg_backup_cleanup.sh
# Conserva gli ultimi N backup base di PostgreSQL e pulisce i segmenti WAL
# archiviati che non sono più necessari per nessuno dei backup conservati.
#
# Uso: pg_backup_cleanup.sh [N]
#   N = numero di backup base da conservare (default: 2)

set -euo pipefail

BACKUP_DIR="/backup/pgbase_*"
WAL_ARCHIVE="/backup/wal_archive"
KEEP=${1:-2}
LOG="/var/log/pg_backup_cleanup.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG"
}

# 1. Identificare tutti i backup base ordinati dal più vecchio al più recente
mapfile -t ALL_BACKUPS < <(ls -1d /backup/pgbase_* 2>/dev/null | sort)
TOTAL=${#ALL_BACKUPS[@]}

if [[ $TOTAL -eq 0 ]]; then
    log "Nessun backup base trovato in /backup. Uscita."
    exit 0
fi

log "Backup base trovati: $TOTAL — da conservare: $KEEP"

# 2. Identificare i backup da eliminare (i più vecchi oltre la soglia)
if [[ $TOTAL -le $KEEP ]]; then
    log "Numero di backup ($TOTAL) <= soglia di conservazione ($KEEP). Nessuna pulizia necessaria."
    exit 0
fi

DELETE_COUNT=$(( TOTAL - KEEP ))
BACKUPS_TO_DELETE=("${ALL_BACKUPS[@]:0:$DELETE_COUNT}")
OLDEST_KEPT="${ALL_BACKUPS[$DELETE_COUNT]}"

log "Backup da eliminare: $DELETE_COUNT"
log "Backup più vecchio conservato: $OLDEST_KEPT"

# 3. Ricavare il segmento WAL di riferimento dal backup_label del più vecchio
#    backup conservato. I segmenti WAL precedenti a questo sono eliminabili.
BACKUP_LABEL_WAL=$(tar -xzf "${OLDEST_KEPT}/base.tar.gz" -O backup_label 2>/dev/null \
    | grep "START WAL LOCATION" \
    | grep -oP '[0-9A-F]{24}')

if [[ -z "$BACKUP_LABEL_WAL" ]]; then
    log "ERRORE: impossibile leggere il segmento WAL di riferimento da $OLDEST_KEPT/base.tar.gz"
    exit 1
fi

log "Segmento WAL di riferimento (dal backup più vecchio conservato): $BACKUP_LABEL_WAL"

# 4. Eliminare i backup base obsoleti
for BACKUP in "${BACKUPS_TO_DELETE[@]}"; do
    log "Elimino backup base: $BACKUP"
    rm -rf "$BACKUP"
done

# 5. Pulire i segmenti WAL archiviati precedenti al segmento di riferimento
log "Pulizia segmenti WAL in $WAL_ARCHIVE precedenti a $BACKUP_LABEL_WAL ..."
sudo -u postgres /usr/pgsql-17/bin/pg_archivecleanup "$WAL_ARCHIVE" "$BACKUP_LABEL_WAL"
log "Pulizia WAL completata."

# 6. Riepilogo spazio liberato
WAL_SIZE=$(du -sh "$WAL_ARCHIVE" 2>/dev/null | cut -f1)
log "Dimensione archivio WAL dopo la pulizia: $WAL_SIZE"
log "---- Pulizia completata ----"

#!/bin/bash
# pg_backup_cleanup.sh
# Conserva gli ultimi N backup base di PostgreSQL e pulisce i segmenti WAL
# archiviati che non sono più necessari per nessuno dei backup conservati.
#
# Uso: pg_backup_cleanup.sh [N]
#   N = numero di backup base da conservare (default: 2)

set -euo pipefail

BACKUP_DIR="/backup/pgbase_*"
WAL_ARCHIVE="/backup/wal_archive"
KEEP=${1:-2}
LOG="/var/log/pg_backup_cleanup.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG"
}

# 1. Identificare tutti i backup base ordinati dal più vecchio al più recente
mapfile -t ALL_BACKUPS < <(ls -1d /backup/pgbase_* 2>/dev/null | sort)
TOTAL=${#ALL_BACKUPS[@]}

if [[ $TOTAL -eq 0 ]]; then
    log "Nessun backup base trovato in /backup. Uscita."
    exit 0
fi

log "Backup base trovati: $TOTAL — da conservare: $KEEP"

# 2. Identificare i backup da eliminare (i più vecchi oltre la soglia)
if [[ $TOTAL -le $KEEP ]]; then
    log "Numero di backup ($TOTAL) <= soglia di conservazione ($KEEP). Nessuna pulizia necessaria."
    exit 0
fi

DELETE_COUNT=$(( TOTAL - KEEP ))
BACKUPS_TO_DELETE=("${ALL_BACKUPS[@]:0:$DELETE_COUNT}")
OLDEST_KEPT="${ALL_BACKUPS[$DELETE_COUNT]}"

log "Backup da eliminare: $DELETE_COUNT"
log "Backup più vecchio conservato: $OLDEST_KEPT"

# 3. Ricavare il segmento WAL di riferimento dal backup_label del più vecchio
#    backup conservato. I segmenti WAL precedenti a questo sono eliminabili.
BACKUP_LABEL_WAL=$(tar -xzf "${OLDEST_KEPT}/base.tar.gz" -O backup_label 2>/dev/null \
    | grep "START WAL LOCATION" \
    | grep -oP '[0-9A-F]{24}')

if [[ -z "$BACKUP_LABEL_WAL" ]]; then
    log "ERRORE: impossibile leggere il segmento WAL di riferimento da $OLDEST_KEPT/base.tar.gz"
    exit 1
fi

log "Segmento WAL di riferimento (dal backup più vecchio conservato): $BACKUP_LABEL_WAL"

# 4. Eliminare i backup base obsoleti
for BACKUP in "${BACKUPS_TO_DELETE[@]}"; do
    log "Elimino backup base: $BACKUP"
    rm -rf "$BACKUP"
done

# 5. Pulire i segmenti WAL archiviati precedenti al segmento di riferimento
log "Pulizia segmenti WAL in $WAL_ARCHIVE precedenti a $BACKUP_LABEL_WAL ..."
sudo -u postgres /usr/pgsql-17/bin/pg_archivecleanup "$WAL_ARCHIVE" "$BACKUP_LABEL_WAL"
log "Pulizia WAL completata."

# 6. Riepilogo spazio liberato
WAL_SIZE=$(du -sh "$WAL_ARCHIVE" 2>/dev/null | cut -f1)
log "Dimensione archivio WAL dopo la pulizia: $WAL_SIZE"
log "---- Pulizia completata ----"

Rendere lo script eseguibile

chmod +x /usr/local/bin/pg_backup_cleanup.sh

chmod +x /usr/local/bin/pg_backup_cleanup.sh

Creare ora uno script che esegue prima il backup base e, solo se va a buon fine, avvia la pulizia. In questo modo i due passi sono sempre in sequenza garantita, indipendentemente da quanto tempo richiede il backup

vi /usr/local/bin/pg_backup_and_cleanup.sh

vi /usr/local/bin/pg_backup_and_cleanup.sh

con il seguente contenuto

#!/bin/bash
# pg_backup_and_cleanup.sh
# Esegue il backup base di PostgreSQL e, solo in caso di successo,
# avvia la pulizia dei backup obsoleti e dei segmenti WAL archiviati.

set -euo pipefail

BACKUP_BASE_DIR="/backup"
WAL_ARCHIVE="/backup/wal_archive"
KEEP=2
LOG="/var/log/pg_backup_cleanup.log"
BACKUP_DEST="${BACKUP_BASE_DIR}/pgbase_$(date +%Y%m%d)"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG"
}

log "==== Inizio ciclo backup + pulizia ===="

# 1. Eseguire il backup base
log "Avvio pg_basebackup -> $BACKUP_DEST"

if sudo -u postgres pg_basebackup \
        --pgdata="$BACKUP_DEST" \
        --format=tar \
        --gzip \
        --wal-method=stream \
        --checkpoint=fast \
        --progress \
        --verbose >> "$LOG" 2>&1; then
    log "pg_basebackup completato con successo."
else
    log "ERRORE: pg_basebackup fallito. Pulizia non eseguita per sicurezza."
    exit 1
fi

# 2. Solo se il backup è andato a buon fine, avviare la pulizia
log "Avvio pulizia (conservo gli ultimi $KEEP backup base)..."
/usr/local/bin/pg_backup_cleanup.sh "$KEEP"

log "==== Ciclo backup + pulizia completato ===="

#!/bin/bash
# pg_backup_and_cleanup.sh
# Esegue il backup base di PostgreSQL e, solo in caso di successo,
# avvia la pulizia dei backup obsoleti e dei segmenti WAL archiviati.

set -euo pipefail

BACKUP_BASE_DIR="/backup"
WAL_ARCHIVE="/backup/wal_archive"
KEEP=2
LOG="/var/log/pg_backup_cleanup.log"
BACKUP_DEST="${BACKUP_BASE_DIR}/pgbase_$(date +%Y%m%d)"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG"
}

log "==== Inizio ciclo backup + pulizia ===="

# 1. Eseguire il backup base
log "Avvio pg_basebackup -> $BACKUP_DEST"

if sudo -u postgres pg_basebackup \
        --pgdata="$BACKUP_DEST" \
        --format=tar \
        --gzip \
        --wal-method=stream \
        --checkpoint=fast \
        --progress \
        --verbose >> "$LOG" 2>&1; then
    log "pg_basebackup completato con successo."
else
    log "ERRORE: pg_basebackup fallito. Pulizia non eseguita per sicurezza."
    exit 1
fi

# 2. Solo se il backup è andato a buon fine, avviare la pulizia
log "Avvio pulizia (conservo gli ultimi $KEEP backup base)..."
/usr/local/bin/pg_backup_cleanup.sh "$KEEP"

log "==== Ciclo backup + pulizia completato ===="

Rendere eseguibile anche questo script

chmod +x /usr/local/bin/pg_backup_and_cleanup.sh

chmod +x /usr/local/bin/pg_backup_and_cleanup.sh

Possiamo automatizzare con un job cron il comando per il backup tramite crontab

crontab -e

# Aggiungere
0 1 * * * root /usr/local/bin/pg_backup_and_cleanup.sh

crontab -e

# Aggiungere
0 1 * * * root /usr/local/bin/pg_backup_and_cleanup.sh

Con questa struttura il tempo impiegato dal backup non è rilevante: la pulizia parte sempre e solo dopo che pg_basebackup ha terminato con successo. Se il backup fallisce per qualsiasi motivo (spazio insufficiente, errore di rete, problema sul cluster) lo script si interrompe immediatamente senza toccare né i backup base esistenti né i segmenti WAL archiviati. Per verificare il log di esecuzione

tail -100 /var/log/pg_backup_cleanup.log

# Esempio di output del log
[2026-07-04 16:07:20] ==== Inizio ciclo backup + pulizia ====
[2026-07-04 16:07:20] Avvio pg_basebackup -> /backup/pgbase_20260704
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 3/6E000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot "pg_basebackup_72567"
 45900/341736 kB (13%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
 88467/341736 kB (25%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
128449/341736 kB (37%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
163295/341736 kB (47%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
199806/341736 kB (58%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
239791/341736 kB (70%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
276240/341736 kB (80%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
313174/341736 kB (91%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
341747/341747 kB (100%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
341747/341747 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 3/6E0167E0
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: syncing data to disk ...
pg_basebackup: renaming backup_manifest.tmp to backup_manifest
pg_basebackup: base backup completed
[2026-07-04 16:07:30] pg_basebackup completato con successo.
[2026-07-04 16:07:30] Avvio pulizia (conservo gli ultimi 2 backup base)...
[2026-07-04 16:07:30] Backup base trovati: 1 — da conservare: 2
[2026-07-04 16:07:30] Numero di backup (1) <= soglia di conservazione (2). Nessuna pulizia necessaria.
[2026-07-04 16:07:30] ==== Ciclo backup + pulizia completato ====

tail -100 /var/log/pg_backup_cleanup.log

# Esempio di output del log
[2026-07-04 16:07:20] ==== Inizio ciclo backup + pulizia ====
[2026-07-04 16:07:20] Avvio pg_basebackup -> /backup/pgbase_20260704
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 3/6E000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot "pg_basebackup_72567"
 45900/341736 kB (13%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
 88467/341736 kB (25%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
128449/341736 kB (37%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
163295/341736 kB (47%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
199806/341736 kB (58%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
239791/341736 kB (70%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
276240/341736 kB (80%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
313174/341736 kB (91%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
341747/341747 kB (100%), 0/1 tablespace (/backup/pgbase_20260704/base.tar.gz)
341747/341747 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 3/6E0167E0
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: syncing data to disk ...
pg_basebackup: renaming backup_manifest.tmp to backup_manifest
pg_basebackup: base backup completed
[2026-07-04 16:07:30] pg_basebackup completato con successo.
[2026-07-04 16:07:30] Avvio pulizia (conservo gli ultimi 2 backup base)...
[2026-07-04 16:07:30] Backup base trovati: 1 — da conservare: 2
[2026-07-04 16:07:30] Numero di backup (1) <= soglia di conservazione (2). Nessuna pulizia necessaria.
[2026-07-04 16:07:30] ==== Ciclo backup + pulizia completato ====

Procedura di restore PITR

La procedura di restore da backup fisico con PITR si articola in cinque passi. Va eseguita su un server separato da quello di produzione, o sullo stesso server dopo aver fermato completamente il servizio.

Passo 1: Fermare PostgreSQL e svuotare la directory dati

systemctl stop zabbix-server
systemctl stop postgresql-17

# Rinominare la directory dati esistente come precauzione (non eliminare)
mv /var/lib/pgsql/17/data /var/lib/pgsql/17/data_old
mkdir -p /var/lib/pgsql/17/data
chown postgres:postgres /var/lib/pgsql/17/data
chmod 700 /var/lib/pgsql/17/data

systemctl stop zabbix-server
systemctl stop postgresql-17

# Rinominare la directory dati esistente come precauzione (non eliminare)
mv /var/lib/pgsql/17/data /var/lib/pgsql/17/data_old
mkdir -p /var/lib/pgsql/17/data
chown postgres:postgres /var/lib/pgsql/17/data
chmod 700 /var/lib/pgsql/17/data

Passo 2: Ripristinare il backup base

Per ripristinare il database eseguire il comando

sudo -u postgres tar -xzf /backup/pgbase_20260704/base.tar.gz \
    -C /var/lib/pgsql/17/data

sudo -u postgres tar -xzf /backup/pgbase_20260704/base.tar.gz \
    -C /var/lib/pgsql/17/data

Se il backup contiene anche il tablespace globale (file pg_wal.tar.gz), estrarlo nella directory corretta

sudo -u postgres tar -xzf /backup/pgbase_20260704/pg_wal.tar.gz \
    -C /var/lib/pgsql/17/data/pg_wal

sudo -u postgres tar -xzf /backup/pgbase_20260704/pg_wal.tar.gz \
    -C /var/lib/pgsql/17/data/pg_wal

Passo 3: Configurare il recovery

Creare il file postgresql.auto.conf con i parametri di recovery

sudo -u postgres tee /var/lib/pgsql/17/data/postgresql.auto.conf <<EOF
# Comando per recuperare i segmenti WAL dall'archivio durante il replay
restore_command = 'cp /backup/wal_archive/%f %p'

# Punto nel tempo a cui ripristinare (commentare per ripristinare il massimo possibile)
# Formato: 'YYYY-MM-DD HH:MM:SS TZ'
recovery_target_time = '2026-07-04 17:45:00 Europe/Rome'

# Azione da eseguire quando il target viene raggiunto:
# 'promote' = il server diventa primario e accetta scritture
# 'pause'   = il server si ferma in stato di recovery per ispezione
recovery_target_action = 'promote'
EOF

sudo -u postgres tee /var/lib/pgsql/17/data/postgresql.auto.conf <<EOF
# Comando per recuperare i segmenti WAL dall'archivio durante il replay
restore_command = 'cp /backup/wal_archive/%f %p'

# Punto nel tempo a cui ripristinare (commentare per ripristinare il massimo possibile)
# Formato: 'YYYY-MM-DD HH:MM:SS TZ'
recovery_target_time = '2026-07-04 17:45:00 Europe/Rome'

# Azione da eseguire quando il target viene raggiunto:
# 'promote' = il server diventa primario e accetta scritture
# 'pause'   = il server si ferma in stato di recovery per ispezione
recovery_target_action = 'promote'
EOF

Il valore di recovery_target_time deve essere successivo al momento di completamento del backup base, visibile dalla data di modifica dei file nella directory del backup, e precedente al momento dell’incidente che si vuole recuperare. Se ad esempio il backup è terminato alle 16:27 e un’operazione errata ha cancellato dati alle 17:45, il target corretto è un orario compreso in quella finestra.

Per ripristinare all’ultimo stato disponibile senza un target temporale specifico, rimuovere la riga recovery_target_time in modo che PostgreSQL replicherà tutto il WAL disponibile nell’archivio

Passo 4: Creare il file recovery.signal

Da PostgreSQL 12 e versioni successive la presenza del file recovery.signal nella directory dati segnala a PostgreSQL di entrare in modalità recovery all’avvio

sudo -u postgres touch /var/lib/pgsql/17/data/recovery.signal

sudo -u postgres touch /var/lib/pgsql/17/data/recovery.signal

Passo 5: Avviare PostgreSQL e monitorare il replay

systemctl start postgresql-17

systemctl start postgresql-17

Per seguire il replay in tempo reale possiamo leggere direttamente il log di PostgreSQL

tail -f /var/lib/pgsql/17/data/log/$(ls -t /var/lib/pgsql/17/data/log/ | head -1)

# Output atteso
2026-07-04 16:44:12.199 CEST [2213] LOG:  starting PostgreSQL 17.10 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-11), 64-bit
2026-07-04 16:44:12.200 CEST [2213] LOG:  listening on IPv6 address "::1", port 5432
2026-07-04 16:44:12.200 CEST [2213] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2026-07-04 16:44:12.200 CEST [2213] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2026-07-04 16:44:12.202 CEST [2213] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2026-07-04 16:44:12.205 CEST [2217] LOG:  database system was interrupted while in recovery at log time 2026-07-04 16:27:16 CEST
2026-07-04 16:44:12.205 CEST [2217] HINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
cp: cannot stat '/backup/wal_archive/00000002.history': No such file or directory
2026-07-04 16:44:12.239 CEST [2217] LOG:  restored log file "000000010000000300000072" from archive
2026-07-04 16:44:12.240 CEST [2217] LOG:  starting point-in-time recovery to 2026-07-04 17:45:00+02
2026-07-04 16:44:12.241 CEST [2217] LOG:  redo starts at 3/72000028
2026-07-04 16:44:12.246 CEST [2217] LOG:  restored log file "000000010000000300000073" from archive
2026-07-04 16:44:12.248 CEST [2217] LOG:  consistent recovery state reached at 3/7202EBF0
2026-07-04 16:44:12.248 CEST [2213] LOG:  database system is ready to accept read-only connections
cp: cannot stat '/backup/wal_archive/000000010000000300000074': No such file or directory
cp: cannot stat '/backup/wal_archive/000000010000000300000074': No such file or directory
2026-07-04 16:44:12.256 CEST [2217] LOG:  redo done at 3/730399D0 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.01 s
2026-07-04 16:44:12.256 CEST [2217] LOG:  last completed transaction was at log time 2026-07-04 16:27:54.248614+02
2026-07-04 16:44:12.256 CEST [2217] FATAL:  recovery ended before configured recovery target was reached
2026-07-04 16:44:12.258 CEST [2213] LOG:  startup process (PID 2217) exited with exit code 1
2026-07-04 16:44:12.258 CEST [2213] LOG:  terminating any other active server processes
2026-07-04 16:44:12.258 CEST [2213] LOG:  shutting down due to startup process failure
2026-07-04 16:44:12.263 CEST [2213] LOG:  database system is shut down
2026-07-04 16:47:45.265 CEST [2239] LOG:  starting PostgreSQL 17.10 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-11), 64-bit
2026-07-04 16:47:45.265 CEST [2239] LOG:  listening on IPv6 address "::1", port 5432
2026-07-04 16:47:45.265 CEST [2239] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2026-07-04 16:47:45.266 CEST [2239] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2026-07-04 16:47:45.267 CEST [2239] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2026-07-04 16:47:45.270 CEST [2244] LOG:  database system was interrupted while in recovery at log time 2026-07-04 16:27:16 CEST
2026-07-04 16:47:45.270 CEST [2244] HINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
cp: cannot stat '/backup/wal_archive/00000002.history': No such file or directory
2026-07-04 16:47:45.303 CEST [2244] LOG:  restored log file "000000010000000300000072" from archive
2026-07-04 16:47:45.305 CEST [2244] LOG:  starting archive recovery
2026-07-04 16:47:45.306 CEST [2244] LOG:  redo starts at 3/72000028
2026-07-04 16:47:45.313 CEST [2244] LOG:  restored log file "000000010000000300000073" from archive
2026-07-04 16:47:45.315 CEST [2244] LOG:  consistent recovery state reached at 3/7202EBF0
2026-07-04 16:47:45.315 CEST [2239] LOG:  database system is ready to accept read-only connections
cp: cannot stat '/backup/wal_archive/000000010000000300000074': No such file or directory
cp: cannot stat '/backup/wal_archive/000000010000000300000074': No such file or directory
2026-07-04 16:47:45.323 CEST [2244] LOG:  redo done at 3/730399D0 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.01 s
2026-07-04 16:47:45.323 CEST [2244] LOG:  last completed transaction was at log time 2026-07-04 16:27:54.248614+02
2026-07-04 16:47:45.325 CEST [2244] LOG:  restored log file "000000010000000300000073" from archive
cp: cannot stat '/backup/wal_archive/00000002.history': No such file or directory
2026-07-04 16:47:45.329 CEST [2244] LOG:  selected new timeline ID: 2
cp: cannot stat '/backup/wal_archive/00000001.history': No such file or directory
2026-07-04 16:47:45.485 CEST [2244] LOG:  archive recovery complete
2026-07-04 16:47:45.486 CEST [2242] LOG:  checkpoint starting: end-of-recovery immediate wait
2026-07-04 16:47:45.501 CEST [2242] LOG:  checkpoint complete: wrote 109 buffers (0.1%); 0 WAL file(s) added, 0 removed, 2 recycled; write=0.008 s, sync=0.005 s, total=0.017 s; sync files=53, longest=0.004 s, average=0.001 s; distance=32768 kB, estimate=32768 kB; lsn=3/74000028, redo lsn=3/74000028
2026-07-04 16:47:45.505 CEST [2239] LOG:  database system is ready to accept connections
2026-07-04 16:47:45.509 CEST [2256] LOG:  TimescaleDB background worker launcher connected to shared catalogs

tail -f /var/lib/pgsql/17/data/log/$(ls -t /var/lib/pgsql/17/data/log/ | head -1)

# Output atteso
2026-07-04 16:44:12.199 CEST [2213] LOG:  starting PostgreSQL 17.10 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-11), 64-bit
2026-07-04 16:44:12.200 CEST [2213] LOG:  listening on IPv6 address "::1", port 5432
2026-07-04 16:44:12.200 CEST [2213] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2026-07-04 16:44:12.200 CEST [2213] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2026-07-04 16:44:12.202 CEST [2213] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2026-07-04 16:44:12.205 CEST [2217] LOG:  database system was interrupted while in recovery at log time 2026-07-04 16:27:16 CEST
2026-07-04 16:44:12.205 CEST [2217] HINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
cp: cannot stat '/backup/wal_archive/00000002.history': No such file or directory
2026-07-04 16:44:12.239 CEST [2217] LOG:  restored log file "000000010000000300000072" from archive
2026-07-04 16:44:12.240 CEST [2217] LOG:  starting point-in-time recovery to 2026-07-04 17:45:00+02
2026-07-04 16:44:12.241 CEST [2217] LOG:  redo starts at 3/72000028
2026-07-04 16:44:12.246 CEST [2217] LOG:  restored log file "000000010000000300000073" from archive
2026-07-04 16:44:12.248 CEST [2217] LOG:  consistent recovery state reached at 3/7202EBF0
2026-07-04 16:44:12.248 CEST [2213] LOG:  database system is ready to accept read-only connections
cp: cannot stat '/backup/wal_archive/000000010000000300000074': No such file or directory
cp: cannot stat '/backup/wal_archive/000000010000000300000074': No such file or directory
2026-07-04 16:44:12.256 CEST [2217] LOG:  redo done at 3/730399D0 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.01 s
2026-07-04 16:44:12.256 CEST [2217] LOG:  last completed transaction was at log time 2026-07-04 16:27:54.248614+02
2026-07-04 16:44:12.256 CEST [2217] FATAL:  recovery ended before configured recovery target was reached
2026-07-04 16:44:12.258 CEST [2213] LOG:  startup process (PID 2217) exited with exit code 1
2026-07-04 16:44:12.258 CEST [2213] LOG:  terminating any other active server processes
2026-07-04 16:44:12.258 CEST [2213] LOG:  shutting down due to startup process failure
2026-07-04 16:44:12.263 CEST [2213] LOG:  database system is shut down
2026-07-04 16:47:45.265 CEST [2239] LOG:  starting PostgreSQL 17.10 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-11), 64-bit
2026-07-04 16:47:45.265 CEST [2239] LOG:  listening on IPv6 address "::1", port 5432
2026-07-04 16:47:45.265 CEST [2239] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2026-07-04 16:47:45.266 CEST [2239] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2026-07-04 16:47:45.267 CEST [2239] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2026-07-04 16:47:45.270 CEST [2244] LOG:  database system was interrupted while in recovery at log time 2026-07-04 16:27:16 CEST
2026-07-04 16:47:45.270 CEST [2244] HINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
cp: cannot stat '/backup/wal_archive/00000002.history': No such file or directory
2026-07-04 16:47:45.303 CEST [2244] LOG:  restored log file "000000010000000300000072" from archive
2026-07-04 16:47:45.305 CEST [2244] LOG:  starting archive recovery
2026-07-04 16:47:45.306 CEST [2244] LOG:  redo starts at 3/72000028
2026-07-04 16:47:45.313 CEST [2244] LOG:  restored log file "000000010000000300000073" from archive
2026-07-04 16:47:45.315 CEST [2244] LOG:  consistent recovery state reached at 3/7202EBF0
2026-07-04 16:47:45.315 CEST [2239] LOG:  database system is ready to accept read-only connections
cp: cannot stat '/backup/wal_archive/000000010000000300000074': No such file or directory
cp: cannot stat '/backup/wal_archive/000000010000000300000074': No such file or directory
2026-07-04 16:47:45.323 CEST [2244] LOG:  redo done at 3/730399D0 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.01 s
2026-07-04 16:47:45.323 CEST [2244] LOG:  last completed transaction was at log time 2026-07-04 16:27:54.248614+02
2026-07-04 16:47:45.325 CEST [2244] LOG:  restored log file "000000010000000300000073" from archive
cp: cannot stat '/backup/wal_archive/00000002.history': No such file or directory
2026-07-04 16:47:45.329 CEST [2244] LOG:  selected new timeline ID: 2
cp: cannot stat '/backup/wal_archive/00000001.history': No such file or directory
2026-07-04 16:47:45.485 CEST [2244] LOG:  archive recovery complete
2026-07-04 16:47:45.486 CEST [2242] LOG:  checkpoint starting: end-of-recovery immediate wait
2026-07-04 16:47:45.501 CEST [2242] LOG:  checkpoint complete: wrote 109 buffers (0.1%); 0 WAL file(s) added, 0 removed, 2 recycled; write=0.008 s, sync=0.005 s, total=0.017 s; sync files=53, longest=0.004 s, average=0.001 s; distance=32768 kB, estimate=32768 kB; lsn=3/74000028, redo lsn=3/74000028
2026-07-04 16:47:45.505 CEST [2239] LOG:  database system is ready to accept connections
2026-07-04 16:47:45.509 CEST [2256] LOG:  TimescaleDB background worker launcher connected to shared catalogs

Le righe chiave che indicato il corretto completamento del processo di recovery sono

LOG:  archive recovery complete
LOG:  database system is ready to accept connections
LOG:  TimescaleDB background worker launcher connected to shared catalogs

LOG:  archive recovery complete
LOG:  database system is ready to accept connections
LOG:  TimescaleDB background worker launcher connected to shared catalogs

Ora possiamo avviare Zabbix e verificare che la connessione al database sia stabilita correttamente e che il server riprenda il polling degli host

systemctl start zabbix-server

systemctl start zabbix-server

L’elenco degli articoli di questa serie può essere consultato qui