Consiglio per configurare un Server Storage in ESXi

[TowerPillar]

Buongiorno a tutti,
mi scuso in anticipo per il mio livello principiante, ma ho bisogno di un vostro consiglio;

Ho un microserver in casa con ESXi installato e alcune VM il tutto su 2 dischi in raid1...
Avrei bisogno di utilizzare la stessa macchina anche come server storage e a disposizione ho altri 4 dischi e un secondo controller HW.

Volevo sapere date le vostre conoscenze ed esperienze, qual'era il modo giusto, migliore o più sicuro per ottenere il tutto in ESXi.
Faccio un esempio:
dato il volume (raid5) che si verrà a creare, è cosa migliore creare una VM unica, che risieda interamente sul raid5 e che contenga tutto lo storage, o è meglio una VM col disco virtuale di sistema sul primo raid e una seconda unità virtuale (per lo storage), sul raid5???

E' sicuro poi, data la mole di dati, racchiuderli tutti in un volume virtuale???

O è meglio ad esempio creare una VM sul primo raid che gestisca in maniera diretta ed esclusiva (direct I/O) il controller e tutto il contenuto?

...o magari ho detto una marea di cavolate e non si fà in nessuno dei precedenti modi?!?!?

Spero che qualcuno mi indichi la strada giusta e che la cosa non sia così banale.
Grazie in anticipo

[zeMMeMMe]

Questo mi turba
"
Ho un microserver in casa con ESXi installato e alcune VM il tutto su 2 dischi in raid1", cioè hai aggiunto un controller PCIe per avere il RAID1?
Perchè i microserver HP (NL36, NL40) non dispongono affatto di un controller RAID hardware compatibile con ESXi.

Per il resto:
RAID-5? Nonononononono
DirectIO? Nononononono (in questo caso)

Ti serve un PDC? sì/no
Vuoi andare per forza di Windows? sì/no
Sei pigro? gui/riga di comando

Personalmente se no,no metterei zfsguru con due dischi virtuali (su due datastore) in mirror zfs.
Sì lo so, non è molto sviluppato ormai, ma è 1000 volte più veloce di FreeNAS che ha una gui davvero pessima.

Ancora peggio (sempre come gui) c'è Nexentastor, che però è stabile e funziona bene anche virtualizzato

[TowerPillar]

Allora...
intanto grazie per la risposta, il server si, è un HP (microserver Gen8) oltre al controller su Mobo (raid1) ne ho uno aggiuntivo (areca ARC1212) che controlla le 4 baie originali. Entrambi i controller sono perfettamente riconosciuti da ESXi.

inizio a risponderti e a chiedere...
Raid 5 e DirectIO... ok... ma Perchè no!?!? e che dovrei fare raid 10?

- PDC: No in casa non credo serva..
- Windows? non obbligatoriamente (ho provato per dire anche xPEnology con directIO sul controller)
- Pigro... di certo meglio la GUI, per la riga di comando occorre anche saper che scrivere, no!?

intanto mi informo su cosa sia e come funzioni il mirror zfs, zfsguru e nexentastor... e poi ti chiedo, ma non c'è pericolo che i file che compongono gli HDD virtuali si danneggino e/o corrompano???

[zeMMeMMe]

Originariamente inviato da TowerPillar

Allora...
intanto grazie per la risposta, il server si, è un HP (microserver Gen8) oltre al controller su Mobo (raid1) ne ho uno aggiuntivo (areca ARC1212) che controlla le 4 baie originali. Entrambi i controller sono perfettamente riconosciuti da ESXi.

Non nessun gen8, per quelli più vecchi (NL40) il controller RAID1 "finto" non viene minimamente visto da ESXi (in modalità RAID intendo).

inizio a risponderti e a chiedere...
Raid 5 e DirectIO... ok... ma Perchè no!?!? e che dovrei fare raid 10?

No, devi abbandonare vecchi sistemi

