Veeam 로그 다이빙 구성 요소 및 용어집

Veeam은 로그를 사랑합니다. 그리고 대부분의 솔루션은 모듈식이므로 많은 로그를 작성합니다. 그리고 우리 활동의 범위는 데이터의 안전(즉, 편안한 수면)을 보장하는 것이므로 로그는 모든 재채기를 기록할 뿐만 아니라 세부적으로 기록해야 합니다. 이는 어떤 경우에 이 "무엇"이 어떻게 발생했는지, 누가 책임을 져야 하는지, 그리고 다음에 수행해야 할 작업을 명확하게 하기 위해 필요합니다. 그것은 법의학에서와 같습니다. Laura Palmer의 살인자를 찾는 데 어떤 작은 것이 도움이 될지 결코 알 수 없습니다.

따라서 일련의 기사에서 스윙을하기로 결정했습니다. 여기서 로그에 쓰는 내용, 로그를 저장하는 위치, 구조에 미치지 않는 방법 및 내부에서 찾아야 할 사항에 대해 순차적으로 이야기합니다.

일련의 기사가 필요한 이유는 무엇이며 모든 것을 한 번에 설명하지 않는 이유는 무엇입니까?

단순히 어떤 로그가 어디에 있고 무엇이 저장되어 있는지 나열하는 것은 다소 비참한 작업입니다. 그리고 이 정보를 최신 상태로 유지하는 것에 대해 생각하는 것조차 무섭습니다. Veeam Backup & Replication에서 가능한 모든 로그 유형의 간단한 목록은 작게 인쇄된 여러 시트의 표입니다. 예, 출판 시점에만 관련이 있습니다. 다음 패치가 출시되면 새로운 로그가 나타날 수 있으며 이전 로그에 저장된 정보의 논리가 변경될 수 있습니다. 따라서 그 구조와 그 안에 포함된 정보의 본질을 설명하는 것이 훨씬 더 유리할 것입니다. 이것은 당신이 이름의 진부한 벼락치기보다 장소를 더 잘 탐색할 수 있게 해줄 것입니다.

따라서 텍스트 시트 풀에 서두르지 않으려면 이 기사에서 몇 가지 준비 작업을 수행해 봅시다. 따라서 오늘 우리는 로그 자체에 들어가지 않고 먼 곳에서 갈 것입니다. 용어집을 컴파일하고 로그 생성 측면에서 Veeam 구조에 대해 조금 논의할 것입니다.

용어 및 전문 용어

여기에서 우선 러시아어의 순결을 옹호하는 사람들과 Ozhegov 사전의 증인에게 사과 할 가치가 있습니다. 우리 모두는 모국어를 매우 좋아하지만 망할 IT 산업은 영어로 운영됩니다. 글쎄, 우리는 그것을 생각해 내지 않았지만 그것은 역사적으로 일어났습니다. 내 잘못이 아니야, 그가 직접 왔어 (c)

우리 사업에서 성공회(및 전문 용어) 문제에는 고유한 특성이 있습니다. "주인" 또는 "손님"과 같은 천진난만한 말 아래에 전 세계가 아주 구체적인 것을 이해한 지 오래되었을 때, 그 땅의 ⅙에서는 사전을 샅샅이 뒤지는 영웅적인 혼란과 비틀거림이 계속됩니다. 그리고 엄격하게 의무적 인 주장 "하지만 우리 작업에서 ...".

또한 Veeam 제품에 내재된 순전히 우리 용어가 있지만 일부 단어와 문구는 사람들에게 전달되었습니다. 따라서 이제 우리는 어떤 용어가 무엇을 의미하는지에 대해 동의하고 앞으로 "손님"이라는 단어 아래에서 직장에서 익숙한 것이 아니라이 장에 쓰여진 것을 정확히 의미 할 것입니다. 그리고 예, 이것은 제 개인적인 변덕이 아닙니다. 이것은 업계에서 잘 확립된 용어입니다. 그들과 싸우는 것은 다소 무의미합니다. 나는 항상 댓글에서 차가워지는 것을 선호하지만.

