백업 파트 7: 결론

이 메모는 백업에 대한 주기를 완료합니다. 백업에 편리한 전용 서버(또는 VPS)의 논리적 구성에 대해 논의하고, 재해 발생 시 큰 다운타임 없이 백업에서 서버를 신속하게 복원할 수 있는 옵션도 제공합니다.

원시 데이터

전용 서버에는 첫 번째 수준 RAID 어레이(미러)를 구성하는 데 사용되는 하드 드라이브가 8개 이상 있는 경우가 가장 많습니다. 이는 하나의 디스크에 장애가 발생하더라도 서버를 계속 운영할 수 있도록 하기 위해 필요합니다. 일반 전용 서버인 경우 SSD에 활성 캐싱 기술이 적용된 별도의 하드웨어 RAID 컨트롤러가 있을 수 있으므로 일반 하드 드라이브 외에 하나 이상의 SSD를 연결할 수 있습니다. 때로는 로컬 디스크에 SATADOM(소형 디스크, 구조적으로 SATA 포트에 연결된 플래시 드라이브)만 포함되거나 특수 내부 포트에 연결된 일반 소형(16-10GB) 플래시 드라이브만 포함되는 전용 서버가 제공되는 경우도 있습니다. 데이터는 전용 스토리지 네트워크(이더넷 100G, FC 등)를 통해 연결된 스토리지 시스템에서 가져오며, 스토리지 시스템에서 직접 로드되는 전용 서버가 있습니다. 이러한 경우 서버 백업 작업은 스토리지 시스템을 유지 관리하는 전문가에게 원활하게 전달되므로 이러한 옵션은 고려하지 않겠습니다. 일반적으로 스냅샷 생성, 내장 중복 제거 및 기타 시스템 관리자의 즐거움을 위한 다양한 독점 기술이 있습니다. , 이 시리즈의 이전 부분에서 논의되었습니다. 전용 서버의 디스크 어레이 볼륨은 서버에 연결된 디스크 수와 크기에 따라 수십 테라바이트에 이를 수 있습니다. VPS의 경우 볼륨은 더 적당합니다. 일반적으로 XNUMXGB를 넘지 않지만 그 이상도 가능하며 이러한 VPS에 대한 요금은 동일한 호스팅 업체의 가장 저렴한 전용 서버보다 쉽게 ​​비쌀 수 있습니다. VPS에는 대부분 하나의 디스크가 있습니다. 왜냐하면 그 아래에 스토리지 시스템(또는 하이퍼컨버지드)이 있기 때문입니다. 때때로 VPS에는 다양한 목적을 위해 다양한 특성을 가진 여러 디스크가 있습니다.

• 소규모 시스템 - 운영 체제 설치용.
• 대형 - 사용자 데이터를 저장합니다.

제어판을 사용하여 시스템을 다시 설치하면 사용자 데이터가 있는 디스크는 덮어쓰이지 않지만 시스템 디스크는 완전히 리필됩니다. 또한 VPS의 경우 호스팅 업체는 VPS(또는 디스크) 상태의 스냅샷을 찍는 버튼을 제공할 수 있지만, 자체 운영 체제를 설치하거나 VPS 내부에서 원하는 서비스를 활성화하는 것을 잊어버린 경우 일부 일부 데이터는 여전히 손실될 수 있습니다. 버튼 외에도 일반적으로 데이터 저장 서비스가 제공되지만 대부분 매우 제한적입니다. 이는 일반적으로 FTP 또는 SFTP를 통해 액세스할 수 있는 계정이며, 때로는 SSH와 함께, 간단한 셸(예: rbash)을 사용하거나 Authorized_keys(ForcedCommand를 통해)를 통해 명령 실행을 제한하는 계정입니다.

전용 서버는 1Gbps 속도의 두 포트로 네트워크에 연결되며 때로는 10Gbps 속도의 카드일 수도 있습니다. VPS에는 대부분 하나의 네트워크 인터페이스가 있습니다. 대부분의 경우 데이터 센터는 데이터 센터 내 네트워크 속도를 제한하지 않지만 인터넷 액세스 속도를 제한합니다.

이러한 전용 서버 또는 VPS의 일반적인 부하는 웹 서버, 데이터베이스 및 애플리케이션 서버입니다. 때로는 웹 서버 또는 데이터베이스(검색 엔진, 메일 시스템 등)를 포함하여 다양한 추가 보조 서비스가 설치될 수 있습니다.

특별히 준비된 서버는 백업 복사본을 저장하는 공간 역할을 하며 이에 대해서는 나중에 자세히 작성하겠습니다.

디스크 시스템의 논리적 구성

