0Pricing
SQL Academy · Lezione

Testare i ripristini

Un backup che non si può ripristinare è inutile.

Testare i ripristini è una lezione SQL Academy gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento SQL Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso SQL Academy include 4 lezioni in totale.

Un backup che non si può ripristinare è inutile

Molti team investono tempo nella configurazione di backup automatizzati, ma non verificano mai se questi backup possano essere effettivamente utilizzati per recuperare i dati. Un backup che fallisce durante il ripristino non è affatto un backup.

Questa lezione illustra la disciplina del testing dei ripristini: come verificare che i backup funzionino prima che un vero disastro vi costringa a scoprirlo nel modo più difficile.

In cosa consiste un test di ripristino?

Un test di ripristino consiste nel prendere un file di backup e caricarlo in un database — in genere un'istanza di test separata — quindi nell'eseguire query su quel database per confermare che i dati siano completi e coerenti.

I passaggi sono: 1) Ottenere il file di backup. 2) Ripristinarlo in un ambiente sandbox. 3) Eseguire query di convalida. 4) Confrontare i risultati con quelli dell'ambiente di produzione.

Creare uno snapshot di riferimento per il confronto

Prima di poter verificare un ripristino, è necessario disporre di un riferimento: un insieme noto di conteggi e checksum dell'ambiente di produzione con cui confrontare la copia ripristinata.

Esegua questa operazione sul database di produzione e registri i risultati:

SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

Verificare il numero di righe dopo il ripristino

Quando il backup è stato ripristinato in un database di test, esegua la stessa query e confronti i numeri. Se i conteggi coincidono, la struttura di base del ripristino è corretta.

Una discrepanza indica immediatamente che si sono persi dati durante il backup o il ripristino, prima ancora di intervenire sull'ambiente di produzione.

-- Run on the RESTORED test database
SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

Controllare i dati più recenti

Il numero di righe conferma la quantità, ma non la recentità. Verifichi che il database ripristinato contenga record recenti: il backup dovrebbe riflettere i dati fino al momento in cui è stato eseguito.

SELECT
  MAX(created_at) AS latest_order,
  MIN(created_at) AS oldest_order,
  COUNT(*)        AS total_orders
FROM orders;

Convalidare l'integrità referenziale

Anche se il numero di righe coincide, un ripristino può lasciare righe orfane: record figli il cui elemento padre non esiste più. Questo accade spesso quando le chiavi esterne non vengono applicate durante il backup o il ripristino.

Utilizzi una LEFT JOIN per rilevare gli elementi di ordine orfani:

SELECT
  oi.id       AS orphaned_item_id,
  oi.order_id AS missing_order_id
FROM order_items oi
LEFT JOIN orders o ON o.id = oi.order_id
WHERE o.id IS NULL;

Usare un checksum per rilevare la corruzione

Per le tabelle critiche, generi un checksum dei dati per rilevare la corruzione a livello di bit. In PostgreSQL è possibile combinare MD5 con un cast dell'intera riga.

Se il checksum dell'ambiente di produzione differisce da quello della copia ripristinata, i dati sono stati alterati o corrotti in un determinato momento.

SELECT
  MD5(string_agg(row_data, ',' ORDER BY row_data)) AS table_checksum
FROM (
  SELECT CAST(ROW(id, customer_id, total, created_at) AS TEXT) AS row_data
  FROM orders
) sub;

Creare una tabella di convalida dei ripristini

Per tenere traccia della cronologia dei test di ripristino, crei una tabella di registro dedicata alla convalida. Registri ogni esecuzione del test con la data del backup, il numero di righe ripristinate e l'esito della convalida.

CREATE TABLE IF NOT EXISTS restore_validation_log (
  id             SERIAL PRIMARY KEY,
  backup_taken_at TIMESTAMP NOT NULL,
  restored_at    TIMESTAMP NOT NULL DEFAULT NOW(),
  table_name     VARCHAR(100) NOT NULL,
  expected_rows  INT NOT NULL,
  actual_rows    INT NOT NULL,
  passed         BOOLEAN NOT NULL
);

