Hai già un sistema di backup: come tenerlo sotto controllo

Se hai già un sistema di backup attivo, la scelta più sensata raramente è sostituirlo: è sorvegliarlo in modo continuo. I segnali di degrado — job che falliscono e si ripetono, punti di recupero che invecchiano, conservazione che si accorcia, prove di ripristino rimandate — si possono osservare sulla piattaforma che usi già, organizzando controlli, segnalazioni e responsabilità. Questa guida spiega cosa sorvegliare e chi deve ricevere gli avvisi, senza cambiare strumento.

Il backup c'è: il problema è fidarsi alla cieca

Una soluzione di backup installata anni fa e mai rivista tende a scollare dalla realtà che protegge. I server cambiano, le cartelle si spostano, i database crescono, le persone che avevano configurato i job cambiano ruolo o azienda. Il sistema continua a «funzionare» nel senso che esegue qualcosa ogni notte, ma ciò che esegue può non corrispondere più a ciò che ti serve.

Fidarsi alla cieca significa tre cose concrete: nessuno legge i rapporti di esito oltre la riga «completato»; nessuno confronta la configurazione attuale con ciò che andrebbe protetto oggi; nessuno ha aperto una copia o tentato un ripristino da troppo tempo. Il rimedio non è un nuovo prodotto: è una routine di controllo su quello che hai. Se il dubbio riguarda proprio il significato del messaggio di esito, l'approfondimento è in backup completato con successo: cosa controlla davvero.

I segnali che il backup sta degradando

Questi segnali sono osservabili su quasi ogni piattaforma di backup, senza strumenti aggiuntivi. Se ne riconosci più di uno, la sorveglianza attuale non basta:

• Fallimenti ripetuti sullo stesso job. Un errore una tantum capita; lo stesso errore per giorni consecutivi indica una causa mai affrontata.
• Punto di recupero che invecchia. L'ultima copia utile risale a più tempo fa dell'obiettivo concordato: quanti dati puoi permetterti di perdere (RPO, Recovery Point Objective) è una scelta tua, ma va misurata, non supposta.
• Selezione ferma nel tempo. Server, cartelle o applicativi nuovi non compaiono nella configurazione: il backup protegge l'azienda di due anni fa.
• Conservazione più corta del previsto. Le copie vecchie vengono eliminate prima di quanto credi, per spazio o policy mai riviste; sul tema vedi retention dei backup: quanto conservare le copie.
• Prove di ripristino sempre rimandate. Se nessuno ha ripristinato nulla di recente, la fiducia nel sistema è un'ipotesi.
• Rapporti letti da nessuno. Gli esiti vengono inviati a un indirizzo che non apre più nessuno, o archiviati senza controllo.

Cosa sorvegliare: esiti, scostamenti, conservazione, prove

Organizzare la sorveglianza continua significa trasformare i segnali in una routine con proprietario e cadenza. Quattro aree coprono l'essenziale:

1. Esiti dei job

Non solo «riuscito/fallito», ma il dettaglio: avvisi, elementi saltati, durata anomala. Un job che raddoppia il tempo di esecuzione in un mese sta dicendo qualcosa sul volume dei dati o sullo stato della rete. Definisci chi guarda gli esiti e con che frequenza.

2. Scostamenti dalla situazione attesa

Lo scostamento è più informativo del singolo evento: copertura che si riduce, punto di recupero che invecchia, dimensioni delle copie che calano senza una causa nota. Per osservarli serve una linea di riferimento — com'era la situazione «normale» — e qualcuno o qualcosa che confronti il presente con quella linea.

3. Conservazione e integrità

Verifica che la conservazione effettiva corrisponda a quella dichiarata e che le copie siano protette come richiede il tuo scenario di rischio. Se il timore è che le copie possano essere modificate o cancellate — per esempio in caso di ransomware — il requisito da verificare presso il fornitore è l'immutabilità: vedi backup immutabile: le verifiche da fare.

4. Prove di ripristino

La prova di ripristino è il controllo che chiude il cerchio: dimostra che la copia diventa di nuovo un servizio funzionante. Cadenza e ambito vanno concordati in base a rischio e cambiamenti, non fissati come regola universale; il metodo è in come programmare le prove di ripristino. Il NIST Cybersecurity Framework 2.0, nelle risorse dedicate alle piccole e medie imprese, colloca il recupero tra le funzioni fondamentali della gestione del rischio: testare i backup e riesaminarli è parte di quel lavoro, come ricorda anche la guida NIST SP 1339 sui backup in ambito industriale.

Esempio illustrativo: le segnalazioni che nessuno leggeva

Esempio illustrativo. Lo scenario seguente è inventato per mostrare il ragionamento; non racconta un caso avvenuto presso un cliente.

Un'impresa di installazione e manutenzione impianti, una quindicina di dipendenti, ha un backup gestito da un rivenditore informatico, con rapporto settimanale via email. Il rapporto arriva al titolare, che lo archivia: «tanto se qualcosa non va, mi chiamano». In autunno il job del gestionale inizia a fallire ogni notte, mentre quello dei documenti continua a riuscire: il rapporto settimanale mostra «5 job su 6 riusciti», una riga verde tra tante. Nessuno la apre.

Nove giorni dopo, un errore umano cancella gli ordini della settimana dal gestionale. Il ripristino parte dalla copia di nove giorni prima: si recupera l'archivio, ma gli ordini inseriti nel frattempo vanno ricostruiti da email e appunti, con due giornate di lavoro extra. La revisione successiva cambia poche cose, ma decisive: gli esiti arrivano a una persona nominata; i fallimenti consecutivi generano una chiamata, non una riga; una volta al trimestre si ripristina davvero qualcosa, a rotazione tra i sistemi critici. La piattaforma di backup non è cambiata: è cambiato chi la guarda.

Segnalazioni e proposte: chi decide cosa

La sorveglianza funziona se ogni segnalazione ha un destinatario e una soglia. Uno schema pratico: avvisi informativi (durate in crescita, spazio in calo) al responsabile IT con cadenza di riepilogo; anomalie che riducono la copertura (job falliti, punto di recupero oltre obiettivo) come segnalazione immediata a una persona nominata; prove di ripristino e modifiche alla configurazione come decisioni pianificate, con responsabile e registrazione dell'esito.

OverZeus si inserisce in questo schema senza sostituire la tua piattaforma, tramite le integrazioni concordate con gli strumenti già in uso. Due agenti sono pertinenti:

• Penelope sorveglia backup, conservazione e preparazione al ripristino attraverso le piattaforme collegate. Non è un motore di backup nativo: non esegue le copie e non ripristina direttamente i dati. Osserva esiti e punti di recupero, segnala ciò che rischia di non essere coperto e può proporre un nuovo tentativo o una prova di ripristino in ambiente isolato; l'avvio avviene solo con le autorizzazioni della piattaforma di backup e dopo la tua approvazione.
• Argus osserva eventi, servizi e dispositivi collegati ed evidenzia gli scostamenti dalla situazione attesa: è il suo modo di rendere visibile un degrado progressivo, prima che diventi un'emergenza.

Il modello decisionale resta lo stesso in ogni caso: segnale, contesto, proposta con le conseguenze, approvazione prevista prima di un intervento attivo. Il silenzio non autorizza: se nessuno risponde, non parte alcuna azione. E ogni decisione resta tracciata, così tra sei mesi puoi ricostruire chi ha deciso cosa e perché. Se gestisci anche continuità tra CED e sedi distaccate, il quadro si allarga: vedi pianificare lo scenario degradato tra CED e sedi remote.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus