Snapshots LVM sebagai strategi cadangan

17

Bagaimana layak sebagai strategi cadangan akan menjadi snapshot LVM berkala dari xen domU? Pro, kontra, ada gotcha?

Bagi saya sepertinya solusi sempurna untuk pemulihan yang cepat dan tanpa otak. Penyelidikan dapat dilakukan pada volume logis yang rusak dengan domU berhasil berjalan tanpa gangguan.

EDIT:

Di sinilah saya sekarang, ketika melakukan backup sistem penuh.

lvm snapshot dari domU disk
volume logis baru yang ukurannya sama dengan ukuran foto.
dd if = / dev / snapshot = / dev / new_lv
membuang snapshot dengan lvremove
verifikasi opsional dengan kpartx / mount / ls

Sekarang saya perlu mengotomatisasi ini.

backup xen lvm

— Karolis T.
sumber

32

Snapshots LVM dimaksudkan untuk menangkap sistem file dalam keadaan beku. Mereka tidak dimaksudkan untuk menjadi cadangan di dalam dan dari diri mereka sendiri. Namun, mereka berguna untuk mendapatkan gambar cadangan yang konsisten karena gambar beku tidak dapat dan tidak akan berubah selama proses pencadangan. Jadi, sementara Anda tidak akan menggunakannya secara langsung untuk membuat cadangan jangka panjang, mereka akan sangat bermanfaat dalam proses pencadangan apa pun yang Anda putuskan untuk digunakan.

Ada beberapa langkah untuk mengimplementasikan snapshot. Yang pertama adalah bahwa volume logis baru harus dialokasikan. Tujuan dari volume ini adalah untuk menyediakan area di mana delta (perubahan) ke sistem file dicatat. Ini memungkinkan volume asli untuk melanjutkan tanpa mengganggu akses baca / tulis yang ada. Kelemahan dari ini adalah bahwa area snapshot berukuran terbatas, yang berarti pada sistem dengan penulisan yang sibuk, dapat mengisi lebih cepat. Untuk volume yang memiliki aktivitas penulisan yang signifikan, Anda ingin menambah ukuran snapshot Anda untuk memberikan ruang yang cukup untuk semua perubahan yang akan direkam. Jika foto Anda meluap (terisi), foto itu akan berhenti dan ditandai sebagai tidak dapat digunakan. Jika ini terjadi, Anda akan ingin melepaskan snapshot Anda sehingga Anda bisa mendapatkan volume aslinya kembali online. Setelah rilis selesai, Anda

Hal kedua yang terjadi adalah LVM sekarang "menukar" tujuan sebenarnya dari volume yang dimaksud. Anda akan berpikir bahwa snapshot yang baru dialokasikan akan menjadi tempat untuk mencari perubahan pada sistem file, setelah semua, di situlah semua penulisan akan dilakukan, kan? Tidak, itu sebaliknya. Filesystem di-mount ke nama volume LVM , jadi menukar nama dari bawah sistem akan menjadi tidak-tidak (karena snapshot menggunakan nama yang berbeda ). Jadi solusinya di sini sederhana: Ketika Anda mengakses nama volume asli, itu akan terus merujuk ke versi langsung (baca / tulis) volume yang Anda buat snapshot. Volume foto yang Anda buat akan merujuk ke beku(hanya baca) versi volume yang ingin Anda buat cadangannya. Sedikit membingungkan pada awalnya, tetapi itu masuk akal.

Semua ini terjadi dalam waktu kurang dari 2 detik. Sisa dari sistem bahkan tidak memperhatikan. Kecuali, tentu saja, Anda tidak melepaskan snapshot sebelum meluap ...

Pada titik tertentu Anda akan ingin melepaskan snapshot Anda untuk mendapatkan kembali ruang yang ditempati. Setelah rilis selesai, volume foto dirilis kembali ke volume, dan yang asli tetap.

Saya tidak menyarankan mengejar ini sebagai strategi cadangan jangka panjang. Anda masih meng-hosting data pada drive fisik yang sama yang dapat gagal, dan pemulihan sistem file Anda dari drive yang gagal tidak ada cadangan sama sekali.

