홈 VM 백업을 위한 원격 백업 서버와 클라우드 객체 스토리지 비교

빠른 전체 복구, 잦은 증분 작업, 예측 가능한 저장소 동작, 전체 복구 스택에 대한 제어가 필요하다면 원격 백업 서버가 일반적으로 더 나은 홈 VM 대상입니다. 지리적 분리와 두 번째 서버를 유지 관리 목록에서 제외하는 것이 로컬 제어보다 중요하다면 클라우드 객체 스토리지가 일반적으로 더 강력합니다. 결정은 복구 규모, 업스트림 대역폭, 객체 스토리지의 검색 동작, 불변성 요구 사항, 그리고 오프사이트에서 어느 정도의 인프라를 운영할 의향이 있는지에 따라 달라집니다.

대상을 선택하기 전에 VM 복구 작업을 정의하세요

VM 백업은 단순한 문서 폴더가 아닙니다. 장애가 발생한 홈 하이퍼바이저를 복구하려면 디스크 이미지, VM 구성, 게스트 메타데이터, 암호화 자료, 네트워크 정보, 그리고 여러 대형 게스트를 올바른 순서로 재구축할 수 있는 충분한 처리량이 필요할 수 있습니다.

Proxmox는 백업 통합 기능을 통해 가상 머신과 컨테이너의 예약 백업을 생성할 수 있다고 설명하며, Proxmox Backup Server는 중복 제거 백업 인프라를 추가합니다. 따라서 대상 선택은 일반적인 파일 저장이 아니라 전체 VM 복구 워크플로의 일부가 됩니다.

먼저 통제하려는 결과를 정하세요. 몇 테라바이트를 복구해야 하는지, 첫 번째 핵심 VM을 얼마나 빨리 부팅해야 하는지, 완전한 사이트 손실이 위협 모델에 포함되는지를 정해야 합니다. 이러한 답변에 따라 접근 가능한 서버가 더 어려운 제약을 해결하는지, 아니면 공급자가 운영하는 객체 스토리지가 더 적합한지가 결정됩니다.

대규모 복구를 즉시 시작해야 한다면 원격 백업 서버가 유리합니다

신뢰할 수 있는 다른 위치에 서버를 두면 아카이브 계층의 재수화를 기다리지 않고 백업 형식을 온라인 상태로 유지하여 복구할 수 있습니다. 사이트 간 연결 속도가 충분하다면 기본 홈 랩과 동일한 도구를 사용해 잦은 증분 백업과 저장소 검증도 수행할 수 있습니다.

이 모델에서는 캐시, 네트워크 경로, 보존 정책, 디스크 교체, 저장소 소프트웨어를 직접 제어할 수 있습니다. 몇 개의 파일이 아니라 전체 VM을 복구할 가능성이 높을 때 특히 유용합니다. 복구 대상에 지속적으로 주소를 지정할 수 있기 때문입니다.

숨은 비용은 “오프사이트 백업”이 직접 소유한 또 하나의 서버가 된다는 점입니다. 원격 노드 자체를 위해 전원, 네트워크, 물리적 공간, 업데이트, 모니터링, 드라이브 교체, 복구 계획을 제공해야 합니다. 이러한 운영 작업이 실제 RTO 개선으로 이어질 때만 이 방식이 매력적입니다.

두 번째 사이트를 없애는 것이 우선이라면 클라우드 객체 스토리지가 유리합니다

객체 스토리지는 원격 섀시, 디스크, UPS, 가정용 네트워크 의존성을 공급자가 관리하는 스토리지 서비스로 대체합니다. 따라서 친구나 친척에게 두 번째 장비를 맡기지 않고도 명확한 지리적 분리를 구축할 수 있습니다.

Amazon S3는 백업 객체를 다른 계층으로 이동하거나 만료시키는 수명 주기 정책을 지원하며, 다른 객체 스토리지 공급자도 유사한 정책 기능을 제공합니다. 중요한 운영상의 이점은 특정 공급자의 기능 목록이 아니라, 미디어 교체와 스토리지 하드웨어 유지 관리가 더 이상 사용자의 작업이 아니라는 점입니다.

복구가 드물고 WAN 업로드를 감당할 수 있으며 백업 애플리케이션이 공급자를 안전하게 사용할 수 있다면 클라우드 객체 스토리지가 더 적합합니다. 수 테라바이트 규모의 전체 복구가 긴급하거나 공급자 검색 및 네트워크 전송 동작이 복구 시간을 좌우한다면 매력도가 떨어집니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

검색 클래스에 따라 다운로드를 시작하기 전부터 클라우드 RTO가 달라질 수 있습니다

모든 클라우드 객체를 즉시 읽을 수 있는 것은 아닙니다. 저렴한 아카이브 클래스는 데이터를 사용할 수 있게 되기 전에 복원 요청이 필요할 수 있으므로, “클라우드에 저장됨”이 자동으로 “지금 바로 스트리밍하여 되돌릴 수 있음”을 의미하지는 않습니다.

