0Pricing
SQL Academy · Lezione

Pianificazione del disaster recovery

RPO, RTO e runbook.

Pianificazione del disaster recovery è una lezione SQL Academy gratuita su CoddyKit. Questa è la lezione 4 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.

Che cos'è il disaster recovery?

Il Disaster Recovery (DR) è l'insieme di criteri, strumenti e procedure progettati per consentire il recupero dell'infrastruttura tecnologica e dei sistemi essenziali dopo un disastro naturale o causato dall'uomo.

Nel contesto dei database, la pianificazione del DR garantisce che i dati rimangano al sicuro e che i sistemi possano tornare online entro tempi accettabili in seguito a eventi come guasti hardware, eliminazioni accidentali dei dati, attacchi ransomware o interruzioni dei data center.

Recovery Point Objective (RPO)

RPO definisce la quantità massima accettabile di dati che si può perdere, espressa in termini di tempo. Se l'RPO è di 1 ora, deve essere possibile recuperare i dati fino ad almeno 1 ora prima del verificarsi del disastro.

Un RPO più breve richiede backup più frequenti o una replica continua. È possibile interrogare la cronologia dei backup per verificare il rispetto dell'obiettivo RPO.

-- Check the last backup time and calculate data loss window
SELECT
  backup_id,
  backup_type,
  started_at,
  finished_at,
  EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;

Recovery Time Objective (RTO)

RTO definisce la durata massima accettabile del periodo in cui il sistema può rimanere offline dopo un disastro. Se l'RTO è di 4 ore, il database deve essere completamente operativo entro 4 ore dal verificarsi del guasto.

L'RTO determina le decisioni relative ai server standby, all'automazione del failover e alle procedure di ripristino. Monitorare nel tempo la durata dei ripristini aiuta a prevedere se sarà possibile rispettare l'RTO.

-- Track restore durations to validate RTO compliance
SELECT
  restore_id,
  triggered_at,
  completed_at,
  EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
  CASE
    WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
    THEN 'WITHIN RTO'
    ELSE 'RTO BREACHED'
  END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;

RPO vs RTO — La differenza fondamentale

Queste due metriche vengono spesso confuse. Ecco il modo più semplice per ricordarle:

  • RPO = Quanti dati si può sostenere di perdere? (rivolto al passato, misurato in termini di tempo prima del disastro)
  • RTO = Per quanto tempo si può sostenere di rimanere offline? (rivolto al futuro, misurato in termini di tempo dopo il disastro)

Insieme definiscono la finestra di ripristino e influenzano direttamente la frequenza dei backup, la strategia di replica e il budget per l'infrastruttura.

-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
  db_name       VARCHAR(100) PRIMARY KEY,
  rpo_minutes   INT NOT NULL,
  rto_minutes   INT NOT NULL,
  tier          VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
  updated_at    TIMESTAMP DEFAULT NOW()
);

INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
  ('orders_db',    15,   60, 'CRITICAL'),
  ('analytics_db', 120, 240, 'MEDIUM'),
  ('archive_db',   480, 480, 'LOW');

Tipi di backup

Esistono tre strategie principali di backup, ciascuna con un diverso compromesso tra velocità e spazio di archiviazione:

  • Backup completo: uno snapshot completo dell'intero database. È il più lento da creare, ma il più veloce da ripristinare.
  • Backup differenziale: include solo le modifiche dall'ultimo backup completo. Offre una velocità moderata in entrambe le fasi.
  • Backup incrementale: include solo le modifiche dall'ultimo backup di qualsiasi tipo. È il più veloce da creare, ma il più lento da ripristinare, perché sono necessari più file.

La maggior parte delle strategie di DR combina backup completi settimanali con backup incrementali giornalieri, per bilanciare l'RPO e i costi di archiviazione.

-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
  backup_id   SERIAL PRIMARY KEY,
  db_name     VARCHAR(100) NOT NULL,
  backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
  started_at  TIMESTAMP NOT NULL,
  finished_at TIMESTAMP,
  size_mb     NUMERIC(12, 2),
  status      VARCHAR(20) DEFAULT 'IN_PROGRESS'
);

INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
  ('orders_db', 'FULL',        '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00',   320, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00',   290, 'SUCCESS');

Ripristino a un punto nel tempo (PITR)

Il ripristino a un punto nel tempo consente di ripristinare un database a un momento specifico qualsiasi, non solo al momento dell'ultimo backup. Questo risultato si ottiene riproducendo i log delle transazioni (WAL in PostgreSQL) sopra un backup di base.

Il PITR è essenziale quando è necessario recuperare dati corrotti o eliminati accidentalmente in un momento noto. È possibile ripristinare il database a un momento immediatamente precedente all'evento dannoso.

-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
  segment_name  VARCHAR(200) PRIMARY KEY,
  archived_at   TIMESTAMP DEFAULT NOW(),
  size_bytes    BIGINT,
  storage_path  TEXT
);

-- Find all WAL segments archived within a recovery window
SELECT
  segment_name,
  archived_at,
  ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;

Database standby e replica

Un database standby (replica) è una copia continuamente aggiornata del database primario, eseguita su hardware separato. Svolge due funzioni di DR:

  • Hot standby: può accettare query di lettura e completare il failover in pochi secondi (RTO quasi nullo).
  • Warm standby: viene mantenuto sincronizzato, ma non gestisce traffico; il failover richiede alcuni minuti.

Monitorare il ritardo di replica è fondamentale: una replica in ritardo significa che l'RPO effettivo è peggiore del previsto.

-- Monitor replication lag on a PostgreSQL primary
SELECT
  client_addr,
  application_name,
  state,
  sent_lsn,
  replay_lsn,
  (sent_lsn - replay_lsn) AS lag_bytes,
  EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;

