용량 계층(또는 Vim 내에서 captir라고 부름)은 Veeam Backup and Replication 9.5 업데이트 4 시절에 Archive Tier라는 이름으로 나타났습니다. 그 이면의 아이디어는 소위 운영 복원 기간을 벗어난 백업을 개체 스토리지로 이동할 수 있도록 하는 것입니다. 이는 디스크 공간이 거의 없는 사용자를 위해 디스크 공간을 정리하는 데 도움이 되었습니다. 그리고 이 옵션을 이동 모드라고 했습니다.

이 간단한(보이는 대로) 작업을 수행하려면 두 가지 조건을 충족하는 것만으로도 충분했습니다. 이동된 백업의 모든 지점은 위에서 언급한 운영 복원 창(UI에 명시적으로 설정됨)의 경계 밖에 있어야 합니다. 둘째, 체인은 소위 "봉인된 형태"(봉인된 백업 체인 또는 비활성 백업 체인)여야 합니다. 즉, 이 체인에서는 시간이 지나도 아무런 변화가 발생하지 않습니다.

그러나 VBR v10에서는 개념이 새로운 기능으로 보완되었습니다. 복사 모드, 밀봉 모드 및 발음하기 어려운 불변성이라는 이름이 등장했습니다.

이것이 오늘 우리가 이야기할 흥미로운 것들입니다. 먼저 VBR9.5u4에서 어떻게 작동했는지, 그리고 XNUMX번째 버전의 변경 사항에 대해 설명합니다.

그리고 순수한 언어의 옹호자들이 저를 용서해 주시기를 바랍니다. 하지만 번역할 수 없는 용어가 너무 많습니다.
그래서 여기에는 수많은 성공회가 있을 것입니다.
그리고 많은 gif.
그리고 사진.

• 조금도 후회하지 않고. 기사의 저자.

그대로

우선 운영 복원 창과 봉인된 백업(또는 비활성 백업 체인 문서에서 호출되는 방식)을 분석해 보겠습니다. 그들의 이해 없이는 더 이상의 설명이 불가능합니다.

그림에서 볼 수 있듯이, 용량 계층이 연결된 저장소의 성능 계층 SOBR에 위치한 데이터 블록이 있는 일종의 백업 체인이 있습니다. 우리의 운영 백업 기간은 XNUMX일입니다.

따라서 월요일에 생성된 .vbk는 기간이 XNUMX일로 설정된 이전 체인을 봉인합니다. 이는 XNUMX일보다 오래된 모든 것을 사격장으로 안전하게 운반할 수 있음을 의미합니다.

하지만 봉인된 체인이 정확히 무엇을 의미하며 업데이트 4에서 용량 사격장으로 보낼 수 있는 것은 무엇입니까?

순방향 증분의 경우 체인 봉인의 표시는 새로운 전체 백업이 생성된다는 것입니다. 그리고 이 전체 백업을 얻는 방법은 중요하지 않습니다. 합성 전체 백업과 활성 전체 백업이 모두 고려됩니다.

Reverse의 경우에는 동작창에 들어가지 않는 파일들이 모두 해당됩니다.

롤백을 통한 정방향 증가의 경우 성능 범위에 또 다른 .vbk가 있는 경우 이는 모두 롤백 및 .vbk입니다.

이제 백업 복사본 체인을 사용하는 옵션을 고려해 보겠습니다. GFS 보존에 해당하는 항목만 여기로 전송되었습니다. 최신 백업 복사본 체인에 저장된 모든 내용은 어떤 방식으로든 변경될 수 있기 때문입니다.

이제 후드 아래를 살펴보겠습니다. 거기에서 탈수(dehydration)라는 프로세스가 발생합니다. 즉, 빈 백업 파일을 범위에 남겨두고 이 파일의 블록을 용량 사격장으로 드래그하는 것입니다. 이 프로세스를 최적화하기 위해 소위 탈수 지수가 사용됩니다. 이를 통해 용량 사격장에 이미 복사된 블록을 복사하는 것을 방지할 수 있습니다.

