Cosa fare se…
Il backup di stanotte non è riuscito
Un backup non riuscito per una notte non è un disastro, è un ritardo: l’ultima copia integra ha almeno 48 ore se quella del giorno prima era riuscita. Più errori consecutivi sono un incidente di protezione: se ne cerca la causa il giorno stesso, non ci si limita a confermare l’allarme.
Aggiornato a ottobre 20263 min di lettura5 fonti citate
In sintesi
- Leggete il messaggio di errore, non solo la spia rossa: spazio, origine assente, credenziali, file bloccati, banda, agente arrestato.
- Un job «riuscito» può aver copiato una cartella vuota: controllate la dimensione copiata.
- Annotate la data dell’ultimo backup riuscito e comunicatela al responsabile del servizio interessato.
- Rilanciate dopo la correzione, poi verificate la notte successiva.
- Tre errori in un mese sulla stessa macchina: cambiate la configurazione, non limitatevi al pulsante «rilancia».
1. Leggere l’errore, non solo la spia rossa
Le cause più comuni, nell’ordine in cui si presentano:
| Causa | Segnale | Correzione |
|---|---|---|
| Spazio esaurito sulla destinazione, o quota raggiunta | Errore di scrittura, conservazione che si accorcia | Aumentare il volume, o accorciare la cronologia con cognizione di causa |
| Origine spenta, fuori rete, percorso modificato | Lettera di unità o condivisione rinominata; job «riuscito» su una cartella vuota | Ripristinare l’origine, correggere il percorso, verificare la dimensione copiata |
| Credenziali rifiutate | Password dell’account di servizio scaduta | Ripristinare l’account: altrimenti, tutte le notti falliranno |
| File bloccati o database non messo in stato di quiescenza | Copia parziale | Usare il metodo previsto per i database aperti; un database SQL in questo stato non è ripristinabile correttamente |
| Collegamento troppo lento o interrotto | Job interrotto a fine finestra | Incrementale più efficiente, finestra più lunga, o meno dati inutili |
| Agente arrestato sulla macchina | Nessun invio | Riavviare il servizio, capire perché si è arrestato |
Il caso più ingannevole è il job verde su una cartella vuota. L’ANSSI, l’agenzia nazionale per la cybersicurezza francese, chiede che il backup sia sistematicamente oggetto di controllo, monitorando in particolare un volume di dati o di file incoerente, rallentamenti di rete e modifiche di configurazione. Una dimensione copiata che crolla bruscamente da una notte all’altra merita la stessa attenzione di un errore.
2. Sapere a quando risale l’ultimo backup riuscito
È l’unica data che conta per l’RPO del giorno. Se risale a più di qualche giorno fa, comunicatelo alla persona responsabile del servizio interessato. Sta lavorando senza rete di sicurezza e deve saperlo. Confermare l’allarme nella console senza questa comunicazione è il gesto che trasforma un incidente in una perdita di dati due settimane dopo.
3. Rilanciare dopo la correzione
Rilanciate un job manuale una volta risolta la causa. Attendete che termini. Se il rilancio fallisce, la causa è ancora presente. La mattina dopo, verificate la notte successiva: molte correzioni «ovvie» non superano il secondo passaggio.
Un job riuscito dimostra che una copia è stata scritta, non che sia ripristinabile. Per un database SQL Server, Microsoft precisa che il comando di verifica di un backup non controlla la struttura dei dati che contiene. L’ANSSI chiede che i backup siano testati regolarmente, con una procedura di ripristino scritta; anche il NIST raccomanda di testare i backup per assicurarsi che i file si recuperino senza errori. Dopo un incidente di backup, un ripristino di prova di un file o di un database è il controllo migliore. Vedere Come verificare che un backup funzioni?.
4. Se si ripete
Tre errori in un mese sulla stessa macchina: il perimetro, la banda o il prodotto non sono adeguati. Si cambia un parametro (escludere una cartella enorme e inutile, suddividere il job, aumentare lo storage), non ci si limita a rilanciare manualmente ogni lunedì.
Checklist del mattino
- Tutti i job della notte sono terminati, e non solo «senza errori»?
- La dimensione copiata è coerente con quella delle notti precedenti?
- La data dell’ultimo backup riuscito di ogni macchina critica è inferiore a 24 ore?
- Gli allarmi sono stati letti da una persona designata, e non solo ricevuti?
- Lo spazio residuo sulla destinazione copre la conservazione prevista?
Con WeDoBack
Il monitoraggio 24 ore su 24 riguarda i backup e invia un allarme quando un backup non va a buon fine. L’allarme è l’inizio di questa pagina, non la fine. Con INTEGRAL, due ore di assistenza al mese possono servire a risolvere la causa. Con SMART, l’assistenza è fatturata a intervento: l’errore resta visibile al cliente nella console, ed è compito suo leggerlo. L’assistenza è raggiungibile al +33 9 72 50 78 28, dalle 9:00 alle 13:00 e dalle 14:00 alle 17:30 (ora di Parigi). Per dimensionare lo storage, l’ordine di grandezza indicato è il volume attuale moltiplicato per tre, con un adeguamento dopo una settimana di utilizzo: un volume troppo ridotto si nota dai job che falliscono o da una conservazione che si accorcia. La chiave di cifratura, custodita dal cliente, non ha alcun ruolo nel mancato invio: se il job fallisce, la copia remota semplicemente non è stata aggiornata.
Domande frequenti
Una notte di errore è grave?
Raramente, se la notte precedente il backup è riuscito e la causa viene corretta in giornata. Il rischio deriva dall’accumulo: ogni notte di errore aumenta la quantità di lavoro che andrebbe persa in caso di disastro. Oltre qualche giorno, è un incidente da segnalare alla direzione.
Lo stato «riuscito» basta a dimostrare che un backup è valido?
No. L’ANSSI chiede un controllo sistematico dei backup, in particolare dei volumi di dati incoerenti, e test di ripristino regolari. Per SQL Server, Microsoft precisa che la verifica di un backup non controlla la struttura dei dati che contiene: solo un ripristino reale, seguito da un controllo di coerenza, lo dimostra.
Chi deve monitorare gli allarmi di backup?
Una persona designata, con un sostituto per le ferie. Un allarme che arriva in una casella condivisa che nessuno legge equivale a nessun allarme. Decidete anche chi avvisa la direzione quando l’ultimo backup riuscito supera una soglia concordata in anticipo.
Fonti
Documenti consultati a ottobre 2026.
- Backup dei sistemi informativi – I fondamentali (ANSSI-BP-100, v1.1, 27 novembre 2025, in francese) — ANSSI (agenzia francese)
- Cybersecurity guide for SMEs (in inglese, giugno 2021) — ENISA
- RESTORE VERIFYONLY (Transact-SQL) — Microsoft Learn
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Offerte e prezzi — WeDoBack
Ha bisogno di aiuto adesso?
Non ripristini nulla prima di aver individuato una copia integra. Possiamo guidarLa.
Chiami il +33 9 72 50 78 28oppure ci scrivaUn incidente in corso?
I nostri team La aiutano a individuare la copia giusta e a ripristinarla, dal lunedì al venerdì dalle 9:00 alle 13:00 e dalle 14:00 alle 17:30 (ora di Parigi).