불행히도 우리 작업과 제품에는 많은 용어가 있으므로 모두 나열하지는 않겠습니다. 바다에서 생존하기 위한 백업과 로그에 대한 가장 기본적이고 필요한 정보만 담았습니다. 관심 있는 분들을 위해 저도 기사를 제안하다 기능의 해당 부분과 관련된 용어 목록도 제공했습니다.

호스트(호스트): 가상화 세계에서 이것은 하이퍼바이저가 있는 기계입니다. 물리적, 가상, 클라우드 - 중요하지 않습니다. 무언가가 하이퍼바이저(ESXi, Hyper-V, KVM 등)를 실행 중인 경우 이 "무언가"를 호스트라고 합니다. XNUMX개의 랙이 있는 클러스터든 XNUMX개의 가상 머신을 위한 랩이 있는 랩탑이든 하이퍼바이저를 시작하면 호스트가 됩니다. 하이퍼바이저가 가상 머신을 호스팅하기 때문입니다. 한때 VMware가 ESXi와 호스트라는 단어의 확고한 연관성을 달성하기를 원했다는 이야기도 있습니다. 하지만 그녀는 그러지 않았습니다.

현대 세계에서 "호스트"의 개념은 "서버"의 개념과 실질적으로 병합되어 특히 Windows 인프라와 관련하여 통신에 약간의 혼란을 가져옵니다. 따라서 관심 있는 서비스를 호스팅하는 모든 시스템을 안전하게 호스트라고 부를 수 있습니다. 예를 들어 WinSock 로그에서 모든 항목은 호스트라는 단어로 표시됩니다. 고전적인 "호스트를 찾을 수 없음"이 이에 대한 예입니다. 따라서 우리는 컨텍스트에서 시작하지만 가상화의 세계에서 호스트는 게스트를 호스트하는 것입니다(자세한 내용은 아래 두 줄 참조).

지역 전문 용어(이 경우에는 두문자어)에서 VMware는 VI, vSphere는 VC, Hyper-V는 HV로 기억됩니다.

손님(손님): 호스트에서 실행 중인 가상 머신입니다. 여기에 설명 할 것이 없으며 모든 것이 매우 논리적이고 간단합니다. 그러나 많은 사람들이 여기에 다른 의미를 부지런히 끌고 있습니다.

무엇을 위해? 모르겠습니다.
게스트 OS는 각각 게스트 시스템의 운영 체제입니다. 등등.

백업/복제 작업(jobA): 일부 작업을 나타내는 순수한 Wim 전문 용어. 백업 작업 == 백업 작업. 아무도 그것을 러시아어로 아름답게 번역하는 방법을 알아내지 못해서 모두가 "JobA"라고 말합니다. 마지막 음절을 강조합니다.

예, 그들은 단순히 그것을 받고 "joba"라고 말합니다. 그리고 편지에서도 그렇게 쓰고 모든 것이 좋습니다.
모든 종류의 백업 작업, 백업 작업 등은 감사하지만 필요하지 않습니다. 그냥 직업이면 이해하게 될 것입니다. 가장 중요한 것은 마지막 음절에 강세를 두는 것입니다.

백업(백업, 백업. true-oldfags의 경우 백업이 허용됨): 명백한 것(어딘가에 있는 데이터의 백업 복사본) 외에도 작업 자체(이미 잊어버린 경우 위의 세 줄)를 의미하며 그 결과 바로 백업 파일이 나타납니다. 아마도 영어를 모국어로 하는 신사 분들은 제가 매번 백업을 했다고 말하기에는 너무 게을러서 그냥 제가 백업을 했다고 말할 뿐이고 모두가 서로를 완벽하게 이해합니다. 이 멋진 이니셔티브를 지원하도록 여러분을 초대합니다.