예를 들어 이것이 어떻게 보이는지 살펴보겠습니다. 트랜잭션 창에서 나와 봉인된 체인에 속하는 .vbk가 있다고 가정해 보겠습니다. 이는 우리가 수용 가능한 사격장으로 이동할 모든 권리가 있음을 의미합니다. 이동 시 전송된 파일의 용량 대시와 블록에 메타데이터 파일이 생성됩니다. 링크 수준 메타데이터 파일은 파일이 어떤 블록으로 구성되어 있는지 설명합니다. 그림의 경우 첫 번째 파일은 블록 a, b, c로 구성되며 메타데이터에는 이러한 블록에 대한 링크가 포함되어 있습니다. 이동할 준비가 되어 있고 블록 a, b, d로 구성된 두 번째 .vbk 파일이 있으면 탈수 지수를 분석하여 블록 d만 전송하면 된다는 것을 이해합니다. 그리고 해당 메타데이터 파일에는 두 개의 이전 블록과 하나의 새 블록에 대한 링크가 포함됩니다.

따라서 이러한 빈 공간을 데이터로 다시 채우는 과정을 재수화(Rehydration)라고 합니다. 이미 로컬 성능 범위에서 가장 오래된 .vbk 파일을 기반으로 자체 수분 보충 인덱스를 사용하고 있습니다. 즉, 사용자가 용량 촬영 범위에서 파일을 반환하려는 경우 먼저 가장 오래된 전체 백업의 블록에 대한 인덱스를 생성하고 용량 촬영 갤러리에서 누락된 블록만 전송합니다. 그림에 표시된 경우 Rehydration Index에 따라 FullBackup1.vbk를 Rehydrate하려면 용량 촬영 범위에서 가져온 블록 C만 필요합니다. 스토리지 클라우드 객체가 용량 사격장 역할을 하면 막대한 비용을 절약할 수 있습니다.

여기에서 이 기술은 WAN 가속기에 사용된 기술과 동일해 보일 수 있지만 실제로는 그렇게 보입니다. 가속기에서 중복 제거는 전역적이지만, 여기서는 각 파일 내 특정 오프셋에서 로컬 중복 제거가 사용됩니다. 이는 해결되는 작업의 차이로 인해 발생합니다. 여기서는 대용량 전체 백업 파일을 복사해야 하며, 연구에 따르면 파일 사이에 오랜 시간이 걸리더라도 이 중복 제거 알고리즘이 최상의 결과를 제공합니다.

하지만 인덱스의 신을 위한 인덱스가 더 많아졌습니다! 데이터 복구를 위한 인덱스도 있습니다! 용량 대시에 있는 머신 복원을 시작하면 성능 대시에 없는 고유한 데이터 블록만 읽습니다.

그것이 된대로

이것이 소개 부분의 전부입니다. 매우 상세하지만 위에서 언급한 것처럼 이러한 세부 정보가 없으면 새 기능이 어떻게 작동하는지 설명할 수 없습니다. 그러므로 더 이상 고민하지 말고 첫 번째로 넘어가겠습니다.

복사 모드

이는 주로 기존 기술을 기반으로 하지만 완전히 다른 사용 논리를 전달합니다. 

이 모드의 목적은 로컬 범위에 있는 모든 데이터가 용량 대시에 복사본이 있는지 확인하는 것입니다.

이동 및 복사 모드를 정면으로 비교하면 다음과 같습니다.

• 봉인된 체인만 이동할 수 있습니다. 복사 모드의 경우 백업 작업에서 발생하는 상황에 관계없이 모든 것이 전송됩니다.
• 파일이 운영 백업 창의 범위를 벗어나면 이동이 시작되고, 백업 파일이 나타나는 즉시 복사가 시작됩니다.
• 복사를 위한 새로운 데이터에 대한 모니터링은 지속적으로 이루어지며, 이동의 경우 4시간마다 한 번씩 트리거되었습니다.

새로운 모드를 고려할 때 간단한 예제에서 복잡한 예제로 이동할 것을 제안합니다.

가장 일반적인 경우에는 단순히 증분된 새 파일을 갖고 이를 수용 가능한 사격장에 복사하기만 하면 됩니다. 백업 작업에 어떤 모드가 사용되는지, 체인의 봉인된 부분에 속하는지 여부, 운영 기간이 만료되었는지 여부에 관계없이. 그들은 단지 그것을 가져다가 복사했습니다.