Jadi, singkatnya:

Snapshots baik untuk membantu backup
Snapshots bukanlah, dalam dan dari diri mereka sendiri, suatu bentuk cadangan
Jepretan tidak bertahan selamanya
Cuplikan penuh bukanlah hal yang baik
Snapshots perlu dirilis di beberapa titik
LVM adalah teman Anda, jika Anda menggunakannya dengan bijak.

— Avery Payne
sumber

4

Juga kinerja snapshot LVM menurun secara linear - 8 snapshot 8 kali IO.

— Steven

9

Ada beberapa poin dalam uraian Anda yang saya pikir salah. Dalam versi LVM saat ini, jika foto menjadi penuh, itu hanya ditandai sebagai tidak dapat digunakan dan perlu dihapus. I / O pada perangkat tidak terhenti. Kedua, ketika Anda menghapus foto, tidak ada data yang disalin kembali ke volume aslinya. Pada dasarnya, ketika Anda menulis ke volume langsung, blok asli pertama disalin ke snapshot, dan kemudian blok hidup diperbarui. Lalu ketika Anda menjatuhkan snapshot, itu hanya masalah menghapus entri dari mapper perangkat. Tidak perlu menyalin.

— Kamil Kisiel

2

Demi kelengkapan, Kamil Kisiel benar. Lihat: tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html

— ktower

1

Setelah banyak menggerutu pada diri sendiri karena informasi yang salah, jawabannya telah diubah berdasarkan berbagai sumber dokumentasi dan diskusi. Maaf teman-teman, salahku.

— Avery Payne

10

Snapshots LVM sangat bagus untuk dapat membuat cadangan server Anda tanpa membuatnya offline. Seperti yang dinyatakan snapshot LVM adalah salinan hampir instan. Anda membuatnya menggunakan lvcreateperintah seperti halnya Anda akan membuat LV itu sendiri, hanya Anda yang memberikannya --snapshotopsi dan LV asli alih-alih VG. Contohnya:

lvcreate -L <LV size> -s -n <snapshot name> /dev/<VG name>/<LV name>

Ini akan membuat snapshot dari LV yang diberikan dengan nama snapshot yang ditentukan yang kemudian Anda bisa pasang dan gunakan LV snapshot ini untuk melakukan backup Anda tanpa khawatir tentang file yang sedang digunakan secara aktif. Ini sangat membantu jika Anda mencoba membuat cadangan server database aktif.

Setelah Anda selesai mencadangkan dari snapshot, Anda ingin menghapusnya untuk mengurangi overhead I / O tambahan atau masalah kinerja lainnya seperti yang disebutkan orang lain menggunakan:

lvremove /dev/<VG name>/<snapshot name>

Walaupun snapshot LVM sangat berharga dalam menghasilkan cadangan sistem yang andal seperti basis data dan Anda biasanya ingin melakukan shutdown ke cadangan untuk menghindari pertengkaran file, mereka tidak ideal untuk operasi jangka panjang sebagai pemulihan cepat.

— Jeremy Bouse
sumber

9

Bukan ide yang bagus, IMO.

Snapshots diimplementasikan dalam mode copy-on-write sehingga Anda mengubah setiap penulisan menjadi read dan two write (blok yang Anda perbarui adalah yang pertama dibaca dari volume utama dan disimpan dalam volume snapshot sebelum data baru Anda ditempatkan di tempatnya) sehingga Anda akan melihat beberapa penurunan kinerja jika banyak tulisan yang umum di VM.

Juga, IIRC, jika volume foto menjadi penuh hanya dijatuhkan tanpa basa-basi. Ini tidak baik untuk keperluan pencadangan! Jadi jika Anda mencoba ini sebagai metode cadangan, pastikan untuk membuat volume snapshot cukup besar untuk menangani semua perubahan yang akan terjadi selama masa manfaat snapshot. Tentu saja jika Anda mengetahui dan memantau masalah ukuran dan masalah kinerja bukan masalah bagi Anda, maka apa yang Anda sarankan dapat membuat tambahan yang berguna untuk proses pencadangan lain yang Anda miliki.