- PDC: No in casa non credo serva..

E' importante perchè sennò ci voleva BSD e non Nexentastor

- Pigro... di certo meglio la GUI, per la riga di comando occorre anche saper che scrivere, no!?

Eh diciamo proprio di sì

intanto mi informo su cosa sia e come funzioni il mirror zfs, zfsguru e nexentastor... e poi ti chiedo, ma non c'è pericolo che i file che compongono gli HDD virtuali si danneggino e/o corrompano???

Dipende cosa intendi, i .vmdk dentro vmfs?
Certo che sì, come tutto.
Proprio per questo ti consiglio un filesystem (zfs) che può darti la certezza (ripeto: la certezza) che i tuoi dati non si siano corrotti in nessuna parte, fino all'ultimo bit, mediante la funzione di scrub.

Riguardo all'avere più copie, per il rischio di guasto fisico, puoi usare la funzione mirror (RAID1) integrata in zfs, che non richiede nulla (anzi, meno controller hardware usi meglio è, normalmente li si configura in passthrough o alla peggio JBOD, ci sono un sacco di firmware specifici per "sraidizzarli").

In sostanza puoi avere
disco virtuale1 => datastore1 => disco fisico 1
disco virtuale2 => datastore2 => disco fisico 2
e direttamente da zfs fare il RAID1.

L'unico dubbio è la CPU davvero poco potente che utilizzi, queste configurazioni le monto con Xeon a 8 core e >=128GB di RAM, quindi ti tocca provare.

Ci sono parecchie possibilità, riguardo a zfs, essenzialmente suddivise in "sistemi operativi" e "distribuzioni con GUI".
E poi tra le due grandi famiglie "BSD" e "Solaris".

In altri termini puoi installarti il tuo sistema operativo, e poi gestire "a mano" le condivisioni (samba per BSD, CIFS per Solaris), ma da quanto capisco non è il caso.

Puoi mettere delle "distribuzioni" (cioè con interfaccia GUI web), tra le quali le 3 che ti consiglio sono
- zfsguru (in pratica su un freebsd standard c'è un'interfaccina davvero molto veloce e gradevole, unico problema usa samba3 e non samba4)
- nexentastor. Una "distribuzione" basata su solaris, con una sua GUI abbastanza lenta (molto lenta), ma funziona bene anche virtualizzato
- freenas. freebsd+interfaccia utente pessima, lenta e difficile da capire, e non certificata per l'uso virtualizzato (ma funziona comunque). ha il grosso pregio di una comunità di forummisti molto evoluta. per il resto a me non piace tanto, è incredibile come anche hardware potente venga messo in ginocchi da GUI veramente "inchiodate"

poi ce ne sono tante altro, distribuzioni sempre di tipo solaris ma con interfacce più spartane (sconsiglio), oppure basate su Linux, ma lì perdi zfs che per quanto mi riguarda oggi è IL file system per lo storage

[TowerPillar]

Un secondo, e una cosa alla volta!
partiamo dal raid...

Ti assicuro che entrambi i controller vengono rilevati da ESXi tant'è vero che dal sito HP puoi scaricare direttamente la ISO con il pieno supporto al server.

io ora come ora, nel server ho 6 HDD:
2 da 750Gb in raid1 collegati al controller HP del server (datastore1 700Gb - ESXi)
4 da 4Tb in Raid5 collegati ad un controller aggiuntivo (datastore2 12Tb)

per iniziare non ho capito proprio bene il motivo del raid5 del perchè è sconsigliato.

Grazie nuovamente per il supporto.

[zeMMeMMe]

Originariamente inviato da TowerPillar

Un secondo, e una cosa alla volta!
partiamo dal raid...

Ti assicuro che entrambi i controller vengono rilevati da ESXi tant'è vero che dal sito HP puoi scaricare direttamente la ISO con il pieno supporto al server...

