백업, 1부: 목적, 방법 및 기술 검토

왜 백업을 해야 합니까? 결국 장비는 매우 안정적이며 물리적 서버보다 안정성이 더 뛰어난 "클라우드"가 있습니다. 적절한 구성을 사용하면 "클라우드" 서버는 인프라 물리적 서버의 오류에서도 쉽게 살아남을 수 있습니다. 서비스 사용자의 관점에서 볼 때, 시간 서비스에는 미미하고 거의 눈에 띄지 않는 점프가 있을 것입니다. 또한 정보를 복제하려면 "추가" 프로세서 시간, 디스크 로드 및 네트워크 트래픽에 대한 비용을 지불해야 하는 경우가 많습니다.

이상적인 프로그램은 빠르게 실행되고, 메모리 누수가 없고, 구멍이 없고, 존재하지 않습니다.

-알려지지 않은

프로그램은 여전히 ​​단백질 개발자에 의해 작성되고 테스트 프로세스가 없는 경우가 많으며 프로그램이 "모범 사례"(그 자체도 프로그램이므로 불완전함)를 사용하여 제공되는 경우가 거의 없기 때문에 시스템 관리자는 간단하게 들리지만 문제를 해결해야 하는 경우가 가장 많습니다. 간결하게: "원래대로 돌아가기", "베이스를 정상 작동으로 가져오기", "천천히 작동 - 롤백", 그리고 제가 가장 좋아하는 "무엇인지는 모르겠지만 고치세요"입니다.

개발자의 부주의한 작업 또는 상황의 조합으로 인해 발생하는 논리적 오류 외에도 운영 체제, 드라이버 및 펌웨어를 포함한 연결 및 시스템 기능을 포함하여 프로그램 구축의 작은 기능에 대한 불완전한 지식 또는 오해가 있습니다. 다른 오류도 있습니다. 예를 들어, 대부분의 개발자는 프로그램을 사용하여 우회하는 것이 여전히 불가능한 물리적 법칙을 완전히 잊어버린 채 런타임에 의존합니다. 여기에는 디스크 하위 시스템과 일반적으로 모든 데이터 저장 하위 시스템(RAM 및 프로세서 캐시 포함!)의 무한한 신뢰성, 프로세서의 처리 시간 없음, 네트워크를 통한 전송 및 처리 중 오류 없음이 포함됩니다. 프로세서 및 네트워크 대기 시간은 0입니다. 악명 높은 마감일을 무시해서는 안됩니다. 제 시간에 맞추지 않으면 네트워크 및 디스크 작동의 뉘앙스보다 더 심각한 문제가 발생하기 때문입니다.

본격적으로 발생하고 귀중한 데이터에 영향을 미치는 문제를 해결하려면 어떻게 해야 합니까? 살아있는 개발자를 대체할 수 있는 것은 없으며 가까운 시일 내에 가능하다는 것도 사실이 아닙니다. 반면, 소수의 프로젝트만이 프로그램이 의도한 대로 작동할 것임을 완전히 입증하는 데 성공했으며, 증거를 확보하여 다른 유사한 프로젝트에 적용하는 것이 반드시 가능한 것은 아닙니다. 또한 이러한 증거는 시간이 많이 걸리고 특별한 기술과 지식이 필요하므로 마감일을 고려하면 실제로 사용할 가능성이 최소화됩니다. 게다가 우리는 정보를 저장, 처리, 전송하기 위해 초고속, 저렴하고 무한히 신뢰할 수 있는 기술을 사용하는 방법을 아직 모릅니다. 그러한 기술이 존재한다면 개념의 형태로 존재하거나, 대부분 공상과학 소설과 영화에만 존재합니다.

훌륭한 예술가는 베끼고 위대한 예술가는 훔칩니다.

-파블로 피카소.

가장 성공적인 솔루션과 놀라울 정도로 간단한 일은 언뜻 보기에 전혀 양립할 수 없는 개념, 기술, 지식, 과학 분야가 만나는 곳에서 흔히 발생합니다.

