Il backup non è una moda tecnologica di cui si parla in continuazione. Deve semplicemente far parte di qualsiasi azienda seria, e basta. Nel nostro istituto, facciamo il backup di diverse migliaia di server – è un lavoro complesso e interessante, di cui vorrei parlare riguardo alcune sottigliezze e le tipiche misconceptions sul backup.
Mi occupo di questo tema da quasi 20 anni, di cui gli ultimi 2 anni – in Promsvyazbank. All'inizio della mia carriera, eseguivo i backup praticamente a mano, con script che copiavano semplicemente i file. Poi in Windows sono comparsi strumenti più comodi: l'utilità Robocopy per preparare i file e NT Backup per il copia. Solo in seguito è arrivato il momento del software specializzato, in particolare Veritas Backup Exec, ora conosciuto come Symantec Backup Exec. Quindi ho una lunga esperienza con i backup.
In termini semplici, il backup è la conservazione di una copia dei dati (di macchine virtuali, applicazioni, database e file) con una certa regolarità per ogni evenienza. Queste evenienze si manifestano solitamente come guasti hardware o logici, portando alla perdita di dati. L'obiettivo del sistema di backup è ridurre al minimo le perdite causate dalla perdita di informazioni. Un guasto hardware è, ad esempio, un malfunzionamento del server o dello storage dove risiede il database. Il guasto logico, invece, implica la perdita o la modifica di una parte dei dati, anche a causa di errori umani: ad esempio, la cancellazione accidentale di una tabella o di un file, o l'esecuzione di uno script errato. Ci sono anche requisiti normativi per la conservazione di determinati tipi di informazioni per un lungo periodo, ad esempio fino a diversi anni.
La richiesta più comune riguardante i backup è il recupero di una copia salvata di database per l'implementazione di vari sistemi di test, cloni per sviluppatori.
Attorno al backup circolano diversi miti comuni che è tempo di sfatare. Ecco i più noti.
Mito 1. Il backup è già da tempo una semplice funzione all'interno dei sistemi di sicurezza o di archiviazione.
I sistemi di backup continuano a rappresentare una categoria a sé stante di soluzioni, e sono piuttosto indipendenti. È un compito di fondamentale importanza quello che hanno. Fondamentalmente, essi sono l'ultima linea di difesa quando si tratta di protezione dei dati. Pertanto, il backup opera al suo ritmo, secondo un proprio programma. Viene redatto un report quotidiano sui server, con eventi che fungono da attivatori per il sistema di monitoraggio.
Inoltre, il modello di accesso al sistema di backup consente di delegare parte delle responsabilità agli amministratori dei sistemi target per la gestione dei backup.
Mito 2. Quando c'è il RAID, il backup non è più necessario.
Certamente, i dispositivi RAID e la replicazione dei dati sono un buon modo per proteggere i sistemi informatici da guasti hardware, e con un server di standby disponibile, è possibile organizzare rapidamente il passaggio a quest'ultimo in caso di guasto della macchina principale.
Le logiche errori commesse dagli utenti del sistema non possono essere salvate da ridondanza e replica. Ecco un server standby con scrittura in attesa – sì, può aiutare se l'errore viene rilevato prima che venga sincronizzato. E se si perde il momento? Qui può aiutare solo un backup effettuato in tempo. Se si sa che i dati sono stati modificati ieri, è possibile ripristinare il sistema allo stato di ieri e recuperare i dati necessari. Considerando che le errori logiche sono le più comuni, un vecchio e fidato backup rimane uno strumento fondamentale e necessario.
Mito 3. Il backup è qualcosa che si fa una volta al mese.
La frequenza del backup è un parametro configurabile, principalmente dipendente dai requisiti del sistema di backup. È del tutto possibile trovare dati che praticamente non cambiano mai e non sono particolarmente importanti, la loro perdita non sarà critica per l'azienda.
Possono essere eseguiti backup una volta al mese e anche meno frequentemente. Tuttavia, i dati più critici vengono salvati con maggiore frequenza, in base al RPO (Recovery Point Objective), che stabilisce la perdita di dati accettabile. Questo può avvenire una volta a settimana, una volta al giorno o addirittura più volte all'ora. Noi utilizziamo ad esempio i registri delle transazioni del sistema di gestione del database.
Quando si implementano sistemi in un ambiente di produzione, è necessaria l'approvazione della documentazione sui backup, che evidenzia i punti principali, le regole di aggiornamento, le procedure di ripristino del sistema, le modalità di archiviazione dei backup e così via.
Mito 4. Il volume dei backup cresce incessantemente e occupa completamente qualsiasi spazio assegnato.
I backup hanno una durata di conservazione limitata. Non ha senso, ad esempio, conservare tutti i 365 backup giornalieri per un anno. Di solito, è consentito mantenere i backup quotidiani per 2 settimane, dopodiché vengono sostituiti con versioni fresche, mentre rimane per una conservazione a lungo termine la versione realizzata per prima nel mese. Anche questa, a sua volta, ha un tempo di vita definito.
Esiste una protezione contro la perdita di dati. La regola è: prima che un backup venga eliminato, deve essere creato il successivo. Quindi, i dati non verranno eliminati se il backup non è stato completato, ad esempio a causa dell'inaccessibilità del server. Non solo vengono rispettati i tempi, ma viene anche controllato il numero di copie nel set. Se il sistema prevede che debbano esserci due backup completi, ce ne saranno sempre due, e il vecchio verrà eliminato solo quando sarà registrato con successo un nuovo terzo. Pertanto, l'aumento dello spazio occupato dall'archivio dei backup è legato solo alla crescita della quantità di dati protetti e non dipende dal tempo.
Mito 5. È iniziato il backup – tutto si è bloccato
Meglio dire così: se tutto si è bloccato, significa che l'amministratore non sta agendo correttamente. In generale, le prestazioni del backup dipendono da molti fattori. Ad esempio, dalla velocità del sistema di backup stesso: quanto sono veloci gli storage, le librerie a nastro. Dalla velocità server del sistema di backup: se riescono a elaborare i dati, a eseguire la compressione e la deduplicazione. Inoltre, dalla velocità delle linee di comunicazione tra il client e il server.
Il backup può avvenire in uno o più flussi, a seconda che il sistema riservato supporti il multithreading. Ad esempio, il DBMS Oracle consente di gestire più flussi, in base al numero di processori disponibili, fino a quando la velocità di trasferimento non raggiunge il limite di banda della rete.
Se si tenta di eseguire il backup con un numero elevato di flussi, c'è il rischio di sovraccaricare il sistema in esecuzione, e potrebbe effettivamente iniziare a rallentare. Pertanto, si sceglie un numero ottimale di flussi per garantire prestazioni adeguate. Se anche una minima riduzione delle prestazioni è critica, esiste un'ottima opzione in cui il backup viene eseguito non dal server di produzione, ma dalla sua copia – standby nella terminologia dei database. Questo processo non carica il sistema di lavoro principale. I dati possono essere estratti attraverso un numero maggiore di flussi poiché il server non è utilizzato per la gestione.
Nelle grandi organizzazioni, viene creato un network separato per il sistema di backup, affinché il backup non influisca sul produttivo. Inoltre, il traffico può essere trasmesso non tramite rete, ma attraverso SAN.
Ci sforziamo di distribuire il carico anche nel tempo. I backup avvengono principalmente durante le ore non lavorative: di notte e nei fine settimana. Inoltre, non vengono avviati tutti contemporaneamente. I backup delle macchine virtuali sono un caso particolare. Il processo influisce praticamente poco sulle prestazioni della macchina stessa, quindi è possibile pianificare i backup anche durante il giorno, senza dover rimandare tutto alla notte. Ci sono molte sfumature da considerare; se tutto viene tenuto in conto, il backup non inciderà sulle prestazioni dei sistemi.
Mito 6. Ho avviato il sistema di backup – ed ecco la tolleranza agli errori.
Non dimenticate mai che il sistema di backup è l'ultima linea di difesa, e quindi deve esserci anche un paio di sistemi che garantiscono la continuità, l'alta disponibilità e la resilienza delle IT infrastructure e dei sistemi informativi dell'azienda.
Sperare che il backup ripristini tutti i dati e rimetta in funzione rapidamente il servizio non è realistico. È garantita la perdita di dati dal momento del backup fino al momento del guasto, e i dati su un nuovo server possono richiedere diverse ore (o giorni, a seconda delle circostanze) per essere caricati. Pertanto, ha senso creare sistemi di alta disponibilità completi, senza fare affidamento esclusivamente sui backup.
Mito 7. Ho impostato il backup una volta, ho verificato che funzioni. Resta solo da controllare i log.
Questo è uno dei miti più dannosi, e ci si rende conto della sua falsità solo durante un incidente. I log che attestano il successo del backup non garantiscono che tutto sia andato realmente come previsto. È importante verificare in anticipo la capacità di ripristino della copia salvata. Ciò significa avviare il processo di recupero in un ambiente di test e osservare il risultato.
E un po' sul lavoro dell'amministratore di sistema.
In modalità manuale, nessuno copia più i dati da tempo. I moderni sistemi di gestione delle configurazioni (CM) sono capaci di effettuare backup praticamente di tutto, basta configurarli correttamente. Se si aggiunge un nuovo server, è necessario definire le politiche: scegliere i contenuti da sottoporre a backup, specificare i parametri di archiviazione e applicare un programma.
Nonostante ciò, il lavoro rimane consistente a causa dell'ampio parco server, che include database, sistemi di posta elettronica, cluster di macchine virtuali e risorse file sia su Windows che su Linux/Unix. Gli operatori che mantengono la funzionalità del sistema di backup non rimangono inattivi.
In occasione della festività, desidero augurare a tutti gli amministratori nervi saldi, movimenti precisi e uno spazio infinito per l'archiviazione dei backup!
Fonte: habr.com