Certo che ci credo, come sopra precisato NON ho quel modello di microserver, ma quelli più vecchi (NL40).

per iniziare non ho capito proprio bene il motivo del raid5 del perchè è sconsigliato.

Dal punto di vista teorico per il write hole, poi per il carico CPU del tutto inutile, e per il "dramma" del rebuild.
Infatti il momento più rischioso è nel momento in cui si guasta un disco e lo si sostituisce: quando parte la "ricostruzione" è frequentissimo che il carico molto gravoso sugli altri dischi... li faccia morire.

Dal punto di vista pratico perchè il recovery dei problemi (e problemi ne capitano molto spesso) è di sovente difficile e/o impossibile.

Quindi: RAID5? No se non assolutamente indispensabile.
In tutti gli altri casi? No, grazie

[TowerPillar]

E ok, anche perchè per creare il raid5 mi sembra ci abbia impiegato circa 56 ore. Come altre configurazioni però ho solo 0, 1, 10, 3, 5, 6, Single Disk or JBOD... Che tipo di raid dovrei mettere?

Poi mi interessa molto la cosa del file system in ZFS in ESXi, ora cerco di reperire informazioni.

Per quanto riguarda la configurazione hardware, come CPU c'è uno Xeon E3-1270v2 e 16Gb di DDR3 1333.

[zeMMeMMe]

Originariamente inviato da TowerPillar

E ok, anche perchè per creare il raid5 mi sembra ci abbia impiegato circa 56 ore. Come altre configurazioni però ho solo 0, 1, 10, 3, 5, 6, Single Disk or JBOD... Che tipo di raid dovrei mettere?

Single disk o jbod

Per quanto riguarda la configurazione hardware, come CPU c'è uno Xeon E3-1270v2 e 16Gb di DDR3 1333.

Allora ti chiedo scusa perchè non avevo capito niente.
Mi ha tratto in inganno la lettura di "microserver", pensavo fosse questo
http://n40l.wikia.com/wiki/HP_MicroServer_N40L_Wiki che monta una CPU AMD della fascia atom.

Con quell'hardware invece non avrai problemi particolari per carichi normali.

Se vuoi iniziare con zfs parti da qui
http://zfsguru.com/download

e qui
https://nexenta.com/products/downloa...ition-download

(la seconda ha un limite di 18terabyte di spazio per la versione gratuita, penso siano più che sufficienti per te)

[TowerPillar]

Tranquillo in realtà è proprio la versione nuova (e fisicamente più piccola) di quello che hai postato... http://product-images.www8-hp.com/di.../c03760124.png con un pò di modifiche.

Tornando a noi, se ho capito bene devo togliere il raid5 e importare tutti e 4 i dischi singolarmente come 4 datastore. Poi metto un disco virtuale detro ogni datastore e faccio il raid "software" da macchina virtuale?

[zeMMeMMe]

Originariamente inviato da TowerPillar

Tranquillo in realtà è proprio la versione nuova (e fisicamente più piccola) di quello che hai postato... http://product-images.www8-hp.com/di.../c03760124.png con un pò di modifiche.

Tornando a noi, se ho capito bene devo togliere il raid5 e importare tutti e 4 i dischi singolarmente come 4 datastore. Poi metto un disco virtuale detro ogni datastore e faccio il raid "software" da macchina virtuale?

si io farei e faccio così

[nanotek]

Leggendo il post mi sorgono alcuni dubbi:
Il microserver gen 8, così come i predecessori, ha solo 4 baie per i dischi.
Dove hai infilato gli altri dischi ?

Zfs richiede 1Gb di ram per ogni Tb di dati nel datastore. Fai i conti della ram impiegata e di quanta te ne avanza, di conseguenza puoi calcolare il tuo massimo datastore.
12 TB richiedono 12 Gb di Ram. Su 16 Gb che hai in dotazione sei sicuro di usarne solo 4 per hypervisor e altre macchine virtuali ?
Le ram sono ECC ?

