Ciao a tutti
Ho un nuovo portatile e leggendo qui e la mi pare che zfs sia tecnologicamente superiore praticamente in tutti gli aspetti rispetto al classico LVM + luks
In particolare la possibiltà di creare snapshot e inviarli tramite send a un eventuale server zfs mi pare quasi possa essere il sacro graal del backup. Se ho capito bene
Il portatile ha 16 gb di ram quindi dovrebbe essere sufficiente a livello di risorse hardware
I dubbi nascono ovviamente dalla mancanza di supporto sia kernel sia di distribuzione
Leggiucchiando qualche guida pare che installare slackware su zfs sia una bella mole di lavoro
Tra l'altro mi pare servirebbe adattare anche qualcuno degli script di avvio (nonché mantenere le patch in caso di upgrade)
Poi c'è ovviamente il problema del bootloader. Pare che la soluzione migliore ad oggi sia ZFSBootMenu
Ma con il fatto che ad ogni kernel upgrade ci sia da ricompilare il modulo e ricreare l'initrd vedo già dei disastri all'orizzonte
Per cui in particolare mi chiedevo se fosse possibile aggiungere il comando zfs all'initrd, in modo che in caso di boot failure si possa riuscire a ristorare un vecchio snapshot funzionante. Il tutto anche tenendo conto del fatto che ho intenzione di criptare il disco
Non so il tutto mi sembra una bella avventura, forse anche un po' troppo rischiosa
Qualcuno per caso ha esperienza in generale con ZFS e Slackware?
Secondo voi ne vale la pena o meglio rimanere su LVM +LUKS?
Grazie
Slackware on ZFS
Moderatore: Staff
Regole del forum
1) Citare sempre la versione di Slackware64 usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Slackware64, se l'argomento è Slackware32 o generale usate rispettivamente il forum Slackware o Gnu/Linux in genere.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Citare sempre la versione di Slackware64 usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Slackware64, se l'argomento è Slackware32 o generale usate rispettivamente il forum Slackware o Gnu/Linux in genere.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Re: Slackware on ZFS
Partiamo da un presupposto: Snapshots e backup sono due cose differenti.
I backup sono pensati che per archiviare copie consistenti del dato a lungo termine.
Gli snapshots sono pensati per replicare in situazioni di Disaster Recovery.
Detto ciò, ZFS non è un mero file system.
È una soluzione di storage pensata per ambienti SAN, le cui LUN vengono esportate in iSCSI o Fiber Channel, e i dataset vengono condivisi tramite NFS e SMB.
Per quello è stato pensato fin dall’inizio con le ACL NFSv4 che sono basate su quelle di Windows, supportando quelle POSIX tramite interfacce di compatibilità.
Per quanto certa gente si ostini a volerlo usare come file system di root immaginando chissà quali benefit, ZFS non è pensato per quello.
ZFS è pensato per gestire enormi moli di dati su storage pool basate su dischi multipli in setup di tipo RAID e con grandi quantità di memoria ECC.
Grandi quantità di memoria perché, come tutte le soluzioni storage, è pensato per comprimere e deduplicare i dati.
ECC perché una soluzione di storage senza controllo dí parità in memoria PRIMA della scrittura può servire a ben poco, per prevenire la corruzione dei dati.
In aggiunta alle funzionalità di RAID, che permettono il controllo di parità a livello di disco poi (RAIDZ 1/2/3, equivalenti ai RAID 5/6), ZFS è in grado di fare self-healing.
In sostanza usarlo per la root del sistema operativo è una roba del tutto inutile.
Se proprio vuoi usarlo, usalo su un NAS per il pool dei dati. Quello è il suo posto.
Per il normale sistema operativo LVM è più che sufficiente.
ANZI, è il caso d’uso normale anche lato server se si fa boot da SAN.
Lo storage server con ZFS esporta la catena di LUN via Fiber Channel/iSCSI, e il server target vede la catena e la usa con LVM, costruendo il volume group da cui fare il boot.
TL;DR non perder tempo con una soluzione overkilled per quello che devi fare.
Se proprio vuoi giocare con gli snapshots, c’è BTRFS in Slackware.
Meno sbattimento, meno funzionalità che non ti servono e integrazione nativa.
I backup sono pensati che per archiviare copie consistenti del dato a lungo termine.
Gli snapshots sono pensati per replicare in situazioni di Disaster Recovery.
Detto ciò, ZFS non è un mero file system.
È una soluzione di storage pensata per ambienti SAN, le cui LUN vengono esportate in iSCSI o Fiber Channel, e i dataset vengono condivisi tramite NFS e SMB.
Per quello è stato pensato fin dall’inizio con le ACL NFSv4 che sono basate su quelle di Windows, supportando quelle POSIX tramite interfacce di compatibilità.
Per quanto certa gente si ostini a volerlo usare come file system di root immaginando chissà quali benefit, ZFS non è pensato per quello.
ZFS è pensato per gestire enormi moli di dati su storage pool basate su dischi multipli in setup di tipo RAID e con grandi quantità di memoria ECC.
Grandi quantità di memoria perché, come tutte le soluzioni storage, è pensato per comprimere e deduplicare i dati.
ECC perché una soluzione di storage senza controllo dí parità in memoria PRIMA della scrittura può servire a ben poco, per prevenire la corruzione dei dati.
In aggiunta alle funzionalità di RAID, che permettono il controllo di parità a livello di disco poi (RAIDZ 1/2/3, equivalenti ai RAID 5/6), ZFS è in grado di fare self-healing.
In sostanza usarlo per la root del sistema operativo è una roba del tutto inutile.
Se proprio vuoi usarlo, usalo su un NAS per il pool dei dati. Quello è il suo posto.
Per il normale sistema operativo LVM è più che sufficiente.
ANZI, è il caso d’uso normale anche lato server se si fa boot da SAN.
Lo storage server con ZFS esporta la catena di LUN via Fiber Channel/iSCSI, e il server target vede la catena e la usa con LVM, costruendo il volume group da cui fare il boot.
TL;DR non perder tempo con una soluzione overkilled per quello che devi fare.
Se proprio vuoi giocare con gli snapshots, c’è BTRFS in Slackware.
Meno sbattimento, meno funzionalità che non ti servono e integrazione nativa.
Re: Slackware on ZFS
Ciao, scusami per la tarda risposta.
Alla fine ho finito per mettere zfs nel portatile, anche se purtroppo non ho avuto ancora tempo di giocarci per niente praticamente
Detto ciò ti ringrazio per la risposta e ti spiego meglio quello che intendevo
Quello su cui cercavo di chiarirmi era la possibile combinazione di snapshot e backup che zfs permetterebbe
"In particolare la possibiltà di creare snapshot e inviarli tramite send a un eventuale server zfs mi pare quasi possa essere il sacro graal del backup"
E ti spiego meglio questa affermazione del mio post originale
Normalmente uso il classico backup con hard link + rsync su lvm + raid, ossia tutte le tecnologie linux storiche o come le vogliamo chiamare
Gli hard link permettono una ottimizzazione a livello di filesystem copia per quanto riguarda la gestione dei backup incrementali di cui mantengo versioni sia mensili sia annuali sia giornaliere che vengono gestite e configurate da uno script bash nel mio caso
A livello di filesystem sorgente come potrai immaginare rsync si prende il suo tempo per leggere il filtro, controllare i timestamp, e generare l'incremental file list, dal momento che agisce su un layer superiore al file system (nel mio caso xfs). In caso vengano modificati file di grandi dimensioni rsync deve anche andare a guardarsi i checksum dei blocchi sul server remoto, confrontarli con i checksum locali che deve ricalcolarsi.... insomma deve andare a farsi il reverse engineering del layer inferiore se vogliamo, con un inutile consumo di risorse
E, per inciso, sarebbe impensabile sul mio hardware fallo agire sull'intero disco senza filtri
Mentre invece gli snapshot zfs sono praticamente instantanei e globali. E tutto avviene in maniera locale dato che la cronologia degli snapshot viene mantenuta anche sul client
Questo di suo forse sarebbe già un bel vantaggio, ma mi pare che i vantaggi che zfs possa offrire siano ben superiori
Innanzitutto il mio script backup viene avviato tramite anacron nel bel mezzo di chissà cosa sto facendo, con la possibilità che mentre rsync fa il suo scan & copy magari il famoso file di qualche GB viene modificato (tipo immagine di vm), con chissà quale conseguenza. Mentre invece nel caso di zfs gli snapshot sono gestiti direttamente dal fs e sono atomici
Non solo. Perché snapshot a parte, zfs sostituirebbe rsync anche nella fase di copia incrementale remota tramite il send verso un server nas zfs, come appunto dicevo. Questo avrebbe vantaggi enormi rispetto a rsync + hard link
Per esempio, mettiamo che perda il portatile. Potrei semplicemente comprarne uno nuovo e fare il receive del dataset dal nas, ottenendo un restore praticamente indolore, preservando tutti gli attributi e anche la cronologia degli snapshot, con un comando solo
Senza contare la crittografia. Il backup dello snapshot tramite send se ho capito bene si può fare anche a livello di blocchi, mantenendo la crittografia e l'incrementalità anche sul nas, e su eventuali futuri restore
Insomma mi pare che zfs incorpori luks, lvm, raid, rsync e in più aggiunge performance ben superiori, compressione, crittografia nativa e atomicità
E secondo me anche comodità e semplicità d'uso alla fine invece di smanettare con 5 software diversi
Per quello parlavo di sacro graal del backup
Poi come ti dicevo purtroppo non ho ancora avuto il tempo di implementare niente di ciò che ho detto
Alla fine ho finito per mettere zfs nel portatile, anche se purtroppo non ho avuto ancora tempo di giocarci per niente praticamente
Detto ciò ti ringrazio per la risposta e ti spiego meglio quello che intendevo
Si questo è chiaro graziehashbang ha scritto:Partiamo da un presupposto: Snapshots e backup sono due cose differenti.
I backup sono pensati che per archiviare copie consistenti del dato a lungo termine.
Gli snapshots sono pensati per replicare in situazioni di Disaster Recovery.
Quello su cui cercavo di chiarirmi era la possibile combinazione di snapshot e backup che zfs permetterebbe
"In particolare la possibiltà di creare snapshot e inviarli tramite send a un eventuale server zfs mi pare quasi possa essere il sacro graal del backup"
E ti spiego meglio questa affermazione del mio post originale
Normalmente uso il classico backup con hard link + rsync su lvm + raid, ossia tutte le tecnologie linux storiche o come le vogliamo chiamare
Gli hard link permettono una ottimizzazione a livello di filesystem copia per quanto riguarda la gestione dei backup incrementali di cui mantengo versioni sia mensili sia annuali sia giornaliere che vengono gestite e configurate da uno script bash nel mio caso
A livello di filesystem sorgente come potrai immaginare rsync si prende il suo tempo per leggere il filtro, controllare i timestamp, e generare l'incremental file list, dal momento che agisce su un layer superiore al file system (nel mio caso xfs). In caso vengano modificati file di grandi dimensioni rsync deve anche andare a guardarsi i checksum dei blocchi sul server remoto, confrontarli con i checksum locali che deve ricalcolarsi.... insomma deve andare a farsi il reverse engineering del layer inferiore se vogliamo, con un inutile consumo di risorse
E, per inciso, sarebbe impensabile sul mio hardware fallo agire sull'intero disco senza filtri
Mentre invece gli snapshot zfs sono praticamente instantanei e globali. E tutto avviene in maniera locale dato che la cronologia degli snapshot viene mantenuta anche sul client
Questo di suo forse sarebbe già un bel vantaggio, ma mi pare che i vantaggi che zfs possa offrire siano ben superiori
Innanzitutto il mio script backup viene avviato tramite anacron nel bel mezzo di chissà cosa sto facendo, con la possibilità che mentre rsync fa il suo scan & copy magari il famoso file di qualche GB viene modificato (tipo immagine di vm), con chissà quale conseguenza. Mentre invece nel caso di zfs gli snapshot sono gestiti direttamente dal fs e sono atomici
Non solo. Perché snapshot a parte, zfs sostituirebbe rsync anche nella fase di copia incrementale remota tramite il send verso un server nas zfs, come appunto dicevo. Questo avrebbe vantaggi enormi rispetto a rsync + hard link
Per esempio, mettiamo che perda il portatile. Potrei semplicemente comprarne uno nuovo e fare il receive del dataset dal nas, ottenendo un restore praticamente indolore, preservando tutti gli attributi e anche la cronologia degli snapshot, con un comando solo
Senza contare la crittografia. Il backup dello snapshot tramite send se ho capito bene si può fare anche a livello di blocchi, mantenendo la crittografia e l'incrementalità anche sul nas, e su eventuali futuri restore
Insomma mi pare che zfs incorpori luks, lvm, raid, rsync e in più aggiunge performance ben superiori, compressione, crittografia nativa e atomicità
E secondo me anche comodità e semplicità d'uso alla fine invece di smanettare con 5 software diversi
Per quello parlavo di sacro graal del backup
Poi come ti dicevo purtroppo non ho ancora avuto il tempo di implementare niente di ciò che ho detto
Ah ecco ecco non sapevo. Ma scusa non perdi molti vantaggi di zfs se lo usi solamente come block device su cui metti sopra lvm?hashbang ha scritto:ANZI, è il caso d’uso normale anche lato server se si fa boot da SAN.
Lo storage server con ZFS esporta la catena di LUN via Fiber Channel/iSCSI, e il server target vede la catena e la usa con LVM, costruendo il volume group da cui fare il boot.