Come si esegue il backup di un server di archiviazione?

Sto cercando di implementare un server di archiviazione molto grande da utilizzare come NAS live per molti altri server (tutti basati su Linux).

In termini molto ampi, intendo tra 4 TB e 20 TB di spazio utilizzabile (anche se è improbabile che in realtà lo faremo 20 TB).

Il server di archiviazione sarà RAID 10 per la sicurezza e le prestazioni dei dati, ma avremo comunque bisogno di una soluzione di backup che includa il backup off-site.

La mia domanda è: come si fa a fare il backup di tutti quei dati !?

Non è che posso semplicemente collegare un disco rigido portatile e trasferire i file. Al momento non abbiamo altri dispositivi con così tanto spazio di archiviazione.

Devo effettuare il budget per un secondo server di archiviazione off-site o esiste una soluzione migliore?

Esistono molti modi per gestire i dati di quelle dimensioni. Molto dipende dal tuo ambiente e da quanti soldi sei disposto a spendere. In generale ci sono alcune strategie generali di "rimozione dei dati dal server":

• Su Ethernet Come indicato sulla confezione, i dati vengono trasmessi ad Some Where Else per la gestione. 20 TB richiederà molto tempo per copiare oltre 1 GB, ma è possibile farlo. L'hardware può aiutare (come i collegamenti 10GbE o, in alcuni casi, il collegamento NIC).
• Sul sottosistema di archiviazione Se si è su Fibre Channel, inviarlo a un altro dispositivo sulla rete FC. Se hai SAS, invialo a un dispositivo collegato SAS. Generalmente più veloce di Ethernet.
• Invialo a un altro array di dischi Invialo a un altro pezzo di memoria collegato allo stesso server.

Questa è la vista 100Km. Una volta che inizi a ingrandire, le cose diventano molto più frammentate. Come già accennato, LTO5 è una tecnologia a nastro specifica progettata per questo tipo di carichi ad alta densità. Un altro array di archiviazione identico è un buon obiettivo, soprattutto se è possibile utilizzare qualcosa come GlusterFS o DRBD per ottenere i dati lì. Inoltre, se hai bisogno di una rotazione di backup o solo la possibilità di continuare a funzionare nel caso in cui l'array non funzioni influirà su ciò che hai messo in atto.