[zeMMeMMe]

Originariamente inviato da nanotek

Zfs richiede 1Gb di ram per ogni Tb di dati nel datastore.

Preciso che quella è la richiesta (alla grossa) per la deduplicazione.
Funziona tranquillamente con 2-4-8GB.
L'elemento-chiave è l'uso efficiente della cache, cui viene destinata praticamente tutta la memoria libera.

La deduplicazione non è un granchè utile, se non in casi particolari, e può comunque essere attivata selettivamente su dataset (non su pool interi)

Mem: 2208K Active, 474M Inact, 60G Wired, 80K Cache, 102M Buf, 1877M Free
ARC: 57G Total, 48G MFU, 8598M MRU, 162K Anon, 295M Header, 734M Other
Swap: 4096M Total, 4096M Free

In questo esempio, preso or ora da un server freebsd virtualizzato, vedi l'occupazione di memoria modesta del sistema.

Riguardo alle memorie ECC, che dovrebbe avere e che sono in generale cosa buona e giusta, non sono necessarie per zfs (nonostante quanto affermino sul forum freebsd), proprio per il mantenimento costante degli hash di tutte le strutture.
Ovviamente è inutile ribadire che è meglio ECC.
Anzi in certi casi (vedi server Dell) è possibile utilizzare addirittura una sorta di "raid-1" per le RAM, proprio per ridurre i rischi di errori di questo tipo.
Francamente mi è capitato di farlo in produzione solo una volta

[nanotek]

In questo esempio, preso or ora da un server freebsd virtualizzato, vedi l'occupazione di memoria modesta del sistema.

Dipende anche cosa sta facendo quel server... se in quel momento non c'è nessuno che carica/compie operazioni sui file la memoria è tutta per la cache.

Facendo qualche prova, con poca ram 2 Gb su 8 Tb (2x4) il sistema aveva prestazioni veramente scarse mentre si caricavano dati massicciamente (i dati dell'archivio precedente, circa 5 Tb).

Non sapevo che si potesse attivare selettivamente la deduplicazione su alcuni dataset.

Visto che sei molto informato aggiungo una domanda: Senza deduplicazione, secondo te, bisogna comunque proteggere il server con un ups ?
Con deduplicazione attiva è indispensabile perchè può richiedere qualche instante (anche secondi) prima che il file venga salvato su disco.. ma senza deduplicazione ?

[zeMMeMMe]

Originariamente inviato da nanotek

Dipende anche cosa sta facendo quel server... se in quel momento non c'è nessuno che carica/compie operazioni sui file la memoria è tutta per la cache.

Bhè diciamo che è "abbastanza" utilizzato
Il punto è che lasciato "libero" utilizza come cache (ARC) praticamente tutta la RAM (normalmente i controller anche più "intelligenti" hanno a bordo 1GB di RAM, in questo caso ce n'è 50 volte di più).

Facendo qualche prova, con poca ram 2 Gb su 8 Tb (2x4) il sistema aveva prestazioni veramente scarse mentre si caricavano dati massicciamente (i dati dell'archivio precedente, circa 5 Tb).

??? Cosa intendi per "scarse" ???

Non sapevo che si potesse attivare selettivamente la deduplicazione su alcuni dataset.

Sì può, si può... così come si può attivare la compressione, il controllo hash ed addirittura la memorizzazione di più copie (in pratica gli stessi dati su parti diverse del disco)

Visto che sei molto informato aggiungo una domanda: Senza deduplicazione, secondo te, bisogna comunque proteggere il server con un ups ?
Con deduplicazione attiva è indispensabile perchè può richiedere qualche instante (anche secondi) prima che il file venga salvato su disco.. ma senza deduplicazione ?

??? Secondi ???
Non mi è mai capitato.
Per ordine
1) la deduplicazione non serve praticamente a nulla (oggi), con i supporti di massa di dimensione molto elevata. Serve in certi casi, ad esempio quelli in cui si mantengono molte copie degli stessi dati (server di sviluppo, dove ci sono 10000 cartelle diverse con le 10000 versioni dei sorgenti, che sono essenzialmente identici)
2) non mi risulta che richieda secondi, nel senso che banalmente si riduce la velocità di copia e bon. La deduplicazione è a livello di blocco, e non di file (per zfs).
3) l'UPS è sempre cosa buona e giusta. Tuttavia per zfs, col suo metodo COW, NON esistono chkdsk o fsck o simili.
In altri termini il sistema è SEMPRE (a meno di guasti fisici) in uno stato coerente.
Puoi benissimo staccare il cavo di alimentazione mentre stai scrivendo a tutto spiano: si riavvia senza fare una piega, senza fare scansioni del disco etc (che spesso sono molto lunghe e di dubbi risultati)
4) puoi vedere in ogni momento lo stato di integrità dei dati con lo scrub.
Anzi è prassi normale pianificarlo con crontab ogni TOT e farsi spedire per email i risultati (nexentastor lo fa da GUI)
5) non hai più la manfrina dei virus crypto locker e simili
6) puoi vedere da Windows i file nelle "versioni precedenti" (nexentastor lo fa da solo, per BSD bisogna sistemare smb.conf ma nulla di che)

