Veeam Log Diving Bileşenleri ve Sözlüğü

Veeam Log Diving Bileşenleri ve Sözlüğü

Veeam aşk günlüklerinde biz. Çözümlerimizin çoğu modüler olduğundan, çok sayıda günlük yazıyorlar. Ve faaliyetimizin kapsamı verilerinizin güvenliğini (yani dinlendirici uyku) sağlamak olduğundan, günlükler yalnızca her hapşırmayı kaydetmemeli, aynı zamanda bunu biraz ayrıntılı olarak yapmalıdır. Bu, bir şey olması durumunda bunun "ne" olduğunu, kimin suçlanacağını ve bundan sonra ne yapılması gerektiğini netleştirmek için gereklidir. Adli tıpta olduğu gibi: Laura Palmer'ın katilini bulmanıza hangi küçük şeyin yardım edeceğini asla bilemezsiniz.

Bu nedenle, günlüklere ne yazdığımızdan, onları nerede sakladığımızdan, yapılarıyla nasıl çıldırmayacağımızdan ve içlerinde ne aramamız gerektiğinden sırayla bahsedeceğim bir dizi makaleye hız kesmeye karar verdim.

Neden bir dizi makale ve neden her şeyi bir kerede anlatmıyorsunuz?

Hangi günlüğün nerede ve içinde nelerin saklandığını listelemek oldukça feci bir girişimdir. Ve bu bilgileri güncel tutmayı düşünmek bile korkutucu. Veeam Backup & Replication'daki tüm olası günlük türlerinin basit bir listesi, birkaç sayfadan oluşan küçük puntolu bir tablodur. Evet ve yalnızca yayınlandığı tarihte geçerli olacaktır, çünkü. bir sonraki yama yayınlandığında yeni günlükler görünebilir, eskilerde depolanan bilgilerin mantığı değişecektir vb. Bu nedenle yapılarını ve içerdikleri bilgilerin özünü açıklamak çok daha karlı olacaktır. Bu, yerlerde adların banal tıkış tıkış dolaşmasından daha iyi gezinmenizi sağlayacaktır.

Bu nedenle, metin sayfaları havuzuna acele etmemek için, bu makalede bazı hazırlık çalışmaları yapalım. Bu nedenle, bugün günlüklerin kendilerine girmeyeceğiz, ancak uzaktan gideceğiz: bir sözlük derleyeceğiz ve günlük oluşturma açısından Veeam yapısını biraz tartışacağız.

Sözlük ve jargon

Burada her şeyden önce Rus dilinin saflığının savunucularından ve Ozhegov'un sözlüğünün tanıklarından özür dilemeye değer. Hepimiz anadilimizi çok seviyoruz ama kahrolası bilişim sektörü İngilizce çalışıyor. Biz bulmadık ama tarihsel olarak oldu. Benim hatam değil, kendisi geldi (c)

Bizim işimizde İngilizce (ve jargon) sorununun kendine has özellikleri vardır. "Ev sahibi" veya "misafir" gibi masum kelimeler altında tüm dünya çok özel şeyleri çoktan anlamışken, o zaman ülkenin ⅙'inde kahramanca bir kafa karışıklığı ve sözlüklere dalmakla şaşırtma devam ediyor. Ve kesinlikle zorunlu argüman "Ama bizim işimizde ...".

Ayrıca, bazı sözcükler ve deyimler insanlara geçmiş olsa da, Veeam ürünlerinin doğasında olan tamamen bizim terminolojimiz var. Bu nedenle, şimdi hangi terimin ne anlama geldiği konusunda hemfikir olacağız ve gelecekte "misafir" kelimesi altında işte alışık olduğunuz şeyi değil, tam olarak bu bölümde yazılanları kastedeceğim. Ve evet, bu benim kişisel hevesim değil, bunlar sektörde köklü terimler. Onlarla savaşmak biraz anlamsız. Her zaman yorumlarda rahatlamaktan yanayım.

Ne yazık ki, çalışmalarımızda ve ürünlerimizde çok fazla terim var, bu yüzden hepsini listelemeye çalışmayacağım. Denizde hayatta kalmak için yedeklemeler ve günlükler hakkında yalnızca en temel ve gerekli bilgiler. ilgilenenler için ben de makale önermek arkadaşlarına, işlevselliğin o kısmıyla ilgili terimlerin bir listesini de verdiği kasetler hakkında bilgi verdi.

