Mengapa orang tidak menggunakan rsync untuk membuat cadangan tamu vmware?


12

Jika saya menjalankan sistem ESXi vmware modern, saya dapat memasukkan file rsync biner dan rsync yang terhubung secara statis ke tujuan apa pun melalui SSH.

Saya mencoba memahami mengapa sebagian besar (semua?) Cadangan tamu vmware tidak dilakukan dengan cara ini.

Jika VM sedang berjalan, Anda cukup menggunakan 'vim-cmd vmsvc / snapshot.create' untuk membuat snapshot lalu rsync snapshot itu ke host jarak jauh. (bahkan ada opsi untuk "menenangkan" snapshot)

ATAU, jika Anda ingin cadangan yang lebih kuat, Anda dapat dengan anggun menghentikan VM dan rsync di atas file vmdk.

Jadi ... sepertinya saya adalah skrip shell sederhana yang jauh dari semua cadangan yang ingin saya lakukan, secara sederhana dan mudah, menggunakan rsync lama yang sederhana.

Apa yang kulewatkan di sini ?


1
Karena jika satu file berubah di VM Anda harus membuat cadangan seluruh vmdk?
faker

Tidak, rsync akan memperbarui satu file secara efisien hanya dengan perubahan sejak transfer terakhir. Tentu saja operasi VM dapat menghasilkan BANYAK perubahan lebih banyak daripada yang Anda harapkan, tetapi itu tidak akan membuat Anda mengirim ulang seluruh vmdk ...
user227963

Selain fakta Anda tidak boleh menggunakan shell esxi untuk apa pun selain pemeliharaan, OS esxi tidak dibuat untuk bekerja dengan cara itu, dan Anda tidak akan didukung, saya pikir Anda salah memahami konsep snapshot. Cuplikan dalam kasus ini adalah delta. Jadi jika Anda mengambil snap dan menyalinnya langsung, itu akan menjadi kecil, dan hampir tidak mengandung informasi. Anda memikirkan snapshot penyimpanan backend, dan ya orang membuat cadangan VM dengan cara ini
Rqomey

1
@Rqomey - ada berbagai "snapshots" di ESXi. Anda sedang berbicara tentang satu jenis yang terlihat melalui Klien vSphere - tetapi menggunakan API Anda mendapatkan opsi lain, misalnya: klon penuh.
masi

@MASI Apakah Anda maksudkan kloning daripada menentang snapshot? ;)
Rqomey

Jawaban:


32
  • Karena kecepatan transfer dari konsol ESXi sengaja dibatasi.
  • Karena ini tidak dapat diukur dengan cara apa pun.
  • Karena Anda harus memasukkan binary rsync yang dikompilasi secara statis ke host ESXi.
  • Karena VM, VMDK, file ramdisk, dan komponen lainnya dapat berubah cukup untuk menjadikan rsync kehilangan proposisi ... apakah Anda benar - benar ingin menyinkronkan kembali VM 200GB yang telah di-boot ulang dan sejumlah kecil file diubah?
  • Karena kebutuhan sumber daya CPU / memori pada sumber atau tujuan. Rsync tidak gratis.
  • Karena ada produk lain di pasaran, baik pihak ketiga maupun yang disediakan VMware. Cari Pelacakan Blok Berubah .
  • Karena ESXi BUKAN sistem operasi untuk tujuan umum.

Lihat juga: Instal rsync di server VMware ESX 4.1


1
Jawaban yang luar biasa.
EEAA

3
Mereka bukan ... Maksudku, itu namanya: ghettoVCB . Ada solusi yang lebih baik di luar sana. Veeam, vSphere Data Protection, dll.
ewwhite

2
Anda tentu bisa menggunakan metode rsync jika Anda beralih ke xen / kvm.
Zoredache

9
@ user227963 Rsync juga agak tidak efisien pada keduanya - sejumlah besar file serta file besar. Dan sementara itu mungkin tidak harus mengirim ulang seluruh file melalui kawat, itu harus membaca ulang pada sumber dan tujuan sama. CBT akan membantu Anda di sini, tetapi rsync tidak tahu apa-apa tentang CBT.
the-wabbit

2
@ user227963 menyalin file sederhana. Sekarang membuatnya cepat dan bukan sumber daya babi pada file besar dengan perubahan konstan kecil. rsync layak tetapi tidak mendekati kinerja apa pun dengan info orang dalam yang bloknya berubah.
JamesRyan

4

Saya biasa melakukan ini beberapa tahun yang lalu. (sunting: dengan VMWare berjalan pada host CentOS, tidak diakui ESXi)

Setiap malam saya memiliki skrip yang akan menangguhkan VM, rsync file dari disk ke server cadangan dan kemudian mulai VM lagi. Ini bekerja dengan sangat baik kecuali ...

Rsync tidak bekerja dengan baik dengan file 2GB.

Itu bukan karena rsync tidak brilian, lebih dari itu setiap 2GB vmdk perubahan dengan cara yang sangat buram untuk rsync, bahkan perubahan kecil pada filesystem terlampir menghasilkan perubahan dalam vmdk (atau semua vmdks karena suatu alasan) yang saya salahkan. Windows, baik secara otomatis mendefrag atau melakukan semua hal lain yang dilakukan itu tidak masalah jika Anda menjalankan sistem nyata, tetapi muncul ketika Anda mencoba rsync VM!

