Un fornitore che avvia il backup presso i suoi clienti vive una progressione in tre tempi. I primi cinque clienti: tutto bene, i rapporti si leggono. I venti successivi: si scorrono. Oltre: non si leggono più, e lo si scopre il giorno in cui un cliente chiede un ripristino su un backup fermo da sei settimane.
Non è un problema di rigore. È un problema di progettazione.
Perché il rapporto quotidiano per posta non tiene
Il modello predefinito di molte soluzioni: ogni backup invia un rapporto, si ricevono tutti, si guardano.
Con cinquanta clienti e tre macchine per cliente, sono centocinquanta messaggi al giorno. Alcuni riflessi nascono da soli: una regola di smistamento li mette in una cartella, poi si consultano «quando c'è tempo», poi non più.
Il vizio di costruzione è qui: il rapporto quotidiano segnala quello che è avvenuto, non quello che non ha avuto luogo. Un backup che fallisce invia un messaggio di errore. Un backup che non parte affatto — postazione spenta, agente rimosso durante un cambio di macchina, servizio arrestato — non invia nulla. Il silenzio è indistinguibile dalla calma.
L'allarme che conta: l'esecuzione mancata
Il punto di svolta arriva quando si rovescia la logica: invece di attendere un segnale di errore, si sorveglia l'assenza di un segnale atteso.
Un allarme di mancata partenza utile ha tre proprietà:
Si regola per macchina, non globalmente. Un portatile che salva tre volte a settimana e un server che salva ogni notte non hanno la stessa soglia. Una soglia unica produce o rumore o punti ciechi.
Tiene conto dei server multipli. Se replica o se ha più server di backup, una postazione che ha salvato altrove non deve far scattare un allarme. Una soluzione che interroga gli altri server prima di allertare le evita i falsi allarmi — e i falsi allarmi sono ciò che uccide una supervisione, perché si finisce per ignorarli tutti.
È consultabile, non soltanto inviato. Un messaggio si perde. Un pannello che mostra gli stati in corso si legge in trenta secondi la mattina.
Il pannello come punto di partenza
L'obiettivo del mattino non è verificare tutto: è sapere in una schermata se c'è qualcosa da fare.
Concretamente, uno stato che distingua le situazioni: errore, avviso, non partito, bloccato, backup in corso, ripristino in corso, replica in corso, controllo di integrità, backup Microsoft 365. Ognuna chiede un'azione diversa — o nessuna.
Il filtraggio per perimetro conta tanto quanto gli stati stessi. Un tecnico che gestisce dieci clienti non deve vederne cinquanta: il rumore rende la vista inutilizzabile.
I diritti per tecnico
È un tema che si rinvia e che diventa bloccante.
Finché si è soli, tutti sono amministratori. Con tre tecnici arrivano le domande: un primo livello deve poter riavviare un backup? Sì, è lo scopo. Modificare una regola di conservazione? No, può cancellare versioni. Ripristinare presso un cliente? Dipende dai casi.
Una granularità fine — dell'ordine di una cinquantina di diritti nominati — permette di rispondere a queste domande una volta, poi di assumere senza riaprire il dibattito. La domanda giusta da porsi: qual è l'azione più distruttiva che questo profilo può innescare?
I rapporti che arrivano al cliente
Due realtà convivono: quello che sorveglia lei, e quello che il suo cliente vede.
Il cliente non ha bisogno delle centocinquanta righe quotidiane. Ha bisogno, a intervalli regolari, di una pagina leggibile che dica che cosa è protetto, su quale profondità, e se tutto va bene. A suo nome, non a quello del produttore: è lei che rende il servizio.
È anche il documento che tira fuori nell'incontro annuale quando le chiedono a cosa serve la voce «backup» della fattura.
Il test di ripristino, da pianificare come un compito
Tutto quanto precede sorveglia che i backup avvengano. Nulla garantisce che siano ripristinabili.
Il test di ripristino è la sola verifica che conta, ed è anche la prima che si abbandona per mancanza di tempo. Due modi per tenere nel tempo:
- Il controllo di integrità automatico lato server, che rilegge i dati e confronta le impronte dopo ogni backup o secondo una regola per macchina. Non sostituisce un ripristino, ma rileva la corruzione silenziosa senza impegnare nessuno.
- Un ripristino reale per cliente e per anno, pianificato come un compito di manutenzione. Un file, una cartella, e una volta ogni due o tre anni un sistema completo presso i clienti critici.
Il secondo punto ha un beneficio commerciale spesso sottovalutato: un verbale di ripristino datato è l'argomento più solido di cui disponga davanti a un concorrente che non ne produrrà nessuno.
Un'organizzazione che tiene
| Frequenza | Che cosa si fa |
|---|---|
| Ogni mattina | Un'occhiata al pannello, filtrato sulle anomalie |
| Ogni settimana | Trattamento delle macchine silenziose e degli avvisi ricorrenti |
| Ogni mese | Revisione dei volumi, delle quote e dello spazio disco residuo |
| Ogni trimestre | Un ripristino di controllo, documentato |
| Ogni anno | Revisione del perimetro con il cliente: che cosa è cambiato nel suo sistema informativo |
L'ultima riga è quella che rende. Un cliente che ha aggiunto un server, un'applicazione di lavoro o una condivisione senza dirglielo ha un buco nella sua protezione — e scoprirlo durante una revisione, anziché durante un sinistro, è ciò che le permette di restare il suo fornitore.
BeBackup è stato progettato da un fornitore informatico per il proprio parco: console multi-cliente, allarmi di mancata partenza calcolati per macchina, diritti fini e rapporti in marchio bianco. Vedere la pagina fornitori oppure chiedere una dimostrazione.