이 뒤에 있는 과정은 위에서 설명한 것처럼 여전히 탈수입니다. 복사 모드에서는 이미 스토리지에 있는 블록을 복사하지 않도록 합니다. 유일한 차이점은 영화 모드에서 실제 파일을 더미 파일로 바꾼 경우 여기서는 어떤 식으로든 건드리지 않고 모든 것을 그대로 둔다는 것입니다. 그렇지 않으면 돈과 시간을 절약하기 위해 신중하게 노력하는 탈수 지수와 똑같습니다.

문제가 발생합니다. UI를 보면 두 옵션을 동시에 선택할 수 있습니다. 이러한 결합 모드는 어떻게 작동합니까?

알아 내자.

시작은 표준입니다. 백업 파일이 즉시 생성되고 복사됩니다. 여기에 증분이 생성되고 복사됩니다. 이는 파일이 운영 창을 떠나 봉인된 체인이 나타나는 순간까지 발생합니다. 이 시점에서 우리는 탈수 작업을 수행하고 이러한 파일을 더미 파일로 바꿉니다. 물론 수용 가능한 사격장에는 다시 아무것도 복사하지 않습니다.

이 모든 흥미로운 논리는 인터페이스에서 단 하나의 확인란, 즉 백업이 생성되자마자 개체 스토리지에 백업을 복사하는 역할을 담당합니다.

이 복사 모드가 필요한 이유는 무엇입니까?

질문을 다음과 같이 바꾸는 것이 더 좋습니다. 도움을 받으면 어떤 위험으로부터 보호받을 수 있습니까? 어떤 문제를 해결하는 데 도움이 되나요?

대답은 분명합니다. 물론 이것은 데이터 복구입니다. 객체 스토리지에 로컬 데이터의 전체 복사본이 있으면 제품에 무슨 일이 일어나더라도 조건부 Amazon에 있는 파일에서 항상 데이터를 복원할 수 있습니다.

이제 가장 단순한 것부터 더 복잡한 것까지 가능한 시나리오를 살펴보겠습니다.

우리 머리에 닥칠 수 있는 가장 단순한 불행은 백업 체인에 있는 파일 중 하나에 액세스할 수 없다는 것입니다.

더 슬픈 이야기는 SOBR 저장소의 범위 중 하나가 손상되었다는 것입니다.

전체 SOBR 저장소에 액세스할 수 없게 되었지만 용량 사격 범위는 작동하면 상황은 더욱 악화됩니다.
그리고 모든 것이 정말 나쁩니다. 백업 서버가 죽고 첫 번째 욕구는 XNUMX분 안에 캐나다 국경으로 달려가는 것입니다.

이제 각 상황을 개별적으로 살펴 보겠습니다.

하나(또는 여러 개)의 백업 파일을 잃어버린 경우 저장소 재검색 프로세스를 시작하기만 하면 손실된 파일이 더미 파일로 대체됩니다. 그리고 기사 시작 부분에서 논의한 재수화 프로세스를 사용하여 사용자는 용량 사격장에서 로컬 저장소로 데이터를 다운로드할 수 있습니다.

이제 상황은 더욱 복잡해졌습니다. SOBR이 성능 모드에서 실행되는 두 개의 익스텐트로 구성되어 있다고 가정해 보겠습니다. 즉, .vbk 및 .vib가 고르지 않은 레이어에 분산되어 있음을 의미합니다. 그리고 어느 시점에서 익스텐트 중 하나를 사용할 수 없게 되고 사용자는 긴급하게 머신을 복원해야 하며, 그 중 데이터의 일부는 바로 이 익스텐트에 있습니다.

사용자는 복구 마법사를 시작하고 복원할 지점을 선택하며 마법사는 작업하는 동안 복구에 필요한 모든 데이터가 로컬에 없기 때문에 용량 촬영에서 다운로드해야 한다는 사실을 깨닫게 됩니다. 갤러리. 동시에 로컬 스토리지에 남아 있는 블록은 클라우드에서 다운로드되지 않습니다. 복원 색인에 영광을 돌립니다(예, 기사 시작 부분에서도 언급되었습니다).

이 사례의 하위 유형은 전체 SOBR 저장소에 액세스할 수 없게 된 것입니다. 이 경우 로컬 스토리지에서 복사할 것이 없으며 모든 블록이 클라우드에서 다운로드됩니다.

