Veeam B&R 스토리지 정책 - 기술 지원과 함께 백업 체인 풀기

블로그 독자 여러분께 인사드립니다! 우리는 부분적으로 이미 친숙합니다. 내 영어 게시물이 여기에 표시되었으며 사랑하는 동료가 번역했습니다. 북극곰. 이번에 나는 러시아어를 사용하는 청중에게 직접 연설하기로 결정했습니다.

데뷔를 위해서는 최대한 많은 청중이 관심을 갖고 세심한 고려가 필요한 주제를 찾고 싶었습니다. Daniel Defoe는 죽음과 세금이 모든 사람을 기다리고 있다고 주장했습니다. 제 입장에서는 모든 지원 엔지니어가 복구 지점 저장소 정책(또는 더 간단하게 보존)에 대해 질문을 할 것이라고 말할 수 있습니다. 저는 4년 전에 XNUMX급 주니어 엔지니어로서 보존이 어떻게 작동하는지 설명하기 시작했고, 이미 스페인어와 이탈리아어를 사용하는 팀의 리더로서 지금 계속해서 설명하고 있습니다. 나는 두 번째, 심지어 세 번째 지원 수준의 동료들도 정기적으로 동일한 질문에 대답한다고 확신합니다.

이러한 관점에서 나는 러시아어를 사용하는 사용자가 참고서로 계속해서 돌아올 수 있도록 가능한 한 자세한 최종 게시물을 작성하고 싶었습니다. 바로 그 순간입니다. 최근 출시된 XNUMX주년 버전에는 수년 동안 변경되지 않은 기본 기능에 새로운 기능이 추가되었습니다. 내 게시물은 주로 이 버전에 초점을 맞추고 있습니다. 작성된 내용의 대부분은 이전 버전에 해당되지만 설명된 기능 중 일부는 여기에서 찾을 수 없습니다. 마지막으로 조금 미래를 내다보면서 다음 버전에서는 약간의 변화가 있을 것으로 예상되는데 이에 대해서는 때가 되면 말씀드리겠습니다. 그럼 시작해 보겠습니다.

백업 작업

먼저 버전 10에서 변경되지 않은 부분을 살펴보겠습니다. 보존 정책은 여러 매개변수에 의해 결정됩니다. 새 작업 생성 창을 열고 스토리지 탭으로 이동해 보겠습니다. 여기서는 원하는 복원 지점 수를 결정하는 매개변수를 볼 수 있습니다.

그러나 이는 방정식의 일부일 뿐입니다. 실제 포인트 수는 작업에 설정된 백업 모드에 의해서도 결정됩니다. 이 옵션을 선택하려면 동일한 탭에서 고급 버튼을 클릭하세요. 그러면 다양한 옵션이 포함된 새 창이 열립니다. 번호를 매기고 하나씩 고려해 봅시다.

옵션 1만 활성화하면 작업이 "영구 순방향 증분" 모드로 실행됩니다. 여기에는 어려움이 없습니다. 작업은 전체 백업(VBK 확장자를 가진 파일)에서 마지막 증분(VIB 확장자를 가진 파일)까지 지정된 수의 복구 지점을 저장합니다. 포인트 수가 설정 값을 초과하면 가장 오래된 증분부터 전체 백업과 병합됩니다. 즉, 작업이 3개의 포인트를 저장하도록 설정된 경우 다음 세션 직후 저장소에 4개의 포인트가 있게 되며 그 후 전체 백업이 가장 오래된 증분과 병합되고 총 포인트 수가 다음으로 돌아갑니다. 삼.

"역방향 증분" 모드(옵션 2)에 대한 보존도 매우 간단합니다. 이 경우 최신 지점은 전체 백업이고 이어서 소위 롤백 체인(VRB 확장자를 가진 파일)이 따르므로 보존을 적용하려면 가장 오래된 롤백을 삭제하는 것으로 충분합니다. 상황은 동일합니다. 세션 직후 포인트 수가 설정 값을 1만큼 초과한 후 원하는 값으로 돌아갑니다.

역증분 모드를 사용하면 주기적인 전체 백업(옵션 4)을 활성화할 수도 있지만 이것이 본질을 바꾸지는 않습니다. 예, 전체 복구 지점이 체인에 표시되지만 가장 오래된 지점을 하나씩 삭제하면 됩니다.

마지막으로 흥미로운 부분에 이르렀습니다. 증분 백업을 활성화하고 옵션 3이나 4(또는 둘 다 동시에)를 활성화하는 경우 작업은 "활성" 또는 합성 방법을 사용하여 주기적인 전체 백업을 생성하기 시작합니다. 전체 백업을 생성하는 방법은 중요하지 않습니다. 전체 백업에는 동일한 데이터가 포함되며 증분 체인은 "하위 체인"으로 나뉩니다. 이 방법을 순방향 증분이라고 하며 고객의 질문 중 상당 부분을 제기하는 방법이 바로 이 방법입니다.

