Sejauh yang saya tahu, LVM memungkinkan untuk mengambil snapshot dari suatu volume. Ada juga sejumlah sistem file (ZFS, Btrfs, reiserfs, ...) yang mendukung snapshot.
Namun, saya tidak pernah mengerti perbedaan antara snapshot LVM dan snapshot sistem file. Jika dimungkinkan untuk mengambil foto dengan LVM, mengapa seseorang meluangkan waktu untuk mengimplementasikannya dalam sistem file?
Sunting: Apakah ada di antara mereka yang disukai dalam beberapa situasi? Mengapa?
Jawaban:
Sebagian besar snapshot ini adalah snapshot copy-on-write, yang sangat cepat dan sangat murah (berdasarkan penyimpanan) pada sistem yang jarang diperbarui. Snapshots LVM adalah snapshot SAP, ZFS / BTRFS keduanya memiliki mode SAP untuk snapshot, reiserfs tidak memiliki snapshot asli, sistem file NSS Novell juga SAP, seperti volume Shadow Copy untuk volume Windows NTFS.
Salinan snap-on-write mengambil salinan metadata volume target ke kumpulan snapshot. Kemudian, tergantung pada mode SAP yang mereka gunakan, mereka menyalin data yang akan ditimpa oleh tulisan baru ke kumpulan foto sebelum menulis data baru.
ZFS dan (akhirnya jika belum ada) BTRFS memiliki kemampuan snapshot penuh, yang berguna untuk memotret media yang terpisah, yang pada gilirannya sangat berguna untuk sistem cadangan sneakernet menggunakan media yang dapat dipindahkan. ZFS tidak menyebut ini "snapshot", mereka memanfaatkan kemampuan ZFS untuk menggunakan zfs senddan zfs recvmenyalin volume dan snapshot melalui jaringan ke host jarak jauh (atau array lokal).
Saya lebih suka kemampuan snapshot tingkat sistem file daripada LVM karena saya lebih percaya sistem file itu sendiri untuk menangani proses dengan bersih. Namun, dalam kurangnya dukungan sistem file langsung, LVM seharusnya berfungsi dengan baik dalam kebanyakan kasus.
Jepretan SAPI baik jika Anda memerlukan cadangan point-in-time yang diambil sangat cepat untuk kebutuhan pemulihan jangka pendek. Seperti melakukan harian, atau 4x setiap hari, jepret untuk disimpan selama seminggu. Ini berguna jika Anda perlu memulihkan file yang tidak sengaja dihapus pengguna, atau perlu memutar kembali seluruh sistem ke konfigurasi pra-pembaruan. Mereka juga dapat digunakan oleh beberapa sistem cadangan sebagai sistem file yang sepenuhnya diam, sehingga cadangan yang diambil dari volume snapshot tidak perlu khawatir tentang membuka file yang menghalangi. Hal utama yang perlu diingat adalah bahwa volume snapshot akan berada di penyimpanan yang sama dengan volume primer, jadi jangan beri Anda apa pun jika terjadi kegagalan array.
Jepretan FULL bagus jika diambil ke media yang bisa dilepas atau jauh. Jika Anda memiliki penyimpanan jaringan, targetnya bisa berupa array iSCSI atau Fibre Channel yang berbeda dari yang di-host penyimpanan utamanya. Ini memberi Anda perlindungan off-array untuk beberapa jenis kesalahan. Jika menggunakan media yang dapat dilepas, seperti drive ESATA 3TB, Anda bahkan dapat menggunakannya sebagai sistem cadangan-ke-disk yang sederhana. Foto-foto ini BISA berada di perangkat keras yang berbeda dari saudara-saudara SAP mereka, jadi berguna untuk ketahanan bencana.
Pada snapshot Penuh vs SAPI.
Istilah 'snapshot' telah sedikit berubah selama bertahun-tahun. Tahun ini, saya cukup yakin itu berarti "salinan Copy-On-Write dari data asli menggunakan blok-relokasi". Dengan definisi ini, snapshot "Penuh" yang disajikan di atas sebenarnya bukan snapshot, melainkan replikasi. Beberapa vendor penyimpanan telah menggunakan definisi 'snapshot' yang berbeda di masa lalu untuk menggambarkan berbagai operasi tingkat blok yang mereka lakukan. Yang membingungkan adalah sistem yang menggunakan snapshot sebagai bagian dari proses replikasi.
LVM membutuhkan pra-perencanaan. Saya cenderung tidak menggunakannya karena itu juga lapisan abstraksi dan jarang tersedia ketika saya membutuhkannya. Ada beberapa opsi lain untuk dikloning pada tingkat filesystem (di Linux) tanpa LVM. Anda dapat menggunakan Hot Copy dari R1Soft untuk melakukan ini. Ini adalah modul kernel, tetapi memungkinkan Anda untuk menambahkan kemampuan ini saat bepergian.
Masalah yang sangat jelas: foto - foto LVM tidak dijamin memiliki jue FS yang konsisten karena LVM "tidak tahu apa-apa tentang FS yang dibebani dengan
Diedit (lihat komentar): - benar kecuali FS memiliki dukungan untuk .freeze_fs, jika tidak harus ditangani oleh FS dengan anggun.
sync, snapshot adalah duplikat yang tepat dari sistem file yang sudah terpasang; jadi ketika Anda memasangnya, itu muncul sebagai 'tidak bersih tidak di-mount' (karena itu tidak di-mount), dan harus melakukan beberapa tindakan korektif sebelum konsisten. Tentu saja, itu biasanya hanya replay jurnal dan setelah syncitu, itu harus replay kosong; jadi tidak ada bahaya kehilangan data.
xfs_freeze is intended to be used with volume managers and hardware RAID devices that support the creation of snapshots.) - hal khusus untuk snapshot, apakah LVM-2 sudah mengetahuinya dan sudah menggunakannya? 3) Beri tahu saya di mana di ruang pengguna ( sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/?cvsroot=lvm2 ) atau dalam sumber kernel saya dapat membuktikan bahwa Anda benar memberi tahu kami bahwa LVM mendorong FS ke sinkronkan.
lock a filesystem and force it into a consistent state. Jadi, setidaknya saya dapat mengatakan saya mungkin salah mengatakan "tidak dijamin untuk memiliki FS yang konsisten", karena ini adalah masalah dukungan 'metode' freeze_fs di dalam implementasi FS - beberapa FSes pasti memiliki dukungan seperti itu (EXT3, Reiser3, XFS), dan beberapa tidak (EXT2, misalnya). Juga, itu menjawab pertanyaan ke-2 - pembekuan XFS sangat mungkin ditangani secara otomatis dengan LVM.
Sebagai pelengkap jawaban lainnya. Dalam snapshot FS Anda dapat memanfaatkan fitur FS seperti kompresi dan deduplikasi di semua snapshot.