통합(통합): ESXi 5.0에 등장한 용어 소위 고립된 스냅샷을 삭제하는 프로세스를 시작하는 스냅샷 메뉴의 옵션입니다. 즉, 물리적으로 사용할 수 있지만 표시된 논리적 구조에서 벗어난 스냅샷입니다. 이론적으로 이 프로세스는 스냅샷 관리자에 표시되는 파일에 영향을 미치지 않아야 하지만 어떤 일이든 발생할 수 있습니다. 통합 프로세스의 핵심은 스냅샷(하위 디스크)의 데이터가 기본(상위) 디스크에 기록된다는 것입니다. 디스크를 결합하는 과정을 병합이라고 합니다. 통합 명령이 실행된 경우 스냅샷이 병합 및 삭제되기 전에 데이터베이스에서 스냅샷 레코드를 제거할 수 있습니다. 어떤 이유로든 스냅샷을 삭제할 수 없는 경우 이와 동일한 고아 스냅샷이 나타납니다. 스냅샷 작업에 대해 VMware는 좋은 KB. 그리고 우리는 그들에 대해 어떻게 든 하브레에 썼다.

데이터 저장소(Stora 또는 스토리지):  매우 광범위한 개념이지만 가상화 세계에서는 가상 머신 파일이 저장되는 장소로 이해됩니다. 그러나 어쨌든 여기에서 문맥을 매우 명확하게 이해하고 약간의 의심으로 대담자가 정확히 무엇을 염두에 두었는지 명확히해야합니다. 

프록시(프록시): Veeam 프록시가 우리가 인터넷에서 사용하던 것과 완전히 동일하지 않다는 것을 즉시 이해하는 것이 중요합니다. Veeam 제품 내에서 이것은 한 곳에서 다른 곳으로 데이터를 전송하는 일을 처리하는 일종의 엔터티입니다. 자세히 살펴보지 않으면 VBR은 명령 및 제어 서버이고 프록시는 그 일꾼입니다. 즉, 프록시는 트래픽이 흐르고 이 트래픽을 관리하는 데 도움이 되는 VBR 구성 요소가 설치된 시스템입니다. 예를 들어, 한 채널에서 다른 채널로 데이터를 전송하거나 단순히 디스크를 자체에 고정합니다(HotAdd 모드).

저장소(저장소):  기술적으로 이것은 백업이 저장된 위치와 이 위치에 연결하는 방법을 나타내는 VBR 데이터베이스의 항목일 뿐입니다. 실제로 CIFS 볼일 수도 있고 클라우드의 별도 디스크, 서버 또는 버킷일 수도 있습니다. 다시 말하지만 우리는 맥락에 있지만 리포지토리는 백업이 있는 장소일 뿐이라는 것을 이해합니다.

 스냅샷(SnapshOt): 옥스퍼드 문법 애호가들은 누가 스냅샷이고 누가 스냅샷인지 말하기를 선호하지만 문맹자 대다수는 더 큰 대중으로부터 이익을 얻습니다. 혹시 모르시는 분들은 디스크 상태를 특정 시점으로 복원시켜주는 기술입니다. 이는 I/O 작업을 메인 디스크에서 일시적으로 리디렉션하여 RoW(Redirect on Write) 스냅샷이라고 합니다. 또는 재기록 가능한 블록을 디스크에서 다른 디스크로 이동하여 CoW(Copy on Write)라고 합니다. ) 스냅샷. Veeam이 백업 마법을 발휘할 수 있는 것은 이러한 기능을 사용할 수 있는 광범위한 가능성 덕분입니다. 엄밀히 말하면 그들뿐만 아니라 다음 릴리스의 문제입니다.