여기에는 체인의 가장 오래된 부분을 삭제하여(전체 백업부터 증분까지) 보존이 적용됩니다. 동시에 전체 백업만 삭제하거나 증분의 일부만 삭제하지는 않습니다. 전체 "하위 체인"이 한 번에 완전히 제거됩니다. 포인트 수 설정의 의미도 변경됩니다. 다른 방법에서 이것이 허용되는 최대 수이고 그 후에 보존을 적용해야 하는 경우 여기서 이 설정이 최소 수를 결정합니다. 즉, 가장 오래된 "서브체인"을 제거한 후 나머지 부분의 포인트 수가 이 최소값 아래로 떨어지지 않아야 합니다.

나는 이 개념을 그래픽으로 묘사하려고 노력할 것이다. 보존이 3포인트로 설정되어 있고 월요일에 전체 백업으로 작업이 매일 실행된다고 가정해 보겠습니다. 이 경우 보유는 총 포인트 수가 10에 도달할 때 적용됩니다.

10개를 올렸는데 왜 벌써 3개가 있는 걸까요? 월요일에 전체 백업이 생성되었습니다. 화요일부터 일요일까지 작업이 증가했습니다. 마지막으로 다음 월요일에 전체 백업이 다시 생성되고 2개의 증분이 생성된 경우에만 체인의 이전 부분 전체를 삭제할 수 있습니다. 왜냐하면 남은 포인트 수가 세트 3 아래로 떨어지지 않기 때문입니다.

아이디어가 명확하다면 유지율을 직접 계산해 보는 것이 좋습니다. 다음 조건을 가정해 보겠습니다. 작업이 목요일에 처음으로 시작됩니다(당연히 전체 백업이 생성됩니다). 수요일과 일요일에 전체 백업을 생성하고 8개의 복구 지점을 저장하도록 작업이 설정되어 있습니다. 보존은 언제 처음 적용되나요?

이 질문에 답하기 위해서는 종이 한 장을 가져다가 요일별로 줄을 서서 매일 어떤 포인트가 만들어지는지 적어 보는 것을 추천합니다. 답은 뻔해지겠죠

답변

설명: 대답하려면 "보존은 언제 적용되나요?"라고 스스로에게 물어보세요. 답은 처음 3개 포인트(VBK, VIB, VIB)를 제거할 수 있고 체인의 나머지 부분이 필요한 8개 포인트 아래로 떨어지지 않는 경우입니다. 총 11개의 포인트가 있을 때, 즉 둘째 주 일요일에 이 작업을 수행할 수 있다는 것이 분명해졌습니다.

일부 독자들은 다음과 같이 이의를 제기할 수 있습니다. rps.dewin.me?. 이것이 매우 유용한 도구라는 점에는 의심의 여지가 없으며 어떤 경우에는 사용하겠지만 한계도 있습니다. 우선, 초기 조건을 지정할 수 없으며 많은 경우 정확하게 "우리가 그런 체인을 가지고 있는데, 이러저러한 설정을 변경하면 어떻게 될까요?"라는 질문이 제기됩니다. 둘째, 이 도구는 여전히 명확성이 다소 부족합니다. RPS 페이지를 클라이언트에게 보여주면서 이해가 되지는 않았지만, 예제와 같이 (동일한 페인트를 사용해도) 칠해 보니 날이 갈수록 모든 것이 명확해졌습니다.

마지막으로 "이전 백업 체인을 롤백으로 변환" 옵션(5번으로 표시)을 고려하지 않았습니다. 이 옵션은 "자동으로" 활성화하는 클라이언트를 혼란스럽게 하여 단순히 합성 백업을 활성화하려는 경우가 있습니다. 동시에 이 옵션은 매우 특별한 백업 모드를 활성화합니다. 자세히 설명하지 않고 현 제품 개발 단계에서 "이전 백업 체인을 롤백으로 전환"은 오래된 옵션이며 사용해야 하는 단일 시나리오를 생각할 수 없다고 바로 말씀드리겠습니다. 그 가치가 너무 의심스러워서 한동안 Anton Gostev 자신이 포럼을 통해 유용한 사용 사례를 보내달라고 요청했습니다(있는 경우 댓글을 작성해 주세요. 매우 관심이 있습니다). 아무 것도 없다면(그럴 것이라고 생각합니다), 이후 버전에서는 이 옵션이 제거될 것입니다.

이 작업은 통합 전체 백업이 예약되는 날까지 증분(VIB)을 생성합니다. 이날 실제로 VBK가 생성되지만 이 VBK 이전의 모든 지점은 롤백(VRB)으로 변환됩니다. 이후 작업은 다음 종합 백업까지 전체 백업에 대한 증분을 계속 생성합니다. 결과적으로 VBK, VBR 및 VIB 파일의 폭발적인 혼합이 체인에 생성됩니다. 보존은 매우 간단하게 적용됩니다. 마지막 VBR을 제거하면 됩니다.

문제

실제로 작동 방식을 이해하는 것 외에도 증분 모드를 사용할 때 발생하는 대부분의 문제는 일반적으로 전체 백업과 관련이 있습니다. 이 모드에는 정기적인 전체 백업이 필요합니다. 그렇지 않으면 리포지토리가 가득 찰 때까지 포인트를 축적합니다.