Ana bilgisayar (Ana bilgisayar): Sanallaştırma dünyasında bu, hiper yöneticili bir makinedir. Fiziksel, sanal, bulut fark etmez. Bir şey hiper yönetici çalıştırıyorsa (ESXi, Hyper-V, KVM vb.), bu "bir şeye" ana bilgisayar denir. İster on raflı bir küme, ister bir buçuk sanal makinelik bir laboratuvarı olan dizüstü bilgisayarınız olsun, bir hipervizör başlattıysanız, bir ana bilgisayar oldunuz. Çünkü hipervizör sanal makineleri barındırır. Hatta bir zamanlar VMware'in host kelimesini ESXi ile sağlam bir şekilde ilişkilendirmek istediğine dair bir hikaye bile var. Ama yapmadı.

Modern dünyada, "ana bilgisayar" kavramı, özellikle Windows altyapısı söz konusu olduğunda, iletişime biraz kafa karışıklığı getiren "sunucu" kavramıyla fiilen birleşti. Bu nedenle, bizi ilgilendiren bazı hizmetleri barındıran herhangi bir makineye güvenli bir şekilde ana bilgisayar denilebilir. Örneğin, WinSock günlüklerinde her şey ana bilgisayar kelimesiyle işaretlenmiştir. Klasik "Ana bilgisayar bulunamadı" buna bir örnektir. Bu nedenle, bağlamdan başlıyoruz, ancak unutmayın - sanallaştırma dünyasında, bir ev sahibi konukları ağırlayan şeydir (bununla ilgili daha fazla bilgiyi aşağıdaki iki satırda bulabilirsiniz).

Yerel jargondan (bu durumda daha ziyade kısaltmalar), burada VMware'in VI, vSphere'in VC ve Hyper-V'nin HV olduğu hatırlanır.

Misafir (Misafir): Ana bilgisayarda çalışan sanal makine. Burada açıklanacak bir şey yok, her şey çok mantıklı ve basit. Bununla birlikte, birçoğu özenle başka anlamları da buraya sürükler.

Ne için? Bilmiyorum.
Konuk işletim sistemi, sırasıyla konuk makinenin işletim sistemidir. Ve benzeri.

Yedekleme/Çoğaltma İşi (işA): Bazı görevleri ifade eden saf Wim jargonu. Yedekleme işi == Yedekleme İşi. Kimse onu güzelce Rusçaya nasıl çevireceğini bulamadı, bu yüzden herkes "JobA" diyor. Son heceye vurgu yaparak.

Evet, basitçe alıyorlar ve “joba” diyorlar. Ve mektuplarda bile böyle yazıyorlar ve her şey yolunda.
Her türlü Yedekleme işi, Yedekleme Görevleri vb. teşekkürler ama gerek yok. Sadece bir iş ve anlaşılacaksın. Önemli olan vurguyu son heceye koymaktır.

Yedekleme (Yedekleme, yedekleme. Eski tipler için yedeklemeye izin verilir): Bariz olana (bir yerde yatan verilerin yedek kopyası) ek olarak, aynı zamanda işin kendisi (zaten unuttuysanız üç satır yukarıda) anlamına gelir ve bunun sonucunda yedekleme dosyası görünür. Muhtemelen, ana dili İngilizce olan beyefendiler, her seferinde yedekleme işimi çalıştırdığımı söylemek için çok tembeller, bu yüzden sadece yedeklememi çalıştırdığımı söylüyorlar ve herkes birbirini mükemmel bir şekilde anlıyor. Sizi bu harika girişimi desteklemeye davet ediyorum.

Konsolidasyon (Konsolidasyon): ESXi 5.0'da ortaya çıkan bir terim Anlık görüntü menüsünde artık durumdaki anlık görüntüleri silme işlemini başlatan bir seçenek. Yani, fiziksel olarak mevcut olan ancak görüntülenen mantıksal yapının dışında kalan anlık görüntüler. Teorik olarak, bu işlem anlık görüntü yöneticisinde görüntülenen dosyaları etkilememelidir, ancak her şey olabilir. Konsolidasyon işleminin özü, anlık görüntüden (alt disk) gelen verilerin ana (ana) diske yazılmasıdır. Diskleri birleştirme işlemine birleştirme denir. Bir konsolidasyon komutu verildiyse, anlık görüntü birleştirilip silinmeden önce anlık görüntü kaydı veritabanından kaldırılabilir. Anlık görüntü herhangi bir nedenle silinemezse, aynı yetim anlık görüntüler görünür. Anlık görüntülerle çalışma hakkında, VMware'in iyi KB. Ve biz de bir şekilde onlar hakkında Habré'de yazdı.