예를 들어, 새와 비행기에는 날개가 있지만 기능적 유사성에도 불구하고 일부 모드의 작동 원리는 동일하며 기술적 문제는 유사한 방식으로 해결됩니다(중공 뼈, 강하고 가벼운 재료 사용 등). 결과는 매우 유사하지만 완전히 다릅니다. 우리 기술에서 볼 수 있는 가장 좋은 예는 대부분 자연에서 차용한 것입니다. 선박과 잠수함의 압력이 가해진 구획은 환형동물과 직접적인 유사점입니다. RAID 어레이 구축 및 데이터 무결성 확인 - DNA 체인 복제 쌍을 이루는 기관뿐만 아니라 중추 신경계(심장 자동화)와 다른 기관의 작업 독립성 및 반사 신경(인터넷의 자율 시스템)도 포함됩니다. 물론 기성 솔루션을 "직접" 적용하고 적용하는 것은 문제가 많지만 다른 솔루션이 없을 수도 있다는 것을 누가 압니까?

네가 어디로 떨어질지 알았더라면 빨대를 깔았을 텐데!

—벨로루시 민속 속담

이는 다음을 원하는 사람들에게 백업 복사본이 매우 중요하다는 것을 의미합니다.

• 가동 중지 시간을 최소화하거나 전혀 가동 중지 시간 없이 시스템 작동을 복원할 수 있습니다.
• 오류 발생 시 항상 롤백 가능성이 있으므로 과감하게 행동하세요.
• 의도적인 데이터 손상으로 인한 결과 최소화

여기에 약간의 이론이 있습니다.

모든 분류는 임의적입니다. 자연은 분류하지 않습니다. 우리에게 더 편리하기 때문에 분류합니다. 그리고 우리도 임의로 취한 데이터에 따라 분류합니다.

—장 브루러

물리적 저장 방법에 관계없이 논리적 데이터 저장은 이 데이터에 액세스하는 두 가지 방법, 즉 블록과 파일로 나눌 수 있습니다. 순수 블록, 순수 파일 논리 스토리지가 존재하지 않기 때문에 최근 이러한 구분이 매우 모호해졌습니다. 그러나 단순화를 위해 그것들이 존재한다고 가정하겠습니다.

블록 데이터 스토리지는 특정 고정 부분, 즉 블록에 데이터가 기록되는 물리적 장치가 있음을 의미합니다. 블록은 특정 주소에서 액세스되며 각 블록은 장치 내에서 자체 주소를 갖습니다.

백업은 일반적으로 데이터 블록을 복사하여 이루어집니다. 데이터 무결성을 보장하기 위해 복사 시 새 블록의 기록과 기존 블록의 변경 사항이 일시 중지됩니다. 평범한 세계에서 비유하자면, 가장 가까운 것은 동일한 번호의 셀이 있는 벽장입니다.

논리적 장치 원리에 기반한 파일 데이터 저장소는 블록 저장소에 가깝고 상위에 구성되는 경우가 많습니다. 중요한 차이점은 스토리지 계층 구조와 사람이 읽을 수 있는 이름이 있다는 것입니다. 추상화는 명명된 데이터 영역인 파일과 다른 파일에 대한 설명 및 액세스가 저장되는 특수 파일인 디렉토리의 형태로 할당됩니다. 파일에는 생성 시간, 액세스 플래그 등 추가 메타데이터가 제공될 수 있습니다. 백업은 일반적으로 다음과 같은 방식으로 수행됩니다. 변경된 파일을 찾은 다음 동일한 구조를 가진 다른 파일 저장소에 복사합니다. 데이터 무결성은 일반적으로 기록되는 파일이 없을 때 구현됩니다. 파일 메타데이터도 같은 방식으로 백업됩니다. 가장 가까운 비유는 다양한 책이 있는 섹션이 있고 사람이 읽을 수 있는 책 이름이 포함된 카탈로그가 있는 도서관입니다.

최근에는 원칙적으로 파일 데이터 저장이 시작되고 동일한 구식 기능인 객체 데이터 저장을 갖는 또 다른 옵션이 때때로 설명됩니다.

