Soluzione 1:
Perché non dare un'occhiata alla sezione delle istantanee di LVM-HOWTO?
Le istantanee LVM sono la tua soluzione istantanea "copia su scrittura" di base. L'istantanea non è altro che chiedere a LVM di darti un "puntatore" allo stato corrente del filesystem e di scrivere le modifiche apportate dopo l'istantanea in un'area designata.
Le istantanee LVM "vivono" all'interno del gruppo di volumi che ospita il volume soggetto all'istantanea, non un altro volume. La tua affermazione "... un sacco di spazio libero non allocato non è la partizione" fa sembrare che il tuo pensiero sia che le istantanee "vivano" al di fuori del gruppo di volumi soggetto all'istantanea, e questo non è accurato. Il tuo gruppo di volumi si trova in una partizione del disco rigido e il volume è soggetto a snapshot e a qualsiasi shapshot che hai eseguito in quel gruppo di volumi.
Il modo normale in cui vengono utilizzate le istantanee LVM non è per l'archiviazione a lungo termine, ma piuttosto per ottenere una "immagine" coerente del filesystem in modo tale da poter eseguire un backup. Al termine del backup, lo snapshot viene eliminato.
Quando crei un'istantanea LVM, designi una quantità di spazio per contenere tutte le modifiche apportate mentre l'istantanea è attiva. Se vengono apportate più modifiche rispetto a quelle designate, lo spazio per l'istantanea diventa inutilizzabile e deve essere eliminato. Non vuoi lasciare gli snapshot in giro perché (a) si riempiono e diventano inutilizzabili e (b) le prestazioni del sistema ne risentono mentre uno snapshot è attivo:le cose diventano più lente.
Modifica:
Ciò che fanno i servizi Microsoft Volume Shadow Copy e gli snapshot LVM non sono molto diversi. La soluzione di Microsoft è un po' più completa (come accade in genere con Microsoft:nel bene e nel male i loro strumenti e prodotti spesso cercano di risolvere problemi piuttosto grandi invece di concentrarsi su una sola cosa).
VSS è una soluzione più completa che unifica il supporto per dispositivi hardware che supportano snapshot e snapshot basati su software in un'unica API. Inoltre, VSS dispone di API per consentire alle applicazioni di essere rese inattive tramite le API snapshot, mentre le istantanee LVM riguardano solo le istantanee:qualsiasi applicazione inattiva è il tuo problema (mettere i database in stati di "backup", ecc.).
Soluzione 2:
Gli snapshot LVM sono un esempio di una soluzione di snapshot copy-on-write, come ha affermato Evan. Il modo in cui funziona è un po' diverso da quello implicito di Evan, ma non di molto.
Quando si dispone di un volume LVM senza istantanee, le scritture sul volume avvengono come previsto. Un blocco viene modificato e basta.
Non appena crei uno snapshot, LVM crea un pool di blocchi. Questo pool contiene anche una copia completa dei metadati LVM del volume. Quando si verificano scritture sul volume principale, come l'aggiornamento di un inode, il blocco che viene sovrascritto viene copiato in questo nuovo pool e il nuovo blocco viene scritto nel volume principale. Questo è il "copia su scrittura". Per questo motivo, più dati vengono modificati tra il momento in cui è stata acquisita una snapshot e lo stato corrente del volume principale, più spazio verrà consumato da quel pool di snapshot.
Quando si monta lo snapshot, i metadati scritti quando è stato acquisito lo snapshot consentono la mappatura dei blocchi del pool di snapshot sui blocchi modificati nel volume (o snapshot di livello superiore). In questo modo, quando arriva un accesso per un blocco specifico, LVM sa quale blocco accede. Per quanto riguarda il filesystem su quel volume, non ci sono istantanee.
James ha sottolineato uno dei difetti di questo sistema. Quando si hanno più snapshot dello stesso volume, ogni volta che si scrive su un blocco nel volume principale si attivano potenzialmente scritture in ogni singolo snapshot. Questo perché ogni snapshot mantiene il proprio pool di blocchi modificati. Inoltre, per lunghi alberi di istantanee, l'accesso a uno snapshot può causare un bel po' di calcoli sul server per capire quale blocco esatto deve essere servito per un accesso.
Quando elimini un'istantanea, LVM elimina semplicemente il pool di istantanee e aggiorna l'albero delle istantanee secondo necessità. Se l'istantanea rilasciata fa parte di un albero di istantanee, alcuni blocchi verranno copiati nell'istantanea di livello inferiore. Se è l'istantanea più bassa (o l'unica), il pool viene eliminato e l'operazione è molto veloce.
Alcuni file system offrono istantanee nel file system, ZFS e BTRFS sono solo due dei più noti. Funzionano in modo simile, sebbene il filesystem stesso gestisca la mappatura modificata/non modificata. Questo è probabilmente un modo migliore per farlo poiché puoi eseguire il fsck di un'intera famiglia di snapshot per coerenza, cosa che non puoi fare con LVM direttamente.
Soluzione 3:
Le istantanee LVM sono inefficienti, più istantanee ci sono più lento sarà il sistema.
Supporto solo xfs perché è ciò che usiamo e xfs_freeze può essere utilizzato per bloccare nuovi accessi al file system e creare un'immagine stabile su disco.
Copia su scrittura viene utilizzato in modo che lo spazio su disco venga utilizzato in modo efficiente.
Hai creato un filesystem in un volume logico che contiene spazio libero per gli snapshot.
Questo è un esempio tratto dalle FAQ
Soluzione 4:
Non si specifica se si utilizza Linux o HP-UX. In HP-UX, si crea un volume logico e lo si monta come un'istantanea di un altro volume logico. In Linux, crei un volume logico come volume snapshot.
La rimozione di un'istantanea in HP-UX viene eseguita smontando il volume; in Linux è fatto usando lvremove per rimuovere il volume logico.
In ogni caso, le modifiche sono l'unica cosa che viene memorizzata sulla tua istantanea. Più a lungo l'istantanea rimane disponibile, più modifiche vengono immagazzinate e c'è la possibilità che si riempia se non viene ridimensionata o rilasciata correttamente.
La velocità di accesso al disco su un volume snapshot è più lenta rispetto a un volume normale; devi tenerne conto.