Il backup non è una delle tecnologie di tendenza di cui si grida da ogni ferro. Deve semplicemente essere in qualsiasi azienda seria, tutto qui. Eseguiamo il backup di diverse migliaia di server nella nostra banca: questo è un lavoro complesso e interessante, alcune delle cui sottigliezze, così come le tipiche idee sbagliate sui backup, vogliono solo essere raccontate.
Lavoro su questo argomento da quasi 20 anni, di cui gli ultimi 2 anni presso Promsvyazbank. All'inizio della pratica, eseguivo i backup quasi manualmente, con script che semplicemente copiavano i file. Quindi in Windows sono comparsi strumenti utili: l'utilità Robocopy per preparare i file e NT Backup per la copia. E solo allora arrivò il momento dei software specializzati, in primo luogo Veritas Backup Exec, che ora si chiama Symantec Backup Exec. Quindi conosco i backup da molto tempo.
In termini semplici, il backup consiste nel conservare una copia dei dati (macchine virtuali, applicazioni, database e file) per ogni evenienza con una certa regolarità. Ogni caso di solito si manifesta come un errore hardware o logico e provoca la perdita di dati. Lo scopo di un sistema di backup è ridurre la perdita di informazioni. Un guasto hardware è, ad esempio, un guasto del server o dello storage in cui si trova il database. Logico: questa è la perdita o la modifica di parte dei dati, anche a causa del fattore umano: hanno cancellato accidentalmente una tabella, un file, hanno avviato uno script storto per l'esecuzione. Esistono anche requisiti normativi per la conservazione di un certo tipo di informazioni per un lungo periodo, ad esempio fino a diversi anni.
L'uso più tipico dei backup è il ripristino di una copia salvata dei database per l'implementazione di vari sistemi di test, cloni per gli sviluppatori.
Esistono alcuni miti tipici sul backup che dovrebbero essere sfatati molto tempo fa. Ecco i più famosi.
Mito 1. Il backup è stato per molto tempo solo una piccola funzione all'interno dei sistemi di sicurezza o di archiviazione
I sistemi di backup rimangono ancora una classe di soluzioni separata e molto indipendente. Hanno troppo lavoro da fare. Di fatto, rappresentano l’ultima linea di difesa quando si tratta di integrità dei dati. Pertanto il backup funziona secondo i propri ritmi e secondo la propria pianificazione. Viene generato un report giornaliero per i server, ci sono eventi che fungono da trigger per il sistema di monitoraggio.
Inoltre, il modello di ruolo di accesso al sistema di backup consente di delegare parte dell'autorità agli amministratori dei sistemi di destinazione per gestire i backup.
Mito 2. Quando è presente un RAID, il backup non è più necessario.
Indubbiamente, gli array RAID e la replica dei dati sono un buon modo per proteggere i sistemi informativi da guasti hardware e, se si dispone di un server di standby, è possibile organizzare rapidamente il passaggio ad esso nel caso in cui la macchina principale si guasti.
Dagli errori logici commessi dagli utenti del sistema, la ridondanza e la replica non salvano. Ecco un server di standby di write-back: sì, può essere d'aiuto se viene rilevato un errore prima della sincronizzazione. E se si perde il momento? Solo un backup tempestivo aiuterà qui. Se sai che i dati sono cambiati ieri, puoi ripristinare il sistema all'altro ieri ed estrarne i dati necessari. Dato che gli errori logici sono i più comuni, il buon vecchio backup rimane uno strumento collaudato e necessario.
Mito 3. Un backup è qualcosa che viene fatto una volta al mese.
La frequenza di backup è un'impostazione configurabile che dipende principalmente dai requisiti del sistema di backup. È del tutto possibile trovare dati che non cambiano quasi mai e non sono particolarmente importanti, la loro perdita non sarà fondamentale per l'azienda.
È infatti possibile eseguire il backup una volta al mese e anche meno spesso. Ma i dati più critici vengono salvati più spesso, a seconda dell'indicatore RPO (Recovery point objrective), che imposta la perdita di dati consentita. Può essere una volta alla settimana, una volta al giorno o anche più volte all'ora. Abbiamo questi registri delle transazioni dal DBMS.
Quando i sistemi vengono messi in esercizio commerciale, è necessario approvare la documentazione di backup, che riflette i punti principali, la procedura di aggiornamento, la procedura per ripristinare il sistema, la procedura per l'archiviazione dei backup e simili.
Mito 4. Il volume delle copie è in costante crescita e occupa completamente lo spazio assegnato.
I backup hanno un periodo di conservazione limitato. Non ha senso, ad esempio, archiviare tutti i 365 backup giornalieri durante l’anno. Di norma, è accettabile conservare le copie giornaliere per 2 settimane, dopodiché vengono sostituite con altre nuove e la versione creata per prima nel mese rimane nell'archivio a lungo termine. A sua volta, viene anche archiviato per un certo periodo: ogni copia ha una vita.
Esiste una protezione contro la perdita di dati. Vale la regola: prima che un backup venga cancellato, deve essere formato quello successivo. Pertanto i dati non verranno cancellati se il backup non è stato completato, ad esempio a causa dell'indisponibilità del server. Non solo vengono rispettate le tempistiche, ma viene controllato anche il numero di copie presenti nel set. Se il sistema è progettato per avere due backup completi, ce ne saranno sempre due e quello vecchio verrà eliminato solo quando un nuovo terzo verrà scritto con successo. Pertanto la crescita del volume occupato dall'archivio di backup è associata solo alla crescita della quantità di dati protetti e non dipende dal tempo.
Mito 5. Il backup è iniziato: tutto si è bloccato
È meglio dirlo: se tutto è sospeso, le mani dell'amministratore non crescono da lì. In generale, le prestazioni di un backup dipendono da molti fattori. Ad esempio, dalla velocità del sistema di backup stesso: quanto sono veloci gli archivi su disco e le librerie su nastro. Dalla velocità dei server del sistema di backup: se hanno tempo per elaborare i dati, eseguire compressione e deduplicazione. E anche dalla velocità delle linee di comunicazione tra client e server.
Il backup può essere indirizzato a uno o più flussi, a seconda che il sistema di cui viene eseguito il backup supporti il multithreading. Ad esempio, Oracle DBMS consente di assegnare più thread, in base al numero di processori disponibili, finché la velocità di trasferimento non raggiunge il limite della larghezza di banda della rete.
Se provi a eseguire il backup di un numero elevato di thread, c'è la possibilità di sovraccaricare il sistema in esecuzione, che inizierà davvero a rallentare. Pertanto, viene scelto il numero ottimale di thread per garantire prestazioni sufficienti. Se anche il minimo calo delle prestazioni è critico, allora esiste un'opzione eccellente quando il backup viene eseguito non da un server di combattimento, ma dal suo clone - standby nella terminologia del database. Questo processo non avvia il sistema operativo principale. I dati possono essere recuperati attraverso più flussi, poiché il server non viene utilizzato per la manutenzione.
Nelle grandi organizzazioni viene creata una rete separata per il sistema di backup in modo che il backup non influisca sulla produzione. Inoltre, il traffico potrebbe non essere trasmesso attraverso la rete, ma attraverso la SAN.
Cerchiamo anche di distribuire il carico nel tempo. I backup vengono eseguiti principalmente durante le ore non lavorative: di notte, nei fine settimana. Inoltre, non funzionano tutti contemporaneamente. I backup delle macchine virtuali sono un caso speciale. Il processo non ha praticamente alcun effetto sulle prestazioni della macchina stessa, quindi il backup può essere distribuito durante il giorno e non posticipare tutto di notte. Ci sono molte sottigliezze, se si tiene conto di tutto, il backup non influirà sulle prestazioni dei sistemi.
Mito 6. Lanciato un sistema di backup: per te è tolleranza agli errori
Non dimenticare mai che un sistema di backup è l'ultima linea di difesa, il che significa che dovrebbero esserci altri cinque sistemi davanti ad esso che garantiscano la continuità, l'elevata disponibilità e la tolleranza ai disastri dell'infrastruttura IT e dei sistemi informativi aziendali.
Sperare che il backup ripristinerà tutti i dati e ripristinerà rapidamente il servizio interrotto non vale la pena. La perdita di dati dal momento del backup al momento del guasto è garantita e i dati possono essere caricati su un nuovo server per diverse ore (o giorni, se sei fortunato). Pertanto, ha senso creare sistemi di tolleranza agli errori a tutti gli effetti senza spostare tutto su un backup.
Mito 7. Ho configurato un backup una volta e ho verificato che funzionasse. Resta solo da guardare i registri
Questo è uno dei miti più dannosi, della cui falsità ci si rende conto solo durante l'incidente. I registri di backup riusciti non sono una garanzia che tutto sia andato davvero come dovrebbe. È importante verificare in anticipo la distribubilità della copia salvata. Cioè, avvia il processo di ripristino in un ambiente di test e osserva il risultato.
E qualcosa sul lavoro dell'amministratore di sistema
In modalità manuale, nessuno copia i dati da molto tempo. I moderni SRK possono eseguire il backup di quasi tutto, devi solo configurarlo correttamente. Se è stato aggiunto un nuovo server, imposta le policy: seleziona il contenuto di cui verrà eseguito il backup, specifica le opzioni di archiviazione e applica la pianificazione.
Allo stesso tempo, c’è ancora molto lavoro a causa dell’ampio parco di server, inclusi database, sistemi di posta, cluster di macchine virtuali e condivisioni di file sia su Windows che Linux/Unix. I dipendenti che mantengono attivo il sistema di backup non restano inattivi.
In onore della vacanza, auguro a tutti gli amministratori nervi saldi, chiarezza di movimenti e spazio infinito per archiviare i backup!
Fonte: habr.com