예를 들어, 전체 백업이 너무 드물게 생성될 수 있습니다. 작업이 10개의 포인트를 저장하도록 설정되어 있고 한 달에 한 번씩 전체 백업이 생성된다고 가정해 보겠습니다. 여기에 있는 실제 포인트 수는 표시된 포인트 수보다 훨씬 더 많을 것임이 분명합니다. 또는 작업은 일반적으로 무한 증분 모드로 작동하고 50포인트를 저장하도록 설정됩니다. 그런 다음 누군가 실수로 전체 백업을 만들었습니다. 그게 전부입니다. 이제부터 작업은 전체 포인트가 49개 증분을 누적할 때까지 기다린 후 보존을 적용하고 무한 전체 모드로 돌아갑니다.

다른 경우에는 전체 백업이 정기적으로 생성되도록 설정되어 있지만 어떤 이유로 인해 그렇지 않습니다. 여기에 가장 인기 있는 이유를 나열하겠습니다. 일부 클라이언트는 "다음 이후 실행" 예약 옵션을 사용하고 작업이 체인에서 실행되도록 구성하는 것을 선호합니다. 이 예를 들어보겠습니다. 매일 실행되고 일요일에 전체 백업을 생성하는 3개의 작업이 있습니다. 첫 번째 작업은 22.30시 10분에 시작되고 나머지는 체인으로 시작됩니다. 증분 백업에는 23.00분이 걸리므로 22.30시까지 모든 작업이 완료됩니다. 그러나 전체 백업에는 23.30시간이 걸리므로 일요일에는 첫 번째 작업이 23.30시 00.30분부터 XNUMX시 XNUMX분까지 실행됩니다. 다음은 XNUMX부터 XNUMX까지입니다. 하지만 세 번째 작업은 월요일부터 시작됩니다. 전체 백업은 일요일로 설정되어 있으므로 이 경우에는 백업이 발생하지 않습니다. 작업은 전체 백업이 보존을 적용할 때까지 기다립니다. 따라서 "다음 이후 실행" 옵션을 사용할 때는 주의하거나 전혀 사용하지 마십시오. 작업이 동시에 시작되도록 설정하고 리소스 스케줄러가 해당 작업을 수행하도록 하십시오.

어려운 옵션 "삭제된 항목 제거"

저장소 - 고급 - 유지 관리 작업의 설정을 살펴보면 "다음 이후에 삭제된 항목 데이터 제거" 옵션을 찾을 수 있으며 이는 일 단위로 계산될 수 있습니다.

일부 고객은 이것이 유지되기를 기대합니다. 실제로 이것은 완전히 별개의 옵션이므로 오해로 인해 예상치 못한 결과가 발생할 수 있습니다. 그러나 먼저 세션 중에 소수의 머신만 성공적으로 백업되는 상황에 B&R이 어떻게 반응하는지 설명해야 합니다.

이 시나리오를 상상해 봅시다. 6개 포인트를 저장하도록 구성된 무한 증분 작업입니다. 작업에는 2개의 머신이 있는데, 하나는 항상 성공적으로 백업되었고 다른 하나는 때때로 오류가 발생했습니다. 결과적으로 일곱 번째 지점에서는 다음과 같은 상황이 발생했습니다.

리텐션을 적용할 시간인데 한 차에는 포인트가 7개 있고 다른 차에는 4개만 있습니다. 여기에 리텐션이 적용됩니까? 대답은 '그렇습니다'입니다. 최소한 하나의 객체가 백업된 경우 B&R은 해당 포인트가 생성된 것으로 간주합니다.

특정 세션 동안 일부 시스템이 작업에 포함되지 않은 경우에도 유사한 상황이 발생할 수 있습니다. 예를 들어 머신이 개별적으로가 아니라 컨테이너(폴더, 스토리지)의 일부로 작업에 추가되고 일부 머신이 일시적으로 다른 컨테이너로 마이그레이션되는 경우에 이런 일이 발생합니다. 이 경우 작업은 성공한 것으로 간주되지만 통계에는 해당 기계가 더 이상 작업에 의해 처리되지 않는다는 점에 주의하라는 메시지가 표시됩니다.

이것에 주의를 기울이지 않으면 어떻게 될까요? 무한 증분 또는 역증분 모드의 경우 "문제" 시스템의 복구 지점 수는 VBK에 저장된 1에 도달할 때까지 각 세션마다 감소합니다. 즉, 머신을 오랫동안 백업하지 않더라도 하나의 복구 지점이 여전히 남아 있습니다. 주기적인 전체 백업이 활성화된 경우 상황은 다릅니다. B&R의 신호를 무시하면 결국 체인의 이전 부분과 함께 마지막 포인트가 삭제될 수 있습니다.