RAID 컨트롤러 또는 하나의 디스크가 있는 VPS가 있고 디스크 하위 시스템의 작동에 대한 특별한 기본 설정(예: 데이터베이스용 별도의 빠른 디스크)이 없는 경우 모든 여유 공간은 다음과 같이 나뉩니다. 하나의 파티션 생성되고 그 위에 LVM 볼륨 그룹이 생성되고 그 안에 여러 볼륨이 생성됩니다. 루트 파일 시스템으로 사용되는 동일한 크기의 작은 볼륨 2개(빠른 롤백 가능성을 위해 업데이트 중에 하나씩 변경됨) 아이디어는 Calculate Linux 배포판에서 따왔습니다), 또 다른 하나는 스왑 파티션용이고 나머지 여유 공간은 작은 볼륨으로 나누어져 본격적인 컨테이너용 루트 파일 시스템, 가상 머신용 디스크, 파일 /home의 계정용 시스템(각 계정에는 자체 파일 시스템이 있음), 애플리케이션 컨테이너용 파일 시스템.

중요 사항: 볼륨은 완전히 독립적이어야 합니다. 서로 의존하거나 루트 파일 시스템에 의존해서는 안 됩니다. 가상 머신이나 컨테이너의 경우 이 지점이 자동으로 관찰됩니다. 애플리케이션 컨테이너나 홈 디렉터리인 경우 볼륨 간의 종속성을 최대한 제거하는 방식으로 웹 서버와 기타 서비스의 구성 파일을 분리하는 것을 고려해야 합니다. 예를 들어 각 사이트는 자체 사용자에 의해 실행되고 사이트 구성 파일은 사용자의 홈 디렉터리에 있으며 웹 서버 설정에서 사이트 구성 파일은 /etc/nginx/conf.d/를 통해 포함되지 않습니다..conf 및 예: /home//configs/nginx/*.conf

디스크가 여러 개 있는 경우 소프트웨어 RAID 어레이를 생성할 수 있으며(필요와 기회가 있는 경우 SSD에 캐싱을 구성) 그 위에 위에서 제안한 규칙에 따라 LVM을 구축할 수 있습니다. 이 경우에도 ZFS 또는 BtrFS를 사용할 수 있지만 이에 대해 다시 생각해야 합니다. 둘 다 리소스에 대해 훨씬 더 진지한 접근 방식이 필요하며 게다가 ZFS는 Linux 커널에 포함되어 있지 않습니다.

사용된 구성표에 관계없이 항상 변경 사항을 디스크에 기록하는 대략적인 속도를 미리 추정한 다음 스냅샷 생성을 위해 예약될 여유 공간의 양을 계산하는 것이 좋습니다. 예를 들어, 서버가 초당 10MB의 속도로 데이터를 쓰고 전체 데이터 배열의 크기가 10TB인 경우 동기화 시간은 하루(22시간)에 도달할 수 있습니다. 이는 해당 볼륨이 전송되는 양입니다. 네트워크를 통해 1Gbps) - 약 800GB를 예약할 가치가 있습니다. 실제로는 이 수치가 더 작으므로 논리 볼륨 수로 안전하게 나눌 수 있습니다.

백업 스토리지 서버 장치

백업 복사본을 저장하는 서버의 주요 차이점은 크고 저렴하며 상대적으로 느린 디스크입니다. 최신 HDD는 이미 하나의 디스크에서 10TB 기준을 넘었으므로 체크섬이 있는 파일 시스템이나 RAID를 사용해야 합니다. 왜냐하면 어레이를 재구축하거나 파일 시스템을 복원하는 동안(며칠!) 두 번째 디스크가 오류로 인해 실패할 수 있기 때문입니다. 부하가 증가합니다. 최대 1TB 용량의 디스크에서는 그다지 민감하지 않았습니다. 설명을 단순화하기 위해 디스크 공간이 대략 동일한 크기의 두 부분으로 나누어져 있다고 가정합니다(예: LVM 사용).

• 사용자 데이터를 저장하는 데 사용되는 서버에 해당하는 볼륨(마지막 백업은 확인을 위해 해당 서버에 배포됩니다)
• BorgBackup 리포지토리로 사용되는 볼륨(백업 데이터는 여기에 직접 이동됩니다)

작동 원리는 BorgBackup 저장소의 각 서버마다 별도의 볼륨이 생성되어 전투 서버의 데이터가 이동하는 것입니다. 리포지토리는 의도적으로 데이터를 삭제할 가능성을 제거하는 추가 전용 모드로 작동하며 오래된 백업에서 리포지토리의 중복 제거 및 주기적인 정리로 인해(연간 복사본은 지난 해에는 매월, 지난 달에는 매주, 다음 달에는 매일 유지됩니다) 지난 주, 특별한 경우 가능 - 마지막 날의 시간별: 총 24 + 7 + 4 + 12 + 연간 - 각 서버당 약 50개 복사본).
BorgBackup 리포지토리는 추가 전용 모드를 활성화하지 않습니다. 대신 .ssh/authorized_keys의 ForcedCommand가 다음과 같이 사용됩니다.

from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......