Veri deposu (Stora veya depolama):  Çok geniş bir kavram, ancak sanallaştırma dünyasında sanal makine dosyalarının depolandığı bir yer olarak anlaşılmaktadır. Ancak her durumda, burada bağlamı çok net bir şekilde anlamanız ve en ufak bir şüpheyle muhatabınızın tam olarak ne düşündüğünü netleştirmeniz gerekir. 

Proxy (Proxy): Veeam Proxy'nin internette alışık olduğumuzdan farklı olduğunu hemen anlamak önemlidir. Veeam ürünlerinde bu, verilerin bir yerden başka bir yere aktarılmasıyla ilgilenen bir tür varlıktır. Ayrıntılara girmezseniz, VBR bir komuta ve kontrol sunucusudur ve proxy'ler onun işgücüdür. Yani proxy, trafiğin aktığı ve bu trafiğin yönlendirilmesine yardımcı olan VBR bileşenlerinin kurulu olduğu bir makinedir. Örneğin, bir kanaldan diğerine veri aktarmak veya sadece diskleri kendisine yapıştırmak (HotAdd modu).

Depo (Havuz):  Teknik olarak, bu sadece VBR veritabanında, yedeklerin depolandığı yeri ve bu yere nasıl bağlanılacağını gösteren bir giriştir. Aslında, yalnızca bir CIFS topu veya bulutta ayrı bir disk, sunucu veya kova olabilir. Yine bağlamdayız, ancak bir deponun yalnızca yedeklerinizin bulunduğu bir yer olduğunu anlıyoruz.

 Anlık Görüntü (Anlık Görüntü): Oxford dilbilgisi meraklıları, kimin anlık, kimin anlık olduğunu söylemeyi tercih ediyor, ancak okuma yazma bilmeyen çoğunluk daha büyük kitleden yararlanıyor. Kimse bilmiyorsa, bu, bir diskin durumunu belirli bir zamanda geri yüklemenizi sağlayan bir teknolojidir. Bu, G / Ç işlemlerini geçici olarak ana diskten uzaklaştırarak yapılır - daha sonra RoW (Yazma Yönlendirme) anlık görüntüsü olarak adlandırılır - veya yeniden yazılabilir blokları diskinizden diğerine taşıyarak - buna CoW (Yazma Kopyalama) adı verilir ) anlık görüntü. Bu işlevlerin geniş kullanım olanakları sayesinde Veeam yedekleme büyüsünü gerçekleştirebilir. Kesin konuşmak gerekirse, sadece onlar değil, bu sonraki sürümlerin meselesi.

ESXi belgelerinde ve günlüklerinde bu terim etrafında bir kaos var ve anlık görüntülerden bahsetme bağlamında, anlık görüntülerin kendilerini bulabilir ve günlüğü yeniden yapabilir ve hatta delta diski bulabilirsiniz. Veeam belgeleri böyle bir yırtılma içermez ve anlık görüntü anlık görüntüdür ve redo günlüğü tam olarak bağımsız, kalıcı olmayan bir disk tarafından oluşturulan bir REDO dosyasıdır. REDO dosyaları, sanal makine kapatıldığında silinir, bu nedenle bunların anlık görüntülerle karıştırılması başarısızlığa giden bir yoldur.

Sentetik (Sentetikler): Sentetik yedeklemeler, ters artımlı ve sonsuza kadar ileri yedeklemelerdir. Bu terime rastlamadıysanız, bu bir yedek zincir dönüşümü oluşturmak için kullanılan mekanizmalardan sadece biridir. Bununla birlikte, günlüklerde artımlardan (sentetik tam) tam kopyalar oluşturma çerçevesinde kullanılan Dönüşüm kavramını da bulabilirsiniz.