Snapshots LVM sangat berguna sebagai bagian dari proses pencadangan (mengambil snapshot, mencadangkan snapshot ke tempat lain untuk memastikan cadangan konsisten tanpa harus menonaktifkan pembaruan pada volume "nyata", letakkan snapshot sesudahnya), antara lain, tetapi tidak dimaksudkan sebagai fasilitas cadangan sendiri.

— David Spillett
sumber

Mungkin saya tidak mengerti cara kerja snapshot. Manual mengatakan bahwa snapshot adalah salinan hampir instan dari volume logis, menghindari kebutuhan untuk mengambil sistem yang menggunakannya secara offline. Dari uraian Anda, sepertinya snapshot lebih dari cabang, replika, dan bukan salinan yang dibekukan. Apakah snapshot diperbarui dengan semua perubahan yang dibuat di sistem asli setelah dibuat? Jika demikian, saya perlu mengambil data darinya dengan segera dan menghancurkan snapshot, karena itu tidak dimaksudkan sebagai mekanisme penyimpanan untuk cadangan? Terima kasih!

— Karolis T.

2

Ini adalah salinan beku dari volume yang dibuatnya, tetapi hanya berisi blok yang telah berubah sejak snapshot diambil (karenanya volume snapshot bisa jauh lebih kecil dari volume yang merupakan snapshot). Jika blok diperbarui dalam volume langsung maka konten blok asli ditambahkan ke penyimpanan snapshot, jadi ketika Anda melihat snapshot LVM dapat melayani blok asli bukan yang diperbarui.

— David Spillett

Tetapi jika itu diubah (snapshot), dari mana "beku" ini berasal? Katakanlah saya memiliki skenario ini, suatu sistem kerja entah bagaimana rusak dari waktu ke waktu. Saya memiliki snapshot ketika bekerja dengan benar. Apakah snapshot akan menjadi representasi sistem saat masih berfungsi dengan benar, atau apakah akan ada perubahan yang membuat sistem asli rusak? Semoga aku cukup jelas, hanya ingin memastikan aku benar-benar memahaminya.

— Karolis T.

Untuk memahami dari mana pembekuan berasal, sadari bahwa Anda sekarang memiliki dua volume terpisah - dokumen asli yang berisi sistem file yang aktif, dan snapshot, yang mengubah versi beku dari sistem file. Lihat jawaban saya untuk lebih jelasnya.

— Avery Payne

1

Kalian membuatnya terdengar lebih rumit dari itu. Snapshot menyimpan status sistem file sumber seperti ketika snapshot dibuat. Ketika sumber fs berubah, snapshot tidak berubah, yang memungkinkan Anda mengarahkan program cadangan Anda untuk membaca dari snapshot alih-alih sumber fs. Ya, copy-on-write terjadi di belakang layar, tetapi pengguna tidak memperhatikan ini kecuali untuk penggunaan IO tambahan.

— Martijn Heemels

6

Anda perlu memastikan bahwa data pada disk dalam keadaan konsisten sebelum foto dibuat. misal mysql mungkin memiliki data yang di-cache di memori yang perlu dipaksa ke disk, baik dengan membuang database atau mematikannya. Lihat manual aplikasi Anda untuk detailnya.

— pgs
sumber

5

Di bawah hal-hal yang tampak cerdas, LVM sebenarnya 'hanya' trik perangkat mapper. Membuat snapshot dengan lvcreate tidak lebih dari bungkus untuk beberapa hal dmsetup. Wrapper membuat perangkat baru (volume foto) dari satu volume lama (volume asli) dan yang baru (volume copy-on-write). Bersamaan dengan itu, LV asli diganti namanya menjadi -real (lihat di bawah, yang merupakan dmsetup ls --tree output). LV nyata ini dipetakan ke volume snapshot dan volume asli, sehingga dapat digunakan di kedua tempat. Volume copy-on-write berfungsi sebagai overlay ke -real LV. -Snap LV menampilkan kombinasi volume copy-on-write dan -real volume. Ini memang menciptakan beberapa overhead kinerja.