중첩(플랫 구성)이 두 개 이상 없으며 파일 이름은 사람이 읽을 수 있지만 여전히 기계에서 처리하는 데 더 적합하다는 점에서 파일 저장소와 다릅니다. 백업을 수행할 때 객체 스토리지는 파일 스토리지와 유사하게 취급되는 경우가 많지만 때로는 다른 옵션이 있는 경우도 있습니다.

— 시스템 관리자에는 백업을 수행하지 않는 관리자와 이미 백업을 수행한 관리자의 두 가지 유형이 있습니다.
- 실제로는 세 가지 유형이 있습니다. 백업을 복원할 수 있는지 확인하는 사람도 있습니다.

-알려지지 않은

데이터 백업 프로세스 자체가 프로그램에 의해 수행되므로 다른 프로그램과 동일한 단점이 있다는 점도 이해할만한 가치가 있습니다. 개별적으로는 큰 영향을 미치지 않지만 함께 눈에 띄는 효과를 줄 수 있는 기능뿐만 아니라 인적 요소에 대한 의존성을 제거(제거하지 않음!)하려면 소위 규칙 3-2-1. 암호를 해독하는 방법에는 여러 가지 옵션이 있지만 다음과 같은 해석을 선호합니다. 동일한 데이터의 3세트를 저장해야 하고, 2세트는 다른 형식으로 저장해야 하며, 1세트는 지리적으로 원격 저장소에 저장해야 합니다.

저장 형식은 다음과 같이 이해해야 합니다.

• 물리적 저장 방법에 대한 의존성이 있는 경우 물리적 방법을 변경합니다.
• 논리적 저장 방법에 대한 의존성이 있는 경우 논리적 방법을 변경합니다.

3-2-1 규칙의 효과를 극대화하려면 두 가지 방법 모두에서 저장 형식을 변경하는 것이 좋습니다.

의도된 목적(기능 복원)을 위한 백업 준비 상태의 관점에서 "핫" 백업과 "콜드" 백업이 구분됩니다. 핫 버전은 콜드 버전과 한 가지 차이점이 있습니다. 즉시 사용할 수 있는 반면, 콜드 버전은 복호화, 아카이브에서 추출 등 복구를 위한 몇 가지 추가 단계가 필요합니다.

핫 복사본과 콜드 복사본을 온라인 및 오프라인 복사본과 혼동하지 마십시오. 이는 데이터의 물리적 격리를 의미하며 실제로 백업 방법 분류의 또 다른 표시입니다. 따라서 복원해야 하는 시스템에 직접 연결되지 않은 오프라인 복사본은 복구 준비 측면에서 핫 또는 콜드 상태일 수 있습니다. 온라인 사본은 복원이 필요한 곳에서 직접 사용할 수 있으며 가장 자주 핫하지만 콜드 사본도 있습니다.

또한 백업 복사본을 생성하는 프로세스 자체는 일반적으로 하나의 백업 복사본을 생성하는 것으로 끝나지 않으며 상당히 많은 수의 복사본이 있을 수 있다는 점을 잊지 마십시오. 따라서 전체 백업을 구별해야 합니다. 다른 백업과 독립적으로 복원할 수 있는 복사본 및 차등(증분, 차등, 감소 등) 복사본 - 독립적으로 복원할 수 없고 하나 이상의 다른 백업을 예비 복원해야 하는 복사본입니다.

차등 증분 백업은 백업 저장 공간을 절약하려는 시도입니다. 따라서 이전 백업에서 변경된 데이터만 백업 복사본에 기록됩니다.

차등 감소 백업은 동일한 목적으로 생성되지만 약간 다른 방식으로 생성됩니다. 즉, 전체 백업 복사본이 만들어지지만 실제로는 새 복사본과 이전 복사본 간의 차이점만 저장됩니다.