In generale zfs è PIU' LENTO di un filesystem più arcaico (il migliore da questo punto di vista è FAT32).
Se lo scopo è fare dei benchmark è tempo perso, conviene andare di ext2 o FAT32.

La differenza è che con l'hardware odierno, superpotente e tipicamente usato al 2% nei server, e per il 98% in idle, si riesce a sfruttare non dico tutte le capacità di elaborazione, ma una frazione decisamente superiore.

E le funzioni di snapshot e scrub, e resilvering, e raidz, per quanto mi riguarda (e per chiunque si occupi di storage di dati importanti) sono indispensabili.

Ci sono anche degli aspetti migliorabili, soprattutto nel meccanismo di zfs send che non è bufferizzato e senza possibilità di scegliere lo snapshot da spedire.

Su una macchina moderna di fascia "consumer" tranquillamente satura la banda gigabit, sia in "fisico" che in "virtuale", il che significa che fin quando non si ha una infrastruttura da 10Gb è veloce quanto Linux o Windows.

D'altronde se hai macchine a 10Gb quasi certamente hai dati importanti, e quindi... userai zfs lo stesso

[nanotek]

5) non hai più la manfrina dei virus crypto locker e simili

Questa non l'ho capita..

Cosa intendi per "scarse" ???

La prova l'avevo fatta in ufficio: hp microserver gen 7 N40L, 2 gb di ram, 4 hdd 2Tb wd red.
La prova era per vedere se zfs era più performante di un raid mdadm (2 coppie raid 1). Con mdadm riesce a caricare i dati tramite cartella condivisa samba a 80 Mbyte/s al secondo.. con un raid zfs eravamo poco sotto ai 45 Mbyte/s. In lettura invece le velocità erano praticamente uguali, arrivano quasi a saturare la gigabit.
La deduplicazione era attiva. SO Centos 7, samba configurato così come è dopo l'installazione.
Alla fine non mi è parso conveniente su piccoli datastore.. nas per piccoli uffici etc.

Due aspetti che quando ho approcciato zfs per qualche test ho trovato critici:
Aumentare il volume del datastore è impegnativo quasi quanto lo è con mdadm e la ricostruzione del raidZ è indicato da tutti come operazione gravosa sui dischi, tanto quanto lo è la ricostruzione di un raid5. Con alcuni vantaggi per zfs dato che ricostruisce solo i dati.

[zeMMeMMe]

Originariamente inviato da nanotek

Questa non l'ho capita..