이러한 세부 사항을 이해한 후에는 마침내 "다음 이후에 삭제된 항목 데이터 제거" 옵션을 고려할 수 있습니다. 해당 머신이 X일 동안 백업되지 않으면 특정 머신에 대한 모든 포인트가 삭제됩니다. 이 설정은 오류에 응답하지 않는다는 점에 유의하십시오(시도했지만 작동하지 않았습니다). 머신을 백업하려는 시도도 있어서는 안 됩니다. 이 옵션은 유용하고 항상 활성화된 상태로 유지되어야 하는 것 같습니다. 관리자가 작업에서 머신을 제거한 경우 잠시 후 불필요한 데이터 체인을 지우는 것이 논리적입니다. 그러나 사용자 정의에는 규율과 주의가 필요합니다.

실습의 예를 들어 보겠습니다. 여러 컨테이너가 작업에 추가되었으며 그 구성은 매우 역동적이었습니다. RAM 부족으로 인해 B&R 서버는 감지되지 않는 문제를 겪고 있었습니다. 작업이 시작되어 당시 컨테이너에 없었던 머신을 제외하고 머신의 백업을 만들려고 했습니다. 많은 기계에서 오류가 발생했기 때문에 B&R은 기본적으로 "문제" 기계를 백업하기 위해 3번의 추가 시도를 해야 합니다. RAM의 지속적인 문제로 인해 이러한 시도는 며칠 동안 지속되었습니다. 누락된 VM을 백업하려는 반복적인 시도가 없었습니다(VM이 없는 것은 오류가 아닙니다). 그 결과, 반복된 시도 중 하나에서 "삭제된 항목 제거" 조건이 충족되었으며 시스템의 모든 포인트가 삭제되었습니다.

이와 관련하여 다음과 같이 말할 수 있습니다. 작업 결과에 대한 알림이 설정되어 있고 더 나은 경우 Veeam ONE과의 통합을 사용하면 이런 일이 발생하지 않을 가능성이 높습니다. 일주일에 한 번씩 B&R 서버를 확인하여 모든 것이 작동하는지 확인하는 경우 잠재적으로 백업 삭제로 이어질 수 있는 옵션을 거부하는 것이 좋습니다.

v.10에 추가된 내용

우리가 이전에 이야기한 내용은 B&R에 여러 버전으로 존재했습니다. 이러한 작동 원리를 이해했으므로 이제 "XNUMX" 기념일에 추가된 내용을 살펴보겠습니다.

일일 보존

위에서는 포인트 수를 기준으로 한 "전통적인" 스토리지 정책을 살펴보았습니다. 또 다른 접근 방식은 동일한 메뉴에서 "복원 지점" 대신 "일"을 설정하는 것입니다.

아이디어는 이름에서 분명합니다. 보존은 설정된 일수를 저장하지만 매일 포인트 수는 중요하지 않습니다. 이 경우 다음 사항을 기억해야 합니다.

• 보존 기간을 계산할 때 현재 날짜는 고려되지 않습니다.
• 작업이 전혀 작동하지 않은 날도 계산됩니다. 불규칙하게 작동하는 작업의 포인트를 실수로 잃지 않도록 이 점을 명심해야 합니다.
• 복구 지점은 생성이 시작된 날부터 계산됩니다. 즉, 작업이 월요일에 작업을 시작하고 화요일에 완료된 경우 월요일부터의 지점이 됩니다.

그렇지 않으면 작업별 보존 사용 원칙도 선택한 백업 방법에 따라 결정됩니다. 동일한 증분 방법을 사용하여 다른 계산 작업을 시도해 보겠습니다. 보존 기간이 8일로 설정되어 있고 작업이 수요일에 전체 백업과 함께 6시간마다 실행된다고 가정해 보겠습니다. 그러나 일요일에는 작업이 작동하지 않습니다. 작업은 월요일에 처음으로 실행됩니다. 보존은 언제 적용되나요?

답변
언제나 그렇듯이 기호를 그리는 것이 가장 좋습니다. 여기서는 일일 포인트 수가 중요하지 않기 때문에 작업을 단순화하고 매일 생성된 모든 포인트를 그리지는 않겠습니다. 첫 번째 월요일과 수요일에는 첫 번째 지점이 전체 백업이 되고 나머지 날에는 작업이 단순히 4개의 증분 지점을 생성한다는 것이 중요합니다.

월요일의 전체 백업과 그 증분분을 삭제하여 보존이 적용됨을 분명히 합니다. 언제 이런 일이 일어날까요? 체인의 나머지 부분에 8일이 포함되어 있는 경우. 동시에 우리는 현재 날짜를 계산하지 않지만 반대로 일요일을 계산합니다. 따라서 정답은 둘째 주 목요일입니다.

일반 작업을 위한 GFS 보관

v.10 이전에는 GFS(Grandfather-Father-Son) 저장 방법을 백업 복사 작업 및 테이프 복사 작업에만 사용할 수 있었습니다. 이제 정기적인 백업이 가능해졌습니다.