Görev (Görev): Bu, iş içindeki her bir makineyi işleme sürecidir. Yani: üç makine içeren bir yedekleme işiniz var. Bu, her arabanın ayrı bir görevin parçası olarak işleneceği anlamına gelir. Toplamda dört günlük olacak: işler için ana ve görevler için üç. Ancak burada önemli bir nüans var: Zamanla "görev" kelimesi gereksiz yere belirsiz hale geldi. Genel günlüklerden bahsettiğimizde, bir görevin tam olarak bir VM olduğunu kastediyoruz. Ancak hem proxy'de hem de depoda "görevler" vardır. Orada bir sanal disk, bir sanal makine ve tüm iş anlamına gelebilir. Yani, bağlamı kaybetmemek önemlidir.

Veeam %name% Hizmeti:  Başarılı yedeklemeler için, bir listesi standart donanımda bulunabilen birkaç hizmet aynı anda çalışır. İsimleri oldukça şeffaf bir şekilde özlerini yansıtıyor, ancak eşitler arasında en önemlisi var - Veeam Yedekleme Hizmeti, onsuz geri kalanı işe yaramaz.

VSS: Teknik olarak, VSS her zaman Microsoft Birim Gölge Kopyası Hizmeti anlamına gelmelidir. Aslında, birçok kişi tarafından Uygulama Duyarlı Görüntü İşleme ile eşanlamlı olarak kullanılır. Elbette kategorik olarak yanlış olan, ancak bu, "Herhangi bir SUV'a cip denilebilir ve sizi anlayacaksınız" kategorisinden bir hikaye.

Fantastik kütükler ve yaşadıkları yerler

Bu bölüme büyük sırrı açıklayarak başlamak istiyorum - günlüklerde saat kaçta gösteriliyor?

Hatırlamak:

  • ESXi, günlükleri her zaman UTC+0'da yazar.
  • vCenter, günlükleri saat dilimine göre tutar.
  • Veeam, günlükleri bulunduğu sunucunun saatine ve saat dilimine göre tutar.
  • Ve yalnızca EVTX biçimindeki Windows olayları hiçbir şeye bağlanmaz. Açıldığında, açıldıkları araba için zaman yeniden hesaplanır. Zorluklar olmasına rağmen en uygun seçenek. Tek somut zorluk, yerel ayarlardaki farktır. Bu, okunamayan günlüklere pratik olarak garantili bir yoldur. Evet, bunun nasıl ele alınacağına dair seçenekler var, ancak BT'deki her şeyin İngilizce çalıştığı gerçeğini tartışmayalım ve sunucularda her zaman İngilizce yerel ayarı ayarlamayı kabul edelim. Lütfen. 

Şimdi kütüklerin yaşadığı yerlerden ve nasıl elde edileceğinden bahsedelim. VBR durumunda, iki yaklaşım vardır. 

İlk seçenek, özellikle sorununuzla ilgili genel yığındaki dosyaları aramaya istekli değilseniz uygundur. Bunu yapmak için, günlüklere ihtiyaç duyduğunuz belirli bir işi ve belirli bir dönemi belirtebileceğiniz ayrı bir sihirbazımız var. Sonra klasörleri kendisi gözden geçirecek ve ihtiyacınız olan her şeyi tek bir arşive koyacaktır. Nerede arayacağınız ve onunla nasıl çalışacağınız ayrıntılı olarak açıklanmaktadır. bu HF.

Ancak, sihirbaz tüm görevlerin günlüklerini toplamaz ve örneğin geri yükleme, yük devretme veya yeniden çalışma günlüklerini incelemeniz gerekirse yolunuz klasörde bulunur. %ProgramData%/Veeam/Yedekleme. Bu ana VBR logo deposudur ve %ProgramData% gizli bir klasördür ve sorun değil. Bu arada, varsayılan konum, HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Yedekleme ve Çoğaltma dalında REG_SZ: LogDirectory türü kayıt defteri anahtarı kullanılarak yeniden atanabilir.

Linux makinelerde, çalışan aracı günlükleri / içinde aranmalıdır.var/log/VeeamBackup/bir kök veya sudo hesabı kullanıyorsanız. Böyle ayrıcalıklara sahip değilseniz, girişleri arayın /tmp/VeeamBackup

%OS_name% için Veeam aracısı için günlükler şurada aranmalıdır: %ProgramData%/Veeam/Endpoint (ya %ProgramData%/Veeam/Yedekleme/Son Nokta) Ve /var/log/veeam sırasıyla.