Metti snapshot ogni 5 minuti e passa la paura. In sostanza puoi tornare indietro a come erano i file 5 minuti fa, 10 minuti... 15... 1 ora... 3 ore... 2 giorni... 1 settimana... magari 3 mesi fa...
E puoi "browsare" direttamente dalle sottocartelle snapshot dentro .zfs (se abiliti la proprietà), o da tasto destro=>versioni precedenti di Windows.

La prova l'avevo fatta in ufficio: hp microserver gen 7 N40L, 2 gb di ram, 4 hdd 2Tb wd red.
La prova era per vedere se zfs era più performante di un raid mdadm (2 coppie raid 1). Con mdadm riesce a caricare i dati tramite cartella condivisa samba a 80 Mbyte/s al secondo.. con un raid zfs eravamo poco sotto ai 45 Mbyte/s. In lettura invece le velocità erano praticamente uguali, arrivano quasi a saturare la gigabit.
La deduplicazione era attiva. SO Centos 7, samba configurato così come è dopo l'installazione.
Alla fine non mi è parso conveniente su piccoli datastore.. nas per piccoli uffici etc.

E' evidente che con la deduplicazione e una CPU poco potente, e poca RAM, ti sei messo nella situazione peggiore.
Se disattivi la deduplicazione, e magari pure la compressione, le prestazioni sono identiche a Linux anche con una configurazione così leggerina (intendo per saturazione gigabit)

Due aspetti che quando ho approcciato zfs per qualche test ho trovato critici:
Aumentare il volume del datastore è impegnativo quasi quanto lo è con mdadm

A dir la verità è banale

e la ricostruzione del raidZ è indicato da tutti come operazione gravosa sui dischi, tanto quanto lo è la ricostruzione di un raid5. Con alcuni vantaggi per zfs dato che ricostruisce solo i dati.

Qualsiasi operazione che implichi la lettura dell'intero disco è ontologicamente gravosa.

"tutti" spesso (senza offesa) significa "utenti non molto formati"

Per quanto mi riguarda non lo uso praticamente mai (raidz), a favore del semplice ed assai performante mirror, con dischi da 2TB (SSD) e 6TB (magnetici)

Ho una macchina virtuale FreeBSD che gira proprio su uno di quei serverini NL40, virtualizzato, con 8GB di RAM e 4x2TB di dischi Western Digital RE.
Lo uso per fare le replice zfs dei server di produzione con una scheda di rete Intel 10Gb e sono ragionevolmente soddisfatto.

ps non confrontiamo mdadm, e LVM, con zfs.
E' come confrontare vetro e diamanti.
Basta questo (quando si parla di raid >1)

Which brings us to the coolest thing about RAID-Z: self-healing data. In addition to handling whole-disk failure, RAID-Z can also detect and correct silent data corruption. Whenever you read a RAID-Z block, ZFS compares it against its checksum. If the data disks didn't return the right answer, ZFS reads the parity and then does combinatorial reconstruction to figure out which disk returned bad data. It then repairs the damaged disk and returns good data to the application. ZFS also reports the incident through Solaris FMA so that the system administrator knows that one of the disks is silently failing.

[nanotek]

Metti snapshot ogni 5 minuti e passa la paura.

Adesso ho capito.

A dir la verità è banale