지정된 경로에는 매개변수를 사용하여 바이너리를 시작하는 것 외에도 데이터가 제거된 후 백업 복사본을 복원하는 프로세스를 추가로 시작하는 borg 위에 래퍼 스크립트가 포함되어 있습니다. 이를 위해 래퍼 스크립트는 해당 저장소 옆에 태그 파일을 생성합니다. 마지막 백업은 데이터 채우기 과정이 완료된 후 해당 논리 볼륨에 자동으로 복원됩니다.

이 설계를 통해 불필요한 백업을 주기적으로 정리할 수 있으며 전투 서버가 백업 스토리지 서버의 모든 항목을 삭제하는 것을 방지할 수도 있습니다.

백업 프로세스

백업 시작자는 전용 서버 또는 VPS 자체입니다. 이 구성표를 사용하면 이 서버 측의 백업 프로세스를 더 효과적으로 제어할 수 있기 때문입니다. 먼저, BorgBackup을 사용하여 백업 스토리지 서버에 마운트 및 업로드되는 활성 루트 파일 시스템 상태의 스냅샷이 생성됩니다. 데이터 캡처가 완료되면 스냅샷이 마운트 해제되고 삭제됩니다.

작은 데이터베이스(사이트당 최대 1GB)가 있는 경우 데이터베이스 덤프가 생성되어 동일한 사이트의 나머지 데이터가 있는 적절한 논리 볼륨에 저장되지만 덤프는 웹 서버를 통해 접근할 수 없습니다. 데이터베이스가 큰 경우 예를 들어 MySQL용 xtrabackup을 사용하거나 PostgreSQL에서 archive_command를 사용하여 WAL을 사용하여 "핫" 데이터 제거를 구성해야 합니다. 이 경우 데이터베이스는 사이트 데이터와 별도로 복원됩니다.

컨테이너나 가상 머신을 사용하는 경우 qemu-guest-agent, CRIU 또는 기타 필요한 기술을 구성해야 합니다. 다른 경우에는 추가 설정이 대부분 필요하지 않습니다. 간단히 논리 볼륨의 스냅샷을 생성한 다음 루트 파일 시스템 상태의 스냅샷과 동일한 방식으로 처리합니다. 데이터 촬영 후 사진은 삭제됩니다.

백업 스토리지 서버에서 추가 작업이 수행됩니다.

• 각 저장소의 마지막 백업을 확인합니다.
• 마크 파일의 존재 여부를 확인하여 데이터 수집 프로세스가 완료되었음을 나타냅니다.
• 데이터는 해당 로컬 볼륨으로 확장됩니다.
• 태그 파일이 삭제되었습니다

서버 복구 프로세스

메인 서버가 종료되면 유사한 전용 서버가 시작되어 일부 표준 이미지에서 부팅됩니다. 대부분 다운로드는 네트워크를 통해 이루어지지만 서버를 설정하는 데이터 센터 기술자는 이 표준 이미지를 디스크 중 하나에 즉시 복사할 수 있습니다. 다운로드가 RAM으로 수행된 후 복구 프로세스가 시작됩니다.

• iscsinbd 또는 다른 유사한 프로토콜을 통해 죽은 서버의 루트 파일 시스템이 포함된 논리 볼륨에 블록 장치를 연결하라는 요청이 이루어집니다. 루트 파일 시스템은 작아야 하므로 이 단계는 몇 분 안에 완료되어야 합니다. 부트로더도 복원됩니다.
• 로컬 논리 볼륨의 구조가 다시 생성되고 dm_clone 커널 모듈을 사용하여 백업 서버에서 논리 볼륨이 연결됩니다. 데이터 복구가 시작되고 변경 사항이 즉시 로컬 디스크에 기록됩니다.
• 사용 가능한 모든 물리적 디스크를 사용하여 컨테이너가 시작됩니다. 서버의 기능은 완전히 복원되지만 성능은 저하됩니다.
• 데이터 동기화가 완료된 후 백업 서버의 논리 볼륨 연결이 끊어지고 컨테이너가 꺼지며 서버가 재부팅됩니다.

재부팅 후 서버는 백업이 생성된 시점에 있던 모든 데이터를 갖게 되며 복원 프로세스 중에 적용된 모든 변경 사항도 포함하게 됩니다.

시리즈의 다른 기사

백업, 파트 1: 백업이 필요한 이유, 방법 및 기술 개요
백업 2부: rsync 기반 백업 도구 검토 및 테스트
백업 파트 3: 이중성 검토 및 테스트
백업 파트 4: zbackup, restic, borgbackup 검토 및 테스트
백업 5부: Linux용 Bacula 및 Veeam Backup 테스트
백업: 독자의 요청에 따른 부분: AMANDA, UrBackup, BackupPC 검토
백업 파트 6: 백업 도구 비교
백업 파트 7: 결론

댓글에서 제안된 옵션에 대해 논의해 보시기 바랍니다. 관심을 가져주셔서 감사합니다!

출처 : habr.com