Il backup non è una tecnologia di moda di cui si parla in continuazione. Deve semplicemente essere presente in ogni azienda seria, e basta. Nella nostra banca, eseguiamo il backup di diverse migliaia di server - è un lavoro complesso e interessante, di alcune sfumature di cui vorrei proprio parlare, così come dei miti comuni riguardo ai backup.
Mi occupo di questo tema da quasi 20 anni, dei quali gli ultimi 2 anni – in Promsvyazbank. All'inizio della mia carriera, effettuavo backup praticamente manualmente, utilizzando script che copiavano semplicemente i file. Poi in Windows sono stati introdotti strumenti utili: l'utility Robocopy per la preparazione dei file e NT Backup per il backup. Solo successivamente è arrivato il software specializzato, in particolare Veritas Backup Exec, ora noto come Symantec Backup Exec. Quindi ho una lunga esperienza con i backup.
In parole semplici, il backup è la conservazione di una copia dei dati (macchine virtuali, applicazioni, database e file) a scopo precauzionale con una certa regolarità. L'imprevisto si manifesta solitamente attraverso un guasto hardware o logico, causando la perdita di dati. Il compito di un sistema di backup è ridurre le perdite derivanti dalla perdita di informazioni. Un guasto hardware, ad esempio, può essere il malfunzionamento di un server o di uno storage in cui è presente un database. Il guasto logico comporta la perdita o la modifica di parte dei dati, anche a causa di fattori umani: si è accidentalmente eliminata una tabella, un file o si è eseguito uno script difettoso. Ci sono anche requisiti normativi per la conservazione di un certo tipo di informazioni per un lungo periodo, ad esempio per alcuni anni.
L'uso più comune dei backup è il ripristino di una copia salvata dei database per il dispiegamento di vari sistemi di test, cloni per gli sviluppatori.
Esistono diversi miti comuni attorno al backup che è ora giunto il momento di sfatare. Ecco i più noti.
Mito 1. Il backup è da tempo solo una funzione secondaria all'interno dei sistemi di sicurezza o di archiviazione
I sistemi di backup rimangono ancora una categoria separata di soluzioni e sono molto indipendenti. Si tratta di un compito troppo importante per loro. In sostanza, essi rappresentano l'ultima linea di difesa quando si tratta di proteggere i dati. Di conseguenza, il backup funziona nel proprio ritmo, secondo il proprio programma. Viene generato un rapporto giornaliero sui server, ci sono eventi che agiscono come trigger per il sistema di monitoraggio.
Inoltre, il modello di accesso basato sui ruoli al sistema di backup consente di delegare parte dei poteri agli amministratori dei sistemi di destinazione per la gestione delle copie di sicurezza.
Mito 2. Quando c'è RAID, il backup non è più necessario.
Senza dubbio, i sistemi RAID e la replica dei dati sono un buon modo per proteggere i sistemi informativi da guasti hardware, e in presenza di un server di standby è possibile organizzare rapidamente il passaggio su di esso in caso di guasto della macchina principale.
La ridondanza e la replica non proteggono dagli errori logici commessi dagli utenti del sistema. Ecco che il server di standby con registrazione ritardata può essere utile se l'errore viene scoperto prima che sia stata effettuata la sincronizzazione. E se il momento è andato perduto? 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 ante ieri e recuperare i dati necessari. Considerando che gli errori logici sono i più comuni, il buon vecchio backup rimane uno strumento affidabile e necessario.
Mito 3. Il backup è qualcosa che si fa una volta al mese.
La frequenza di backup è un parametro configurabile, che dipende principalmente 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 la società.
Questi, in effetti, possono essere sottoposti a backup una volta al mese e anche meno frequentemente. Mentre i dati più critici vengono salvati più frequentemente, a seconda dell'indicatore RPO (Recovery Point Objective), che stabilisce la perdita di dati accettabile. Questo può essere una volta a settimana, una volta al giorno o anche più volte all'ora. Noi utilizziamo i registri delle transazioni del DBMS.
Quando si introducono i sistemi in produzione industriale, è obbligatorio approvare la documentazione sul backup, che riflette i punti principali, il regolamento di aggiornamento, la procedura di ripristino del sistema, la procedura di archiviazione dei backup e simili.
Mito 4. Il volume dei backup cresce incessantemente e occupa completamente qualsiasi spazio assegnato.
I backup hanno una durata limitata di archiviazione. Non ha senso, ad esempio, accumulare per un anno tutti i 365 backup giornalieri. In generale, è consentito conservare copie giornaliere per 2 settimane, dopodiché vengono sostituite con copie fresche, mentre per l'archiviazione a lungo termine rimane la versione realizzata per prima nel mese. Anche questa, a sua volta, viene conservata per un certo periodo: ogni copia ha una durata di vita.
Esiste una protezione contro la perdita di dati. Vige la regola: prima che un backup venga eliminato, deve essere creato il successivo. Pertanto, i dati non verranno cancellati se il backup non è riuscito, ad esempio a causa di un server non disponibile. Si rispettano non solo i limiti temporali, ma si controlla anche il numero di copie nel set. Se nel sistema è previsto che ci debbano essere due backup completi, ce ne saranno sempre due, e il vecchio sarà eliminato solo quando il nuovo terzo verrà scritto con successo. Pertanto, la crescita del volume occupato dall'archivio dei backup è legata solo all'aumento 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 il cielo del gestore non è all'altezza. In generale, le prestazioni del backup dipendono da molti fattori. Ad esempio, dalla rapidità del sistema di backup stesso: quanto sono veloci i dispositivi di archiviazione e le librerie a nastro. Dalla rapidità server del sistema di backup: riescono a elaborare i dati, a comprimere e a eseguire la deduplicazione. Inoltre, dalla velocità delle linee di comunicazione tra il cliente e il server.
Il backup può avvenire in uno o più flussi, a seconda che il sistema da riservare supporti il multithreading. Ad esempio, il DBMS Oracle consente di gestire più flussi, in base al numero di processori disponibili, finché la velocità di trasmissione non raggiunge il limite della larghezza di banda della rete.
Se si cerca di eseguire il backup con un alto numero di thread, c'è il rischio di sovraccaricare il sistema in funzione e questo inizierà a rallentare. Pertanto si sceglie un numero ottimale di thread per garantire prestazioni adeguate. Se invece è cruciale anche una minima riduzione delle prestazioni, c'è un'ottima opzione in cui il backup non viene effettuato dal server operativo, ma dal suo clone – standby nella terminologia dei database. Questo processo non sovraccarica il sistema principale. I dati possono essere recuperati attraverso un numero maggiore di thread, poiché il server non è utilizzato per il servizio.
Nelle grandi organizzazioni viene creata una rete separata per il sistema di backup, in modo che il backup non influenzi l'ambiente di produzione. Inoltre, il traffico può essere trasmesso non attraverso la rete, ma tramite SAN.
Cerchiamo di distribuire il carico anche nel tempo. I backup si svolgono principalmente in orari non lavorativi: di notte, nei fine settimana. Inoltre, non vengono avviati tutti contemporaneamente. I backup delle macchine virtuali rappresentano un caso particolare. Il processo influisce praticamente poco sulle prestazioni della macchina stessa, quindi il backup può essere distribuito durante il giorno, anziché essere rimandato alla notte. Ci sono molte sfumature da considerare, e una volta tenuto conto di tutto, il backup non influenzerà le prestazioni dei sistemi.
Mito 6. Ho avviato il sistema di backup – ecco la mia tolleranza ai guasti
Non dimenticate mai che il sistema di backup è l'ultima linea di difesa, il che significa che deve esserci un altro insieme di sistemi a garantire la continuità, l'alta disponibilità e la tolleranza ai guasti delle infrastrutture IT e dei sistemi informativi dell'azienda.
Non si deve contare sul fatto che il backup recupererà tutti i dati e ripristinerà rapidamente il servizio interrotto. La perdita di dati dal momento del backup fino al guasto è garantita, e i dati sul nuovo server possono richiedere ore (o giorni, a seconda della situazione) per essere caricati. Pertanto, ha senso creare veri e propri sistemi di tolleranza ai guasti, senza riporre tutte le speranze sul backup.
Mito 7. Ho impostato un backup una volta, ho controllato che funzionasse. Resta solo da monitorare i log
Questo è uno dei miti più dannosi, la cui falsità si comprende solo durante un incidente. I log di un backup effettuato con successo non garantiscono che tutto sia andato come previsto. È importante verificare in anticipo la deportabilità della copia salvata. Cioè, avviare il processo di ripristino in un ambiente di test e osservare il risultato.
E un po' di lavoro dell'amministratore di sistema
In modalità manuale, nessuno copia più i dati da tempo. I moderni sistemi di backup possono fare il backup praticamente di tutto, basta configurarlo correttamente. Se viene aggiunto un nuovo server, è necessario impostare le politiche: scegliere il contenuto da eseguire il backup, specificare i parametri di archiviazione e applicare un programma.
Tuttavia, ci sono comunque molti lavori a causa dell'ampia gamma di server, tra cui database, sistemi di posta, cluster di macchine virtuali e risorse file sia su Windows che su Linux/Unix. I dipendenti che mantengono la funzionalità del sistema di backup non stanno con le mani in mano.
In occasione della festa, desidero augurare a tutti gli amministratori nervi saldi, movimenti precisi e uno spazio infinito per la conservazione dei backup!
Fonte: habr.com