Saya pikir mekanisme rsync untuk mendeteksi perubahan tidak bekerja dengan sangat baik pada file 2GB, sementara itu cukup sering melewatkan potongan awal vmdk, setelah mulai menemukan perbedaan, ia hanya akan menyalin sisa file. Saya tidak tahu apakah itu masalah dengan rsync tidak dapat mendeteksi sepotong data biner yang dipindahkan, atau dengan kurangnya memori pada kotak sumber, atau apakah vmdk baru saja diperbarui sepanjang jalan. Tidak masalah karena hasilnya sama - mayoritas vmdk disalin.

Pada akhirnya saya hanya menyalin file yang diubah dan menimpa mereka, masih menggunakan rsync. Saya juga memiliki kinerja yang lebih baik dengan hanya menimpa file cadangan daripada membiarkan rsync menyalin dan mengganti apa yang ada di sana.

Server cadangan kami juga bukan yang tercepat dan sampai pada titik semalam tidak cukup lama untuk mendukung semua VM yang berjalan.

Namun, ketika kami perlu mengembalikan VM, itu benar-benar mudah dan berfungsi dengan baik.


Ok, itu sangat membantu. Saya tahu sedikit tentang cara kerja rsync, dan saya dapat memberitahu Anda itu tidak ada hubungannya dengan ukuran file - tetapi apa yang Anda gambarkan adalah bahwa jauh lebih banyak perubahan file daripada yang Anda harapkan ... yaitu untuk katakanlah, Anda menjalankan VM selama sehari, dan Anda hanya melakukan beberapa hal kecil dengannya, dan kemudian Anda menghentikannya ... tetapi file vmdk berubah 30-40% (walaupun Anda hanya melakukan sedikit). Jadi rsync akan baik-baik saja, itu hanya memiliki banyak pekerjaan yang harus dilakukan ... lebih dari yang Anda harapkan. Terima kasih!
user227963

1
Tapi kemudian ... pertanyaan ini menimbulkan ... bagaimana alat "profesional" melakukannya? Jenis sihir apa yang mereka lakukan yang entah bagaimana lebih optimal daripada apa yang akan dilakukan rsync (atau scp, atau bahkan cp)? Pada akhirnya, Anda memiliki lingkungan unix (konsol ESXi) dan Anda ingin memindahkan file masuk atau keluar ... rahasia apa yang bisa terlibat dengan itu?
user227963

@ user227963 Alat profesional memanfaatkan fitur seperti pelacakan blok-berubah atau memiliki akses ke API vSphere atau ESXi lainnya.
ewwhite

2

Rsyncing satu file bukan solusi cadangan,

apa yang Anda lakukan ketika sesuatu terjadi pada vm dan file dihapus, tetapi Anda hanya memperhatikan ini setelah rsync Anda berjalan kembali? Anda akan menimpa 'cadangan' file Anda dengan gambar yang buruk sekarang.

Jika Anda ingin cadangan, Anda perlu menyimpan versi lama di suatu tempat, atau di diff. Rsync hanya akan menyalin di atas diff untuk Anda, tetapi itu tidak akan menyimpan hanya diff, tetapi menimpa file sebelumnya.

Mungkin ada opsi untuk Anda di sini, dengan rsync, dan sistem file copy-on-write dengan informasi versi, yang pada dasarnya akan menyimpan diffs setiap kali skrip rsync Anda berjalan. Solusi ini mulai menjadi sedikit lebih rumit, jadi ini sebabnya orang menggunakan solusi kerja yang dikenal dengan imho.


Tentu saja ada lebih banyak kerumitan yang terlibat di sini daripada yang saya pikirkan, tetapi apa yang Anda sebutkan bukanlah masalah. Tentu saja jika Anda menjalankan rsync secara membabi buta berulang-ulang Anda akan mengalami masalah, seperti yang Anda sarankan, tetapi ada banyak cara sederhana untuk mengkloning / memutar backup yang dibuat rsync (bahkan file tunggal) ... masalah itu telah dipecahkan lama. waktu yang lalu, syukurlah.
user227963

0

Tidak ada alasan mengapa Anda tidak dapat menggunakan Rsync di server ESXi. Kami menawarkan versi terkompilasi secara statis di sini https://33hops.com/rsync-for-vmware-vsphere-esxi.html yang berfungsi dengan sangat baik. Ada informasi tentang cara mengkompilasi Anda sendiri.

Namun demikian, siapa pun yang mau menggunakannya harus mempertimbangkan bahwa Rsync dan algoritma Delta-nya tidak dianggap mencadangkan file besar yang tetap, seperti VM hard disk, tetapi untuk menyinkronkan file berukuran panjang yang lebih kecil. Jadi, ini berfungsi, tetapi membutuhkan banyak waktu dan CPU untuk menghitung data diff. Sebenarnya itu hanya cara untuk bertukar bandwidth dengan CPU. Bagaimanapun, itu masih cukup bisa diterapkan, khususnya jika cakram virtual Anda berada di urutan beberapa puluh gigabytes.

Saya telah menerbitkan posting lengkap tentang topik di sini, merinci semua pro dan kontra https://33hops.com/blog_xsibackup-rsync-considerations.html

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.