별도로, 중복 저장이 없도록 지원하는 저장 공간에 대한 백업 프로세스를 고려해 볼 가치가 있습니다. 따라서 그 위에 전체 백업을 쓰면 실제로는 백업 간의 차이점만 기록되지만, 백업을 복원하는 과정은 전체 복사본에서 복원하는 것과 비슷하고 완전히 투명합니다.

custodiet ipsos custodes를 종료 하시겠습니까?

(파수꾼을 지키는 사람은 누구입니까? - 위도.)

백업 복사본이 없는 경우는 매우 불쾌하지만, 백업 복사본이 만들어진 것처럼 보이지만 복원 시 다음과 같은 이유로 복원할 수 없는 것으로 밝혀지면 훨씬 더 나쁩니다.

• 소스 데이터의 무결성이 손상되었습니다.
• 백업 저장소가 손상되었습니다.
• 복원 작업은 매우 느리게 진행되므로 부분적으로 복구된 데이터는 사용할 수 없습니다.

적절하게 구성된 백업 프로세스에서는 이러한 설명, 특히 처음 두 가지를 고려해야 합니다.

소스 데이터의 무결성은 여러 가지 방법으로 보장될 수 있습니다. 가장 일반적으로 사용되는 방법은 다음과 같습니다: a) 블록 수준에서 파일 시스템의 스냅샷 생성, b) 파일 시스템 상태 "동결", c) 버전 저장소가 있는 특수 블록 장치, d) 파일의 순차적 기록 또는 블록. 복구 중에 데이터가 검증되었는지 확인하기 위해 체크섬도 적용됩니다.

체크섬을 사용하여 스토리지 손상을 감지할 수도 있습니다. 추가적인 방법은 이미 기록된 데이터를 변경할 수 없지만 새로운 데이터를 추가할 수 있는 특수 장치나 파일 시스템을 사용하는 것입니다.

복구 속도를 높이기 위해 느린 네트워크 또는 느린 디스크 시스템 형태의 병목 현상이 없는 경우 데이터 복구는 여러 복구 프로세스와 함께 사용됩니다. 데이터가 부분적으로 복구된 상황을 해결하려면 백업 프로세스를 상대적으로 작은 하위 작업으로 나누어 각 작업을 개별적으로 수행할 수 있습니다. 따라서 복구 시간을 예측하면서 지속적으로 성능을 복원하는 것이 가능해집니다. 이 문제는 대부분 조직 평면(SLA)에 있으므로 이에 대해서는 자세히 설명하지 않겠습니다.

향신료 전문가는 모든 요리에 향신료를 첨가하는 사람이 아니라, 아무것도 추가하지 않는 사람입니다.

-안에. 신야브스키

시스템 관리자가 사용하는 소프트웨어에 관한 관행은 다양할 수 있지만 일반적인 원칙은 어떤 식으로든 동일합니다. 특히 다음과 같습니다.

• 기성 솔루션을 사용하는 것이 좋습니다.
• 프로그램은 예측 가능하게 작동해야 합니다. 문서화되지 않은 기능이나 병목 현상이 없어야 합니다.
• 각 프로그램의 설정은 매번 매뉴얼이나 치트 시트를 읽을 필요가 없을 정도로 간단해야 합니다.
• 가능하다면 솔루션은 보편적이어야 합니다. 서버는 하드웨어 특성이 크게 다를 수 있습니다.

블록 장치에서 백업을 수행하기 위한 일반적인 프로그램은 다음과 같습니다.

• dd, 시스템 관리 베테랑에게 친숙한 여기에는 유사한 프로그램(예: 동일한 dd_rescue)도 포함됩니다.
• 파일 시스템의 덤프를 생성하는 일부 파일 시스템에 내장된 유틸리티입니다.
• 잡식성 유틸리티; 예를 들어 부분클론.
• 자신의, 종종 독점적인 결정을 내립니다. 예를 들어 NortonGhost 이상입니다.

파일 시스템의 경우 백업 문제는 블록 장치에 적용 가능한 방법을 사용하여 부분적으로 해결되지만 다음과 같은 방법을 사용하면 문제를 보다 효율적으로 해결할 수 있습니다.