현재 주제와는 관련이 없지만, 새로운 기능이 3-2-1 전략에서 벗어나는 것을 의미하지 않는다고 말씀드릴 수밖에 없습니다. 기본 저장소에 보관 지점이 있어도 안정성에는 어떤 영향도 미치지 않습니다. GFS는 확장 저장소와 함께 사용되어 이러한 포인트를 S3 및 유사한 저장소에 업로드하는 것으로 이해됩니다. 사용하지 않는 경우 기본 및 아카이브 지점을 다른 리포지토리에 계속 저장하는 것이 좋습니다.

이제 GFS 포인트 생성 원리를 살펴보겠습니다. 작업 설정의 저장 단계에서 다음 메뉴를 불러오는 특수 버튼이 나타났습니다.

GFS의 본질은 여러 가지로 요약될 수 있습니다(GFS는 다른 유형의 작업에서는 다르게 작동하지만 이에 대해서는 나중에 자세히 설명합니다).

• 이 작업은 GFS 포인트에 대한 별도의 전체 백업을 생성하지 않습니다. 대신 사용 가능한 가장 적합한 전체 백업이 사용됩니다. 따라서 작업은 주기적인 전체 백업을 통해 증분 모드로 수행되어야 하며, 그렇지 않으면 사용자가 전체 백업을 수동으로 생성해야 합니다.
• 기간이 하나만 활성화된 경우(예: 일주일) GFS 기간이 시작될 때 작업은 전체 백업을 기다리기 시작하고 첫 번째 적합한 백업을 GFS로 표시합니다.

예: 수요일에 백업을 사용하여 매주 GFS를 저장하도록 작업이 구성되었습니다. 작업은 매일 실행되지만 전체 백업은 금요일에 예약됩니다. 이 경우 GFS 기간은 수요일에 시작되며 작업은 적절한 지점을 기다리기 시작합니다. 금요일에 나타나며 GFS 플래그로 표시됩니다.

• 여러 기간이 한 번에 포함되는 경우(예: 주간 및 월간) B&R은 동일한 포인트를 여러 간격의 GFS로 사용할 수 있도록 허용하는 방법을 사용합니다(공간 절약). 플래그는 가장 어린 것부터 순서대로 지정됩니다.

예: 매주 GFS는 수요일로 설정되고, 월간 GFS는 매월 마지막 주로 설정됩니다. 작업은 매일 실행되며 월요일과 금요일에 전체 백업을 생성합니다.

단순화를 위해 매월 두 번째 주부터 계산을 시작하겠습니다. 이번 주에는 전체 백업이 월요일에 생성되지만 주간 GFS 간격이 수요일에 시작되므로 무시됩니다. 하지만 금요일의 전체 백업은 GFS 지점에 완전히 적합합니다. 이 시스템은 우리에게 이미 익숙합니다.

이제 매월 마지막 주에 무슨 일이 일어나는지 살펴보겠습니다. 월별 GFS 간격은 월요일에 시작되지만 작업에서 하나의 VBK를 월별 및 주별 GFS 포인트로 표시하려고 하기 때문에 월요일의 VBK는 GFS로 표시되지 않습니다. 이 경우 정의에 따라 월별 검색이 될 수도 있으므로 검색은 주별 검색으로 시작됩니다.

그러나 주별 및 연간 간격만 포함하면 서로 독립적으로 작동하며 2개의 별도 VBK를 해당 GFS 간격으로 표시할 수 있습니다.

백업 복사 작업

작업에 대한 설명이 필요한 또 다른 유형의 작업입니다. 먼저 혁신이 없는 "고전적인" 작업 방식을 살펴보겠습니다. v.10

간단한 보관 방법

기본적으로 이러한 작업은 무한 증분 모드로 실행됩니다. 지점 생성은 복사 간격과 원하는 복구 지점 수(여기서는 일별 보존이 없음)라는 두 가지 매개변수에 의해 결정됩니다. 복사 간격은 작업을 생성할 때 첫 번째 작업 탭에서 설정됩니다.

포인트 수는 Target 탭에서 조금 더 결정됩니다.

작업은 각 간격마다 1개의 새 포인트를 생성합니다(원래 작업에 의해 VM에 대해 생성된 포인트 수는 중요하지 않음). 간격이 끝나면 새 포인트가 확정되고 필요한 경우 VBK와 가장 오래된 증분을 결합하여 보존이 적용됩니다. 이 메커니즘은 우리에게 이미 익숙합니다.

GFS를 이용한 보존 방법

BCJ는 보관 지점을 저장할 수도 있습니다. 이는 복구 지점 수 설정 바로 아래에 있는 동일한 대상 탭에서 구성됩니다.

GFS 포인트는 두 가지 방법으로 생성할 수 있습니다. 즉, 보조 저장소의 데이터를 사용하여 합성하거나, 전체 백업을 시뮬레이션하고 기본 저장소에서 모든 데이터를 읽는 방식입니다(3으로 표시된 옵션으로 활성화됨). 두 경우 모두 보존 방법이 매우 다르기 때문에 별도로 고려할 것입니다.

합성 GFS