그리고 가장 흥미로운 상황은 백업 서버가 죽었다는 것입니다. 여기에는 두 가지 옵션이 있습니다. 관리자는 훌륭하고 구성 백업을 수행했으며 관리자는 사악한 피노키오이며 구성 백업을 수행하지 않았습니다.

첫 번째 경우에는 어딘가에 VBR을 새로 설치하고 표준 수단을 사용하여 백업에서 데이터베이스를 복원하는 것만으로도 충분합니다. 이 과정이 끝나면 모든 것이 정상으로 돌아옵니다. 또는 위의 시나리오 중 하나에 따라 복원됩니다.

그러나 관리자가 자신의 적이거나 구성 백업도 심각한 실패를 겪은 경우 여기에서도 그를 운명의 자비에 맡기지 않을 것입니다. 이 경우 Import Object Storage라는 새로운 절차를 도입했습니다. 이를 통해 SOBR 저장소를 수동으로 다시 생성하고 후속 재검색을 통해 용량 사격 범위를 여기에 연결하는 프로세스를 건너뛰고 Vim 인터페이스에 저장소 개체를 추가하고 저장소 저장소 가져오기 절차를 실행하기만 하면 됩니다. 귀하와 백업 사이에 방해가 될 수 있는 유일한 것은 백업이 암호화된 경우 비밀번호를 입력하라는 요청입니다.

이것은 아마도 복사 모드에 관한 전부일 것입니다.

밀봉 모드

주요 아이디어는 저장소의 선택된 SOBR 범위에 새 백업이 나타날 수 없다는 것입니다. v10 이전에는 저장소 작업이 완전히 금지된 유지 관리 모드만 있었습니다. 스토리지를 종료하기 위한 일종의 하드코어 모드로, 대피 버튼만 사용할 수 있으며 백업을 다른 범위로 한 번만 전송할 수 있습니다.

봉인 모드는 일종의 "소프트" 옵션입니다. 새 백업 생성을 금지하고 선택한 보존 기간에 따라 오래된 백업을 점차적으로 삭제하지만 그 과정에서 저장된 지점에서 복원하는 기능을 잃지 않습니다. 수명이 거의 다한 하드웨어를 교체해야 하거나 더 중요한 작업을 위해 비워두어야 하는데 가져가서 한 번에 모든 것을 이동할 수 있는 곳이 없을 때 매우 유용한 기능입니다. 아니면 삭제할 수 없습니다.

따라서 작동 원리는 매우 간단합니다. 모든 쓰기 작업(새 데이터 출현)을 금지하고 읽기(복원) 및 삭제(보존)를 남겨 두어야 합니다.

두 모드를 동시에 사용할 수 있지만 유지 관리의 우선 순위가 더 높다는 점에 유의하세요.

예를 들어, 두 개의 익스텐트로 구성된 SOBR을 생각해 보십시오. 처음 XNUMX일 동안 Forward Forever Incremental 모드에서 백업을 생성한 다음 범위를 봉인한다고 가정하면 사용 가능한 두 번째 범위에서 새로운 활성 전체 생성을 시작하게 됩니다. 우리의 보존이 XNUMX라면 봉인된 범위에 위치한 체인 전체가 한계를 넘었을 때 양심에 따라 삭제됩니다.

삭제가 더 일찍 발생하는 상황이 있습니다. 예를 들어, 이는 주기적으로 가득 찬 정방향 증분입니다. 처음 이틀 동안 전체 백업을 생성하고 목요일에 저장소를 봉인하기로 결정한 경우 금요일에 새 백업이 생성되면 월요일에 대한 파일이 삭제됩니다. 이 시점에는 종속성이 없습니다. 그리고 요점 자체는 누구에게도 의존하지 않습니다. 그런 다음 사용 가능한 범위에 XNUMX개의 포인트가 생성될 때까지 기다렸다가 서로 독립적으로 삭제할 수 없는 나머지 XNUMX개를 삭제합니다.

Reverse Incremental을 사용하면 상황이 더 간단해집니다. 그 안에서 가장 오래된 포인트는 어떤 것에도 의존하지 않으며 안전하게 삭제할 수 있습니다. 따라서 새 익스텐트에 새 .vbk가 생성되자마자 기존 .vrbs가 하나씩 삭제됩니다.