Inserire un risultato di convalida

Dopo ogni test di ripristino, inserisca una riga nel registro di convalida. In questo modo disporrà di una traccia di audit che dimostra che i backup sono stati testati e mostra l'andamento degli esiti positivi e negativi nel tempo.

INSERT INTO restore_validation_log
  (backup_taken_at, table_name, expected_rows, actual_rows, passed)
VALUES
  ('2024-06-09 02:00:00', 'orders',      15482, 15482, TRUE),
  ('2024-06-09 02:00:00', 'customers',    8201,  8201,  TRUE),
  ('2024-06-09 02:00:00', 'order_items', 47310, 47310, TRUE);

Consultare la cronologia delle convalide

Esamini regolarmente il registro di convalida per individuare eventuali regressioni. Un backup che ha superato il test la settimana scorsa ma lo fallisce questa settimana segnala un problema nella pipeline dei backup che deve essere analizzato immediatamente.

SELECT
  backup_taken_at,
  table_name,
  expected_rows,
  actual_rows,
  passed,
  CASE
    WHEN passed THEN 'OK'
    ELSE 'MISMATCH - investigate!'
  END AS status
FROM restore_validation_log
ORDER BY backup_taken_at DESC, table_name;

Verifica del ripristino a un punto nel tempo

I database moderni supportano il ripristino a un punto nel tempo (PITR), che consente di ripristinare il database a qualsiasi momento usando un backup di base e gli archivi WAL (Write-Ahead Log).

Per verificare che il PITR funzioni, ripristini il database a un timestamp noto e controlli che un record creato dopo quel timestamp NON compaia nel database ripristinato:

-- After a PITR restore to '2024-06-09 03:00:00',
-- this order (created at 03:45) should NOT exist:
SELECT id, created_at, total
FROM orders
WHERE created_at > '2024-06-09 03:00:00'
ORDER BY created_at
LIMIT 5;
-- Zero rows = PITR worked correctly

Verifica rapida

Quale delle seguenti query è più utile per rilevare i record figli orfani dopo il ripristino di un backup?

Riepilogo della lezione: test dei ripristini

In questa lezione ha appreso perché il testing dei ripristini è una parte obbligatoria di qualsiasi strategia di backup e come implementarlo con SQL:

  • Snapshot di riferimento — registrare il numero di righe dell'ambiente di produzione prima del test.
  • Confronto del numero di righe — eseguire la stessa query sul database ripristinato e confrontare i risultati.
  • Controllo della recentità — confermare che i record più recenti corrispondano alla finestra di backup prevista.
  • Integrità referenziale — usare LEFT JOIN per trovare le righe figlie orfane.
  • Convalida tramite checksum — rilevare la corruzione a livello di bit con aggregati MD5.
  • Tabella del registro di convalida — tenere traccia di ogni esecuzione del test per disporre di una cronologia verificabile.
  • Verifica del PITR — confermare che il ripristino a un punto nel tempo raggiunga il momento corretto.

Un backup vale quanto l'ultimo test di ripristino riuscito. Pianifichi regolarmente questi controlli e consideri ogni errore un incidente critico.

Domande Frequenti

La lezione «Testare i ripristini» è gratuita?

Sì — il testo completo di «Testare i ripristini» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso SQL Academy, passa a CoddyKit PRO. Il corso SQL Academy include 4 lezioni in totale.

Cosa imparerò in «Testare i ripristini»?

Un backup che non si può ripristinare è inutile. Eserciti SQL Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare SQL Academy?

Non è richiesta alcuna esperienza precedente. SQL Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.

Quanto tempo richiede la lezione «Testare i ripristini»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione SQL Academy?

Sì. Ogni lezione SQL Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Backup logici e fisici
  2. Ripristino point-in-time
  3. Testare i ripristini
  4. Pianificazione del disaster recovery
← Torna a SQL Academy