이 경우 GFS 포인트는 지정된 날짜에 정확하게 생성되지 않습니다. 대신 GFS 포인트 생성이 예약된 날짜의 VIB가 전체 백업과 병합되면 GFS 포인트가 생성됩니다. 시간이 지나도 여전히 GFS 포인트가 없어 오해를 불러일으키는 경우도 있습니다. 그리고 기술 지원팀의 강력한 주술사만이 포인트가 나타날 날짜를 예측할 수 있습니다. 실제로 마법은 필요하지 않습니다. 설정된 포인트 수와 동기화 간격(매일 생성되는 포인트 수)만 살펴보세요. 다음 예를 사용하여 직접 계산해 보세요. 작업은 7포인트를 저장하도록 설정되어 있고 동기화 간격은 12시간입니다(즉, 하루에 2포인트). 현재 체인에는 이미 7개의 포인트가 있으며 오늘은 월요일이며 GFS 포인트 생성이 이날 예정되어 있습니다. 언제 만들어질까요?

답변
시간이 지남에 따라 체인이 매일 어떻게 변하는지 설명하는 것이 더 좋습니다.

따라서 월요일에는 체인의 마지막 증분은 GFS로 표시되지만 다른 눈에 띄는 변경 사항은 발생하지 않습니다. 매일 작업은 2개의 새로운 포인트를 생성하고 유지는 체인을 앞으로 나아가게 합니다. 마지막으로 목요일에는 바로 그 증가분에 보존을 적용할 시간이 됩니다. 이 세션은 평소보다 오래 걸립니다. 작업이 체인에서 필요한 블록을 "추출"하고 새로운 완전한 지점을 생성하기 때문입니다. 이 순간부터 체인에는 이미 8개의 포인트(메인 체인 + GFS의 7개)가 있습니다.

"전체 포인트 읽기" 옵션을 사용하여 GFS 포인트 생성

위에서 나는 BCJ가 무한 증분 모드로 작동한다고 말했습니다. 이제 우리는 이 규칙의 유일한 예외를 살펴보겠습니다. "전체 포인트 읽기" 옵션이 활성화되면 GFS 포인트가 예약된 날짜에 정확히 생성됩니다. 작업 자체는 위에서 설명한 주기적인 전체 백업을 통해 증분 모드로 작동합니다. 체인의 가장 오래된 부분을 제거하여 유지 기능도 적용됩니다. 그러나 이 경우 증분만 삭제되고 전체 백업은 GFS 포인트로 남게 됩니다. 따라서 보존 기간을 계산할 때 GFS 플래그로 표시된 지점은 고려되지 않습니다.

작업이 7개의 포인트를 저장하고 월요일에 매주 GFS 포인트를 생성하도록 설정되어 있다고 가정해 보겠습니다. 이 경우 매주 월요일 작업은 실제로 전체 백업을 생성하고 이를 GFS로 표시합니다. 가장 오래된 부분에서 증분을 제거한 후 남은 증분 수가 7 미만이 되지 않으면 보존이 적용됩니다. 다이어그램은 다음과 같습니다.

따라서 두 번째 주가 끝날 때까지 체인에는 총 14개의 포인트가 있습니다. 두 번째 주에는 이 작업으로 7개의 포인트가 생성되었습니다. 이것이 간단한 작업이었다면 이미 보존이 적용되었을 것입니다. 하지만 GFS Retention을 적용한 BCJ이므로 GFS 포인트를 계산하지 않고 6개만 존재하므로 아직 Retention을 적용할 수 없습니다. 세 번째 주에는 GFS 플래그를 사용하여 또 다른 전체 백업을 생성합니다. 15점이지만 이것도 계산하지 않습니다. 그리고 마지막으로 세 번째 주 화요일에 증분을 생성합니다. 이제 첫 번째 주의 체인 증분을 제거하면 총 증분 수가 설정된 보존을 충족하게 됩니다.

위에서 언급했듯이 이 방법에서는 전체 백업을 정기적으로 생성하는 것이 매우 중요합니다. 예를 들어, 기본 보존 기간을 7일로 설정했지만 연간 포인트는 1개만 설정한 경우 증분이 7보다 훨씬 많이 누적될 것이라고 상상하기 쉽습니다. 이러한 경우 합성 생성 방법을 사용하는 것이 좋습니다. GFS.

그리고 다시 "삭제된 항목 제거"

이 옵션은 BCJ에도 있습니다.

여기서 이 옵션의 논리는 일반 백업 작업과 동일합니다. 즉, 지정된 일수 동안 머신이 처리되지 않으면 해당 데이터가 체인에서 삭제됩니다. 그러나 BCJ의 경우 이 옵션의 유용성이 객관적으로 더 높으며 그 이유는 다음과 같습니다.

일반 모드에서 BCJ는 무한 증분 모드로 작동하므로 특정 시점에 작업에서 머신이 제거되면 보존은 VBK에 하나만 남을 때까지 모든 복구 지점을 점차적으로 삭제합니다. 이제 작업이 여전히 합성 GFS 포인트를 생성하도록 구성되어 있다고 가정해 보겠습니다. 때가 되면 작업은 체인의 모든 컴퓨터에 대해 GFS를 생성해야 합니다. 어떤 기계에 새로운 포인트가 전혀 없다면, 새로운 포인트가 있는 기계를 사용해야 합니다. 그리고 매번. 결과적으로 다음과 같은 상황이 발생할 수 있습니다.