Volume00-snap (253:11)
 |-Volume00-snap-cow (253:13)
 |  `- (104:2)
 `-Volume00-LogVol01-real (253:12)
    `- (104:2)

Volume00-LogVol01 (253:5)
 `-Volume00-LogVol01-real (253:12)
    `- (104:2)

Saat menghapus snapshot, sekali lagi terjadi penggantian nama dan pemetaan. Setelah itu, situasinya akan kembali terlihat seperti

Volume00-LogVol01 (253:5)
 `- (104:2)

Adapun dalam howfar ini adalah metode yang baik untuk mencadangkan barang: bisa jadi, jika Anda memperhitungkan ini akan (1) tidak membantu RAM mesin virtual, (2) membuat penalti kinerja dan (3) Anda perlu untuk menyimpan gambar foto di tempat lain.

VMware VCB juga berfungsi dengan snapshot, btw, meskipun bukan LVM.

— wzzrd
sumber

4

Sekalipun snapshot tidak memengaruhi kinerja, Anda harus memahami: Snapshots tidak lebih dari cadangan daripada salinan ke folder lain pada disk yang sama.

Jika disk mengerem, data dan cadangan Anda hilang. Bahkan jika Anda menetapkan area snapshot ke PE lain di VG, itu hanya berisi data yang diubah sejak snapshot.

Mencadangkan berarti salinan setidaknya ke drive yang sepenuhnya terpisah sebagai persyaratan minimum.

— Sven
sumber

Ya aku mengerti itu. RAID 1 ada di tempat untuk melindungi dari kegagalan perangkat penyimpanan, membuat cadangan ke lokasi terpencil - dari korupsi perangkat lunak. Saya mempertimbangkan snapshot LVM sebagai alat untuk pengembalian cepat yang BENAR-BENAR ketika Anda tidak tahu apa yang terjadi dan Anda membutuhkan sistem online sekarang. Ada opsi lain, lebih cepat dari itu mengembalikan domU dari cadangan LVM?

— Karolis T.

3

saya menggunakan pengaturan seperti itu untuk snapshot dari mesin server vmware dan database mysql. berfungsi dengan baik sejauh ini. ada beberapa mengembalikan - semua tanpa masalah. satu hal yang perlu dipertimbangkan - saat berjalan dengan snapshot lvm mendapat hit kinerja yang signifikan untuk operasi i / o. lihat di sini . abaikan fakta mereka berbicara tentang mysql, i / o ops adalah i / o ops ... tidak peduli apa pun jenis data yang ada di lvm.

— pQd
sumber

1

aha. yeah - saya berasumsi snapshot akan diambil dan diekspor ke server penyimpanan jarak jauh. tidak ditinggalkan di host lokal.

— pQd

2

Saya menggunakan snapshot lvm hanya untuk menyalin DomU Lv yang lain dalam Vg terpisah, di mana setiap Domain memiliki tiga "node" cadangan untuk dibuang.

Setelah itu, snapshot dihancurkan, dan cadangan Lv akan tetap sampai babak berikutnya. Jika saya harus mengembalikan, saya hanya perlu memilih sumber Lv dari cadangan Vg dan menyalinnya ke domain Lv.

Sesekali, Lv cadangan dibuang ke file gambar di server terpisah.

Semua ini otomatis melalui skrip, dengan cadangan setiap dua hari dan dump setiap minggu.

Saya bahkan memiliki mode "panik" dalam pikiran, di mana Domain Lv akan dipulihkan tetapi dijalankan dari snapshot, dan reset-ed setiap 2 jam, untuk menjaga situs online jika terjadi peretasan serius, sampai pertahanan yang tepat dapat diatur .

— Berzemus
sumber

1

Apa yang menjadi garis ide pertahanan 'mode panik'?

— NginUS
sumber