Backup del server: quando una cartella importante resta fuori dal salvataggio
Avere un backup non significa avere tutti i dati al sicuro. Un caso reale mostra perché è fondamentale sapere quali cartelle vengono salvate, chi le controlla e quando viene verificato il ripristino.
In azienda capita spesso che la gestione informatica cresca un pezzo alla volta: un fornitore si occupa dei computer, qualcuno interno segue il server, un’altra persona conserva le password, un backup viene configurato anni prima e poi nessuno lo rimette davvero in discussione.
Finche tutto funziona, questa organizzazione sembra sufficiente. Il problema arriva quando un guasto costringe a ricostruire la situazione reale, non quella che tutti pensavano di avere sotto controllo.
Il caso: server fermo e disco di sistema danneggiato
Un cliente seguito da tempo ci contatta per un problema al server. Fino a quel momento la nostra attività era stata limitata ad assistenza su desktop, stampanti e interventi marginali, mentre la gestione completa dell’infrastruttura informatica era rimasta in mano a risorse interne.
Il guasto riguarda l’hard disk che contiene il sistema operativo, installato sull’unità C:. Quel disco non era configurato in RAID. La richiesta iniziale è semplice: sostituire il disco, reinstallare il sistema, rimettere i PC in dominio e recuperare i dati dal backup.
Il backup effettivamente esisteva. L’unità D: risultava salvata regolarmente e il ripristino dei dati presenti li è andato a buon fine. Dal punto di vista tecnico, l’intervento sembrava concluso correttamente.
La cartella che nessuno sapeva fosse su C:
Dopo qualche giorno arriva una nuova chiamata: manca una cartella fondamentale per l’azienda. A quel punto viene fatta una verifica più approfondita, ricostruendo dove fosse realmente salvata quella cartella e quali percorsi fossero inclusi nel backup.
La conclusione è amara: la cartella non era sull’unità D:,cioè quella backuppata, ma sull’unità C:. Proprio il disco danneggiato. Nessun backup disponibile, nessuna copia alternativa documentata.
Il recupero dati non è un piano di backup
Il cliente decide di portare il disco presso un centro specializzato nel recupero dati. E’ una strada possibile, ma non può essere considerata una garanzia: i costi possono essere molto alti e il risultato dipende dalle condizioni fisiche del supporto.
In questo caso la risposta finale è stata la peggiore: hard disk seriamente danneggiato e dati non recuperabili. Una cartella aziendale importante e andata persa non per assenza totale di backup, ma perché il backup non copriva tutto ciò che l’azienda considerava importante.
Avere un backup non significa sapere cosa si sta salvando
La frase “abbiamo il backup” da sola non basta. Bisogna sapere quali dischi, quali cartelle, quali applicazioni e quali database sono inclusi nel salvataggio. Serve anche sapere ogni quanto viene eseguito, dove viene conservato e se il ripristino è stato testato.
Una cartella fuori percorso, un gestionale spostato su C:, un archivio creato sul desktop del server o una condivisione non documentata possono trasformare un backup apparentemente corretto in una protezione solo parziale.
Il RAID non sostituisce il backup
In questo caso il disco di sistema non era in RAID, quindi il guasto ha fermato subito il server. Ma anche con un RAID correttamente configurato il problema della cartella non protetta sarebbe rimasto: il RAID aiuta a garantire continuità in caso di guasto di un disco, ma non protegge da cancellazioni, errori umani, ransomware, corruzione dei file o cartelle escluse dal backup.
Per questo backup, ridondanza e monitoraggio sono tre elementi diversi. Devono lavorare insieme, ma non sono intercambiabili.
Cosa controllare prima che succeda un guasto
La prevenzione parte da una mappa chiara dell’infrastruttura. Per ogni server andrebbero documentati ruoli, dischi, cartelle condivise, database, percorsi dei gestionali, utenti autorizzati e destinazioni di backup.
- Verificare quali unità e cartelle sono incluse nel backup.
- Controllare se esistono dati importanti su C:, desktop del server o percorsi locali non condivisi.
- Tenere traccia di chi può creare nuove cartelle o spostare archivi aziendali.
- Configurare notifiche di errore e controlli periodici dei job di backup.
- Eseguire test di ripristino, non solo controllare che il backup risulti “completato”.
Anche Microsoft, nella documentazione di Windows Server Backup, distingue il semplice salvataggio dalla possibilità di ripristinare file, cartelle, volumi e server. Il valore di un backup si misura nel momento in cui serve davvero recuperare qualcosa.
La responsabilità deve essere chiara
Quando la gestione informatica è divisa tra più persone, il rischio maggiore e che ognuno pensi che un controllo sia stato fatto da qualcun altro. Non basta avere “qualcuno che segue il server”: serve una responsabilità chiara su backup, aggiornamenti, sicurezza, accessi e documentazione.
Un fornitore esterno può intervenire in emergenza, ma se non ha visibilità completa dell’infrastruttura non può garantire ciò che non conosce. Per questo è importante definire perimetro, accessi, procedure e controlli prima del problema, non durante il fermo macchina.
La morale della storia
La morale è semplice: un backup non è una sensazione di sicurezza, è una procedura verificabile. Se non sappiamo cosa viene salvato, dove si trovano davvero i dati critici e come ripristinarli, il backup esiste solo sulla carta.
Per un’azienda, perdere una cartella fondamentale può costare molto più di un controllo periodico. Nei servizi di sicurezza, protezione e recupero dati, la parte più importante non e intervenire quando il disco è già danneggiato, ma costruire prima un sistema in cui le informazioni essenziali non restino fuori dal salvataggio.
Se sei interessato ad un supporto tecnico informatico visualizza più informazioni su Pacchetti di Assistenza Informatica per Aziende a Roma e contattaci per avere un preventivo gratuito.