그런데 매번 새로운 .vbk를 만드는 이유는 무엇입니까? 생성하지 않고 이전 증분 체인을 계속하면 이전 .vbk가 모든 모드에서 무한히 오랫동안 정지되어 삭제를 방지할 수 있습니다. 따라서 익스텐트가 봉인되는 즉시 무료 익스텐트에 전체 백업을 생성하기로 결정했습니다.

용량 사격장에서는 상황이 더 복잡해집니다.

먼저 복사 모드를 살펴보겠습니다. XNUMX일 동안 적극적으로 백업을 생성한 후 용량 사격장이 봉쇄되었다고 가정해 보겠습니다. 어떠한 것도 삭제하지 않으며, 보존 기간을 겸허히 견디며, 이후 용량 사격장에서 데이터를 삭제합니다.

이동 모드에서도 거의 동일한 일이 발생합니다. 수정을 기다리고, 로컬 저장소에서 이전 항목을 삭제하고, 개체 저장소에 저장된 항목을 삭제합니다.

Forever 순방향 증분을 사용한 흥미로운 예입니다. 우리는 세 지점에 보존을 설치하고 월요일에 백업을 시작하며 정기적으로 클라우드에 복사됩니다. 저장소를 봉인한 후에도 백업은 계속 생성되어 XNUMX점을 유지하지만, 용량 대시에 저장된 데이터는 종속 상태로 남아 삭제할 수 없습니다. 따라서 우리는 .vbk가 보존 범위를 벗어나는 목요일까지 기다린 다음 저장된 체인 전체를 침착하게 삭제합니다.

그리고 작은 면책조항: 여기에 있는 모든 예는 하나의 시스템으로 표시됩니다. 백업에 여러 개가 있는 경우 Active Full이 만들어졌는지 여부에 따라 수정이 달라집니다.

기본적으로 그게 전부입니다. 이제 가장 하드코어한 기능으로 넘어가겠습니다.

불변성

이전 요점과 마찬가지로 가장 먼저 이 기능이 해결하는 문제가 무엇인지입니다. 백업을 저장하기 위해 어딘가에 업로드하자마자 백업의 안전을 보장하려는 강한 욕구가 있습니다. 즉, 특정 보존 기간 동안 백업의 삭제 및 수정을 물리적으로 금지하려는 강한 욕구가 있습니다. 루트 계정을 포함하여 관리자를 포함합니다. 이를 통해 우발적이거나 의도적인 손상으로부터 제품을 보호할 수 있습니다. AWS에서 작업하는 사람이라면 누구나 객체 잠금이라는 유사한 기능을 접했을 것입니다.

이제 일반적인 용어로 모드를 살펴본 다음 세부 사항을 살펴보겠습니다. 이 예에서는 XNUMX일 동안 보존되는 용량 사격 범위에 대해 불변성이 활성화됩니다. 그리고 백업에서는 복사 모드가 활성화됩니다.

불변성은 어떤 방식으로든 일반 보존과 상호 작용하지 않습니다. 예를 들어, 추가 포인트나 이와 유사한 것을 추가하지 않습니다. 단, XNUMX일 이내에는 백업 파일을 삭제할 수 없습니다. 월요일에 백업을 하면 금요일에만 해당 파일을 삭제할 수 있습니다.

이전에 설명한 모든 탈수, 인덱스 및 메타데이터 개념은 계속해서 동일하게 작동합니다. 그러나 한 가지 조건으로 블록은 데이터뿐만 아니라 메타데이터에도 설정됩니다. 이는 교활한 공격자가 메타데이터 데이터베이스를 삭제하고 데이터 블록이 쓸모없는 바이너리로 변하는 것을 방지하기로 결정한 경우에 수행됩니다.

이제 우리의 블록 생성 기술을 설명할 수 있는 좋은 시간입니다. 아니면 블록 생성. 이를 위해서는 그 출현으로 이어진 상황을 고려하십시오.

