Per quanto ne so, LVM rende possibile scattare istantanee di un volume. Esistono anche numerosi file system (ZFS, Btrfs, reiserfs, ...) che supportano le istantanee.
Tuttavia, non ho mai capito la differenza tra snapshot LVM e snapshot del file system. Se è possibile scattare istantanee con LVM, perché qualcuno impiega il proprio tempo per implementarlo in un file system?
Modifica: qualcuno di loro è preferito in alcune situazioni? Perché?
Risposte:
La maggior parte di queste istantanee sono istantanee copia-su-scrittura, che sono molto veloci e molto economiche (dal punto di vista dell'archiviazione) su sistemi raramente aggiornati. Le snapshot LVM sono snapshot COW, ZFS / BTRFS hanno entrambe una modalità COW per snapshot, reiserfs non ha snapshot nativamente, il file system NSS di Novell è anche COW, così come i volumi Shadow Copy per volumi Windows NTFS.
Le istantanee copia su scrittura eseguono una copia dei metadati del volume di destinazione nel pool di istantanee. Quindi, a seconda della modalità di COW in uso, copiano i dati che verrebbero sovrascritti da nuove scritture nel pool di snapshot prima di scrivere i nuovi dati.
ZFS e (eventualmente se non già presente) BTRFS dispongono di funzionalità di snapshot completo, utile per lo snap su supporti separati, che a sua volta è molto utile per i sistemi di backup di sneakernet che utilizzano supporti rimovibili. ZFS non lo definisce "istantanea", ma sfrutta la capacità di ZFS di utilizzare zfs sende zfs recvcopiare volumi e istantanee sulla rete su un host remoto (o array locale).
Preferisco le capacità di snapshot a livello di filesystem rispetto a quelle LVM perché mi fido maggiormente del filesystem stesso per gestire il processo in modo pulito. Tuttavia, in mancanza del supporto diretto del filesystem, LVM dovrebbe funzionare bene nella maggior parte dei casi.
Le snapshot COW sono utili se è necessario un backup temporizzato eseguito molto velocemente per esigenze di ripristino a breve termine. Come fare uno scatto giornaliero o 4x giornaliero, da conservare per una settimana. Ciò è utile se è necessario ripristinare i file eliminati accidentalmente dagli utenti o se è necessario ripristinare un intero sistema in una configurazione pre-aggiornamento. Possono anche essere utilizzati da alcuni sistemi di backup come filesystem completamente sospeso, quindi i backup prelevati dal volume dell'istantanea non devono preoccuparsi che i file aperti si frappongano . La cosa fondamentale da ricordare è che i volumi di snapshot saranno nella stessa memoria del volume primario, quindi non dare nulla in caso di errore dell'array.
Le istantanee COMPLETE sono buone se vengono portate su supporti rimovibili o remoti di qualche tipo. Se si dispone di uno storage di rete, la destinazione potrebbe essere un array iSCSI o Fibre Channel diverso da quello in cui è ospitato lo storage primario. Ciò offre una protezione off-array per alcuni tipi di guasti. Se si utilizzano supporti rimovibili, come un'unità ESATA da 3 TB, è anche possibile utilizzarlo come un semplice sistema di backup su disco. Queste istantanee POSSONO essere su hardware diverso rispetto ai loro fratelli COW, quindi sono utili per la resilienza ai disastri.
Sugli snapshot Full vs COW.
Il termine "snapshot" è leggermente cambiato negli anni. Quest'anno, sono abbastanza sicuro che significhi "una copia Copy-On-Write dei dati originali usando il riposizionamento dei blocchi". Con questa definizione, lo snapshot "Full" presentato sopra non è in realtà uno snapshot, è una replica. Alcuni fornitori di archiviazione hanno utilizzato diverse definizioni di "snapshot" in passato per descrivere varie operazioni a livello di blocco che eseguono. Dove si crea confusione sono i sistemi che utilizzano le snapshot come parte del processo di replica.
LVM richiede una pianificazione preliminare. Tendo a non usarlo perché è anche un altro livello di astrazione ed è raramente disponibile quando ne ho bisogno. Tuttavia, ci sono altre opzioni per clonare a livello di filesystem (in Linux) senza LVM. A tale scopo, è possibile utilizzare Hot Copy da R1Soft . È un modulo del kernel, ma ti consente di aggiungere questa funzionalità al volo.
Problema molto chiaro: gli snapshot di LVM non sono garantiti per avere una jue FS coerente a causa di LVM "non sa" nulla di FS con cui viene caricato
Modificato (vedere i commenti): - vero a meno che FS non abbia il supporto .freeze_fs, altrimenti dovrebbe essere gestito da FS con garbo.
sync, lo snapshot è un duplicato esatto di un filesystem già montato; quindi quando lo monti, appare come 'non smontato in modo pulito' (perché non è stato smontato) e deve fare qualche azione correttiva prima che sia coerente. Naturalmente, questo è in genere solo un replay del journal e dopo il sync, dovrebbe essere un replay vuoto; quindi non c'è pericolo di perdita di dati.
xfs_freeze is intended to be used with volume managers and hardware RAID devices that support the creation of snapshots.) - cosa speciale per le istantanee, LVM-2 lo sa e lo usa già? 3) Dimmi dove o nello spazio utente ( sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/?cvsroot=lvm2 ) o nelle fonti del kernel posso dimostrare che hai ragione nel dirci che LVM ha prodotto FS per sync.
lock a filesystem and force it into a consistent state. Quindi, almeno posso dire che probabilmente ho sbagliato a dire "non è garantito che abbia FS coerente", poiché si tratta del supporto del 'metodo' di freeze_fs all'interno dell'implementazione di FS - alcuni FS certamente hanno un tale supporto (EXT3, Reiser3, XFS), e alcuni no (EXT2, per esempio). Inoltre, risponde alla seconda domanda: è molto probabile che il blocco di XFS venga gestito automaticamente con LVM.
A complemento di altre risposte. Nelle istantanee FS puoi beneficiare di funzionalità FS come la compressione e la deduplicazione in tutte le istantanee.