파일 섹션에 주의하세요. 기본 VBK와 2개의 주간 GFS 포인트가 있습니다. 이제 복원 지점 섹션으로 이동합니다. 실제로 이러한 파일에는 동일한 시스템 이미지가 포함되어 있습니다. 당연히 이러한 GFS 포인트에는 의미가 없으며 공간만 차지합니다.

이 상황은 합성 GFS를 사용할 때만 가능합니다. 이를 방지하려면 '삭제된 항목 제거' 옵션을 사용하세요. 적절한 일수로 설정하는 것을 잊지 마십시오. 기술 지원에서는 옵션이 동기화 간격보다 짧은 일수로 설정된 사례를 확인했습니다. BCJ는 포인트가 생성되기 전에 맹렬히 삭제하기 시작했습니다.

또한 이 옵션은 이미 생성된 GFS 포인트에는 영향을 미치지 않습니다. 아카이브를 정리하려면 머신을 마우스 오른쪽 버튼으로 클릭하고 "디스크에서 삭제"를 선택하여 이 작업을 수동으로 수행해야 합니다(나타나는 창에서 "GFS 전체 백업 제거" 상자를 선택하는 것을 잊지 마십시오). :

혁신 v.10 – 즉시 복사

"클래식" 기능을 처리한 후 새로운 기능으로 넘어가겠습니다. 하나의 혁신이 있지만 매우 중요한 혁신이 있습니다. 이것은 새로운 작동 모드입니다.

"동기화 간격"과 같은 것은 없습니다. 작업은 새로운 포인트가 나타나는지 지속적으로 모니터링하고 개수에 관계없이 모두 복사합니다. 그러나 동시에 작업은 증분 상태로 유지됩니다. 즉, 기본 작업이 VBK 또는 VRB를 생성하더라도 이러한 포인트는 VIB로 복사됩니다. 그렇지 않으면 이 모드에서는 놀랄 일이 없습니다. 표준 및 GFS 보존 모두 위에서 설명한 규칙에 따라 작동합니다(그러나 여기서는 합성 GFS만 사용할 수 있습니다).

디스크가 회전하고 있습니다. 드라이브가 회전된 저장소의 기능

랜섬웨어 바이러스의 끊임없는 위협으로 인해 바이러스가 도달할 수 없는 매체에 데이터 사본을 보관하는 것이 사실상의 보안 표준이 되었습니다. 한 가지 옵션은 디스크가 한 번에 하나씩 사용되는 디스크 회전 리포지토리를 사용하는 것입니다. 하나의 디스크가 연결되어 쓰기 가능한 동안 나머지는 안전한 위치에 저장됩니다.
B&R이 이러한 리포지토리와 함께 작동하도록 가르치려면 리포지토리 단계에서 리포지토리 설정의 고급 버튼을 클릭하고 적절한 옵션을 선택해야 합니다.

그 후 VBR은 기존 체인이 저장소에서 주기적으로 사라질 것으로 예상하며 이는 디스크 회전을 의미합니다. 저장소 유형과 작업 유형에 따라 B&R은 다르게 작동합니다. 이는 다음 표로 나타낼 수 있습니다.

각 옵션을 고려해 보겠습니다.

일반 작업 및 Windows 저장소

그래서 첫 번째 디스크에 체인을 저장하는 작업이 있습니다. 순환하는 동안 생성된 체인은 실제로 사라지며 작업은 어떻게든 이 손실에서 살아남아야 합니다. 그녀는 전체 백업을 생성함으로써 위안을 찾습니다. 따라서 각 순환은 완전한 백업을 의미합니다. 그러면 연결이 끊어진 디스크의 포인트는 어떻게 되나요? 보존 기간을 계산할 때 기억되고 고려됩니다. 따라서 작업에 설정된 포인트 수는 모든 디스크에 유지되어야 하는 포인트 수입니다. 예는 다음과 같습니다.

작업은 무한 증분 모드로 실행되며 3개의 복원 지점을 저장하도록 구성됩니다. 하지만 두 번째 디스크도 있고 일주일에 한 번 회전합니다(디스크가 더 있을 수 있지만 이것이 본질을 바꾸지는 않습니다).

첫 주에 작업은 첫 번째 디스크에 포인트를 생성하고 추가 디스크를 병합합니다. 따라서 총 포인트 수는 XNUMX이 됩니다.

그런 다음 두 번째 드라이브를 연결합니다. 시작 시 B&R은 디스크가 교체되었음을 알 수 있습니다. 첫 번째 디스크의 체인은 인터페이스에서 사라지지만 이에 대한 정보는 데이터베이스에 남아 있습니다. 이제 작업은 두 번째 디스크에 3개의 포인트를 유지합니다. 일반적인 상황은 다음과 같습니다.

