Verifica dell'integrità dei dati dopo il ripristino

Ripristinare un database non è sempre una passeggiata: sembra che tutto sia andato bene, ma poi nei log saltano fuori errori, alcune tabelle spariscono o i dati sembrano strani. Ecco perché è super importante controllare per bene tutto dopo il ripristino, per essere sicuri che sia davvero tutto ok.

A volte una parte dei dati potrebbe non essere stata ripristinata — tipo se il backup era corrotto. Può capitare che la struttura delle tabelle si incasini: spariscono le foreign key, mancano gli indici o compaiono valori assurdi. E anche se a prima vista sembra tutto normale, i log potrebbero suggerire che il database non è proprio in forma.

La verifica dell'integrità è come il tagliando dopo una riparazione. Meglio perdere un po' di tempo per controllare che tutto funzioni, piuttosto che trovarsi un problema improvviso in produzione.

Analisi dei log di ripristino

Quando ripristini i dati con pg_restore, PostgreSQL genera sempre un log. Il log contiene un sacco di info utili sul processo di ripristino, inclusi warning ed errori. Ecco un esempio di comando con il file di log specificato:

pg_restore -U username -d database_name backup_file.dump > restore_log.txt 2>&1

Occhio a > restore_log.txt 2>&1 — così mandi sia l'output standard che gli errori nello stesso file.

Cosa cercare nei log?

1. Errori. Fai attenzione a parole chiave tipo "ERROR" o "FATAL". Esempio:

   ERROR:  relazione "students" non esiste
   

2. Warning. A volte puoi vedere warning "WARNING". Anche se non sono critici, leggili comunque — potrebbero segnalare problemi:

   WARNING:  nessun privilegio può essere assegnato alla tabella "grades"
   

3. Incongruenze nei dati. Controlla che tutti gli oggetti chiave siano stati ripristinati: tabelle, indici, foreign key.

Controllo veloce con grep

Se il file di log è troppo lungo (a volte sembrano "Guerra e Pace"), puoi usare grep per cercare le parole chiave:

grep -i "error" restore_log.txt
grep -i "warning" restore_log.txt

Analisi degli errori dai log

Vediamo un esempio reale dal log:

ERROR:  vincolo "fk_student_course" per la relazione "enrollments" non esiste
DETAIL:  Chiave (course_id)=(2) non è presente nella tabella "courses".

Cosa ci dice questo errore? Significa che PostgreSQL sta cercando di ripristinare una riga nella tabella enrollments, ma non esiste il course_id corrispondente nella tabella courses.

Come risolvere? Probabilmente i dati nella tabella courses sono stati danneggiati o non sono stati ripristinati. Dovrai aggiungere manualmente le righe mancanti oppure ripetere il ripristino.

Uso dei checksum per la verifica dell'integrità

Se vuoi essere sicuro che il file di backup non sia stato corrotto prima o dopo il ripristino, puoi usare i checksum.

Un checksum è un numeretto che rappresenta i dati in un file. Se il file cambia anche di un solo bit, il checksum cambia pure lui. Così puoi capire se il file è stato danneggiato.

Per creare un checksum puoi usare l'utility md5sum. Ecco un esempio di comando:

md5sum backup_file.dump

Il risultato sarà tipo così:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Confronto dei checksum

Se hai salvato il checksum del file in anticipo, puoi confrontarlo con quello attuale:

md5sum -c checksum.md5

Il file checksum.md5 deve contenere una riga con il checksum e il nome del file:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Se il checksum coincide, vedrai il messaggio OK. Se no — il file è corrotto.

Verifica dei dati a livello di database

Checksum e log sono utili, ma come fai a controllare che i dati siano davvero a posto? Ecco una lista di azioni standard:

1. Confronto del numero di righe

Confronta il numero di righe nelle tabelle prima e dopo il ripristino. Per esempio:

-- Conta il numero di righe nella tabella students
SELECT COUNT(*) FROM students;

Se il numero di righe è diverso, il ripristino non è andato a buon fine.

2. Verifica dell'integrità delle chiavi

Controlla le relazioni tra le tabelle per assicurarti che tutte le foreign key funzionino:

-- Controlla gli studenti iscritti ai corsi
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

Se la query restituisce dei risultati, vuol dire che nella tabella enrollments ci sono righe con corsi mancanti.

3. Confronto dei dati con l'originale

Se hai una copia dei dati (tipo un dump di un altro database), puoi confrontare le query:

-- Controlla i dati dalla tabella courses
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

Casi reali di ripristino

Un caso dalla pratica: una volta l'amministratore del DBMS Bob ha deciso di ripristinare i dati da un backup dopo un crash del server. Ha eseguito il comando:

pg_restore -U admin -d my_database my_backup.dump

Ma analizzando i log, il ripristino è finito con un errore:

ERROR:  impossibile creare il file "base/16385/pg_internal.init": Spazio su disco esaurito

Questo voleva dire che il disco era pieno. Dopo aver liberato spazio e ripetuto il ripristino, ha scoperto che non tutte le tabelle erano state ripristinate. Per fortuna, grazie ai checksum generati in anticipo e alla configurazione dell'archiviazione WAL, Bob è riuscito a ripristinare completamente il database.

Riepilogo della verifica dell'integrità

Alla fine della verifica dell'integrità dei dati dopo il ripristino, fai così:

1. Controlla i log per errori e warning.
2. Usa i checksum per assicurarti che i file non siano corrotti.
3. Confronta i dati del database per numero di righe e integrità delle relazioni.
4. Se qualcosa non va, analizza gli errori e ripeti il processo di ripristino.

Ora sei pronto per fare un controllo approfondito e assicurarti che i dati siano stati ripristinati proprio come ti aspettavi. Perché la cosa più importante nell'amministrazione dei database è essere sicuri del proprio backup!