• Rsync는 파일 시스템 상태를 동기화하기 위한 범용 프로그램 및 프로토콜입니다.
• 내장 보관 도구(ZFS).
• 타사 보관 도구 가장 인기있는 대표자는 tar입니다. 예를 들어 현대 시스템을 겨냥한 tar를 대체하는 dar와 같은 다른 것도 있습니다.

별도로, 백업 복사본을 생성할 때 데이터 일관성을 보장하기 위한 소프트웨어 도구를 언급할 가치가 있습니다. 가장 일반적으로 사용되는 옵션은 다음과 같습니다.

• 읽기 전용 모드(ReadOnly)로 파일 시스템 마운트 또는 파일 시스템 고정(freeze) - 이 방법은 적용이 제한되어 있습니다.
• 파일 시스템 또는 블록 장치(LVM, ZFS) 상태의 스냅샷을 생성합니다.
• 어떤 이유로 이전 포인트를 제공할 수 없는 경우(핫카피와 같은 프로그램)에도 노출 구성을 위해 제XNUMX자 도구를 사용합니다.
• 그러나 변경 시 복사 기술(CopyOnWrite)은 사용되는 파일 시스템(BTRFS, ZFS)과 가장 자주 연결됩니다.

따라서 소규모 서버의 경우 다음 요구 사항을 충족하는 백업 구성표를 제공해야 합니다.

• 사용하기 쉬움 - 작동 중에 특별한 추가 단계가 필요하지 않으며 복사본을 만들고 복원하는 데 최소한의 단계가 필요합니다.
• 범용 - 대형 및 소형 서버 모두에서 작동합니다. 이는 서버 수를 늘리거나 확장할 때 중요합니다.
• 패키지 관리자에 의해 설치되거나 "다운로드 및 압축 풀기"와 같은 하나 또는 두 개의 명령으로 설치됩니다.
• 안정적 - 표준 또는 오랫동안 확립된 저장 형식이 사용됩니다.
• 작업 속도가 빠릅니다.

요구 사항을 어느 정도 충족하는 지원자:

• rdiff 백업
• rsnapshot
• 트림
• 복제하다
• 이중성
• 복제하자
• 다르
• zbackup
• 소박한
• 보그백업

다음 특성을 가진 가상 머신(XenServer 기반)이 테스트 벤치로 사용됩니다.

• 4코어 2.5GHz,
• 16GB RAM,
• 파티셔닝 없이 별도의 가상 디스크 형태로 50GB 하이브리드 스토리지(가상 디스크 크기의 20%를 SSD에 캐싱하는 스토리지 시스템),
• 200Mbits 인터넷 채널.

거의 동일한 시스템이 백업 수신 서버로 사용되며 500GB 하드 드라이브만 사용됩니다.

운영 체제 - Centos 7 x64: 표준 파티션, 추가 파티션이 데이터 소스로 사용됩니다.

초기 데이터로 40GB의 미디어 파일과 mysql 데이터베이스가 있는 WordPress 사이트를 사용하겠습니다. 가상 서버는 특성이 매우 다양하고 재현성을 높이기 위해 다음과 같습니다.

sysbench를 이용한 서버 테스트 결과.sysbench --threads=4 --time=30 --cpu-max-prime=20000 CPU 실행
sysbench 1.1.0-18a9f86(번들 LuaJIT 2.1.0-beta3 사용)
다음 옵션을 사용하여 테스트 실행 :
스레드 수 : 4
현재 시간부터 난수 생성기 초기화 중

소수 제한: 20000

작업자 스레드 초기화 중…

스레드가 시작되었습니다!

CPU 속도:
초당 이벤트: 836.69

처리량 :
이벤트/초(eps): 836.6908
경과 시간: 30.0039s
총 이벤트 수: 25104

지연 시간(밀리초):
최소 : 2.38
평균: 4.78
최대 : 22.39
95번째 백분위수: 10.46
합계 : 119923.64

