Come si esegue il backup di una SAN?

lettore da molto tempo, prima domanda :)

Ho letto molto su iSCSI e SAN in generale e credo di essere stato in grado di rispondere alla maggior parte delle mie domande e preoccupazioni sull'argomento, ma questo rimane:

Come "esegui il backup di una SAN?"

Quello che segue è uno scenario più o meno reale e i miei pensieri e domande a riguardo.

Supponiamo che tu sia riuscito a convincere la gestione della tua piccola (nella migliore media dimensione) azienda a fornire finalmente i fondi per una soluzione di archiviazione piccola ma adeguata, ovvero una SAN basata su iSCSI. Supponiamo che sia costituito da un server con molte unità in un contenitore che esegue OpenFiler o persino un MD3000i (Dell) o MSA2000i (HP), che sono, a quanto ho capito, le soluzioni entry-level più comuni.

I LUN vengono esportati su un server che deve archiviare repository di codice, documenti, immagini e simili, un altro server che esegue alcuni database, un altro che utilizza i LUN come dischi per guest di virtualizzazione (DomU in Xen-speak) e ancora un altro server che esporta un grande LUN contenente le home directory dell'utente tramite NFS (questo è un negozio Linux puro). I vantaggi sono chiari, credo: i singoli server non hanno bisogno di molta memoria locale e la migrazione di server o servizi diventa più semplice.

Ma ora è necessario disporre di una soluzione di backup per tutti o la maggior parte dei dati archiviati. Come si fa? Esegui il software di backup (mi piace rsnapshot) su tutti i server che dispongono di dati per il backup? Dove metti quei dati? Su un server di backup dedicato con molta memoria locale? O di nuovo nella SAN? Qual è la soluzione "comune", se presente, per il backup di una SAN?

Sto cercando le migliori pratiche e i consigli di persone che hanno più esperienza di me nella gestione delle SAN.

Grazie!

Modifica: considerando che il budget per la SAN è molto limitato all'inizio, credo che sto cercando soluzioni non proprietarie, molto generiche ed economiche alla domanda di backup. Se tali soluzioni esistono, comunque. Non ci saranno soldi per i nastri o un secondo array SAN identico. Avrei dovuto renderlo più esplicito, scusa.

Utilizziamo un cluster SAN NetApp 3020 con i dati iSCSI, FC e CIFS memorizzati su di esso. Questo prodotto supporta i dump NDMP su un caricatore automatico di nastri SCSI collegato localmente. Usando questo, ottengo copie perfette dei miei LUN iSCSI e FC, nonché backup di file per file dei miei dati CIFS condivisi da NetApp. Uso BackupExec per controllare i backup NDMP e le velocità sono eccezionali perché è una connessione SCSI locale a NetApp.

Sembra che ci troviamo su una barca simile, in termini di dimensioni e complessità dell'infrastruttura.

In sostanza, ho una SAN che gestisce i miei dati di produzione, quindi ho un server di backup con una memoria collegata localmente piuttosto decente collegata a una libreria di nastri (LTO-3 che non è compresso da 400 GB / nastro)

In sostanza, eseguo backup a livello di dati. Dato che eseguo Linux, eseguo rsyncs per ottenere i dati dalla macchina collegata alla SAN alla macchina di backup, quindi scrivo i dati su nastro. Sono fortunato che ho abbastanza spazio di archiviazione locale sul server di backup da poterne conservare una copia localmente, quindi sincronizzare di nuovo le differenze, ma se non riesci a configurarlo, molte soluzioni di backup usano l'idea di uno spooling directory per archiviare localmente i dati mentre vengono scritti su nastro.

A causa del modo in cui il nastro scrive, è una pessima idea lo streaming diretto dalla rete al nastro, come una condivisione di file di Windows o una condivisione NFS. Ciò elimina completamente la velocità di scrittura del nastro E uccide la durata dell'unità a nastro. Quindi usa un disco locale per eseguire lo spooling dei dati.