마지막으로 첫 번째 드라이브를 다시 연결합니다. 새 포인트를 생성하기 전에 작업은 보존에 어떤 일이 일어나고 있는지 확인합니다. 그리고 기억나는 점은 3포인트를 저장하도록 설정되어 있다는 점입니다. 한편, 디스크 3에는 2개의 포인트가 있고(그러나 연결이 끊어져 B&R이 도달할 수 없는 안전한 장소에 저장되어 있음) 디스크 3에 1개의 포인트가 있습니다(그러나 이것은 연결되어 있습니다). 이는 보존을 초과하므로 디스크 3에서 1개의 포인트를 안전하게 제거할 수 있음을 의미합니다. 그 후 작업이 다시 전체 백업을 생성하고 체인은 다음과 같이 보이기 시작합니다.

포인트 수 대신 일수를 저장하도록 보존이 구성된 경우 논리는 변경되지 않습니다. 또한 디스크 순환이 포함된 리포지토리를 사용하는 경우 GFS 보존이 전혀 지원되지 않습니다.

일반 작업 및 Linux 리포지토리 네트워크 스토리지

이 옵션도 가능하지만 일반적으로 부과되는 제한 사항으로 인해 권장되지 않습니다. 작업은 전체 백업을 생성하여 동일한 방식으로 디스크 회전 및 체인 소멸에 반응합니다. 제한은 차단 고정 메커니즘으로 인해 발생합니다.

여기서 회전하는 동안 연결이 끊긴 디스크의 전체 체인이 B&R 데이터베이스에서 삭제됩니다. 데이터베이스의 파일 자체는 디스크에 남아 있습니다. 복구를 위해 가져와서 사용할 수 있지만 조만간 잊혀진 체인이 전체 저장소를 채울 것이라고 추측하기 쉽습니다.

해결 방법은 이 페이지에 표시된 대로 DWORD ForceDeleteBackupFiles를 추가하는 것입니다. www.veeam.com/kb1154. 그런 다음 작업은 각 순환에서 작업 폴더 또는 저장소 폴더(값에 따라 다름)의 전체 내용을 삭제하기 시작합니다.

그러나 이는 우아한 보존이 아니라 모든 내용을 정리하는 것입니다. 불행하게도 기술 지원에서는 저장소가 단순히 백업 외에 다른 데이터가 있는 디스크의 루트 디렉터리인 경우도 있었습니다. 이 모든 것은 회전 중에 파괴되었습니다.

또한 ForceDeleteBackupFiles가 활성화되면 모든 유형의 리포지토리에서 작동합니다. 즉, Windows의 리포지토리에서도 보존 적용이 중지되고 콘텐츠 삭제가 시작됩니다. 즉, Windows의 로컬 디스크는 이러한 백업 스토리지 시스템에 가장 적합한 선택입니다.

백업 복사본 및 Windows 저장소

BCJ를 사용하면 상황이 더욱 흥미로워집니다. 본격적인 보존이 가능할 뿐만 아니라, 디스크를 변경할 때마다 전체 백업을 할 필요가 없습니다! 다음과 같이 작동합니다.

먼저, B&R은 첫 번째 디스크에 포인트를 생성하기 시작합니다. 보존을 3포인트로 설정했다고 가정해 보겠습니다. 작업은 무한 증분 모드에서 작동하며 불필요한 모든 항목을 병합합니다(이 경우 GFS 보존이 지원되지 않음을 상기시켜 드립니다).

그런 다음 두 번째 드라이브를 연결합니다. 아직 체인이 없기 때문에 전체 백업을 생성한 후 세 지점으로 구성된 두 번째 체인을 만듭니다.

마지막으로 첫 번째 드라이브를 다시 연결할 차례입니다. 작업이 전체 백업을 생성하지 않고 대신 증분 체인을 계속하기 때문에 마법이 시작되는 곳은 바로 여기입니다.

그 후에는 사실상 각 디스크가 자체적인 독립 체인을 갖게 됩니다. 따라서 여기서 보존이란 모든 디스크의 포인트 수를 의미하는 것이 아니라 각 디스크의 포인트 수를 개별적으로 의미합니다.

백업 복사본 및 Linux 리포지토리 네트워크 스토리지

다시 한 번 말하지만 저장소가 로컬 Windows 드라이브에 없으면 모든 우아함이 사라집니다. 이 스크립트는 간단한 작업으로 위에서 설명한 것과 유사하게 작동합니다. 각 순환마다 BCJ는 전체 백업을 생성하며 기존 포인트는 잊혀집니다. 여유 공간이 부족해지는 것을 방지하려면 DWORD ForceDeleteBackupFiles를 사용해야 합니다.

결론

그래서 이렇게 긴 글을 쓴 결과, 우리는 두 가지 유형의 작업을 살펴보았습니다. 물론 더 많은 작업이 있지만 하나의 기사 형식으로 모두 고려하는 것은 불가능합니다. 읽어보신 후에도 궁금한 점이 있으시면 댓글에 적어주시면 개인적으로 답변해 드리겠습니다.

출처 : habr.com