Una volta che hai optato per un metodo di visualizzazione di 100 km, entrare nel software sarà il prossimo grande compito. I fattori che influenzano questo sono ciò che puoi installare sul tuo server di archiviazione in primo luogo (se è una NetApp, questa è una cosa, un server Linux con un sacco di spazio di archiviazione è un'altra cosa, così come un server Windows con un sacco di spazio di archiviazione) , quale hardware scegli (non tutti i pacchetti di backup FOSS gestiscono bene le librerie di nastri, ad esempio) e quale tipo di conservazione del backup è richiesta.

Devi davvero capire che tipo di Disaster Recovery desideri. La replica live semplice è più semplice, ma non consente di eseguire il ripristino dall'ultima settimana solo ora. Se la capacità di ripristinare dall'ultima settimana è importante per te, allora devi progettare per quel tipo di cose. Per legge (negli Stati Uniti e altrove) alcuni dati devono essere conservati per oltre 7 anni.

La replica semplice è la più semplice da fare. Questo è ciò che DRBD è progettato per fare. Una volta eseguita la copia iniziale, invia solo le modifiche. I fattori complicanti qui sono la località di rete, se il tuo secondo array non è vicino al DRBD primario potrebbe non essere fattibile. Avrai bisogno di un secondo server di archiviazione con almeno lo spazio di archiviazione del primo.

Informazioni sul backup su nastro ...

LTO5 può contenere 1,5 TB di dati senza compressione. Nutrire questi mostri richiede una rete molto veloce, che è Fibre Channel o SAS da 6 Gb. Dato che è necessario eseguire il backup di oltre 1,5 TB in una serie, è necessario esaminare i caricatori automatici (ecco un esempio: link , un caricatore automatico a 1 unità a 24 slot di HP). Con il software che li supporta, gestiranno il cambio dei nastri durante il backup per te. Sono grandi. Dovrai comunque estrarre i nastri per inviarli al di fuori del sito, ma è una vista dannatamente meglio che restare in giro tutta la notte per caricare i nastri da soli quando il backup li richiede.

Se il nastro ti dà gli heebiegeebies ' legacy, ew ', una libreria di nastri virtuali potrebbe essere più veloce (come questa di Quantum: link ). Questi fingono di essere librerie nastro per il backup del software, mentre in realtà archiviano le cose su disco con solide (speri) tecniche di de-duplicazione. I più fantasiosi copieranno persino i nastri virtuali in nastri reali per te, se ti piace quel genere di cose, che possono essere molto utili per le rotazioni fuori sede.

Se non vuoi scherzare con nemmeno i nastri virtuali, ma vuoi comunque eseguire backup diretti su disco, avrai bisogno di un array di archiviazione abbastanza grande da gestire quei 20 TB, oltre ai dati di cambiamento di rete che desideri per trattenere. Diversi pacchetti di backup gestiscono questo in modo diverso. Alcune tecnologie di de-duplicazione sono davvero interessanti, altre sono complicate. Personalmente non conosco lo stato dei pacchetti software di backup FOSS in quest'area (ho sentito parlare di Bacula), ma potrebbero essere sufficienti. Molti pacchetti di backup commerciali dispongono di agenti locali installati sui server di cui eseguire il backup per aumentare la velocità effettiva, il che ha molti meriti.

Jukebox LTO-5? avresti bisogno di un numero compreso tra tre e 15 nastri per eseguire il backup di quell'array, che non è un numero follemente grande. Il jukebox si occuperà di cambiare i nastri per te e un buon software di backup (ad esempio bacula) terrà traccia di quali file si trovano su quale nastro.

Dovresti anche considerare il tempo necessario per eseguire il backup di un file system di dimensioni così grandi, in quanto è molto probabile che l'FS cambierà durante quel periodo. Per risultati ottimali, un file system che supporta le snapshot sarebbe molto utile, quindi è possibile acquisire un'istantanea istantanea ed eseguire backup completi o incrementali rispetto a quello, anziché al filesystem live.

Probabilmente dovresti cercare di eseguire il backup su disco , poiché il nastro richiederà molto tempo ed essendo un accesso sequenziale, i ripristini impiegheranno per sempre.

Sfrutta sicuramente i backup differenziali o incrementali , eseguendo solo il backup delle modifiche, a qualunque frequenza abbia senso per te.

Probabilmente la soluzione ideale dovrebbe avere un secondo server di dimensioni simili in un'altra posizione , in cui i backup incrementali vengono inviati regolarmente e che potrebbero essere sostituiti rapidamente in caso di morte del server principale. Tuttavia, un'altra opzione sarebbe quella di utilizzare le unità rimovibili sul posto, che vengono poi rimosse fuori sede per l'archiviazione.

Quando hai a che fare con così tanti dati, ha anche senso suddividere i backup in processi di backup più piccoli e, se non è possibile eseguirne il backup tutti i giorni, scaglionare i backup in modo che il set A venga eseguito il backup un giorno e imposta B il prossimo.

Pensare sempre alla procedura di ripristino . Ci siamo incantati una volta quando abbiamo dovuto ripristinare un file da un processo di backup di diverse centinaia di gig, che ha richiesto molta memoria e molto tempo per ricostruire l'indice di backup e ripristinare. Alla fine non siamo riusciti a completarlo in un giorno e abbiamo dovuto costruire un server di ripristino dedicato per consentire al nostro server di backup principale di continuare i suoi lavori notturni!

--added--

Vuoi anche pensare alle tecnologie di deduplicazione , che possono risparmiare enormi quantità di spazio non eseguendo il backup delle stesse informazioni più volte, per più utenti. Molte soluzioni di backup o filesystem offrono la deduplicazione come parte della loro funzionalità.

Innanzitutto, elenca i rischi dai quali stai proteggendo. Alcuni rischi comuni:

• Disastro: succede qualcosa di molto sfortunato a tutto il tuo sito.
• Errori umani (questo è quello che succede _all_the_time_):
  • Qualcuno decide di esercitare la funzionalità di "hot-swap" del server di archiviazione in un modo non previsto dal produttore.
  • Qualcuno esegue un processo che corrompe silenziosamente i dati, di cui viene eseguito il backup in modo affidabile per un paio di mesi prima che il problema venga rilevato.
  • Qualcuno cancella l'importante rapporto che arriverà tra un'ora e vale migliaia di dollari.

Quindi valutare il costo delle varie soluzioni di prevenzione dei rischi, ad esempio:

• Backup on-line off-site (mirror remoto): sicuro da disastri, alcuni (ma non tutti) errori umani (è ancora online).
• Archiviazione off-line off-site (nastri): al sicuro da disastri, difficile recuperare rapidamente i dati.
• Backup online (mirror) on-site: al riparo da errori umani, guasti hardware, vulnerabilità al disastro.
• Backup off-line in loco (nastri nel commutatore di nastro): sicuro dalla maggior parte degli errori umani, dalla maggior parte dei guasti hardware.

Quindi valuta le strategie di rotazione (fino a che punto vuoi recuperare, quanti dati puoi permetterti di perdere).

Quindi scegli quanto valgono i tuoi dati.

Ho un cliente con due sistemi simili da 12 TB in due edifici diversi, collegati a 1 GB. Uno è il sistema di produzione; viene eseguito il backup incrementale (con istantanee giornaliere) sull'altro con l' utility rdiff-backup . rdiff-backup deve essere disponibile nel repository di distribuzione standard.

Backup off-site, online (mirror remoto)

usa rsync sebbene ssh (solo modifiche) - il primo backup deve essere eseguito localmente, ma dopo quel backup sarà un gioco da ragazzi a seconda delle modifiche

se è necessario mantenere le versioni con le modifiche rdiff-backup

http://www.nongnu.org/rdiff-backup/

Il file system btrfs in Linux sembra promettente, ma ancora in forte sviluppo

Dai un'occhiata al tuo "contenuto" reale e alla frequenza con cui cambia prima di pianificare la tua strategia. Molte volte le persone sfornano ripetutamente gli stessi dati su nastro settimanalmente senza motivo.

Le tecnologie di deduplicazione di alcuni fornitori possono consentire lo snapshot per salvarti da singoli ripristini di file, ma avrai sempre bisogno di protezione fuori sede.