La procedura che ho trovato scritta su alcune guide (non l'ho provata) diceva, semplificando, di rimpiazzare un disco alla volta con uno di capacità maggiore, rimpiazzarlo nel pool e lasciare che zfs ricostruisse i dati.. se hai 4 dischi pieni da rimpiazzare può prendere un sacco di tempo.
A meno di qualche comando in più è la stessa procedura che richiede un raid mdadm.

[zeMMeMMe]

Originariamente inviato da nanotek

Adesso ho capito.


La procedura che ho trovato scritta su alcune guide (non l'ho provata) diceva, semplificando, di rimpiazzare un disco alla volta con uno di capacità maggiore, rimpiazzarlo nel pool e lasciare che zfs ricostruisse i dati.. se hai 4 dischi pieni da rimpiazzare può prendere un sacco di tempo.
A meno di qualche comando in più è la stessa procedura che richiede un raid mdadm.

Scusami, e quale "magica" procedura non prevede la copia dei dati su un supporto più grande ?
Se rifletti bene vedrai che c'è poco da fare.
Il resilvering di raidz si differenzia per 2 elementi basiliari: da un lato ti dà la CERTEZZA che i dati ricostruiti siano identici a quello di partenza (cosa che mdadm non dà), e poi che nel caso di fail multipli (entro certi limiti) i dati riscostruiti sono di nuovo con CERTEZZA corretti.

Usando GUI (tipo zfsguru) non c'è molto più da fare di un paio di click

[nanotek]

Scusami, e quale "magica" procedura non prevede la copia dei dati su un supporto più grande ?
Se rifletti bene vedrai che c'è poco da fare.

Al pari di una ricostruzione di un raid sia esso gestito da controller dedicato che da mdadm.
E' banale ma fa' perdere un sacco di tempo.

Raidz non lo usi mai e consigli il mirroring e su questo mi trovi daccordo ma:

fail multipli (entro certi limiti)

Se il datastore è piccolo i fail multipli portano comunque alla perdita dei dati. Es. fail multiplo in coppie in mirroring.
Usare tre dischi in mirroring su un set di 4 non è efficiente.
Quindi è un vantaggio ma non per chi deve fare un datastore con 4 dischi in un microserver.

Per quanto riguarda il discorso snapshot volevo farti una domanda:
Esiste un comando per ripristinare una selezione di file alla loro ultima versione contenuta nello snapshot (quindi ultima modifica, perchè se non c'è modifica non viene fatto)?
Te lo chiedo perchè tempo fa' sono intervenuto in una azienda dove un un cryptolocker aveva corrotto circa 5 Gb di dati però in diversi giorni (10 giorni).
Il problema non è stato recuperare i dati, c'era il backup di tutto, ma andare a spulciare ogni backup giornaliero per capire quale era l'ultima versione del file buona (distinguibile perchè il cryptolocker cambiava le estensioni in .encrypted). Non si poteva ripristinare di colpo uno o l'altro backup perchè i file erano stati corrotti in giorni diversi.

[zeMMeMMe]

Originariamente inviato da nanotek

Al pari di una ricostruzione di un raid sia esso gestito da controller dedicato che da mdadm.
E' banale ma fa' perdere un sacco di tempo.

E' inevitabile

Raidz non lo usi mai e consigli il mirroring e su questo mi trovi daccordo ma...

Nel microserver si mettono facilmente almeno 5 hard disk, usando una porta SATA "vuota" sulla scheda madre

Per quanto riguarda il discorso snapshot volevo farti una domanda:
Esiste un comando per ripristinare una selezione di file alla loro ultima versione contenuta nello snapshot (quindi ultima modifica, perchè se non c'è modifica non viene fatto)?
Te lo chiedo perchè tempo fa' sono intervenuto in una azienda dove un un cryptolocker aveva corrotto circa 5 Gb di dati però in diversi giorni (10 giorni).
Il problema non è stato recuperare i dati, c'era il backup di tutto, ma andare a spulciare ogni backup giornaliero per capire quale era l'ultima versione del file buona (distinguibile perchè il cryptolocker cambiava le estensioni in .encrypted). Non si poteva ripristinare di colpo uno o l'altro backup perchè i file erano stati corrotti in giorni diversi.

Non mi è chiarissima la domanda, se interpreto bene basta guardare dentro .zfs, da lì puoi fare banalmente copia-incolla.
Puoi anche cercare con normali programmi tutti i file con l'estensione che vuoi (quindi non .encrypted).

Anzi bisogna porre particolare attenzione ad escludere tale cartella dai backup, per evitare di avere una crescita spropositata.