Cliffhanger: I backup sono proprio ... qui ... giusto?

Nel mio lavoro, i backup hanno una priorità sorprendentemente bassa. La strategia di backup è stata implementata qualche tempo fa e da allora si presume che i backup vadano bene. Se chiedi agli amministratori di sistema, diranno che è stato eseguito il backup di tutto.

Ma poi, quando chiedi un backup SPECIFICO, la metà delle volte non ci sono:

• Il disco si è riempito
• Il nastro non è riuscito
• Sembra che qualcuno abbia disabilitato il processo di backup
• La connessione di rete ha avuto tempi di inattività
• Abbiamo ordinato quel disco anni fa, ma la finanza non ha approvato l'ordine d'acquisto
• I file sono corrotti
• Il file contiene un database errato
• Solo backup del registro delle transazioni (inutili senza uno completo)

Alcune settimane fa, il disastro si è avvicinato molto quando uno dei server ha perso troppi dischi raid. Fortunatamente un disco era ancora abbastanza gentile da copiare i dati, se ci provavi molte volte.

Ma anche dopo quel quasi disastro, non riesco a convincere gli amministratori di sistema a migliorare la situazione. Quindi mi chiedo, qualche consiglio per aprire gli occhi alle persone? Mi sembra che stiamo camminando lungo il bordo di una scogliera.

Devi sempre sistemare queste cose dall'alto.

L'attuale strategia di backup è supportata e compresa dalla direzione? Altrimenti, è inutile.

Il management esecutivo deve conoscere i problemi e quali sono i rischi (perdita di dati finanziari che è necessario divulgare legalmente per sopravvivere o dati dei clienti che hanno impiegato anni per essere raccolti?) E soppesarli nel decidere le azioni o nel decidere permettere a qualcuno (come te) di agire.

Se non riesci a raggiungere la direzione, prova i controllori aziendali o altre posizioni finanziarie in cui il recupero dei dati e la sua integrità sono di grande importanza per i rapporti dell'azienda. A loro volta possono "iniziare la tempesta" se necessario ...

Da dove cominciare? Questo è un disastro in attesa di accadere. Una funzione di lavoro principale di Sysadmins è garantire il backup e il recupero dei dati. Tutto il resto è secondario. No se è no ma è.

Ecco alcune cose che puoi fare:

1. Traccia i KPI per i ripristini. Dovrebbe essere possibile produrre un rapporto che mostri quante richieste di ripristino hanno avuto esito positivo. Qualunque cosa inferiore al 100% dovrebbe essere studiata a fondo. Rapporti d'amore della direzione e questa è una prova concreta.

2. Dovrebbero esserci procedure documentate per tutte le operazioni di backup e ripristino, inclusi tutti i sistemi e la loro strategia di backup, rotazioni del nastro, pianificazioni, percorsi di escalation, ripristini di test ecc. Chiedere di vederli.

3. Parla con il gestore degli amministratori di sistema e dai voce alle tue preoccupazioni. Diventa armato con la prova che i ripristini non funzionano. Se nessuna gioia va più in alto.

Scherzi a parte - fai esplodere un clamore. Roba del genere può distruggere un'azienda.

Proporre (almeno) test annuali di ripristino di emergenza. Il lavoro richiesto per eseguire correttamente il test dovrebbe rivelare carenze.

Nel luogo in cui lavoro abbiamo un dipartimento IT davvero valido, ogni anno si riuniscono da ogni ufficio in Europa e organizzano un "ripristino fest" su server noleggiati in un datacenter, simulando efficacemente cosa accadrebbe se il personale venisse a lavorare un giorno e trovasse l'ufficio si era bruciato durante la notte.

Coinvolgi il grande capo, ricordagli che se un disastro colpisse, quell'anno (o peggio!) Sarebbe fuori di un bonus e quindi forse sarebbe prudente organizzare un simile esercizio di recupero da disastro. Non dovrebbe richiedere molto tempo o costare molto: gli amministratori vengono mandati via con i loro nastri di backup fuori sede e gli viene detto di far emergere un ambiente d'ufficio identico.

Quindi siediti e guarda l'IT migliorare: una volta che la direzione si rende conto che i dati dell'azienda sono pericolosamente vicini alla perdita permanente, le scintille voleranno (dai razzi che saranno posizionati strategicamente in detti amministratori)

È facile incolpare gli amministratori - comunque Oskar ha ragione: queste cose sono guidate dall'alto. Se la gestione non spende i soldi per rendere prioritari i backup, gli amministratori di sistema di solito sono sfortunati e fanno il meglio che possono con le risorse che hanno.

La chiave, se sei uno di quegli sfortunati amministratori - e sono stato su questa barca per alcuni impegni con i clienti - è che tu assicuri che la gestione sia informata, ripetutamente e in modo confermabile su carta, che questo è un rischio per l'azienda.

La mia strategia è di martellare costantemente i problemi. Se lo fai, a volte i problemi verranno risolti, ma è soprattutto in modo che chiunque riferisca di non nascondersi dietro la scusa "Non sono mai stato informato". Come consulente, di solito posso fare di meglio. Riesco a convincere i miei capi a informare più alti dirigenti di quanto possa esserci una vulnerabilità. Questo diffonde la colpa, o almeno la concentra a un livello più alto di me.

Allo stesso tempo devi essere creativo e lavorare sodo per ridurre al minimo i rischi con qualunque risorsa il cliente possa fornire.

Mentre in alcuni casi gli amministratori possono essere colpevoli, la gestione è sempre responsabile: o per conoscere il rischio e non fare abbastanza per mitigarlo, o assumere persone che non li avvertono di questi rischi.

Sono responsabile di circa 200 server sparsi nel nord-ovest del Regno Unito, e questo è ovviamente troppo per verificarli manualmente.

Configuro il backup in modo che al termine esegua uno script (VBScript) che controlli il registro di backup, capisca se il backup ha funzionato o meno e scrive un record in un database centrale con il risultato del backup. Quindi, presso la sede centrale, eseguo uno script che interroga questo database e mi presenta un elenco di siti in cui il backup ha segnalato un errore o non vi è stato alcun rapporto dal sito.

Il risultato finale è che quando mi siedo alla mia scrivania ho un elenco di tutti i siti in cui devo controllare il backup.

Il punto di tutto ciò è che il presupposto predefinito è che il backup non è riuscito e si ritiene che il backup abbia funzionato solo se il mio VBScript non ha rilevato errori e ha scritto questa conclusione nel mio database. Questo assicura che gli errori di backup non passino inosservati.

Alcuni server utilizzano Backup Exec, altri NTBackup e altri semplicemente copiano i loro file su un altro server attraverso la rete. Non importa quale tipo di backup eseguano i server in quanto è facile modificare il mio VBScript per verificare la presenza di errori. Il mio script è in realtà piuttosto semplice, apre solo il rapporto di backup come file di testo e greps per frasi come "errore di montaggio", "nastro pieno", "errore CRC" ecc. Ecc. Sono sicuro che un programmatore professionista farebbe un lavoro da sgranocchiare. Tuttavia, il tutto è semplice e robusto ed è proattivo nel senso che vedo il rapporto di errore di backup se lo voglio o no e non riuscirei a notare un errore solo se avessi deliberatamente ignorato il rapporto.

JR

PS Il 99% degli errori di backup è dovuto al fatto che gli utenti hanno dimenticato di cambiare il nastro di backup. Non ti piacciono solo gli utenti :-)

Un backup non testato non è affatto un backup.