ESXi 설명서 및 로그에서 이 용어를 둘러싼 혼란이 있으며 스냅샷을 언급하는 맥락에서 스냅샷 자체, 리두 로그, 델타 디스크까지 찾을 수 있습니다. Veeam 문서에는 그러한 찢김이 포함되어 있지 않으며 스냅샷은 스냅샷이고 리두 로그는 정확히 독립된 비영구 디스크에서 생성된 REDO 파일입니다. REDO 파일은 가상 머신이 꺼지면 삭제되므로 스냅샷과 혼동하는 것은 실패의 지름길입니다.

합성 (합성): 합성 백업은 역 증분 및 영구 정방향 백업입니다. 이 용어를 접하지 못한 경우 백업 체인 변환을 구축하는 데 사용되는 메커니즘 중 하나일 뿐입니다. 그러나 로그에서 증분에서 전체 복사본을 만드는 프레임워크(합성 전체)에서 사용되는 변환 개념도 찾을 수 있습니다.

태스크(태스크): 이것은 작업 내에서 각 개별 기계를 처리하는 프로세스입니다. 즉, 세 대의 머신을 포함하는 백업 작업이 있습니다. 이는 각 자동차가 별도의 작업의 일부로 처리됨을 의미합니다. 총 XNUMX개의 로그가 있습니다. 작업용 기본 로그와 작업용 로그 XNUMX개가 있습니다. 그러나 여기에 중요한 뉘앙스가 있습니다. 시간이 지남에 따라 "작업"이라는 단어가 불필요하게 모호해졌습니다. 일반 로그에 대해 이야기할 때 작업이 정확히 VM임을 의미합니다. 그러나 프록시와 저장소 모두에 "작업"이 있습니다. 가상 디스크, 가상 머신 및 전체 작업을 의미할 수 있습니다. 즉, 문맥을 잃지 않는 것이 중요합니다.

빔 %name% 서비스:  성공적인 백업을 위해 여러 서비스가 한 번에 작동하며 그 목록은 표준 장비에서 찾을 수 있습니다. 그들의 이름은 본질을 매우 투명하게 반영하지만 가장 중요한 Veeam Backup Service가 있으며 나머지는 작동하지 않습니다.

VSS: 기술적으로 VSS는 항상 Microsoft Volume Shadow Copy Service를 나타냅니다. 실제로 많은 사람들이 응용 프로그램 인식 이미지 처리와 동의어로 사용합니다. 물론 그것은 절대적으로 잘못된 것이지만 이것은 "모든 SUV를 지프라고 부를 수 있으며 이해할 것입니다. "라는 범주의 이야기입니다.

환상적인 통나무와 그들이 사는 곳

나는 위대한 비밀을 밝히는 것으로 이 장을 시작하고 싶습니다. 로그에 표시되는 시간은 무엇입니까?

생각해 내다:

• ESXi는 항상 UTC+0으로 로그를 씁니다.
• vCenter는 시간대에 따라 로그를 유지합니다.
• Veeam은 서버가 있는 서버의 시간과 표준 시간대별로 로그를 보관합니다.
• 그리고 EVTX 형식의 Windows 이벤트만 바인딩되는 문제가 없습니다. 열리면 열렸던 자동차의 시간이 다시 계산됩니다. 어려움이 있지만 가장 편리한 옵션입니다. 유일한 가시적 어려움은 로케일의 차이입니다. 이것은 읽을 수 없는 로그에 대한 실질적으로 보장된 경로입니다. 예, 이것을 처리하는 방법에 대한 옵션이 있지만 IT의 모든 것이 영어로 작동한다는 사실에 대해 논쟁하지 말고 서버에서 항상 영어 로케일을 설정하는 데 동의하십시오. 오 제발. 

이제 통나무가 사는 곳과 통나무를 얻는 방법에 대해 이야기합시다. VBR의 경우 두 가지 접근 방식이 있습니다. 

