slacky.eu

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

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.

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

hashbang 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.

Si questo è chiaro grazie
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

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.

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?

cressida ha scritto: ↑

sab 11 lug 2026, 19:26

Si questo è chiaro grazie
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"

Però quello non è un backup.
È mera replica del dato. ZFS snapshots con send/recv non è pensato per archiviazione a lungo termine.
È pensato per garantire continuità in caso di fallimento in una configurazione in HA.

Per questo snapshots e backup sono cose diverse.
I backup sono copie offline a lungo termine archiviate su dispositivi pensati per durata.
Le repliche sono copie online a breve termine posizionate su uno storage in stand-by, che diventa produzione in caso di fallimento del primario e sono posizionate sulla stessa tipologia di dischi dello storage primario. Ergo, potenzialmente all-flash, per garantire alti IOPS.

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?

No, perché ZFS non è nato per fare da file system di root, ma è nato per fare da storage in ambienti SAN.
I suoi concorrenti non sono EXT4 o XFS, ma NetApp, VMAX ecc.

ZFS è pensato per fornire storage ad altri server, non a se stesso.

I cosiddetti dataset, infatti, sono directory che vengono condivise con NFSv4/SMB, mentre gli ZVOL sono LUN da esporre in Fiber Channel/iSCSI.

Per quello ZFS di default non è nemmeno POSIX. ZFS usa le NFSv4 ACL, che sono di derivazione Windows NT, con un substrato di retrocompatibilità per POSIX. Proprio per permettere condivisioni SMB e NFSv4 fornendo compatibilità assoluta con i client Windows che vedono quelle share.
Su Windows addirittura ZFS fa da backend a Volume Shadow Copies.
Naturalmente Linux non supporta le ACL NFSv4 a livello di OS, a differenza di Solaris, dove ZFS è nato, e FreeBSD, quindi ZFS rimane mezzo monco su questa piattaforma.

Per il normale server, LVM è una soluzione molto più economica e funzionale, dal punto di vista delle operazioni ordinarie.
In un server ti basta una catena SCSI con le LUN aggreggate, e poi usare LVM per partizionarle.
Non hai bisogno di compressione, deduplicazione o cifratura a livello di I/O, che riducono notevolmente il carico di IOPS.
Su un server o fai cifratura at rest (LUKS) o cifratura per file (GPG).

E i backup si fanno sul server, o sfruttando solo il backup dei dati su dispositivi a lungo termine (HDD o LTO), oppure facendo un dump dell'intero volume per garantire consistenza.
Mentre la replica, per garantire HA lo fai con le replica (ZFS send/recv).

Il motivo per il quale ZFS è stato sdoganato come FS di root è che:
1) Solaris non ha LVM, a differenza di AIX e HP-UX. E FreeBSD idem.
Su Solaris si usava VERITAS per sopperire, prima ZFS.

2) Sun all'epoca aveva bisogno di cartine tornasole per sponsorizzare OpenSolaris.
Quindi usava ZFS e DTrace come punte di diamante.
Addirittura su OpenSolaris c'era l'integrazione con ZFS e GNOME per permettere il recupero di file rapido, emulando quello che nel mondo Apple si faceva con Time Capsule, chiamato Time Slider.
E Sun usò gli snapshot di ZFS per creare i Boot Environment per permettere rollback rapidi in caso di aggiornamento.

Ma come dicevo, questi non sono gli usi di ZFS, che rimane overkilled per ambienti non enterprise.
ZFS è nato per essere usato in combinazione con COMSTAR e FMA. FreeBSD, dato che non ha FMA, ha creato zfsd.
Specialmente perché ZFS non è pensato per configurazioni single disk, ma configurazioni multi-disco con RAIDZ o mirroring, combinate con memoria ECC per garantire correttezza dei dati. Per quello si usa in combinazione con FMA/zfsd, che garantiscono monitoraggio continuo di fault hardware o di sistema che possono compromettere l'integrità dello storage.

In sostanza, se vuoi usare gli snapshots, BTRFS è una soluzione migliore, perché è un file system che non è pensato per fare da storage SAN, quindi non la ha complessità di ZFS (es. non ci sono ZVOL su BTRFS), e puoi usare snapshots e reflinks utili su Linux.
Meno sbattimento, totale supporto, e funziona bene anche single-disk. Anzi, BTRFS multi disco funziona solo in RAID 0/1/10. Quindi sei perfetto per un laptop o un NAS domestico.

Non buttare tempo su soluzioni che non to danno reale valore aggiunto, a meno che non stai studiando perché le devi usare per lavoro.