Uygulama Duyarlı Görüntü İşleme kullanıyorsanız (ve büyük olasılıkla kullanıyorsunuz), durum biraz daha karmaşık hale gelir. Yardımcımızın sanal makinenin içinde saklanan günlüklerine ve VSS günlüklerine ihtiyacınız olacak. Bu mutluluğun nasıl ve nereden elde edileceği hakkında ayrıntılı olarak yazılmıştır. Bu makalede. Ve tabii ki var ayrı makale gerekli sistem günlüklerini toplamak için. 

Windows olayları şuna göre uygun bir şekilde toplanır: bu HF. Hyper-V kullanıyorsanız, Uygulamalar ve Hizmet Günlükleri > Microsoft > Windows şubesinden tüm günlüklerine de ihtiyacınız olacağından işler daha karmaşık hale gelir. Yine de her zaman daha aptalca bir yola gidip %SystemRoot%System32winevtLogs'tan tüm nesneleri alabilirsiniz.

Yükleme/yükseltme sırasında bir şey bozulursa ihtiyacınız olan her şey %ProgramData%/Veeam/Setup/Temp klasöründe bulunabilir. Yine de işletim sistemi olaylarında bu günlüklerden daha yararlı bilgiler bulabileceğiniz gerçeğini saklamayacağım. İlginç olanın geri kalanı %Temp% içindedir, ancak temel, .Net kitaplıkları ve diğer şeyler gibi ilgili yazılımlar için yükleme günlükleri vardır. GUI'de gösterilmese bile Veeam'in msi'den yüklendiğini ve tüm bileşenlerinin ayrı msi paketleri olarak yüklendiğini unutmayın. Bu nedenle, bileşenlerden birinin kurulumu başarısız olursa, tüm VBR kurulumu durdurulacaktır. Bu nedenle, günlüklere girmeniz ve tam olarak neyin ve hangi noktada kırıldığını görmeniz gerekir.

Ve son olarak, bir cankurtaran hilesi: kurulum sırasında bir hata alırsanız, Tamam'ı tıklatmak için acele etmeyin. Önce logları alıyoruz ardından OK diyoruz. Bu şekilde, hata anında sona eren ve sonunda çöp olmayan bir günlük elde edersiniz.

Ve vSphere günlüklerine girmeniz gerekiyor. İşgal çok nankör ama kolları sıvadıktan sonra başka bir şey yapmak gerekiyor. En basit sürümde, .vmx dosyasının yanında bulunan vmware.log sanal makine olaylarını içeren günlüklere ihtiyacımız var. Daha zor bir durumda, Google'ı açın ve ana bilgisayar sürümünüz için günlüklerin nerede olduğunu sorun, çünkü VMware burayı yayından sürüme değiştirmeyi sever. Örneğin, 7.0 için makale, ama için 5.5. vCenter günlükleri için prosedürü tekrarlayın googling. Ancak genel olarak, konak olay günlükleri hostd.log, vCenter vpxa.log tarafından yönetilen ana bilgisayar olayları, vmkernel.log çekirdek günlükleri ve auth.log kimlik doğrulama günlükleri ile ilgileneceğiz. Pekala, en çok ihmal edilen durumlarda, SSO klasöründe bulunan SSO günlüğü kullanışlı olabilir.

Hantal? Kafası karışmış? Korkutucu? Ancak bu, desteğimizin günlük olarak çalıştığı bilgilerin yarısı bile değil. Yani gerçekten çok havalılar.

Veeam Bileşenleri

Ve bu giriş niteliğindeki makalenin sonunda, Veeam Backup & Replication'ın bileşenlerinden biraz bahsedelim. Çünkü ağrının sebebini ararken hastanın nasıl çalıştığını anlamak güzel olur.

Dolayısıyla, muhtemelen herkesin bildiği gibi, Veeam Backup sözde SQL tabanlı bir uygulamadır. Yani, tüm ayarlar, tüm bilgiler ve genel olarak yalnızca normal işleyiş için gerekli olan her şey - tüm bunlar veritabanındadır. Daha doğrusu, iki veritabanında, bir dizi VBR ve EM'den bahsediyorsak: sırasıyla VeeamBackup ve VeeamBackupReporting. Ve böylece oldu: başka bir uygulama koyduk - başka bir veritabanı beliriyor. Tüm yumurtaları aynı sepette saklamamak için.