첫 번째 옵션은 특히 문제와 관련된 일반 힙에서 파일을 찾고 싶지 않은 경우에 적합합니다. 이를 위해 특정 작업과 로그가 필요한 특정 기간을 지정할 수 있는 별도의 마법사가 있습니다. 그런 다음 그는 폴더를 직접 살펴보고 필요한 모든 것을 하나의 아카이브에 넣습니다. 그것을 찾을 위치와 작업 방법은에 자세히 설명되어 있습니다. 이 HF.

그러나 마법사는 모든 작업의 ​​로그를 수집하지 않으며, 예를 들어 복원, 장애 조치 또는 장애 복구의 로그를 조사해야 하는 경우 경로는 폴더에 있습니다. %ProgramData%/Veeam/백업. 이것은 기본 VBR 로고 저장소이고 %ProgramData%는 숨겨진 폴더이며 괜찮습니다. 그런데 HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam 백업 및 복제 분기에서 REG_SZ: LogDirectory 유형 레지스트리 키를 사용하여 기본 위치를 재할당할 수 있습니다.

Linux 시스템에서 작업자 에이전트 로그는 /에서 찾아야 합니다.var/log/VeeamBackup/루트 또는 sudo 계정을 사용하는 경우. 그러한 권한이 없으면 로그인을 찾으십시오. /tmp/Veeam백업. 

%OS_name%용 Veeam 에이전트의 경우 로그는 다음 위치에서 검색해야 합니다. %ProgramData%/Veeam/엔드포인트 (또는 %ProgramData%/Veeam/백업/엔드포인트) 그리고 /var/로그/빔 각각.

Application-Aware Image Processing을 사용하고 있다면(아마도 그럴 가능성이 높음) 상황이 좀 더 복잡해집니다. 가상 머신 자체에 저장되는 헬퍼의 로그와 VSS 로그가 필요합니다. 이 행복을 어떻게 어디서 얻을 수 있는지에 대해 자세히 기록되어 있습니다. 이 기사. 그리고 물론 있습니다 별도의 기사 필요한 시스템 로그를 수집합니다. 

Windows 이벤트는 다음에 따라 편리하게 수집됩니다. 이 HF. Hyper-V를 사용하는 경우 애플리케이션 및 서비스 로그 > Microsoft > Windows 분기의 모든 로그도 필요하므로 상황이 더 복잡해집니다. 항상 어리석은 방법으로 %SystemRoot%System32winevtLogs에서 모든 개체를 선택할 수 있습니다.

설치/업그레이드 중에 문제가 발생하면 %ProgramData%/Veeam/Setup/Temp 폴더에서 필요한 모든 것을 찾을 수 있습니다. OS 이벤트에서 이러한 로그보다 더 유용한 정보를 찾을 수 있다는 사실을 숨기지는 않겠습니다. 나머지 흥미로운 부분은 %Temp%에 있지만 기본, .Net 라이브러리 및 기타 항목과 같은 관련 소프트웨어에 대한 설치 로그가 주로 있습니다. Veeam은 msi에서 설치되며 모든 구성 요소는 GUI에 표시되지 않더라도 별도의 msi 패키지로 설치됩니다. 따라서 구성 요소 중 하나의 설치가 실패하면 전체 VBR 설치가 중지됩니다. 따라서 로그로 이동하여 정확히 어떤 지점에서 중단되었는지 확인해야 합니다.

그리고 마지막으로 인생 해킹입니다. 설치 중에 오류가 발생하면 서두르지 말고 확인을 클릭하세요. 먼저 로그를 가져온 다음 확인을 클릭합니다. 이렇게 하면 마지막에 쓰레기 없이 오류가 발생한 시점에 종료되는 로그를 얻을 수 있습니다.