La soluzione di backup che uso si chiama Amanda, che è piuttosto esoterica nella sua configurazione, ma ha una versione commerciale disponibile (per $ 100 / backup del server) che ha una configurazione basata sul web, e puoi anche ottenere estensioni da collegare direttamente a vari banche dati.

MODIFICARE

Dato che hai menzionato di non avere nastri, consiglierei una libreria a nastro virtuale (VTL) di un uomo povero, cioè unità USB esterne. Amanda, almeno, può indirizzare i file come se fossero un VTL, e sono sicuro che anche altri pacchetti software possono farlo.

In realtà, tuttavia, i dischi rigidi hanno una durata definita. Se la tua azienda sta spendendo abbastanza denaro per acquistare una SAN, dovresti lavorare su di essa per ottenere un cambia nastro. In realtà non sono così costosi come una volta, in particolare se non si acquista sul bordo sanguinante.

La forma di backup più economica (e più debole) che è possibile eseguire consiste nel mantenere le istantanee in giro, con qualche forma di backup occasionale a lungo termine.

Ciò presuppone che le istantanee siano economiche - dipende da come sono implementate. Copia su file system di scrittura come WAFL di NetApp e ZFS di SUN hanno snapshot a costo praticamente zero, in contrasto con il costo O (n) degli snapshot di copia. Le istantanee economiche sono davvero belle.

Il solo fatto di tenere le istantanee in giro non è in realtà una soluzione di backup, ma non sono sicuro che qualsiasi soluzione reale sia possibile sotto i tuoi vincoli senza gravi hacking.

Inoltre, sono seriamente di parte qui come sviluppatore di NetApp, ma dovresti almeno parlare seriamente con alcuni venditori di NetApp prima di concludere che sono fuori dalla tua fascia di prezzo. :-)

Una libreria a nastro con collegamento diretto o in fibra ottica + NDMP può essere una soluzione piuttosto semplice ma se il tuo sistema di archiviazione non può usare qualcosa di simile per scrivere su nastro o se il budget è particolarmente limitato, potresti essere nella posizione di avere utilizzare una soluzione di backup tradizionale per eseguire il backup dei dati nel LUN tramite un client di backup sull'host collegato alla SAN.

In uno scenario come questo, i dati ospitati su SAN vengono trattati proprio come i dischi fisici nel client sottoposto a backup.

Mentre la funzionalità NDMP è talvolta inclusa in un sistema di archiviazione (come la NetApp), le applicazioni di backup possono effettivamente caricare costi aggiuntivi per il backup tramite NDMP. Ad esempio, nel nostro ambiente NetBackup, le licenze NDMP erano molto più costose delle normali licenze di backup del client OS.

oops..solo rinfrescato e ho visto la tua aggiunta ri: non avere $$ per i nastri. Dove hai intenzione di mettere i tuoi backup se non su nastro o un'altra SAN?

L'utilizzo di tutti i dischi per il backup è fattibile, ma di solito non è considerato un'opzione di budget per una grande quantità di dati. Allo stesso modo, il backup dei dati nella stessa SAN può mitigare alcuni rischi se stai attento (ad esempio assicurati che separerà completamente i dischi) ma non offre alcun tipo di errore totale o protezione dalle catastrofi. Lo stesso vale per un server di backup con molti dischi ... un certo livello di protezione ma se la posizione in cui vivono sia la SAN che il server di backup big-honkin subisce una grave interruzione o un disastro, tutti quei dati sono spariti.

Abbiamo continuato a utilizzare la nostra infrastruttura di backup esistente che avevamo anche prima di passare a una SAN. I singoli host che eseguono Legato Networker eseguono il dump notturno su un sistema Storagetek Tape. Onestamente se stai cercando una soluzione economica ... il backup su disco è probabilmente più economico, hai anche la possibilità di trasportare quelle unità in una posizione esterna se necessario, proprio come i nastri.

Dato che non disponi di molti dati, procurati un SDLT usato o una prima unità nastro LTO 1,2 ... ce ne sono centinaia in quanto sono obsoleti rispetto a LTO-3, 4