Solusi 1:
Mengapa tidak melihat bagian snapshot dari LVM-HOWTO?
Snapshot LVM adalah solusi snapshot "copy on write" dasar Anda. Snapshot sebenarnya tidak lebih dari meminta LVM untuk memberi Anda "penunjuk" ke status sistem file saat ini dan untuk menulis perubahan yang dibuat setelah snapshot ke area yang ditentukan.
Snapshot LVM "langsung" di dalam grup volume yang menghosting volume yang tunduk pada snapshot-- bukan volume lain. Pernyataan Anda "... banyak dan banyak ruang kosong yang tidak terisi, bukan partisi" membuatnya terdengar seperti pemikiran Anda bahwa snapshot "hidup" di luar grup volume tunduk pada snapshot, dan itu tidak akurat. Grup volume Anda berada di partisi hard disk, dan volume tunduk pada snapshot dan setiap shapshot yang Anda ambil langsung di grup volume tersebut.
Cara normal snapshot LVM digunakan bukan untuk penyimpanan jangka panjang, melainkan untuk mendapatkan "gambaran" yang konsisten dari sistem file sehingga cadangan dapat diambil. Setelah pencadangan selesai, snapshot akan dibuang.
Saat Anda membuat snapshot LVM, Anda menetapkan sejumlah ruang untuk menampung setiap perubahan yang dilakukan saat snapshot aktif. Jika lebih banyak perubahan dilakukan daripada yang telah Anda tetapkan, ruang untuk snapshot menjadi tidak dapat digunakan dan harus dibuang. Anda tidak ingin meninggalkan snapshot karena (a) snapshot akan penuh dan menjadi tidak dapat digunakan, dan (b) kinerja sistem terpengaruh saat snapshot aktif-- semuanya menjadi lebih lambat.
Sunting:
Apa yang dilakukan Microsoft Volume Shadow Copy Services dan snapshot LVM tidak jauh berbeda. Solusi Microsoft sedikit lebih komprehensif (seperti yang biasanya terjadi pada Microsoft-- untuk alat dan produk mereka yang lebih baik atau lebih buruk sering kali berupaya memecahkan masalah yang cukup besar dibandingkan berfokus pada satu hal).
VSS adalah solusi yang lebih komprehensif yang menyatukan dukungan untuk perangkat keras yang mendukung snapshot dan snapshot berbasis perangkat lunak ke dalam satu API. Selain itu, VSS memiliki API untuk memungkinkan aplikasi dibuat diam melalui snapshot API, sedangkan snapshot LVM hanya berkaitan dengan snapshot-- aplikasi quiescing apa pun adalah masalah Anda (menempatkan database ke status "cadangan", dll).
Solusi 2:
Snapshot LVM adalah contoh solusi snapshot copy-on-write, seperti kata Evan. Cara kerjanya sedikit berbeda dari yang tersirat dari Evan, tetapi tidak banyak.
Saat Anda memiliki volume LVM tanpa snapshot, penulisan ke volume terjadi seperti yang Anda harapkan. Sebuah blok diubah, dan hanya itu.
Segera setelah Anda membuat snapshot, LVM membuat kumpulan blok. Kumpulan ini juga berisi salinan lengkap dari metadata LVM volume. Ketika penulisan terjadi pada volume utama seperti memperbarui inode, blok yang sedang ditimpa akan disalin ke kumpulan baru ini dan blok baru ditulis ke volume utama. Ini adalah 'copy-on-write'. Oleh karena itu, semakin banyak data yang diubah antara pengambilan snapshot dan status volume utama saat ini, semakin banyak ruang yang akan digunakan oleh kumpulan snapshot tersebut.
Saat Anda memasang snapshot, meta-data yang ditulis saat snapshot diambil memungkinkan pemetaan blok kumpulan snapshot di atas blok yang diubah dalam volume (atau snapshot tingkat yang lebih tinggi). Dengan cara ini ketika akses datang untuk blok tertentu, LVM mengetahui akses blok mana. Sejauh menyangkut sistem file pada volume itu, tidak ada snapshot.
James menunjukkan salah satu kesalahan dari sistem ini. Saat Anda memiliki beberapa snapshot dari volume yang sama, setiap kali Anda menulis ke blok di volume utama, Anda berpotensi memicu penulisan di setiap snapshot. Ini karena setiap snapshot mempertahankan kumpulan blok yang diubah sendiri. Selain itu, untuk hierarki snapshot yang panjang, mengakses snapshot dapat menyebabkan komputasi yang cukup banyak di server untuk mengetahui blok persis mana yang perlu dilayani untuk akses.
Saat Anda membuang snapshot, LVM hanya menghapus kumpulan snapshot dan memperbarui struktur snapshot sesuai kebutuhan. Jika snapshot yang dijatuhkan adalah bagian dari pohon snapshot, beberapa blok akan disalin ke snapshot tingkat yang lebih rendah. Jika itu snapshot terendah (atau satu-satunya), kumpulan akan dihapus begitu saja dan operasinya sangat cepat.
Beberapa sistem file memang menawarkan snapshot dalam sistem file, ZFS dan BTRFS hanyalah dua dari yang lebih dikenal. Mereka bekerja dengan cara yang sama, meskipun sistem file itu sendiri mengelola pemetaan yang diubah/tidak diubah. Ini bisa dibilang cara yang lebih baik untuk melakukannya karena Anda dapat melakukan fsck seluruh keluarga snapshot untuk konsistensi, yang merupakan sesuatu yang tidak dapat Anda lakukan dengan LVM langsung.
Solusi 3:
Snapshot LVM tidak efisien, semakin banyak snapshot semakin lambat sistem berjalan.
Saya hanya mendukung xfs seperti yang kami gunakan dan xfs_freeze dapat digunakan untuk menghentikan akses baru ke sistem file dan membuat image stabil pada disk.
Copy on Write digunakan sehingga ruang disk digunakan secara efisien.
Anda telah membuat sistem file dalam volume logis yang memiliki ruang kosong di dalamnya untuk snapshot.
Ini adalah contoh dari FAQ
Solusi 4:
Anda tidak menentukan apakah Anda menggunakan Linux atau HP-UX. Di HP-UX, Anda membuat volume logis dan memasangnya sebagai snapshot dari volume logis lainnya. Di Linux, Anda membuat volume logis sebagai volume snapshot.
Menghapus snapshot di HP-UX dilakukan dengan melakukan umount volume; di Linux dilakukan dengan menggunakan lvremove untuk menghapus volume logis.
Bagaimanapun, perubahan adalah satu-satunya hal yang disimpan di snapshot Anda. Semakin lama snapshot tersedia, semakin banyak perubahan yang disimpan - dan ada kemungkinan snapshot dapat terisi jika ukuran atau rilisnya tidak sesuai.
Kecepatan akses disk pada volume snapshot lebih lambat daripada volume normal; Anda harus memperhitungkannya.