AWS는 아카이브 계층의 검색 시간이 몇 분에서 수 시간까지 걸릴 수 있다고 설명합니다. VM 저장소를 아카이브 클래스에 배치한다면 인터넷 다운로드 시간은 계산하기도 전에 그 대기 시간을 RTO에 포함해야 합니다.

빠르게 부팅해야 하는 복구 지점에는 즉시 액세스 가능한 스토리지를 사용하고, 지연을 허용할 수 있는 세대만 아카이브하세요. 딥 아카이브의 낮은 스토리지 비용과 즉시 준비된 원격 서버의 속도를 동시에 원한다면 요구 사항이 충돌하는 것이므로 계층을 나누어야 합니다.

불변성과 자격 증명 분리는 보안 측면의 우위를 뒤집을 수 있습니다

기본 랩과 동일한 관리자 자격 증명으로 원격 서버를 운영하면 관리하기는 쉽지만, 동일한 손상된 제어 플레인에서 파괴하기도 쉬워집니다. 보존 잠금과 제한된 자격 증명을 올바르게 구성하면 클라우드 객체 스토리지가 더 강력한 경계를 만들 수 있습니다.

Backblaze는 수명 주기 제어와 함께 보존 기간 동안 삭제 또는 수정을 제한하는 Object Lock을 문서화하고 있습니다. 가치는 “클라우드”라는 단어가 아니라 독립적으로 적용되는 보존 경계에서 나옵니다.

추가 전용 저장소, 별도 계정, 방화벽 제한, 오프라인 복구 자격 증명을 사용하면 원격 서버에서도 강력한 분리를 구현할 수 있습니다. 기본 시스템이 손상된 상황에서 실제로 격리를 입증할 수 있는 아키텍처를 선택하세요.

저장소가 커질수록 객체 스토리지 비용과 네트워크 정책이 중요해집니다

클라우드는 드라이브 구매를 없애지만 저장 용량, 작업 수, 스토리지 클래스, 경우에 따라 검색 또는 이그레스 비용과 같은 공급자 청구 항목을 추가합니다. 원격 서버는 더 많은 비용을 하드웨어, 디스크, 전력, 교체 작업에 선투입하게 합니다.

Cloudflare R2는 스토리지 및 요청 과금 항목을 공개하고 있으며, 이는 객체 스토리지를 일회성 디스크 구매가 아니라 지속적인 서비스로 모델링해야 하는 이유를 보여줍니다. 수년간의 VM 기록을 보관할 아키텍처에 현재 공급자 가격을 그대로 적용하지 마세요.

복구량과 반복 액세스가 증가할수록, 사이트와 하드웨어가 안정적으로 유지된다는 전제하에 원격 서버가 더 매력적입니다. 저장소에 대부분 한 번만 기록하고 복구가 드물며 다른 물리 시스템을 피하는 가치가 크다면 클라우드가 더 유리합니다.

백업 대상의 이름보다 복구 테스트가 중요합니다

원격 서버는 불량 디스크, 오래된 자격 증명, 중단된 동기화, 누락된 VM 메타데이터로 인해 조용히 장애가 발생할 수 있습니다. 클라우드 객체 스토리지는 만료된 자격 증명, 호환되지 않는 저장소 소프트웨어, 분실한 암호화 키, 테스트하지 않은 검색 가정으로 인해 운영상 문제가 발생할 수 있습니다.

Restic의 복구 문서는 대규모 복구에는 탐색만 하는 방식보다 전체 스냅샷 복구를 사용할 것을 권장합니다. 대상과 관계없이 핵심 원칙은 저장소 목록만 확인하는 것이 아니라 실제 VM 복구 훈련을 수행하는 것입니다.

가상화된 스토리지와 관련된 호스트 복구 의존성에 대한 ZimaSpace 복구 비교 글도 유용한 참고 자료입니다. 테스트한 RTO, 격리 요구 사항, 유지 관리 예산, 문서화된 복구 경로를 충족하는 아키텍처가 하나라도 있다면 그 이후에는 대상을 계속 비교하지 마세요.

최악의 허용 가능한 복구를 지루할 정도로 평범하게 만드는 대상을 선택하세요

공급자 아카이브 지연 없이 대규모 VM 복구를 시작해야 하고, 백업 스택과의 긴밀한 통합을 중시하며, 두 번째 물리 시스템과 사이트를 유지 관리할 의향이 있다면 원격 백업 서버를 선택하세요.

지리적 분리와 원격 하드웨어 유지 관리 제거가 최대한의 제어보다 중요하고, 예상 복구량이 공급자의 액세스 모델과 인터넷 연결에 적합하다면 클라우드 객체 스토리지를 선택하세요.

중요한 홈 VM에는 하이브리드 방식이 적합할 수 있습니다. 최근 복구 지점은 즉시 사용할 수 있는 원격 서버에 보관하고, 오래된 불변 세대는 객체 스토리지에 보관하는 방식입니다. 두 계층이 서로 다른 RTO 또는 장애 요구 사항을 실제로 보호할 때만 이러한 복잡성을 추가하세요.