Runbook — Verifica e Test Restore Backup

Pacchetto onboarding IT Gonzato · Fase P2 · IT Manager · v1 03/07/2026 · bozza da compilare in azienda

Scopo

Primo runbook del Gruppo, scelto perché a basso attrito e ad alto valore: verificare che i backup esistano davvero e che un ripristino funzioni. Oggi i backup girano ma non c'è evidenza documentata di un restore riuscito. Questo runbook trasforma "il backup c'è" in "il backup si ripristina, testato il [data]". Rilevante per continuità operativa e NIS 2. Quick-win: dimostra il metodo prima di estenderlo agli altri servizi.

Perimetro di questa esecuzione

• Sistema/dato oggetto del test: [da compilare: es. gestionale ERP / file server produzione]
• Società/sede: [da compilare]
• Backup di riferimento: [da compilare: nome job / repository]
• Tecnologia backup: [da compilare: es. Veeam / NAS snapshot / altro]

Prerequisiti

• ☐ Accesso alla console di backup
• ☐ Ambiente di ripristino disponibile (VM di test o cartella isolata — MAI ripristinare in produzione per il test)
• ☐ Finestra concordata con l'owner del servizio
• ☐ Contatto di riferimento reperibile durante il test

Passi

1. Inventario job. Elencare i job di backup attivi per il sistema in oggetto. Annotare pianificazione, ultima esecuzione, stato (OK/errore/warning).
2. Verifica esiti recenti. Controllare gli ultimi 7 esiti del job. Registrare eventuali fallimenti o warning ricorrenti.
3. Verifica integrità/spazio. Controllare che il repository non sia pieno e che le catene di backup siano complete (nessun punto mancante).
4. Selezione punto di ripristino. Scegliere il restore point da testare (indicativamente l'ultimo valido).
5. Restore in ambiente isolato. Ripristinare un sottoinsieme rappresentativo (es. una VM di test, o un set di file campione) in ambiente separato dalla produzione.
6. Validazione del dato. Verificare che il dato ripristinato sia coerente e apribile (es. il gestionale si avvia, i file si aprono, gli hash coincidono su un campione).
7. Misura tempi. Annotare tempo di ripristino effettivo (utile per l'RTO reale in sla-ola-baseline.md).
8. Pulizia. Rimuovere l'ambiente/dati di test. Verificare di non aver lasciato residui in produzione.
9. Registrazione. Compilare la checklist esito e il registro test qui sotto.

Checklist esito

• ☐ Tutti i job attesi risultano presenti e pianificati
• ☐ Ultimi 7 esiti verificati (nessun fallimento non spiegato)
• ☐ Repository con spazio sufficiente e catena integra
• ☐ Restore point ripristinato con successo in ambiente isolato
• ☐ Dato ripristinato validato (apribile/coerente)
• ☐ Tempo di ripristino misurato e annotato
• ☐ Ambiente di test ripulito
• ☐ Registro test compilato

Esito complessivo: [ ] OK · [ ] OK con riserve · [ ] KO (aprire change/incident)

Registro test restore

Cadenza consigliata

• Test restore su almeno un sistema critico ogni mese (a rotazione tra i servizi Criticità Alta).
• Riportare la ricorrenza in it-operational-calendar.md.
• Ogni KO genera un incident nel ticket-log-lightweight.md e, se comporta modifiche, una riga in change-register.md.