그리고 vSphere 로그에 들어가야 합니다. 직업은 매우 배은망덕하지만 소매를 걷어 내고 다른 일을해야합니다. 가장 간단한 버전에서는 .vmx 파일 옆에 있는 가상 머신 이벤트 vmware.log가 포함된 로그가 필요합니다. 더 어려운 경우에는 Google을 열고 호스트 버전의 로그가 어디에 있는지 물어보십시오. VMware는 릴리스마다 이 위치를 변경하는 것을 좋아하기 때문입니다. 예를 들어, 7.0용 기사, 이 아니라면 5.5. 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 백업 관리자. 이것은 서비스가 아니라 작업을 시작하고 실행 프로세스를 모니터링하는 엔터티입니다. 호스트에 연결하는 데 사용되는 백업 서비스의 작업 손은 스냅샷을 생성하고 보존을 모니터링하는 등의 작업을 수행합니다.

그러나 서비스 목록으로 돌아갑니다. 빔 브로커 서비스. v9.5에 등장했습니다(당시 생각했던 것처럼 이것은 암호화 채굴기가 아닙니다). VMware 호스트에 대한 정보를 수집하고 관련성을 유지합니다. 그러나 우리가 당신을 감시하고 모든 로그인 / 암호를 taschmajor에 유출하고 있다는 화난 댓글을 작성하기 위해 즉시 실행하지 마십시오. 모든 것이 다소 간단합니다. 백업을 실행할 때 가장 먼저 해야 할 일은 호스트에 연결하고 해당 구조에 대한 모든 데이터를 업데이트하는 것입니다. 이것은 다소 느리고 성가신 이야기입니다. 웹 인터페이스를 통해 로그인하는 데 걸리는 시간을 기억하고 최상위 레이어만 계산된다는 점을 기억하십시오. 그런 다음 여전히 전체 계층 구조를 올바른 위치로 열어야 합니다. 한마디로 공포. 5000개의 백업을 실행하는 경우 각 작업에서 이 절차를 수행해야 합니다. 대규모 인프라에 대해 이야기하는 경우 이 프로세스는 100분 이상 걸릴 수 있습니다. 이에 항시 최신 정보를 제공받을 수 있도록 별도의 서비스를 배정하기로 했다. 시작 시 추가된 모든 인프라를 확인하고 스캔한 다음 증분 변경 수준에서만 작동을 시도합니다. 따라서 동시에 XNUMX개의 백업을 실행하더라도 모두 브로커에서 정보를 요청하고 요청으로 호스트를 괴롭히지 않습니다. 리소스가 걱정된다면 계산에 따르면 XNUMX개의 가상 머신에 약 XNUMXMb의 메모리만 필요합니다.

다음으로 우리는 빔 콘솔. 그는 Veeam Remote Console이고 Veeam.Backup.Shell입니다. 이것은 스크린샷에서 볼 수 있는 것과 동일한 GUI입니다. 모든 것이 간단하고 분명합니다. 콘솔은 Windows이고 VBR 서버에 연결되어 있는 한 어디에서나 시작할 수 있습니다. 말할 수 있는 유일한 것은 FLR 프로세스가 지점을 로컬(즉, 콘솔이 실행 중인 시스템)에 마운트한다는 것입니다. 다양한 Veeam Explorer도 콘솔의 일부이기 때문에 로컬에서 실행됩니다. 그러나 그것은 이미 나를 야생으로 데려갔습니다 ...

또 다른 흥미로운 서비스는 Veeam 백업 카탈로그 데이터 서비스. 서비스 목록에서 Veeam Guest Catalog Service로 알려져 있습니다. 그는 게스트 시스템에서 파일 시스템 인덱싱에 관여하고 있으며 이 지식으로 VBRCatalog 폴더를 채웁니다. 인덱싱 확인란이 활성화된 경우에만 사용됩니다. Enterprise Manager가 있는 경우에만 활성화하는 것이 좋습니다. 따라서 진심으로 조언합니다. EAT가 없으면 그렇게 인덱싱을 켜지 마십시오. 긴장을 풀고 시간을 지원하십시오.