Ancak tüm bu ekonominin sorunsuz çalışması için tüm bileşenleri birbirine bağlayacak bir dizi hizmete ve uygulamaya ihtiyacımız var. Sadece bir örnek olarak, laboratuvarlarımdan birinde şöyle görünüyor:

Veeam Log Diving Bileşenleri ve Sözlüğü
Baş şef olarak hareket eder Veeam Yedekleme Hizmeti. Üslerle bilgi alışverişinden sorumlu olan odur. Ayrıca tüm görevleri başlatmaktan, tahsis edilen kaynakları düzenlemekten ve çeşitli konsollar, aracılar ve diğer her şey için bir tür iletişim merkezi olarak çalışmaktan sorumludur. Tek kelimeyle, kesinlikle onsuz olmaz ama bu, her şeyi kendisinin yaptığı anlamına gelmez.

Planını gerçekleştirmesinde ona yardım eder Veeam Yedekleme Yöneticisi. Bu bir hizmet değil, işleri başlatan ve yürütme sürecini izleyen bir varlıktır. Yedekleme hizmetinin ana bilgisayarlara bağlandığı çalışan elleri, anlık görüntüler oluşturur, saklamayı izler vb.

Ancak hizmetler listesine geri dönelim. Veeam Broker Hizmeti. v9.5'te ortaya çıktı (ve o zamanlar bazılarının düşündüğü gibi bu bir kripto madencisi değil). VMware ana bilgisayarları hakkında bilgi toplar ve alaka düzeyini korur. Ancak, sizi gözetlediğimiz ve tüm oturum açma bilgilerini / şifreleri taschmajor'a sızdırdığımıza dair kızgın yorumlar yazmak için hemen koşmayın. Her şey biraz daha basit. Bir yedekleme çalıştırdığınızda, yapmanız gereken ilk şey ana bilgisayara bağlanıp yapısıyla ilgili tüm verileri güncellemektir. Bu oldukça yavaş ve hantal bir hikaye. Web arayüzü üzerinden oturum açmanızın ne kadar sürdüğünü unutmayın ve burada yalnızca en üst katmanın sayıldığını unutmayın. Ve bu arada, yine de tüm hiyerarşiyi doğru yere açmanız gerekiyor. Tek kelimeyle korku. Bir düzine yedekleme çalıştırırsanız, her işin bu yordamı yapması gerekir. Büyük altyapılardan bahsediyorsak, bu işlem on dakika veya daha fazla sürebilir. Bu nedenle, bunun için her zaman güncel bilgi almanın mümkün olacağı ayrı bir hizmet tahsis edilmesine karar verildi. Başlangıçta, eklenen tüm altyapıyı kontrol eder ve tarar ve ardından yalnızca artımlı değişiklikler düzeyinde çalışmaya çalışır. Dolayısıyla, aynı anda yüz yedekleme çalıştırsanız bile, hepsi aracımızdan bilgi isteyecek ve istekleriyle ana bilgisayarları eziyet etmeyecektir. Kaynaklar konusunda endişeleriniz varsa, hesaplamalarımıza göre 5000 sanal makinenin yalnızca yaklaşık 100 Mb belleğe ihtiyacı vardır.

Sıradaki bizde Veeam Konsolu. O, Veeam Remote Console, o da Veeam.Backup.Shell. Bu, ekran görüntülerinde gördüğümüz GUI'nin aynısıdır. Her şey basit ve açık - konsol, Windows olduğu ve VBR sunucusuna bir bağlantı olduğu sürece herhangi bir yerden başlatılabilir. Söylenebilecek tek şey, FLR işleminin noktaları yerel olarak bağlayacağıdır (yani, konsolun çalıştığı makinede). Çeşitli Veeam Explorer'lar da konsolun parçası oldukları için yerel olarak çalışacak. Ama beni çoktan vahşi doğaya taşıdı ...

Bir diğer ilgi çekici hizmet ise Veeam Yedekleme Katalog Veri Hizmeti. Hizmetler listesinde Veeam Konuk Katalog Hizmeti olarak bilinir. Konuk makinelerde dosya sistemlerini indekslemeyle uğraşıyor ve bu bilgiyle VBRCatalog klasörünü dolduruyor. Yalnızca indeksleme onay kutusunun etkinleştirildiği durumlarda kullanılır. Ve yalnızca Enterprise Manager'ınız varsa etkinleştirmek mantıklıdır. Bu nedenle, kalbimin derinliklerinden gelen bir tavsiye: EAT'niz yoksa indekslemeyi bu şekilde açmayın. Sinirlerinizi koruyun ve zamanı destekleyin.