스레드 공정성 :
이벤트(평균/표준편차): 6276.0000/13.91
실행 시간(평균/stddev): 29.9809/0.01

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=읽기 메모리 실행
sysbench 1.1.0-18a9f86(번들 LuaJIT 2.1.0-beta3 사용)
다음 옵션을 사용하여 테스트 실행 :
스레드 수 : 4
현재 시간부터 난수 생성기 초기화 중

다음 옵션을 사용하여 메모리 속도 테스트를 실행합니다.
블록 크기: 1KiB
총 크기: 102400MiB
작업: 읽기
범위: 글로벌

작업자 스레드 초기화 중…

스레드가 시작되었습니다!

총 작업: 50900446(초당 1696677.10)

49707.47MiB 전송(1656.91MiB/초)

처리량 :
이벤트/초(eps): 1696677.1017
경과 시간: 30.0001s
총 이벤트 수: 50900446

지연 시간(밀리초):
최소 : 0.00
평균: 0.00
최대 : 24.01
95번째 백분위수: 0.00
합계 : 39106.74

스레드 공정성 :
이벤트(평균/표준편차): 12725111.5000/137775.15
실행 시간(평균/stddev): 9.7767/0.10

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=메모리 실행 쓰기
sysbench 1.1.0-18a9f86(번들 LuaJIT 2.1.0-beta3 사용)
다음 옵션을 사용하여 테스트 실행 :
스레드 수 : 4
현재 시간부터 난수 생성기 초기화 중

다음 옵션을 사용하여 메모리 속도 테스트를 실행합니다.
블록 크기: 1KiB
총 크기: 102400MiB
작업: 쓰기
범위: 글로벌

작업자 스레드 초기화 중…

스레드가 시작되었습니다!

총 작업: 35910413(초당 1197008.62)

35068.76MiB 전송(1168.95MiB/초)

처리량 :
이벤트/초(eps): 1197008.6179
경과 시간: 30.0001s
총 이벤트 수: 35910413

지연 시간(밀리초):
최소 : 0.00
평균: 0.00
최대 : 16.90
95번째 백분위수: 0.00
합계 : 43604.83

스레드 공정성 :
이벤트(평균/표준편차): 8977603.2500/233905.84
실행 시간(평균/stddev): 10.9012/0.41

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio 실행
sysbench 1.1.0-18a9f86(번들 LuaJIT 2.1.0-beta3 사용)
다음 옵션을 사용하여 테스트 실행 :
스레드 수 : 4
현재 시간부터 난수 생성기 초기화 중

추가 파일 열기 플래그: (없음)
파일 128개, 각 8MiB
총 파일 크기 1GiB
블록 크기 4KiB
IO 요청 수: 0
결합된 무작위 IO 테스트의 읽기/쓰기 비율: 1.50
주기적 FSYNC가 활성화되어 100개 요청마다 fsync()를 호출합니다.
테스트가 끝나면 fsync()를 호출하고 활성화됩니다.
동기 I/O 모드 사용
무작위 r/w 테스트 수행 중
작업자 스레드 초기화 중…

스레드가 시작되었습니다!

처리량 :
읽기: IOPS=3868.21 15.11MiB/s(15.84MB/s)
쓰기: IOPS=2578.83 10.07MiB/s(10.56MB/s)
fsync: IOPS=8226.98

지연 시간(밀리초):
최소 : 0.00
평균: 0.27
최대 : 18.01
95번째 백분위수: 1.08
합계 : 238469.45

이 메모는 큰 의미로 시작됩니다

백업에 관한 기사 시리즈

1. 백업, 파트 1: 백업이 필요한 이유, 방법 및 기술 개요
2. 백업 2부: rsync 기반 백업 도구 검토 및 테스트
3. 백업 파트 3: 이중성 검토 및 테스트, 이중성, deja dup
4. 백업 파트 4: zbackup, restic, borgbackup 검토 및 테스트
5. 백업 파트 5: Linux용 bacula 및 veeam 백업 테스트
6. 백업 파트 6: 백업 도구 비교
7. 백업 파트 7: 결론

출처 : habr.com