2일 이하의 시간 척도를 사용하여 불변성의 예상 만료 시간을 표시하겠습니다. 첫날에는 데이터 블록 a와 해당 메타데이터로 구성된 파일을 가져와 생성합니다. 불변성이 3일로 설정된 경우 XNUMX일째에 데이터가 잠금 해제되고 삭제된다고 가정하는 것이 논리적입니다. 둘째 날에는 동일한 설정을 가진 블록 b로 구성된 새 fileXNUMX를 추가합니다. 블록 A는 XNUMX일째에 제거되어야 합니다. 그러나 셋째 날에는 끔찍한 일이 발생합니다. 새 블록 d와 이전 블록 a에 대한 링크로 구성된 FileXNUMX 파일이 생성됩니다. 이는 블록과 해당 불변성 플래그가 XNUMX일째로 변경된 새로운 날짜로 재설정되어야 함을 의미합니다. 그리고 여기서 문제가 발생합니다. 실제 백업에는 그러한 블록이 엄청나게 많습니다. 그리고 불변성 기간을 연장하려면 매번 엄청난 수의 요청을 해야 합니다. 실제로 이것은 거의 끝없는 일일 프로세스가 될 것입니다. 왜냐하면 높은 확률로 우리는 각 복사본에서 중복 제거된 블록의 무거운 스택을 발견할 것이기 때문입니다. 객체 스토리지 제공업체의 요청이 많다는 것은 무엇을 의미합니까? 오른쪽! 월말에 엄청난 청구서가 나옵니다.

그리고 당신이 좋아하는 클라이언트를 갑자기 상당한 돈에 노출시키지 않기 위해 블록 생성 메커니즘이 발명되었습니다. 이는 설정된 불변 기간에 추가하는 추가 기간입니다. 아래 예에서 이 기간은 XNUMX일입니다. 그러나 이것은 단지 예일 뿐입니다. 실제로 그들은 월별 잠금 기간 동안 약 XNUMX일을 추가로 제공하는 자체 공식을 사용합니다.

동일한 상황을 블록 생성으로 계속 고려해 보겠습니다. 첫날에는 블록 a와 메타데이터로부터 file1을 생성합니다. 생성 기간과 불변성을 합산합니다. 이는 파일을 삭제할 수 있는 기회가 2일째라는 것을 의미합니다. 둘째 날에 블록 b와 블록 a에 대한 링크로 구성된 File3를 생성하면 예상 삭제 날짜에는 아무 일도 일어나지 않습니다. 그녀는 여섯째 날에도 그대로 서 있었습니다. 따라서 우리는 요청 횟수에 따른 비용을 절약하려고 노력하고 있습니다. 기한을 변경할 수 있는 유일한 상황은 생성 기간이 만료된 경우입니다. 즉, 세 번째 날에 새 File2에 a를 차단하는 링크가 포함되어 있으면 Gen1이 이미 만료되었으므로 XNUMX세대가 추가됩니다. 그리고 블록 A 삭제 예정일이 XNUMX일째로 변경됩니다. 이를 통해 중복 제거된 블록의 수명을 연장하기 위한 요청 수를 대폭 줄여 고객에게 엄청난 비용을 절약할 수 있습니다.

기술 자체는 S3 및 S3 호환 하드웨어 사용자가 사용할 수 있으며 제조업체는 해당 구현이 Amazon의 구현과 다르지 않음을 보장합니다. 따라서 Azure가 지원되지 않는 타당한 질문에 대한 대답은 유사한 기능을 가지고 있지만 개별 개체가 아닌 컨테이너 수준에서 작동합니다. 그런데 Amazon 자체에는 규정 준수와 거버넌스라는 두 가지 모드의 객체 잠금 기능이 있습니다. 두 번째 경우에는 개체 잠금에도 불구하고 관리자 위의 최고 관리자와 루트 위의 루트가 여전히 데이터를 삭제할 가능성이 남아 있습니다. 규정 준수의 경우 모든 것이 단단히 고정되어 누구도 백업을 삭제할 수 없습니다. 공식 성명에 따르면 Amazon 관리자도 마찬가지입니다. 이것이 우리가 지원하는 모드입니다.

그리고 평소와 같이 유용한 링크도 있습니다:

• 약 블록 생성 모든 세부 사항에서.
• 에 관한 모든 정보 Veeam 백업 및 복제 10 최선의
• О 용량 계층 자세히

출처 : habr.com