Ayrıca diğer önemli hizmetlerden de bahsetmeye değer Veeam Kurulum Hizmeti, yardımıyla gerekli bileşenler teslim edilir ve proxy'lere, depolara ve diğer ağ geçitlerine kurulur. Hatta gerekli .msi paketlerini sunuculara alıp kurulumunu yapıyor. 

Veeam Veri Taşıyıcı - proxy'lerde başlatılan yardımcı aracıların yardımıyla (ve yalnızca değil), verileri kaydırmakla meşgul. Örneğin, yedekleme yaparken, bir aracı ana bilgisayar veri deposundaki dosyaları okuyacak ve ikincisi bunları dikkatli bir şekilde yedeklemeye yazacaktır.

Ayrı olarak, müşterilerin sıklıkla tepki verdiği önemli bir şeyi not etmek isterim - bu, Programlar ve Özellikler ek bileşenindeki hizmet ve bilgi sürümleri arasındaki farktır. Evet, liste aynı olacak, ancak sürümler tamamen uyumsuz olabilir. Görsel açıdan çok havalı değil ama her şey stabil çalışıyorsa tamamen normal. Örneğin, Yükleyici hizmeti için sürüm numarası, komşu olanların çok gerisindedir. Korku ve kabus? Hayır, çünkü tamamen yeniden yüklenmedi, ancak DLL'si basitçe güncellendi. Yama v9.5 U4'te bir teknik destek kabusu meydana geldi: güncelleme sırasında, en önemlisi dışında tüm hizmetler yeni sürümler aldı. U4b yamasında, taşıma hizmeti diğerlerini iki sürüme kadar geride bıraktı (sayılara bakılırsa). Ve bu da normaldir - içinde ciddi bir hata bulundu, bu nedenle diğerlerine göre bir bonus güncelleme aldı. Özetlemek gerekirse: sürüm farklılıkları bir sorun OLABİLİR, ancak bir fark varsa ve her şey düzgün çalışıyorsa, o zaman muhtemelen olması gerekir. Ancak kimse bunu teknik destekte açıklamanızı yasaklamaz.

Bunlar sözde zorunlu veya Zorunlu hizmetlerdi. Ve Bant Hizmeti, Montaj Hizmeti, vPowerNFS Hizmeti ve benzeri gibi bir sürü yardımcı hizmet var.

Hyper-V için genel olarak her şey aynıdır, yalnızca belirli bir Veeam Backup Hyper-V Entegrasyon Hizmeti ve CBT ile çalışmak için kendi sürücünüz.

Ve son olarak yedekleme sırasında sanal makinelerde kimlerin çalıştığından bahsedelim. Dondurma öncesi ve sonrası komut dosyalarını çalıştırmak, gölge kopya oluşturmak, meta verileri toplamak, SQL işlem günlükleriyle çalışmak vb. Veeam Konuk Yardımcısı. Ve eğer dosya sistemleri indekslenirse, Veeam Misafir Dizin Oluşturucu . Bunlar, yedekleme süresi boyunca dağıtılan ve sonrasında kaldırılan geçici hizmetlerdir.

Linux makineleri söz konusu olduğunda, çok sayıda yerleşik kitaplığın varlığı ve sistemin kendisinin yetenekleri nedeniyle her şey çok daha basittir. Örneğin, indeksleme mlocate aracılığıyla yapılır.

Şimdilik bu kadar

artık seni incitmeye cesaret edemiyorum kısa Veeam motor bölmesine girişin bittiğini düşünüyorum. Evet, inlerin kendilerine bile yaklaşmadık ama inanın bana, içlerinde sunulan bilgilerin tutarsız bir bilinç akışı gibi görünmemesi için, böyle bir giriş kesinlikle gereklidir. Günlüklere yalnızca üçüncü makalede gitmeyi planlıyorum ve bir sonrakinin planı, günlükleri kimin oluşturduğunu, onlarda tam olarak neyin görüntülendiğini ve neden tam olarak başka türlü olmadığını açıklamaktır.

Kaynak: habr.com

Yorum ekle