또한 다른 중요한 서비스에서 주목할 가치가 있습니다. Veeam 설치 프로그램 서비스, 프록시, 리포지토리 및 기타 게이트웨이에 필요한 구성 요소가 제공되고 설치됩니다. 실제로 필요한 .msi 패키지를 서버로 가져와 설치합니다. 

Veeam 데이터 이동기 - 프록시에서 시작된 보조 에이전트의 도움으로(뿐만 아니라) 데이터 이동에 참여합니다. 예를 들어 백업할 때 한 에이전트는 호스트 데이터 저장소에서 파일을 읽고 두 번째 에이전트는 백업에 주의 깊게 기록합니다.

이와는 별도로 클라이언트가 자주 반응하는 중요한 사항에 주목하고 싶습니다. 이것은 프로그램 및 기능 스냅인의 서비스 버전과 정보의 차이입니다. 예, 목록은 동일하지만 버전이 완전히 일치하지 않을 수 있습니다. 시각적인 관점에서 보면 아주 멋지지는 않지만 모든 것이 안정적으로 작동한다면 완전히 정상입니다. 예를 들어 Installer 서비스의 경우 버전 번호가 인접 항목보다 훨씬 뒤떨어집니다. 공포와 악몽? 아니요, 완전히 다시 설치되지는 않았지만 DLL만 업데이트되기 때문입니다. 패치 v9.5 U4에서 기술 지원 악몽이 발생했습니다. 업데이트 중에 가장 중요한 서비스를 제외한 모든 서비스가 새 버전을 받았습니다. U4b 패치에서 전송 서비스는 두 가지 버전(숫자로 판단)만큼 다른 모든 서비스를 추월했습니다. 그리고 이것은 또한 정상입니다. 심각한 버그가 발견되어 나머지에 비해 보너스 업데이트를 받았습니다. 요약하자면 버전 차이가 문제가 될 수 있지만 차이가 있고 모든 것이 제대로 작동한다면 문제가 될 수 있습니다. 그러나 아무도 기술 지원에서 이것을 명확히 하는 것을 금지하지 않습니다.

이들은 소위 필수 또는 필수 서비스였습니다. 그리고 테이프 서비스, 마운트 서비스, vPowerNFS 서비스 등과 같은 많은 보조 서비스가 있습니다.

Hyper-V의 경우 일반적으로 모든 것이 동일하며 특정 Veeam Backup Hyper-V 통합 서비스 그리고 CBT 작업을 위한 자신의 드라이버.

마지막으로 백업 중에 가상 머신에서 작업하는 사람에 대해 이야기해 보겠습니다. 사전 및 사후 정지 스크립트 실행, 섀도 복사본 생성, 메타데이터 수집, SQL 트랜잭션 로그 작업 등 Veeam 게스트 도우미. 그리고 파일 시스템이 인덱싱되면 Veeam 게스트 인덱서 . 백업 기간 동안 배포되고 이후에 제거되는 임시 서비스입니다.

Linux 시스템의 경우 많은 수의 내장 라이브러리와 시스템 자체의 기능으로 인해 모든 것이 훨씬 간단합니다. 예를 들어 인덱싱은 mlocate를 통해 수행됩니다.

지금은 여기까지입니다

나는 더 이상 감히 당신을 해치지 않습니다 짧은 Veeam 엔진룸에 대한 소개는 끝났다고 생각합니다. 예, 우리는 굴 자체에 가까이 가지도 않았지만 저를 믿으십시오. 그 안에 제시된 정보가 일관되지 않은 의식의 흐름처럼 보이지 않도록 그러한 소개가 절대적으로 필요합니다. 나는 세 번째 기사에서만 로그 자체에 갈 계획이며 다음 계획은 누가 로그를 생성하는지, 로그에 정확히 무엇이 표시되고 왜 정확히 표시되는지, 그렇지 않은지 설명하는 것입니다.

출처 : habr.com