Runbook: documentare le procedure di ripristino

Un runbook è un insieme documentato di istruzioni dettagliate che un operatore segue durante un evento di disaster recovery. Senza un runbook, anche i DBA più esperti commettono errori costosi sotto pressione.

Un buon runbook include: chi contattare, quali sistemi sono interessati, i comandi esatti da eseguire, l'output previsto a ogni passaggio e le procedure di rollback in caso di errore del ripristino. Memorizzare i metadati del runbook in un database aiuta a gestirne le versioni e a verificarne l'utilizzo.

-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
  runbook_id   SERIAL PRIMARY KEY,
  title        VARCHAR(200) NOT NULL,
  scenario     VARCHAR(100),
  version      VARCHAR(20) DEFAULT '1.0',
  last_tested  DATE,
  owner        VARCHAR(100),
  doc_url      TEXT
);

INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
  ('Full Database Restore from S3', 'total_loss',     '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
  ('Failover to Hot Standby',       'primary_down',   '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
  ('PITR to Specific Timestamp',    'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');

Registrazione dell'esecuzione dei runbook

Ogni volta che viene eseguito un runbook, sia durante un disastro reale sia durante un'esercitazione, l'esecuzione dovrebbe essere registrata. I registri di esecuzione consentono di misurare la durata effettiva del ripristino, verificando così l'RTO, di individuare i passaggi lenti o soggetti a errori e di dimostrare la conformità agli auditor.

-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
  execution_id  SERIAL PRIMARY KEY,
  runbook_id    INT REFERENCES runbook(runbook_id),
  triggered_by  VARCHAR(100),
  is_drill      BOOLEAN DEFAULT FALSE,
  started_at    TIMESTAMP NOT NULL,
  completed_at  TIMESTAMP,
  outcome       VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);

-- Report average restore time per runbook
SELECT
  r.title,
  COUNT(*) AS executions,
  ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
  MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;

Test del DR: esercitazioni regolari

Un piano di DR mai testato non è un piano: è un desiderio. Le esercitazioni regolari sono obbligatorie per garantire che il team sia realmente in grado di eseguire i runbook entro l'RTO definito e che i backup siano effettivamente ripristinabili.

Pianificare e tracciare le esercitazioni nel database crea una traccia di audit e aiuta a individuare i runbook la cui verifica è in ritardo.

-- Find runbooks that have not been drilled in over 90 days
SELECT
  r.runbook_id,
  r.title,
  r.scenario,
  MAX(e.completed_at) AS last_drill,
  CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
  ON e.runbook_id = r.runbook_id
  AND e.is_drill = TRUE
  AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
    OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;

Criteri di conservazione dei backup

I criteri di conservazione definiscono per quanto tempo vengono mantenuti i backup. Conservare ogni backup per sempre spreca spazio di archiviazione; eliminarli troppo rapidamente viola l'RPO e i requisiti di conformità.

Un criterio comune prevede: backup incrementali giornalieri per 7 giorni, backup completi settimanali per 4 settimane e backup completi mensili per 12 mesi. È possibile applicare e verificare i criteri di conservazione con query SQL sul registro dei backup.

-- Identify backups that are outside their retention window and ready to purge
SELECT
  backup_id,
  db_name,
  backup_type,
  finished_at,
  CURRENT_DATE - finished_at::DATE AS age_days,
  CASE backup_type
    WHEN 'INCREMENTAL' THEN 7
    WHEN 'DIFFERENTIAL' THEN 28
    WHEN 'FULL'         THEN 365
  END AS retention_days,
  CASE
    WHEN (CURRENT_DATE - finished_at::DATE) >
         CASE backup_type
           WHEN 'INCREMENTAL' THEN 7
           WHEN 'DIFFERENTIAL' THEN 28
           WHEN 'FULL'         THEN 365
         END
    THEN 'PURGE'
    ELSE 'KEEP'
  END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;

Verifica rapida

Verifichi la Sua comprensione delle definizioni di RPO e RTO.

Riepilogo: pianificazione del ripristino d'emergenza

In questa lezione ha esplorato i fondamenti della pianificazione del ripristino d'emergenza dei database:

  • RPO definisce la perdita di dati massima tollerabile, espressa in termini di tempo; un RPO più breve richiede backup più frequenti o la replica continua.
  • RTO definisce in quanto tempo il sistema deve essere ripristinato; un RTO più breve richiede sistemi standby a caldo e il failover automatico.
  • I tipi di backup — completo, differenziale e incrementale — offrono ciascuno compromessi diversi tra spazio di archiviazione, velocità di creazione e velocità di ripristino.
  • PITR (Point-in-Time Recovery) utilizza i log delle transazioni per ripristinare il database a qualsiasi istante preciso, proteggendo dalle modifiche accidentali.
  • I runbook documentano ogni passaggio di una procedura di ripristino; registrare le esecuzioni consente di verificare che l'RTO sia raggiungibile nella pratica.
  • Le esercitazioni di DR regolari sono l'unico modo per confermare che i backup possano essere ripristinati e che il team sia in grado di rispettare gli obiettivi di RPO e RTO sotto pressione reale.
  • Le policy di conservazione bilanciano i costi di archiviazione con i requisiti di conformità e ripristino.

Un piano di DR sottoposto a test approfonditi è uno degli investimenti più preziosi che un team responsabile di database possa effettuare.

Domande Frequenti

La lezione «Pianificazione del disaster recovery» è gratuita?

Sì — il testo completo di «Pianificazione del disaster recovery» è 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 «Pianificazione del disaster recovery»?

RPO, RTO e runbook. 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 4 di 4.

Quanto tempo richiede la lezione «Pianificazione del disaster recovery»?

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