Kami di Veeam menyukai log. Dan karena sebagian besar solusi kami bersifat modular, mereka menulis banyak log. Dan karena ruang lingkup aktivitas kami adalah untuk memastikan keamanan data Anda (yaitu, tidur nyenyak), maka log seharusnya tidak hanya mencatat setiap bersin, tetapi juga melakukannya secara mendetail. Hal ini diperlukan agar jika terjadi sesuatu jelas bagaimana βapaβ ini terjadi, siapa yang harus disalahkan, dan apa yang perlu dilakukan selanjutnya. Ini seperti dalam ilmu forensik: Anda tidak pernah tahu hal kecil apa yang akan membantu Anda menemukan pembunuh Laura Palmer.
Oleh karena itu, saya memutuskan untuk mencoba serangkaian artikel, di mana saya akan berbicara secara berurutan tentang apa yang kami tulis ke log, di mana kami menyimpannya, bagaimana tidak menjadi gila dengan strukturnya dan apa yang harus dicari di dalamnya.
Mengapa serangkaian artikel dan mengapa tidak menjelaskan semuanya sekaligus?
Cukup mendaftar di mana log mana dan apa yang disimpan di dalamnya adalah pekerjaan yang agak membawa malapetaka. Dan menakutkan untuk berpikir tentang memperbarui informasi ini. Daftar sederhana dari semua kemungkinan jenis log di Veeam Backup & Replication adalah tabel pada beberapa lembar dalam cetakan kecil. Ya, dan itu hanya akan relevan pada saat publikasi, karena. ketika patch berikutnya dirilis, log baru mungkin muncul, logika informasi yang disimpan di yang lama akan berubah, dll. Oleh karena itu, akan jauh lebih menguntungkan untuk menjelaskan struktur dan esensi informasi yang terkandung di dalamnya. Ini akan memungkinkan Anda untuk menavigasi tempat dengan lebih baik daripada menjejalkan nama yang dangkal.
Oleh karena itu, agar tidak terburu-buru masuk ke kumpulan lembar teks, mari lakukan beberapa pekerjaan persiapan di artikel ini. Oleh karena itu, hari ini kita tidak akan masuk ke log itu sendiri, tetapi akan pergi dari jauh: kita akan menyusun glosarium dan membahas sedikit struktur Veeam dalam hal menghasilkan log.
Glosarium dan jargon
Di sini, pertama-tama, perlu meminta maaf kepada para juara kemurnian bahasa Rusia dan saksi dari kamus Ozhegov. Kita semua sangat menyukai bahasa ibu kita, tetapi industri TI terkutuk beroperasi dalam bahasa Inggris. Ya, kami tidak memikirkannya, tetapi itu terjadi secara historis. Bukan salahku, dia datang sendiri (c)
Dalam bisnis kami, masalah anglisisme (dan jargon) memiliki kekhususannya sendiri. Ketika di bawah kata-kata polos seperti "tuan rumah" atau "tamu" seluruh dunia telah lama memahami hal-hal yang sangat spesifik, maka di β negeri, kebingungan heroik dan keterkejutan dengan memasukkan kamus terus berlanjut. Dan argumen yang sangat wajib "Tapi di tempat kerja kami ...".
Plus, ada terminologi murni kami, yang melekat pada produk Veeam, meskipun beberapa kata dan frasa telah digunakan oleh orang-orang. Oleh karena itu, sekarang kami akan menyetujui apa arti istilah itu, dan di masa depan, di bawah kata "tamu", saya akan mengartikan persis apa yang tertulis di bab ini, dan bukan apa yang biasa Anda lakukan di tempat kerja. Dan ya, ini bukan keinginan pribadi saya, ini adalah istilah yang sudah mapan di industri ini. Melawan mereka agak tidak ada gunanya. Meskipun saya selalu mendukung untuk bersantai dalam komentar.
Sayangnya, ada banyak istilah dalam karya dan produk kami, jadi saya tidak akan mencoba mencantumkan semuanya. Hanya informasi paling mendasar dan perlu tentang cadangan dan log untuk bertahan hidup di laut. Bagi yang berminat, saya juga bisa rekannya tentang kaset, di mana dia juga memberikan daftar istilah yang terkait dengan bagian fungsi itu.
Tuan rumah (Tuan Rumah): Dalam dunia virtualisasi, ini adalah mesin dengan hypervisor. Fisik, virtual, cloud - tidak masalah. Jika ada sesuatu yang menjalankan hypervisor (ESXi, Hyper-V, KVM dll), maka "sesuatu" ini disebut host. Baik itu cluster dengan sepuluh rak atau laptop Anda dengan lab untuk satu setengah mesin virtual - jika Anda meluncurkan hypervisor, Anda menjadi tuan rumah. Karena hypervisor menghosting mesin virtual. Bahkan ada cerita bahwa VMware pada suatu waktu ingin mencapai asosiasi yang kuat antara word host dengan ESXi. Tapi dia tidak melakukannya.
Di dunia modern, konsep "host" secara praktis telah digabungkan dengan konsep "server", yang menimbulkan kebingungan dalam komunikasi, terutama jika menyangkut infrastruktur Windows. Jadi mesin apa pun yang menghosting beberapa layanan yang menarik bagi kami dapat dengan aman disebut sebagai host. Misalnya, di log WinSock semuanya ditandai dengan kata host. "Host not found" klasik adalah contohnya. Jadi kita mulai dari konteksnya, tapi ingat - dalam dunia virtualisasi, tuan rumah adalah yang menampung tamu (lebih lanjut tentang ini dalam dua baris di bawah).
Dari jargon lokal (lebih tepatnya akronim, dalam hal ini), diingat di sini bahwa VMware adalah VI, vSphere adalah VC, dan Hyper-V adalah HV.
Tamu (Tamu): Mesin virtual berjalan di host. Tidak ada yang perlu dijelaskan di sini, semuanya sangat logis dan sederhana. Namun, banyak yang dengan rajin menyeret beberapa makna lain ke sini.
Untuk apa? Aku tidak tahu.
Guest OS, masing-masing, sistem operasi mesin tamu. Dan seterusnya.
Tugas Pencadangan/Replikasi (jobA): Jargon Wim murni, menunjukkan beberapa tugas. Pekerjaan cadangan == Pekerjaan cadangan. Tidak ada yang menemukan cara menerjemahkannya dengan indah ke dalam bahasa Rusia, jadi semua orang mengatakan "Pekerjaan". Dengan penekanan pada suku kata terakhir.
Ya, mereka hanya mengambilnya dan berkata "joba". Dan bahkan dalam surat mereka menulis seperti itu, dan semuanya baik-baik saja.
Semua jenis pekerjaan Pencadangan, Tugas Pencadangan, dll., terima kasih, tetapi tidak perlu. Hanya pekerjaan, dan Anda akan dipahami. Hal utama adalah memberi tekanan pada suku kata terakhir.
Cadangan (Cadangan, cadangan. Untuk true-oldfags, cadangan diperbolehkan): Selain yang jelas (salinan cadangan data tergeletak di suatu tempat), itu juga berarti pekerjaan itu sendiri (tiga baris di atas, jika Anda sudah lupa), akibatnya file cadangan itu sendiri muncul. Mungkin, tuan-tuan penutur asli bahasa Inggris terlalu malas untuk mengatakan saya menjalankan pekerjaan pencadangan saya setiap saat, jadi mereka hanya mengatakan saya menjalankan pencadangan saya, dan semua orang memahami satu sama lain dengan sempurna. Saya mengundang Anda untuk mendukung inisiatif yang luar biasa ini.
Konsolidasi (Konsolidasi): Istilah yang muncul di ESXi 5.0 Opsi di menu snapshot yang memulai proses menghapus apa yang disebut snapshot yatim piatu. Yaitu, snapshot yang tersedia secara fisik, tetapi keluar dari struktur logis yang ditampilkan. Secara teoritis, proses ini seharusnya tidak memengaruhi file yang ditampilkan di pengelola snapshot, tetapi apa pun bisa terjadi. Inti dari proses konsolidasi adalah bahwa data dari snapshot (disk anak) ditulis ke disk utama (induk). Proses menggabungkan disk disebut penggabungan. Jika perintah konsolidasi telah dikeluarkan, rekaman snapshot dapat dihapus dari database sebelum snapshot digabungkan dan dihapus. Dan jika snapshot tidak dapat dihapus karena alasan apa pun, maka snapshot yatim piatu yang sama ini akan muncul. Tentang bekerja dengan snapshot, VMware punya . Dan kami juga entah bagaimana tentang mereka .
Datastore (Stora atau penyimpanan): Konsep yang sangat luas, tetapi dalam dunia virtualisasi dipahami sebagai tempat penyimpanan file mesin virtual. Tetapi bagaimanapun juga, di sini Anda perlu memahami konteksnya dengan sangat jelas dan, dengan sedikit keraguan, mengklarifikasi apa yang sebenarnya ada dalam pikiran lawan bicara Anda.
Proksi (Proksi): Penting untuk segera dipahami bahwa Veeam Proxy tidak persis sama dengan yang biasa kita gunakan di Internet. Di dalam produk Veeam, ini adalah sejenis entitas yang menangani transfer data dari satu tempat ke tempat lain. Jika Anda tidak merinci, maka VBR adalah server perintah dan kontrol, dan proksi adalah pekerjanya. Artinya, proxy adalah mesin tempat lalu lintas mengalir dan komponen VBR dipasang yang membantu mengelola lalu lintas ini. Misalnya, untuk mentransfer data dari satu saluran ke saluran lain, atau hanya menempelkan disk ke dirinya sendiri (mode HotAdd).
Repositori (Repositori): Secara teknis, ini hanyalah entri di database VBR, yang menunjukkan tempat penyimpanan cadangan, dan cara menyambung ke tempat ini. Faktanya, ini bisa berupa bola CIFS atau disk, server, atau ember terpisah di cloud. Sekali lagi, kami berada dalam konteks, tetapi kami memahami bahwa repositori hanyalah tempat cadangan Anda berada.
Jepretan (Snapshot): Penggemar tata bahasa Oxford lebih suka mengatakan siapa yang snapshot dan siapa yang snapshot, tetapi mayoritas yang buta huruf mendapat manfaat dari massa yang lebih besar. Jika ada yang tidak tahu, ini adalah teknologi yang memungkinkan Anda memulihkan keadaan disk pada titik waktu tertentu. Ini dilakukan baik dengan mengalihkan sementara operasi I / O dari disk utama - kemudian akan disebut snapshot RoW (Redirect on Write) - atau dengan memindahkan blok yang dapat ditulis ulang dari disk Anda ke yang lain - ini akan disebut CoW (Copy on Write ) cuplikan. Berkat kemungkinan luas untuk menggunakan fungsi-fungsi ini, Veeam dapat melakukan keajaiban cadangannya. Tegasnya, bukan hanya mereka, tapi ini soal rilis berikutnya.
Ada kekacauan seputar istilah ini dalam dokumentasi dan log ESXi, dan dalam konteks menyebutkan snapshot, Anda dapat menemukan snapshot itu sendiri, dan mengulang log, dan bahkan disk delta. Dokumentasi Veeam tidak berisi robekan seperti itu, dan snapshot adalah snapshot, dan redo log adalah file REDO yang dibuat oleh non-persistent disk independen. File REDO dihapus saat mesin virtual dimatikan, jadi mengacaukannya dengan snapshot adalah jalan menuju kegagalan.
Sintetis (Sintetis): Cadangan sintetik adalah pencadangan inkremental terbalik dan penerusan selamanya. Jika Anda belum menemukan istilah ini, itu hanyalah salah satu mekanisme yang digunakan untuk membuat transformasi rantai cadangan. Namun, di log Anda juga dapat menemukan konsep Transform, yang digunakan dalam kerangka pembuatan salinan lengkap dari peningkatan (sintetis penuh).
Tugas (Tugas): Ini adalah proses pemrosesan setiap mesin individu dalam pekerjaan. Yaitu: Anda memiliki pekerjaan cadangan, yang mencakup tiga mesin. Artinya, setiap mobil akan diproses sebagai bagian dari tugas terpisah. Secara total, akan ada empat log: yang utama untuk pekerjaan dan tiga untuk tugas. Namun, ada nuansa penting di sini: seiring waktu, kata "tugas" menjadi ambigu yang tidak perlu. Saat kami berbicara tentang log umum, yang kami maksud adalah tugas yang persis seperti VM. Tapi ada "tugas" baik di proxy maupun di repositori. Itu bisa berarti disk virtual, mesin virtual, dan seluruh pekerjaan. Artinya, penting untuk tidak kehilangan konteks.
Layanan Veeam %name%.: Untuk kepentingan pencadangan yang berhasil, beberapa layanan berfungsi sekaligus, daftarnya dapat ditemukan di peralatan standar. Nama mereka cukup transparan mencerminkan esensi mereka, tetapi di antara yang sederajat ada yang paling penting - Veeam Backup Service, yang tanpanya yang lain tidak akan berfungsi.
VSS: Secara teknis, VSS harus selalu berdiri untuk Microsoft Volume Shadow Copy Service. Faktanya, ini digunakan oleh banyak orang sebagai sinonim untuk Pemrosesan Gambar Sadar Aplikasi. Yang tentu saja salah besar, tetapi ini adalah cerita dari kategori "SUV apa pun bisa disebut jip, dan Anda akan mengerti."
Log yang fantastis dan di mana mereka tinggal
Saya ingin memulai bab ini dengan mengungkap rahasia besar - jam berapa yang ditampilkan di log?
Ingat:
- ESXi selalu menulis log di UTC+0.
- vCenter menyimpan log sesuai dengan waktu zona waktunya.
- Veeam menyimpan log berdasarkan waktu dan zona waktu server yang digunakan.
- Dan hanya peristiwa Windows dalam format EVTX yang tidak mengikat apa pun. Saat dibuka, waktu dihitung ulang untuk mobil tempat mereka dibuka. Pilihan paling nyaman, meski ada kesulitan dengannya. Satu-satunya kesulitan nyata adalah perbedaan lokal. Ini adalah jalur yang dijamin secara praktis ke log yang tidak dapat dibaca. Ya, ada opsi untuk cara menanganinya, tetapi jangan berdebat dengan fakta bahwa semua yang ada di TI berfungsi dalam bahasa Inggris, dan setuju untuk selalu menyetel lokal bahasa Inggris di server. Bisa aja.
Sekarang mari kita bicara tentang tempat tinggal log dan cara mendapatkannya. Dalam kasus VBR, ada dua pendekatan.
Opsi pertama cocok jika Anda tidak ingin mencari file di tumpukan umum yang secara khusus terkait dengan masalah Anda. Untuk melakukan ini, kami memiliki wizard terpisah, di mana Anda dapat menentukan pekerjaan tertentu dan periode tertentu yang memerlukan log. Kemudian dia akan memeriksa folder itu sendiri dan memasukkan semua yang Anda butuhkan ke dalam satu arsip. Di mana mencarinya dan cara bekerja dengannya dijelaskan secara rinci di .
Namun, wizard tidak mengumpulkan log dari semua tugas dan, misalnya, jika Anda perlu mempelajari log pemulihan, failover, atau failback, jalur Anda ada di folder %ProgramData%/Veeam/Cadangan. Ini adalah logostore VBR utama dan %ProgramData% adalah folder tersembunyi dan tidak apa-apa. Omong-omong, lokasi default dapat dipindahkan menggunakan kunci registri tipe REG_SZ: LogDirectory di cabang Pencadangan dan Replikasi HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam.
Di mesin Linux, log agen pekerja harus dicari di /var/log/VeeamBackup/jika menggunakan akun root atau sudo. Jika Anda tidak memiliki hak istimewa seperti itu, cari log masuk /tmp/VeeamBackup.
Untuk agen Veeam untuk log %OS_name% harus dicari %ProgramData%/Veeam/Titik Akhir (Atau %ProgramData%/Veeam/Cadangan/Titik Akhir) Dan /var/log/veeam masing.
Jika Anda menggunakan Pemrosesan Gambar Sadar Aplikasi (dan kemungkinan besar demikian), maka situasinya menjadi agak lebih rumit. Anda memerlukan log pembantu kami, yang disimpan di dalam mesin virtual itu sendiri, dan log VSS. Tentang bagaimana dan di mana mendapatkan kebahagiaan ini, ditulis secara rinci di . Dan tentu saja ada untuk mengumpulkan log sistem yang diperlukan.
Peristiwa Windows dikumpulkan dengan mudah menurut . Jika Anda menggunakan Hyper-V, segalanya menjadi lebih rumit, karena Anda juga memerlukan semua log-nya dari Applications and Service Logs > Microsoft > cabang Windows. Meskipun Anda selalu dapat menggunakan cara yang lebih bodoh dan hanya mengambil semua objek dari %SystemRoot%System32winevtLogs.
Jika ada yang rusak selama instalasi/peningkatan, maka semua yang Anda butuhkan dapat ditemukan di folder %ProgramData%/Veeam/Setup/Temp. Meskipun saya tidak akan menyembunyikan fakta bahwa di acara OS Anda dapat menemukan informasi yang lebih berguna daripada di log ini. Hal menarik lainnya terletak pada %Temp%, tetapi sebagian besar ada log instalasi untuk perangkat lunak terkait, seperti basis, pustaka .Net, dan hal lainnya. Perhatikan bahwa Veeam diinstal dari msi dan semua komponennya juga diinstal sebagai paket msi terpisah, meskipun ini tidak ditampilkan di GUI. Oleh karena itu, jika penginstalan salah satu komponen gagal, seluruh penginstalan VBR akan dihentikan. Oleh karena itu, Anda perlu masuk ke log dan melihat apa yang sebenarnya rusak dan pada titik apa.
Dan akhirnya, peretasan seumur hidup: jika Anda menerima kesalahan selama penginstalan, jangan buru-buru mengklik OK. Pertama kita ambil lognya, lalu klik OK. Dengan cara ini Anda akan mendapatkan log yang berakhir pada saat kesalahan terjadi, tanpa sampah pada akhirnya.
Dan kebetulan Anda perlu masuk ke log vSphere. Pekerjaan itu sangat tidak berterima kasih, tetapi, setelah menyingsingkan lengan baju, seseorang harus melakukan sesuatu yang lain. Dalam versi paling sederhana, kita memerlukan log dengan peristiwa mesin virtual vmware.log, yang terletak di sebelah file .vmx-nya. Dalam kasus yang lebih sulit, buka Google dan tanyakan di mana log untuk versi host Anda berada, karena VMware suka mengubah tempat ini dari rilis ke rilis. Misalnya, , tapi untuk . Untuk log vCenter, ulangi prosedurnya . Namun secara umum, kami akan tertarik pada log peristiwa host hostd.log, peristiwa host yang dikelola oleh vCenter vpxa.log, log kernel vmkernel.log, dan log autentikasi auth.log. Nah, dalam kasus yang paling diabaikan, log SSO yang terletak di folder SSO mungkin berguna.
Rumit? Bingung? Menakutkan? Tetapi ini bahkan bukan setengah dari informasi yang digunakan dukungan kami setiap hari. Jadi mereka benar-benar keren.
Komponen Veam
Dan sebagai penutup dari artikel pengantar ini, mari kita bahas sedikit tentang komponen Veeam Backup & Replication. Untuk saat mencari penyebab rasa sakit, alangkah baiknya memahami cara kerja pasien.
Jadi, seperti yang mungkin diketahui semua orang, Veeam Backup adalah aplikasi berbasis SQL. Artinya, semua pengaturan, semua informasi, dan secara umum semua yang hanya diperlukan untuk fungsi normal - semua ini ada di basis datanya. Atau lebih tepatnya, dalam dua database, jika kita berbicara tentang kumpulan VBR dan EM: VeeamBackup dan VeeamBackupReporting, masing-masing. Dan begitulah yang terjadi: kami meletakkan aplikasi lain - basis data lain muncul. Agar tidak menyimpan semua telur dalam satu keranjang.
Tetapi agar semua ekonomi ini bekerja dengan lancar, kami memerlukan serangkaian layanan dan aplikasi yang akan menyatukan semua komponen. Sebagai contoh, seperti inilah tampilan di salah satu lab saya:
Bertindak sebagai kepala konduktor Layanan Pencadangan Veeam. Dialah yang bertanggung jawab atas pertukaran informasi dengan pangkalan. Dia juga bertanggung jawab untuk meluncurkan semua tugas, mengatur sumber daya yang dialokasikan dan bekerja sebagai semacam pusat komunikasi untuk berbagai konsol, agen, dan yang lainnya. Singkatnya, pasti tidak ada cara tanpa dia, tetapi ini tidak berarti bahwa dia melakukan semuanya sendiri.
Membantu dia dalam pemenuhan rencananya Manajer Pencadangan Veeam. Ini bukan layanan, tetapi entitas yang meluncurkan pekerjaan dan memantau proses pelaksanaannya. Tangan kerja layanan cadangan, yang terhubung ke host, membuat snapshot, memantau retensi, dan sebagainya.
Tapi kembali ke daftar layanan. Layanan Broker Veeam. Muncul di v9.5 (dan ini bukan penambang crypto, seperti yang dipikirkan beberapa orang). Terlibat dalam mengumpulkan informasi tentang host VMware dan menjaga relevansinya. Tapi jangan langsung lari menulis komentar marah bahwa kami memata-matai anda dan membocorkan semua login/password ke taschmajor. Semuanya agak lebih sederhana. Saat Anda menjalankan pencadangan, hal pertama yang perlu Anda lakukan adalah menghubungkan ke host dan memperbarui semua data tentang strukturnya. Ini adalah cerita yang agak lambat dan rumit. Ingat saja berapa lama Anda masuk melalui antarmuka web, dan ingat bahwa hanya lapisan atas yang dihitung di sana. Dan kemudian Anda masih perlu membuka seluruh hierarki ke tempat yang tepat. Singkatnya, horor. Jika Anda menjalankan selusin cadangan, maka setiap pekerjaan perlu melakukan prosedur ini. Jika kita berbicara tentang infrastruktur besar, maka proses ini bisa memakan waktu sepuluh menit atau lebih. Oleh karena itu, diputuskan untuk mengalokasikan layanan terpisah untuk ini, yang memungkinkan untuk selalu menerima informasi terkini. Saat memulai, ia memeriksa dan memindai semua infrastruktur tambahan, lalu mencoba bekerja hanya pada tingkat perubahan tambahan. Jadi, bahkan jika Anda menjalankan seratus cadangan pada saat yang sama, semuanya akan meminta informasi dari broker kami, dan tidak akan menyiksa tuan rumah dengan permintaan mereka. Jika Anda mengkhawatirkan sumber daya, menurut perhitungan kami, 5000 mesin virtual hanya membutuhkan sekitar 100 Mb memori.
Selanjutnya kita punya Konsol Veeam. Dia adalah Veeam Remote Console, dia adalah Veeam.Backup.Shell. Ini adalah GUI yang sama yang kita lihat di tangkapan layar. Semuanya sederhana dan jelas - konsol dapat diluncurkan dari mana saja, asalkan itu Windows dan ada koneksi ke server VBR. Satu-satunya hal yang dapat dikatakan adalah bahwa proses FLR akan memasang poin secara lokal (yaitu pada mesin tempat konsol berjalan). Nah, berbagai macam Veeam Explorer juga akan berjalan secara lokal, karena mereka adalah bagian dari konsol. Tapi itu sudah membawaku ke alam liar ...
Layanan menarik lainnya adalah Layanan Data Katalog Cadangan Veeam. Dikenal sebagai Layanan Katalog Tamu Veeam dalam daftar layanan. Dia terlibat dalam pengindeksan sistem file pada mesin tamu dan mengisi folder VBRCatalog dengan pengetahuan ini. Ini hanya digunakan jika kotak centang pengindeksan diaktifkan. Dan masuk akal untuk mengaktifkannya jika Anda memiliki Enterprise Manager. Oleh karena itu, saran dari lubuk hati saya: jangan aktifkan pengindeksan begitu saja jika Anda tidak memiliki EAT. Hemat saraf dan waktu dukungan Anda.
Juga dari layanan penting lainnya perlu diperhatikan Layanan Pemasang Veeam, dengan bantuan komponen yang diperlukan dikirimkan dan diinstal pada proxy, repositori, dan gateway lainnya. Faktanya, dibutuhkan paket .msi yang diperlukan ke server dan menginstalnya.
Penggerak Data Veeam - dengan bantuan agen tambahan yang diluncurkan pada proxy (dan tidak hanya) itu terlibat dalam pemindahan data. Misalnya, saat mencadangkan, satu agen akan membaca file dari penyimpanan data host, dan agen kedua akan menulisnya dengan hati-hati ke cadangan.
Secara terpisah, saya ingin mencatat hal penting yang sering ditanggapi oleh klien - ini adalah perbedaan dalam versi layanan dan informasi di snap-in Program dan Fitur. Ya, daftarnya akan sama, tetapi versinya bisa sangat sumbang. Ini tidak terlalu keren dari sudut pandang visual, tetapi sangat normal jika semuanya bekerja dengan stabil. Misalnya, untuk layanan Pemasang, nomor versinya jauh tertinggal dari yang tetangga. Horor dan mimpi buruk? Tidak, karena tidak diinstal ulang sepenuhnya, tetapi DLL-nya hanya diperbarui. Di patch v9.5 U4, mimpi buruk dukungan teknis terjadi: selama pembaruan, semua layanan menerima versi baru, kecuali yang paling penting. Di tambalan U4b, layanan transportasi mengambil alih yang lainnya sebanyak dua versi (dilihat dari jumlahnya). Dan ini juga normal - bug serius ditemukan di dalamnya, sehingga menerima pembaruan bonus relatif terhadap yang lain. Jadi untuk meringkasnya: perbedaan versi BISA menjadi masalah, tetapi jika ada perbedaan dan semuanya berfungsi dengan baik, maka mungkin seharusnya begitu. Tetapi tidak ada yang melarang Anda untuk mengklarifikasi hal ini dalam dukungan teknis.
Inilah yang disebut layanan wajib atau Wajib. Dan ada banyak layanan tambahan, seperti Tape Service, Mount Service, vPowerNFS Service, dan sebagainya.
Untuk Hyper-V, secara umum semuanya sama, hanya ada yang spesifik Layanan Integrasi Veeam Backup Hyper-V dan driver Anda sendiri untuk bekerja dengan CBT.
Dan terakhir, mari kita bicara tentang siapa yang bekerja pada mesin virtual selama pencadangan. Untuk menjalankan skrip sebelum dan sesudah pembekuan, untuk membuat salinan bayangan, mengumpulkan metadata, bekerja dengan log transaksi SQL, dll. Pembantu Tamu Veeam. Dan jika sistem file diindeks, Pengindeks Tamu Veeam . Ini adalah layanan sementara yang digunakan selama pencadangan dan dihapus setelahnya.
Dalam kasus mesin Linux, semuanya jauh lebih sederhana karena adanya sejumlah besar pustaka bawaan dan kemampuan sistem itu sendiri. Misalnya, pengindeksan dilakukan melalui mlocate.
Itu saja untuk saat ini
Aku tidak berani menyakitimu lagi pendek Saya menganggap pengantar kompartemen mesin Veeam sudah berakhir. Ya, kami bahkan belum mendekati sarangnya sendiri, tapi percayalah, agar informasi yang disajikan di dalamnya tidak tampak seperti aliran kesadaran yang tidak koheren, pengenalan seperti itu mutlak diperlukan. Saya berencana untuk pergi ke log itu sendiri hanya di artikel ketiga, dan rencana berikutnya adalah menjelaskan siapa yang membuat log, apa sebenarnya yang ditampilkan di dalamnya dan mengapa tepatnya, dan bukan sebaliknya.
Sumber: www.habr.com