Di Veeam, kami menyukai log. Dan karena sebagian besar solusi kami bersifat modular, mereka menulis banyak log. Dan karena lingkup aktivitas kami adalah untuk memastikan keamanan data Anda (yaitu, tidur nyenyak), maka log tidak hanya merekam setiap bersin, tetapi juga melakukannya secara detail. Hal ini diperlukan agar jika terjadi sesuatu maka jelaslah bagaimana “apa” tersebut terjadi, siapa yang harus disalahkan, dan apa yang perlu dilakukan selanjutnya. Ini seperti forensik: Anda tidak pernah tahu hal kecil apa yang akan membantu Anda menemukan pembunuh Laura Palmer.
Oleh karena itu, saya memutuskan untuk membidik serangkaian artikel, di mana saya akan secara konsisten berbicara 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?
Hanya untuk membuat daftar log mana dan apa yang disimpan di dalamnya adalah usaha yang cukup membawa bencana. Dan menakutkan untuk memikirkan untuk terus memperbarui informasi ini. Daftar sederhana dari semua kemungkinan jenis log di Veeam Backup & Replication adalah tabel pada beberapa lembar dalam cetakan kecil. Dan itu hanya akan relevan pada saat publikasi, karena ketika tambalan 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 dikandungnya. Ini akan memungkinkan Anda untuk menavigasi dengan lebih baik di lapangan daripada menjejalkan nama-nama yang sepele.
Oleh karena itu, agar tidak terburu-buru dalam pusaran lembaran teks, mari kita 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: menyusun glosarium dan membahas sedikit struktur Veeam dalam hal menghasilkan log.
Glosarium dan jargon
Di sini, pertama-tama, perlu meminta maaf kepada para pendukung kemurnian bahasa Rusia dan saksi kamus Ozhegov. Kami semua sangat menyukai bahasa asli kami, tetapi industri TI yang terkutuk bekerja dalam bahasa Inggris. Kami tidak menemukannya, tetapi itu terjadi secara historis. Saya tidak bersalah, dia datang sendiri (c)
Dalam bisnis kami, masalah Anglicisms (dan jargon) memiliki kekhususannya sendiri. Ketika dengan kata-kata yang tidak bersalah seperti "tuan rumah" atau "tamu" seluruh dunia telah lama memahami hal-hal yang benar-benar konkret, maka di negeri itu, kebingungan heroik dan goyangan dengan memasukkan kamus terus berlanjut. Dan argumen wajib "Dan di sini di tempat kerja ...".
Ditambah lagi, ada terminologi murni kami, yang melekat pada produk Veeam, meskipun beberapa kata dan frasa telah sampai ke tangan orang-orang. Oleh karena itu, sekarang kita akan sepakat tentang apa arti istilah apa, dan di masa depan, di bawah kata "tamu" yang saya maksud adalah apa yang tertulis dalam 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. Melawan mereka agak tidak ada gunanya. Meskipun saya selalu menyukai memasak di kamenty.
Sayangnya, ada banyak istilah dalam pekerjaan dan produk kami, jadi saya tidak akan mencoba mencantumkan semuanya. Hanya informasi paling dasar tentang backup dan log yang diperlukan untuk kelangsungan hidup di laut. Bagi mereka yang tertarik, saya juga dapat menawarkan artikel kolega tentang pita, di mana dia juga memberikan daftar istilah yang terkait dengan bagian fungsi tersebut.
Host: Di dunia virtualisasi, ini adalah mesin hypervisor. Fisik, virtual, cloud - tidak masalah. Jika hypervisor dijalankan pada sesuatu (ESXi, Hyper-V, KVM dll), maka "sesuatu" ini disebut host. Apakah itu cluster untuk sepuluh rak atau laptop Anda dengan lab untuk satu setengah mesin virtual - jika Anda menjalankan hypervisor, Anda menjadi host. Karena hypervisor menghosting mesin virtual. Bahkan ada kisah bahwa VMware pada suatu waktu ingin mencapai asosiasi yang kuat antara kata host dengan ESXi. Tapi dia tidak melakukannya.
Di dunia modern, konsep "host" secara praktis telah digabungkan dengan konsep "server", yang menimbulkan sejumlah kebingungan dalam komunikasi, terutama jika menyangkut infrastruktur Windows. Jadi mesin apa pun yang menghosting beberapa layanan menarik dapat dengan aman disebut sebagai host. Misalnya, di log WinSock, kata host menandai segalanya. "Host tidak ditemukan" klasik adalah contohnya. Jadi kita melanjutkan dari konteksnya, tapi ingat - dalam dunia virtualisasi, tuan rumah adalah tuan rumah para tamu (lebih lanjut tentang dua baris di bawah ini).
Dari jargon lokal (bahkan akronim, dalam hal ini), saya ingat di sini bahwa VMware adalah VI, vSphere adalah VC, dan Hyper-V adalah HV.
Tamu:Mesin virtual yang berjalan di host. Bahkan tidak ada yang perlu dijelaskan, semuanya sangat logis dan sederhana. Namun, banyak yang dengan rajin menyeret beberapa makna lain di sini.
Untuk apa? Saya tidak tahu.
OS Tamu, masing-masing, sistem operasi mesin tamu. Dll
Pekerjaan Cadangan / Replikasi (JobA): Jargon murni Wim, yang menunjukkan beberapa tugas. Pekerjaan cadangan == Pekerjaan cadangan. Betapa indahnya menerjemahkannya ke dalam bahasa Rusia - tidak ada yang menemukannya, jadi semua orang mengatakan "pekerjaan". Dengan penekanan pada suku kata terakhir.
Ya, mereka hanya mengambilnya dan mengatakan "pekerjaan". Dan bahkan dalam surat mereka menulis seperti itu, dan semuanya baik-baik saja.
Semua pekerjaan cadangan, Tugas Pencadangan, dll., Terima kasih, tetapi tidak perlu. Hanya pekerjaan, dan Anda akan dimengerti. Hal utama adalah memberi tekanan pada suku kata terakhir.
Backup (Backup, backup. Untuk hard-oldfags, backup diperbolehkan): Selain yang sudah jelas (salinan backup data ada di suatu tempat), itu juga berarti pekerjaan itu sendiri (tiga baris di atas, jika Anda sudah lupa), sebagai akibatnya file backup yang sama muncul ... Mungkin, Tuan-tuan, penutur asli bahasa Inggris terlalu malas untuk mengatakan saya menjalankan pekerjaan cadangan saya setiap saat, jadi mereka hanya mengatakan saya menjalankan pencadangan saya, dan semua orang saling memahami dengan sempurna. Saya mengusulkan untuk mendukung usaha yang luar biasa ini.
Mengkonsolidasikan:Sebuah istilah yang diperkenalkan di ESXi 5.0 Sebuah opsi di menu snapshot yang memulai proses penghapusan apa yang disebut orphaned snapshots. Artinya, snapshot yang tersedia secara fisik, tetapi dikeluarkan dari struktur logis yang ditampilkan. Secara teori, proses ini seharusnya tidak memengaruhi file yang ditampilkan di manajer snapshot, tetapi apa pun bisa terjadi. Inti dari proses konsolidasi adalah bahwa data dari snapshot (disk anak) ditulis ke disk utama (induk). Proses penggabungan disk disebut merge. Jika perintah konsolidasi telah dikeluarkan, rekaman snapshot dapat dihapus dari database sebelum snapshot dibekukan dan dihapus. Dan jika snapshot tidak dapat dihapus karena alasan apa pun, maka snapshot yatim piatu ini akan muncul. VMware memiliki KB yang baik tentang bekerja dengan snapshot . Dan kami juga, entah bagaimana tentang merekamenulis di Habré .
Datastore (Stora atau toko): Konsep yang sangat luas, tetapi dalam dunia virtualisasi, ini mengacu pada 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:Penting untuk segera memahami bahwa Veeam Proxy tidak persis sama dengan yang biasa kita gunakan di bidang Internet. Dalam produk Veeam, ini adalah entitas yang terlibat dalam mentransfer data dari satu tempat ke tempat lain. Tanpa menjelaskan secara detail, VBR adalah server perintah, dan proxy adalah perangkat kerjanya. Artinya, proxy adalah mesin tempat lalu lintas mengalir dan di mana komponen VBR dipasang yang membantu mengarahkan lalu lintas ini. Misalnya, mentransfer data dari satu saluran ke saluran lain, atau cukup pasang disk ke Anda sendiri (mode HotAdd).
Gudang: Secara teknis, ini hanyalah entri di database VBR yang menunjukkan lokasi penyimpanan cadangan dan cara menyambungkan ke lokasi ini. Faktanya, ini bisa berupa bola CIFS, atau disk, server, atau bucket terpisah di cloud. Sekali lagi, kami berada dalam konteks, tetapi pahami bahwa repositori adalah tempat cadangan Anda berada.
Foto:Pecinta tata bahasa Oxford lebih suka mengatakan siapa itu potret, siapa potret, tetapi mayoritas buta huruf mendapat manfaat dari massa yang lebih besar. Jika ada yang tidak tahu, ini adalah teknologi yang memungkinkan Anda memulihkan status disk ke 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 disk lain - ini akan disebut CoW (Salin saat Menulis) foto. Berkat kemungkinan yang luas untuk penggunaan fungsi-fungsi ini, Veeam dapat melakukan sihir cadangannya sendiri. Sebenarnya, tidak hanya untuk mereka, tetapi ini adalah urusan rilis berikutnya.
Ada kekacauan dalam dokumentasi dan log ESXi seputar istilah ini, dan dalam konteks menyebutkan snapshot, Anda dapat menemukan snapshot itu sendiri, mengulang log, dan bahkan delta disk. Tidak ada gangguan seperti itu dalam dokumentasi Veeam, dan snapshot adalah snapshot, dan redo log adalah file REDO yang dibuat oleh disk non-persisten independen. File REDO dihapus ketika mesin virtual dimatikan, jadi membingungkan mereka dengan snapshot adalah jalan menuju kegagalan.
Sintetis: Pencadangan sintetis mengacu pada pencadangan inkremental terbalik dan pencadangan ke depan selamanya. Jika Anda tiba-tiba tidak menemukan istilah ini, maka ini hanyalah salah satu mekanisme yang digunakan untuk membangun \ mengubah rantai cadangan. Namun, di log, Anda juga dapat menemukan konsep Transform, yang digunakan dalam pembuatan salinan lengkap sintetis.
Tugas (Tugas):Ini adalah proses memproses setiap mesin dalam sebuah pekerjaan. Yaitu: Anda memiliki pekerjaan cadangan yang mencakup tiga mesin. Artinya, setiap mobil akan diproses sebagai tugas tersendiri. Secara total, akan ada empat log: yang utama untuk tugas itu dan tiga untuk tugas. Namun, ada nuansa penting: seiring waktu, kata "tugas" menjadi terlalu ambigu. Ketika kita berbicara tentang log umum, yang kami maksud adalah bahwa tugas adalah VM. Tetapi proxy dan repositori memiliki "tugas" masing-masing. Di sana itu bisa berarti disk virtual, mesin virtual, dan seluruh pekerjaan. Artinya, penting untuk tidak kehilangan konteks.
Veeam% name% Layanan : Untuk kepentingan pencadangan yang berhasil, beberapa layanan bekerja sekaligus, daftarnya dapat ditemukan di peralatan standar. Nama mereka cukup transparan mencerminkan esensi mereka, tetapi di antara yang sederajat ada yang paling penting - Layanan Cadangan Veeam, yang tanpanya, yang lain tidak akan berfungsi.
VSS: Secara teknis, VSS harus selalu merupakan singkatan dari Microsoft Volume Shadow Copy Service. Faktanya, ini digunakan oleh banyak orang sebagai sinonim untuk Pemrosesan Gambar Sadar Aplikasi. Yang, tentu saja, secara kategoris salah, tapi ini adalah cerita dari kategori "SUV apa pun bisa disebut jip, dan Anda akan mengerti."
Kayu gelondongan dan tempat tinggal yang fantastis
Saya ingin memulai bab ini dengan mengungkapkan rahasia besar - jam berapa yang ditampilkan di log?
Ingat:
- ESXi selalu mencatat ke UTC + 0.
- vCenter menyimpan log pada waktu zona waktunya.
- Veeam .
- EVTX . , . , . — . . , , , , IT , . .
Sekarang mari kita bicara tentang tempat tinggal log dan bagaimana mendapatkannya. Dalam kasus VBR, ada dua pendekatan.
Opsi pertama cocok jika Anda tidak ingin mencari file di heap umum yang terkait secara khusus dengan masalah Anda. Untuk melakukan ini, kami memiliki wizard terpisah, di mana Anda dapat menentukan pekerjaan tertentu dan periode tertentu yang Anda perlukan lognya. Kemudian dia akan memeriksa sendiri para ayah dan memasukkan semua yang dia butuhkan ke dalam satu arsip. Tentang di mana mencarinya dan bagaimana cara menggunakannya dijelaskan secara rinci dalam KB ini .
Namun, wizard mengumpulkan log tidak dari semua tugas dan, misalnya, jika Anda perlu mempelajari log restoran, failover atau failback, jalur Anda terletak di folder % ProgramData% / Veeam / Backup... Ini adalah tempat penyimpanan logo VBR utama, dan% ProgramData% adalah folder tersembunyi dan tidak apa-apa. Omong-omong, lokasi default dapat ditetapkan kembali menggunakan kunci registri seperti REG_SZ: LogDirectory di cabang HKEY_LOCAL_MACHINE \ SOFTWARE \ Veeam \ Veeam Backup dan Replikasi \.
Pada mesin Linux, log agen pekerja harus dicari di / var / log / VeeamBackup / jika akun root atau sudo digunakan. Jika Anda tidak memiliki hak istimewa seperti itu, cari log di / tmp / VeeamBackup .
Untuk agen Veeam untuk% OS_name%, log harus dicari di % ProgramData% / Veeam / Endpoint (atau % ProgramData% / Veeam / Backup / Endpoint ) dan / var / log / veeam .
Jika Anda menggunakan Pemrosesan Gambar Sadar Aplikasi (dan kemungkinan besar Anda menggunakannya), situasinya menjadi agak lebih rumit. Anda akan membutuhkan log dari helper kami, yang disimpan di dalam mesin virtual itu sendiri, dan log VSS. Bagaimana dan di mana mendapatkan kebahagiaan ini dijelaskan secara rinci dalam artikel ini . Dan, tentu saja, ada artikel terpisah tentang mengumpulkan log sistem yang diperlukan.
Lebih mudah untuk mengumpulkan acara Windows menurut HF ini . Jika Anda menggunakan Hyper-V, segalanya menjadi lebih rumit, karena Anda juga akan memerlukan semua lognya dari Applications and Service Logs> Microsoft> cabang Windows. Meskipun, Anda selalu dapat mengambil rute yang lebih cerdik dan mengambil semua objek dari% SystemRoot% \ System32 \ winevt \ Logs.
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 Anda dapat menemukan informasi yang lebih berguna di acara OS daripada di log ini. Sisa yang menarik terletak pada% Temp%, tetapi sebagian besar ada log instalasi perangkat lunak terkait, seperti database, pustaka .Net, dan hal-hal lain. Harap dicatat 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. Karena itu, Anda perlu pergi ke log dan melihat apa yang sebenarnya rusak dan pada saat apa.
Dan akhirnya peretasan seumur hidup: jika Anda mendapatkan kesalahan saat instalasi, jangan terburu-buru untuk mengklik OK. Pertama, kami mengambil log, lalu klik OK. Jadi Anda mendapatkan log yang berakhir pada saat kesalahan, tanpa sampah di akhir.
Dan kebetulan Anda perlu masuk ke log vSphere. Ini pekerjaan yang sangat tanpa pamrih, tetapi setelah menyingsingkan lengan baju, Anda harus melakukan sesuatu yang lain. Dalam bentuknya yang paling sederhana, kita memerlukan log dengan kejadian 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, karena VMware suka mengubah tempat ini dari rilis ke rilis. Misalnya, berikut adalah artikel untuk 7.0 , tetapi di sini untuk 5.5 . Untuk log vCenter, ulangi prosedur google... Namun secara umum, kita akan tertarik dengan log peristiwa host hostd.log, peristiwa host yang dikontrol oleh vCenter vpxa.log, log kernel vmkernel.log, dan log otentikasi auth.log. Nah, dalam kasus paling lanjut, log SSO dapat berguna, yang terletak di folder SSO.
Apakah itu merepotkan? Bingung? Mengerikan? Tetapi ini bahkan bukan setengah dari informasi yang digunakan oleh dukungan kami setiap hari. Jadi mereka sangat keren.
Komponen Veeam
Dan untuk melengkapi artikel pengantar ini, mari kita bicara sedikit tentang komponen Backup & Replikasi Veeam. Karena saat mencari penyebab nyeri, alangkah baiknya memahami cara kerja pasien.
Jadi, seperti yang mungkin diketahui semua orang, Veeam Backup adalah apa yang disebut aplikasi berbasis SQL. Artinya, semua pengaturan, semua informasi dan secara umum segala sesuatu yang hanya diperlukan untuk fungsi normal - semua ini ada dalam database-nya. Sebaliknya, dalam dua basis, jika kita berbicara tentang bundel VBR dan EM: VeeamBackup dan VeeamBackupReporting. Dan begitulah yang terjadi: kami meletakkan satu aplikasi lagi - basis lain muncul. Agar tidak menyimpan semua telur dalam satu corine.
Tetapi agar semua ekonomi ini bekerja dengan lancar, kami memerlukan serangkaian layanan dan aplikasi yang akan menghubungkan semua komponen secara bersamaan. Sebagai contoh saja, berikut tampilannya di salah satu lab saya:
Veeam Backup Service adalah konduktor utama . Dialah yang bertanggung jawab atas pertukaran informasi dengan database. Dia juga bertanggung jawab untuk meluncurkan semua tugas, mengatur sumber daya yang dialokasikan dan bekerja sebagai semacam pusat komunikasi untuk berbagai konsol, agen, dan lainnya. Singkatnya, pasti tidak ada apa-apa tanpa dia, tetapi ini tidak berarti sama sekali bahwa dia melakukan semuanya sendiri. Veeam Backup Manager
membantunya melaksanakan rencananya . Ini bukan layanan, tetapi entitas yang meluncurkan pekerjaan dan memantau proses pelaksanaannya. Tangan kerja layanan pencadangan, yang menghubungkannya ke host, membuat snapshot, memantau retensi, dan sebagainya. Tapi kembali ke daftar layanan. Layanan Broker Veeam
... Diperkenalkan di v9.5 (dan ini bukan penambang kripto, seperti yang dipikirkan beberapa orang). Mengumpulkan informasi tentang host VMware dan selalu memperbaruinya. Tapi jangan langsung lari menulis komentar marah karena kami memata-matai Anda dan membocorkan semua login / password ke tashmayor. Semuanya lebih sederhana. Saat Anda memulai pencadangan, hal pertama yang perlu Anda lakukan adalah menyambungkan ke host dan memperbarui semua data tentang strukturnya. Ini adalah cerita yang agak lambat dan tidak praktis. Ingat saja berapa lama waktu yang Anda butuhkan untuk 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 backup, 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 melaluinya akan selalu mungkin untuk menerima informasi yang relevan. Saat memulai, ia memeriksa dan memindai seluruh infrastruktur tambahan, lalu mencoba bekerja hanya pada tingkat perubahan tambahan. Jadi, meskipun Anda menjalankan ratusan backup pada saat yang sama, mereka semua akan meminta informasi dari broker kami, dan tidak akan menyiksa host dengan permintaan mereka. Jika Anda khawatir tentang sumber daya, maka menurut perhitungan kami, untuk 5000 mesin virtual Anda hanya membutuhkan sekitar 100 Mb memori.mereka semua akan meminta informasi dari broker kami, dan tidak akan menyiksa host dengan permintaan mereka. Jika Anda khawatir tentang sumber daya, maka menurut perhitungan kami, untuk 5000 mesin virtual Anda hanya membutuhkan sekitar 100 Mb memori.mereka semua akan meminta informasi dari broker kami, dan tidak akan menyiksa host dengan permintaan mereka. Jika Anda khawatir tentang sumber daya, maka menurut perhitungan kami untuk 5.000 mesin virtual, Anda hanya membutuhkan sekitar 100 Mb memori.
Selanjutnya adalah Konsol Veeam . Aka Veeam Remote Console, alias Veeam.Backup.Shell. Ini adalah GUI yang sama yang kami lihat di tangkapan layar. Semuanya sederhana dan jelas - konsol dapat diluncurkan dari mana saja, selama itu adalah 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, Veeam Explorers yang beraneka ragam juga akan berjalan secara lokal, karena mereka adalah bagian dari konsol. Tapi ini telah membawa saya ke dalam hutan ...
Layanan menarik berikutnya 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. Hanya digunakan jika kotak centang pengindeksan diaktifkan. Dan hanya masuk akal untuk mengaktifkannya jika Anda memiliki Manajer Perusahaan. Oleh karena itu nasehat dari lubuk hati saya yang paling dalam: jangan nyalakan indexing begitu saja kalau belum punya EM. Hemat saraf dan waktu dukungan Anda.
Juga dari layanan penting lainnya, perlu diperhatikan Layanan Penginstal Veeam , dengan bantuan yang komponen yang diperlukan dikirimkan dan diinstal pada proxy, repositori dan gateway lainnya. Nyatanya, dia mengambil paket .msi yang diperlukan ke server dan menginstalnya.
Veeam Data Mover- dengan bantuan agen tambahan yang diluncurkan pada proxy (dan tidak hanya), ia terlibat dalam transfer data. Misalnya, selama pencadangan, satu agen akan membaca file dari datastore host, dan yang kedua akan menulisnya dengan hati-hati ke cadangan.
Secara terpisah, saya ingin mencatat satu hal penting yang sering ditanggapi klien - ini adalah perbedaan antara versi layanan dan informasi di snap-in Program dan Fitur. Ya, daftarnya akan sama, tetapi versinya mungkin benar-benar berantakan. Ini tidak terlalu keren dari sudut pandang visual, tetapi tidak apa-apa jika semuanya bekerja dengan stabil. Misalnya, untuk layanan Installer, nomor versinya jauh di belakang yang berdekatan. Horor dan mimpi buruk? Tidak, karena tidak sepenuhnya diinstal ulang, tetapi DLL-nya hanya diperbarui. Di patch v9.5 U4, ada mimpi buruk dukungan teknis: selama pembaruan, semua layanan menerima versi baru, kecuali yang paling penting. Di patch U4b, layanan transport mengambil alih semua versi lainnya sebanyak dua versi (dilihat dari angkanya). Dan tidak apa-apa juga - bug serius ditemukan di dalamnya, jadi ia mendapat pembaruan bonus dari yang lainnya. Karena itu, untuk meringkas:perbedaan versi MUNGKIN menjadi masalah, tetapi jika ada perbedaan dan semuanya bekerja dengan baik, kemungkinan besar seharusnya demikian. Tetapi tidak ada yang melarang Anda untuk menjelaskan hal ini dalam dukungan teknis.
Inilah yang disebut layanan wajib atau wajib. Dan ada juga sejumlah besar tambahan, seperti Tape Service, Mount Service, vPowerNFS Service dan sebagainya.
Untuk Hyper-V, secara umum semuanya sama, hanya ada Veeam Backup Hyper-V Integration Service tertentu dan drivernya sendiri untuk bekerja dengan CBT.
Dan pada akhirnya, mari kita bahas siapa yang bekerja di mesin virtual selama pencadangan. Veeam Guest Helper digunakan untuk menjalankan skrip pra-dan pasca-pembekuan, untuk membuat salinan bayangan, mengumpulkan metadata, bekerja dengan log transaksi SQL, dan banyak lagi . Dan jika sistem file diindeks, Veeam Guest Indexer . 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
Saya tidak berani menyiksa Anda lagi dan saya mempertimbangkan pengenalan singkat tentang kompartemen mesin Veeam. Ya, kami bahkan belum mendekati log itu sendiri, tetapi percayalah, sehingga informasi yang disajikan di dalamnya tidak tampak seperti aliran kesadaran yang tidak koheren, pengenalan semacam itu mutlak diperlukan. Saya berencana untuk pergi ke log sendiri hanya di artikel ketiga, dan rencana untuk yang berikutnya adalah menjelaskan siapa yang menghasilkan log, apa sebenarnya yang ditampilkan di dalamnya dan mengapa persis seperti ini, dan bukan sebaliknya.