Server di archiviazione di backup con ZFS

Sono tutto per uomo in una piccola azienda. Voglio progettare una nuova infrastruttura che includa un nuovo server e un server di backup separato con criteri di backup a livello aziendale.

La cosa più importante dell'azienda è SQL Server e i suoi database. Esistono 10 database, ma solo 2 sono davvero importanti. Il primo da 8 GB, principalmente dati e numeri di testo. Il secondo di circa 300 GB con 16 GB / mese cresce contenente PDF e GIF.

Per salvare l'archiviazione, il criterio di backup corrente consiste in un backup completo a settimana e in 6 differenziali. Penso che siano circa 350 GB a settimana, 1,4 TB al mese.

Dopo aver letto così articoli sulla corruzione silenziosa dei dati, ho deciso di provare ZFS con Nexenta Community Edition.

La mia domanda: ZFS con deduplicazione è buono per l'archiviazione dei file di backup in termini di affidabilità o dovrei pensare a un backup su nastro o qualcos'altro?

EDIT: So che in questo momento non possiamo prevedere le prestazioni, il rapporto di deduplicazione ecc., Ma voglio sapere se è una buona idea.

Certamente ZFS è abbastanza stabile da fare questo tipo di cose, ci sono molte piattaforme di produzione affidabili e di alto profilo basate su ZFS e Nexenta.

Detto ciò, mi piace sempre avere backup basati su disco in loco come quello che stai suggerendo E backup su disco rimovibile o su nastro che vanno fuori sede quotidianamente per proteggere da incendi / terremoti / Cthulhu ecc.

Quindi la mia risposta è sì, va bene ma sceglierei entrambe le opzioni se puoi.

(supponendo che ti riferisca all'utilizzo della dedupe all'interno di ZFS rispetto al tuo software di backup)

Vorrei non consiglia di utilizzare ZFS nativo deduplicazione per il sistema di backup a meno che non si progetta il sistema di storage appositamente per esso.

L'uso della dedupe in ZFS richiede molta RAM. Poiché la deduplicazione si verifica in tempo reale quando i dati vengono trasmessi / scritti nel pool di archiviazione, esiste una tabella mantenuta in memoria che tiene traccia dei blocchi di dati. Questa è la tabella DDT . Se il tuo server di archiviazione ZFS non ha abbastanza RAM per ospitare questa tabella, le prestazioni ne risentiranno enormemente. Nexenta ti avvertirà mentre la tabella supera una certa soglia, ma ormai è troppo tardi. Ciò può essere aumentato dall'uso di un dispositivo L2ARC (lettura cache), ma molti dei primi utenti di ZFS sono caduti in questa trappola.

Vedere:

ZFS: la distruzione di zvol o set di dati deduplicati blocca il server. Come recuperare?

ZFS - Impatto dell'errore del dispositivo cache L2ARC (Nexenta)

Quando dico che il requisito di RAM è elevato per l'utilizzo della dedupe, stimerei le esigenze di RAM e L2ARC per il set di dati che descrivi a 64 GB + RAM e 200 GB + L2ARC. Questo non è un investimento minore. Mantenere molti file di sistema di Windows e documenti di immagine che non verranno riletti riempirà quel DDT molto rapidamente. Il profitto potrebbe non valere il lavoro di ingegneria che deve essere anticipato.

Un'idea migliore è utilizzare la compressione su zpool, sfruttando possibilmente le funzionalità di gzip per i tipi di dati più comprimibili. La deduplicazione non ne varrà la pena in quanto si verifica un hit quando è necessario eliminare i dati deduplicati (è necessario fare riferimento al DDT).

Inoltre, come presenterai la memoria al tuo software di backup? Quale suite di software di backup utilizzerai? In ambienti Windows, presento ZFS come blocco di archiviazione su Backup Exec su iSCSI. Non ho mai trovato le funzionalità ZFS CIFS abbastanza robuste e ho preferito i vantaggi di un dispositivo formattato in modo nativo.

Inoltre, ecco un'eccellente risorsa ZFS per idee di design. Cose su ZFS che nessuno ti ha detto

Un sistema operativo alternativo è OpenIndiana che è altrettanto buono e riceve aggiornamenti più frequenti qualche volta.

Un'altra opzione è quella di impostare un secondo server ZFS con un pool di archiviazione (potenzialmente) più piccolo con la compressione abilitata. È possibile utilizzare questo secondo dispositivo per backup statici. È quindi possibile rinunciare alla cache di lettura e inoltre non è necessaria una quantità sciocca di CPU / RAM per gestirla.

Eseguiamo un setup come questo dove lavoro:

• OpenIndiana main storage server [ main ] con sei dischi da 2 TB in un pool RaidZ1 composto da tre set di coppie speculari. Questo, pur tagliando lo spazio di archiviazione disponibile, crea un pool di archiviazione rapido e moltiplicato.
• Un server di archiviazione secondario [ backup ] che esegue anche OpenIndiana con una configurazione simile di dischi che funge esclusivamente da dispositivo di backup.
• main ha uno script che viene eseguito da un cron job che istantanee / tank / [set di dati] regolarmente nel corso della giornata
• Ogni sera viene eseguito un altro cron job che esegue il backup delle istantanee del giorno sulla rete . Una volta eseguita la sincronizzazione iniziale di tutte le tue istantanee (una procedura unica), la natura incrementale delle istantanee significa che le modifiche vengono inviate molto rapidamente al tuo dispositivo di backup.

Ho una rapida panoramica su come attrezzare l'invio / la ricezione di ZFS qui: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/