Veeam 熱愛日誌。 而且由於我們的大部分解決方案都是模塊化的，所以他們會寫很多日誌。 並且由於我們的活動範圍是確保您的數據安全（即安眠），因此日誌不僅應記錄每個噴嚏，而且還應詳細記錄。 這是必要的，以便在發生某些事情時，可以清楚地知道“什麼”是如何發生的，應該歸咎於誰，以及接下來需要做什麼。 這就像法醫學：你永遠不知道有什麼小事可以幫助你找到殺害勞拉·帕爾默的兇手。
因此，我決定嘗試寫一系列文章，在這些文章中我將依次討論我們寫入日誌的內容、我們存儲它們的位置、如何不對它們的結構感到瘋狂以及在其中尋找什麼。
為什麼要寫一系列文章，為什麼不一次描述所有內容？
簡單地列出哪個日誌在哪里以及其中存儲了什麼是一項相當災難性的工作。 甚至考慮讓這些信息保持最新都令人恐懼。 Veeam Backup & Replication 中所有可能的日誌類型的簡單列表是一個包含幾張小字體的表格。 是的，它僅在發佈時才相關，因為。 下一個補丁發佈時，可能會出現新的日誌，舊日誌中存儲信息的邏輯會發生變化等。 因此，解釋它們的結構和其中包含的信息的本質會更有利可圖。 這將使您能夠更好地導航這些地方，而不是平庸地填塞名稱。
因此，為了不急於進入文本表池，讓我們在本文中做一些準備工作。 因此，今天我們不會深入日誌本身，而是從遠處說起：我們將編寫一個詞彙表，並從生成日誌的角度稍微討論一下 Veeam 結構。
詞彙表和行話
在這裡，首先，值得向純正俄語的捍衛者和 Ozhegov 詞典的見證人道歉。 我們都非常喜歡我們的母語，但該死的 IT 行業是用英語運作的。 好吧，我們沒有想出它，但它在歷史上發生過。 這不是我的錯，他自己來了（c）
在我們的業務中，英語化（和行話）問題有其自身的特點。 當在“主人”或“客人”這樣無辜的詞語下，全世界早已理解非常具體的事物時，那麼在 ⅙ 的土地上，英勇的困惑和蹣跚地查字典仍在繼續。 以及嚴格的強制性論點“但是在我們的工作中......”。
此外，還有純粹的我們的術語，這是 Veeam 產品中固有的，儘管有些單詞和短語已經傳給了人們。 因此，現在我們將就什麼術語的含義達成一致，並且在未來，在“客人”一詞下，我將準確地表示本章中所寫的內容，而不是您在工作中習慣使用的內容。 是的，這不是我個人的心血來潮，這些都是業內公認的術語。 與他們戰鬥有些毫無意義。 儘管我總是讚成在評論中放鬆一下。
不幸的是，我們的工作和產品中有很多術語，因此我不會嘗試將它們全部列出。 只有關於備份和日誌的最基本和必要的信息才能在海上生存。 有興趣的我也可以 關於磁帶的同事，他還給出了與該部分功能相關的術語列表。
主持人（主持人）： 在虛擬化世界中，這是一台帶有管理程序的機器。 物理的、虛擬的、雲——沒關係。 如果某物正在運行管理程序（ESXi、Hyper-V、KVM 等），那麼這個“某物”就稱為主機。 無論是具有十個機架的集群，還是帶有用於一個半虛擬機的實驗室的筆記本電腦——如果您啟動了管理程序，您就成為了主機。 因為管理程序託管虛擬機。 甚至有一個故事說，VMware 曾一度希望將主機一詞與 ESXi 牢固地聯繫在一起。 但她沒有。
在現代世界中，“主機”的概念實際上已經與“服務器”的概念融合在一起，這給通信帶來了一些混亂，尤其是涉及到 Windows 基礎設施時。 因此，任何託管我們感興趣的服務的機器都可以安全地稱為主機。 例如，在 WinSock 日誌中，所有內容都標有主機一詞。 經典的“找不到主機”就是一個例子。 所以我們從上下文開始，但請記住 - 在虛擬化的世界中，主機就是用來託管來賓的（更多內容在下面的兩行中）。
從本地行話（在本例中甚至是首字母縮寫詞）來看，VMware 是 VI，vSphere 是 VC，而 Hyper-V 是 HV。
嘉賓（來賓）： 在主機上運行的虛擬機。 這裡沒有什麼可解釋的，一切都是那麼合乎邏輯和簡單。 然而，許多人努力地將一些其他含義拖到這裡。
為了什麼？ 我不知道。
Guest OS，分別是來賓機器的操作系統。 等等。
備份/複製作業 (jobA)： 純 Wim 行話，表示一些任務。 備份作業 == 備份作業。 沒有人想出如何將它漂亮地翻譯成俄語，所以每個人都說“JobA”。 強調最後一個音節。
是的，他們只是接受它並說“joba”。 甚至在信中他們也是這樣寫的，一切都很好。
各種備份作業、備份任務等，謝謝，但沒必要。 只是一份工作，你會被理解的。 最主要的是把重音放在最後一個音節上。
Backup（備份，備份。對於true-oldfags，允許備份）： 除了顯而易見的（位於某處的數據備份副本）之外，它還意味著作業本身（上面三行，如果您已經忘記的話），因此出現了備份文件。 可能，以英語為母語的先生們懶得說我每次都運行了我的備份工作，所以他們只是說我運行了我的備份，每個人都非常理解對方。 我邀請你支持這個美妙的倡議。
合併（合併）： ESXi 5.0 中出現的一個術語 快照菜單中的一個選項，用於啟動刪除所謂的孤立快照的過程。 也就是說，物理上可用的快照，但不符合顯示的邏輯結構。 理論上，這個過程不應該影響快照管理器中顯示的文件，但任何事情都有可能發生。 合併過程的本質是將快照（子磁盤）中的數據寫入主（父）磁盤。 合併磁盤的過程稱為合併。 如果發出了合併命令，則可以在合併和刪除快照之前從數據庫中刪除快照記錄。 如果由於任何原因無法刪除快照，則會出現這些相同的孤立快照。 關於使用快照，VMware 有 . 我們也以某種方式了解他們 .
數據存儲（Stora 或存儲）： 一個很寬泛的概念，但是在虛擬化的世界裡，它被理解為存放虛擬機文件的地方。 但是無論如何，在這裡您需要非常清楚地了解上下文，並且要毫不懷疑地弄清楚您的對話者到底在想什麼。
代理（代理）： 重要的是要立即了解 Veeam Proxy 與我們在 Internet 上習慣使用的並不完全相同。 在 Veeam 產品中，這是一種處理將數據從一個地方傳輸到另一個地方的實體。 如果不詳細說明，那麼 VBR 是一個命令和控制服務器，代理是它的主力。 也就是說，代理是一台機器，流量通過它流動，並且在其上安裝了有助於引導該流量的 VBR 組件。 例如，將數據從一個通道傳輸到另一個通道，或者只是將磁盤粘貼到自身（HotAdd 模式）。
存儲庫（存儲庫）： 從技術上講，這只是 VBR 數據庫中的一個條目，指示備份存儲的位置，以及如何連接到該位置。 事實上，它可以只是一個 CIFS 球，也可以是雲中的一個單獨的磁盤、服務器或存儲桶。 同樣，我們在上下文中，但我們知道存儲庫只是您的備份所在的地方。
快照（SnapshOt）： 牛津語法愛好者更喜歡說誰是快照，誰是快照，但大多數文盲受益於更大的質量。 如果有人不知道，這是一項允許您在特定時間點恢復磁盤狀態的技術。 這是通過暫時將 I/O 操作從主磁盤重定向來完成的 - 那麼它將被稱為 RoW（寫時重定向）快照 - 或者通過將可重寫塊從你的磁盤移動到另一個 - 這將被稱為 CoW（寫時復制） ）快照。 正是由於使用這些功能的廣泛可能性，Veeam 才能發揮其備份魔力。 嚴格來說，不僅是他們，這是下一個版本的事情。
在 ESXi 文檔和日誌中圍繞這個術語存在混亂，在提到快照的上下文中，您可以找到快照本身、重做日誌，甚至增量磁盤。 Veeam文檔中沒有這樣的撕裂，快照就是快照，redo log就是獨立的非持久化磁盤創建的REDO文件。 REDO 文件在虛擬機關閉時被刪除，因此將它們與快照混淆是導致失敗的途徑。
合成的（Synthetics）： 合成備份是反向增量和永遠正向備份。 如果您還沒有遇到過這個術語，它只是用於構建備份鏈轉換的機制之一。 但是，在日誌中您還可以找到 Transform 的概念，它用於從增量創建完整副本（合成完整）的框架中。
任務（任務）： 這是處理工作中每台機器的過程。 即：您有一個備份作業，其中包括三台機器。 這意味著每輛車都將作為單獨任務的一部分進行處理。 總共將有四個日誌：主要的一個用於作業，三個用於任務。 然而，這裡有一個重要的細微差別：隨著時間的推移，“任務”這個詞變得不必要地模棱兩可。 當我們談論通用日誌時，我們的意思是一個任務就是一個虛擬機。 但是在代理和存儲庫上都有“任務”。 在那裡它可能意味著虛擬磁盤、虛擬機和整個作業。 也就是說，重要的是不要失去上下文。
Veeam %name% 服務: 為了成功備份，多個服務同時工作，其中的列表可以在標准設備中找到。 它們的名稱非常透明地反映了它們的本質，但在同類產品中，最重要的是 Veeam Backup Service，沒有它，其餘的都將無法運行。
VSS： 從技術上講，VSS 應該始終代表 Microsoft Volume Shadow Copy Service。 事實上，它被許多人用作應用程序感知圖像處理的同義詞。 這當然是絕對錯誤的，但這是“任何 SUV 都可以稱為吉普車，你會被理解的”類別的故事。
神奇的日誌和他們住的地方
我想通過揭開這個大秘密來開始本章——日誌中顯示的時間是什麼時候？
記住：
- ESXi 始終以 UTC+0 寫入日誌。
- vCenter 根據其時區的時間保存日誌。
- Veeam 按其所在服務器的時間和時區保存日誌。
- 並且只有 EVTX 格式的 Windows 事件不會受到任何綁定的影響。 打開時，將重新計算打開它們的汽車的時間。 最方便的選擇，儘管它有一些困難。 唯一明顯的困難是語言環境的差異。 這是通往不可讀日誌的實際保證途徑。 是的，對於如何處理這個問題有多種選擇，但我們不要爭論 IT 中的一切都以英語工作的事實，並同意始終在服務器上設置英語區域設置。 哦拜託。
現在讓我們談談日誌所在的位置以及如何獲取它們。 在 VBR 的情況下，有兩種方法。
如果您不急於在一般堆中查找與您的問題具體相關的文件，則第一個選項是合適的。 為此，我們有一個單獨的嚮導，您可以在其中指定特定的作業和需要日誌的特定時間段。 然後他會親自檢查文件夾並將您需要的所有內容放入一個存檔中。 在哪裡尋找它以及如何使用它在 .
但是，該嚮導不會收集所有任務的日誌，例如，如果您需要研究恢復、故障轉移或故障恢復的日誌，您的路徑位於文件夾中 %ProgramData%/Veeam/備份. 這是主要的 VBR logostore，%ProgramData% 是一個隱藏文件夾，這很好。 順便說一句，可以使用 REG_SZ 重新分配默認位置：HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam 備份和復制分支中的 LogDirectory 類型註冊表項。
在 Linux 機器上，應在 / 中查找 Worker Agent 日誌變種/日誌/VeeamBackup/如果使用 root 或 sudo 帳戶。 如果您沒有此類權限，請查找登錄 /tmp/VeeamBackup.
對於 %OS_name% 日誌的 Veeam 代理，應在 %ProgramData%/Veeam/端點 （或者 %ProgramData%/Veeam/備份/端點）和 /var/日誌/veeam 分別
如果您正在使用應用程序感知圖像處理（很可能您正在使用），那麼情況會變得更加複雜。 您將需要存儲在虛擬機內部的幫助程序日誌和 VSS 日誌。 關於如何以及從哪裡獲得這種幸福，在 . 當然還有 收集必要的系統日誌。
Windows 事件可根據以下方式方便地收集 . 如果您使用的是 Hyper-V，事情會變得更加複雜，因為您還需要應用程序和服務日誌 > Microsoft > Windows 分支中的所有日誌。 儘管您總是可以採取更愚蠢的方式，只是從 %SystemRoot%System32winevtLogs 中獲取所有對象。
如果在安裝/升級期間出現問題，那麼您需要的一切都可以在 %ProgramData%/Veeam/Setup/Temp 文件夾中找到。 儘管我不會隱瞞這樣一個事實，即在操作系統事件中您可以找到比在這些日誌中更有用的信息。 剩下的有意思的地方在%Temp%，不過主要是相關軟件的安裝日誌，比如base，.Net庫之類的。 請注意，Veeam 是從 msi 安裝的，它的所有組件也作為單獨的 msi 包安裝，即使這沒有在 GUI 中顯示。 因此，如果其中一個組件安裝失敗，整個VBR 安裝將停止。 因此，您需要進入日誌並查看到底是什麼地方發生了問題以及發生在什麼時候。
最後，生活小竅門：如果您在安裝過程中收到錯誤消息，請不要急於單擊“確定”。 首先我們獲取日誌，然後單擊“確定”。 這樣你會得到一個在錯誤發生時結束的日誌，最後沒有垃圾。
碰巧您需要進入 vSphere 日誌。 職業很忘恩負義，可是擼起袖子乾點別的。 在最簡單的版本中，我們需要包含虛擬機事件 vmware.log 的日誌，這些日誌位於其 .vmx 文件旁邊。 在更困難的情況下，打開 Google 並詢問您的主機版本的日誌位於何處，因為 VMware 喜歡在不同版本之間更改此位置。 例如， ， 但對於 . 對於 vCenter 日誌，重複該過程 . 但一般來說，我們會對主機事件日誌 hostd.log、vCenter 管理的主機事件 vpxa.log、內核日誌 vmkernel.log 和身份驗證日誌 auth.log 感興趣。 好吧，在大多數被忽視的情況下，位於 SSO 文件夾中的 SSO 日誌可能會派上用場。
麻煩嗎？ 使困惑？ 可怕的？ 但這甚至還不到我們支持人員每天處理的信息的一半。 所以他們真的，真的很酷。
Veeam 組件
作為這篇介紹性文章的結論，我們來談談 Veeam Backup & Replication 的組件。 因為當您尋找疼痛的原因時，了解患者的工作方式會很好。
因此，眾所周知，Veeam Backup 是所謂的基於 SQL 的應用程序。 也就是說，所有設置、所有信息以及一般情況下僅正常運行所需的一切 - 所有這些都在其數據庫中。 或者更確切地說，在兩個數據庫中，如果我們談論的是一堆 VBR 和 EM：分別是 VeeamBackup 和 VeeamBackupReporting。 事情就這樣發生了：我們放置了另一個應用程序 - 出現了另一個數據庫。 為了不把所有的雞蛋都放在一個籃子裡。
但要讓所有這些經濟順利運行，我們需要一套服務和應用程序將所有組件聯繫在一起。 舉個例子，這就是它在我的一個實驗室中的樣子：
擔任總指揮 Veeam 備份服務. 他負責與基地交換信息。 他還負責啟動所有任務，協調分配的資源，並作為各種控制台、代理和其他一切的通信中心。 一句話，沒有他肯定是沒有辦法，但這根本不代表他什麼都得親力親為。
幫助他完成他的計劃 Veeam 備份管理器. 這不是一項服務，而是一個啟動作業並監視其執行過程的實體。 備份服務的工作手，通過它連接到主機、創建快照、監控保留等。
但回到服務列表。 Veeam 經紀服務. 出現在 v9.5 中（這不是加密礦工，正如當時一些人認為的那樣）。 收集有關 VMware 主機的信息並維護其相關性。 但是不要立即跑去寫憤怒的評論，說我們正在監視你並將所有登錄名/密碼洩露給 taschmajor。 一切都比較簡單。 運行備份時，您需要做的第一件事是連接到主機並更新有關其結構的所有數據。 這是一個相當緩慢和繁瑣的故事。 只要記住您通過 Web 界面登錄需要多長時間，並記住那裡只計算頂層。 然後你還需要把整個層級打開到正確的地方，順便說一句。 一句話，恐怖。 如果您運行十幾個備份，那麼每個作業都需要執行此過程。 如果我們談論的是大型基礎設施，那麼這個過程可能需要十分鐘或更長時間。 因此，決定為此分配一項單獨的服務，通過該服務可以始終接收最新信息。 在啟動時，它會檢查並掃描所有添加的基礎架構，然後嘗試僅在增量更改級別上工作。 因此，即使您同時運行一百個備份，他們也會向我們的經紀人請求信息，並且不會用他們的請求來折磨主機。 如果您擔心資源，那麼根據我們的計算，5000 個虛擬機只需要大約 100 Mb 的內存。
接下來我們有 Veeam 控制台. 他是Veeam Remote Console，他是Veeam.Backup.Shell。 這與我們在屏幕截圖中看到的 GUI 相同。 一切都簡單明了——控制台可以從任何地方啟動，只要它是 Windows 並且連接到 VBR 服務器。 唯一可以說的是 FLR 進程將在本地掛載點（即在運行控制台的機器上）。 好吧，各種 Veeam Explorer 也將在本地運行，因為它們是控制台的一部分。 但它已經把我帶入了荒野......
另一個有趣的服務是 Veeam 備份目錄數據服務。 在服務列表中稱為 Veeam Guest Catalog Service。 他從事客戶機上文件系統的索引工作，並用這些知識填充了 VBRCatalog 文件夾。 它僅在啟用索引複選框的情況下使用。 如果您擁有企業管理器，啟用它才有意義。 所以，發自內心的忠告：沒有EAT就不要這樣開啟索引。 節省您的精力和支持時間。
其他重要服務也值得注意 Veeam 安裝程序服務，在其幫助下，必要的組件被交付並安裝在代理、存儲庫和其他網關上。 事實上，它將必要的 .msi 包帶到服務器並安裝它們。
Veeam 數據移動器 - 在代理上啟動的輔助代理的幫助下（不僅如此）它參與移動數據。 例如，在備份時，一個代理會從主機數據存儲中讀取文件，而第二個會小心地將它們寫入備份。
另外，我想指出客戶經常反應的一件重要事情——這是“程序和功能”管理單元中服務和信息版本的差異。 是的，列表將相同，但版本可能完全不一致。 從視覺上看不是很酷，但如果一切穩定，那是完全正常的。 例如，對於 Installer 服務，版本號遠遠落後於相鄰服務。 恐怖和噩夢？ 不是，因為它並沒有完全重新安裝，只是更新了它的 DLL。 在補丁 v9.5 U4 中，發生了技術支持噩夢：在更新期間，所有服務都收到了新版本，除了最重要的服務。 在 U4b 補丁中，傳輸服務超過了所有其他服務多達兩個版本（根據數字判斷）。 這也是正常的 - 其中發現了一個嚴重的錯誤，因此它相對於其他版本獲得了獎勵更新。 所以總結一下：版本差異可能是一個問題，但如果存在差異並且一切正常，那麼它可能應該是。 但是沒有人禁止您在技術支持中澄清這一點。
這些就是所謂的強制性或強制性服務。 還有一大堆輔助的，比如Tape Service，Mount Service，vPowerNFS Service等等。
對於 Hyper-V，一般來說，一切都是一樣的，只是有一個特定的 Veeam 備份 Hyper-V 集成服務 以及您自己的 CBT 驅動程序。
最後，讓我們談談在備份期間誰在虛擬機上工作。 運行凍結前和凍結後腳本、創建卷影副本、收集元數據、使用 SQL 事務日誌等。 Veeam 來賓助手. 如果文件系統被索引， Veeam 來賓索引器 . 這些是在備份期間部署並在備份後刪除的臨時服務。
對於 Linux 機器，由於存在大量內置庫和系統本身的功能，一切都簡單得多。 例如，索引是通過 mlocate 完成的。
目前為止就這樣了
我不敢再傷害你 短的 我認為對 Veeam 發動機艙的介紹到此結束。 是的，我們甚至還沒有接近巢穴本身，但相信我，為了讓它們中呈現的信息看起來不像是不連貫的意識流，這樣的介紹是絕對必要的。 我計劃只在第三篇文章中介紹日誌本身，下一篇的計劃是解釋誰生成了日誌，日誌中到底顯示了什麼以及為什麼，而不是其他。
來源： www.habr.com