백업 전략 회고 (2025)

작년에서 올해에 걸친 여러 차례의 백업 전략 변경은 나름 신경 쓰고 있다고 생각한 백업에 큰 오점이 되었습니다. 장기간에 걸쳐 낮은 비용으로 안정적인 백업을 하고 실제 이를 필요로 하는 상황이 되었을 때 예측 가능한 시점애 복원을 마칠 수 있어야 한다는 짧고 단순한 목표는 개인 입장에서 달성하기 상당히 어려웠고 다들 백업이 중요하다고 이야기하지만 여전히 개인 사용자 수준에서도 낮은 비용으로 장기간에 걸쳐 안정적으로 백업할 방식을 찾기는 굉장히 어렵다는 생각이 들었습니다. 물론 홈랩을 운영하는 등 일반적으로 개인용 솔루션을 개발하는 여러 회사들이 생각하는 일반적인 개인의 페르소나에 완전히 일치하지는 않을 거라는 사실을 인정합니다. 하지만 그들이 생각하고 있을는지도 모르는 그 일반적인 개인의 범위에서 아주 조금만 벗어나도 백업이 아주 골아프고 힘들어진다는 점이 달라지지는 않았습니다. 오늘은 연말을 맞이해 올해 유난히 많이 겪은 백업 방식의 변경과 백업 서비스의 변경, 각각의 장단점, 서비스 교체를 결정하게 된 계기, 그리고 현재 최종 상태를 살펴보고 앞으로 개선할 방향도 생각해보겠습니다. 만약 이미 백업을 나름 잘 하고 있다고 생각하시는 분들이라면 이런 사례도 있다는 관점에서 봐 주시면 되고 유일한 스토리지에 유일한 데이터를 저장하고 계시다면 이 이야기는 별 의미 없을 수 있습니다. 여튼 시작합니다.

백업 원칙은 특별할 것이 없습니다. 그저 흔한 3-2-1 규칙[^Backup]을 지키는 것 뿐입니다. 다만 현실적으로 지키지 불가능한 부분은 임의로 수정했습니다. 일단 최소 세 개의 복사본이 있어야 하고 이는 사용 중인 소위 원본을 포함합니다. 그러니까 내 컴퓨터에 스토리지가 달려있다면 복사본 세 개 중 이미 한 개를 가지고 있는 상태이니 복사본 두 개를 더 확보하기만 하면 복사본 3개를 만족할 수 있습니다. 다음은 적어도 두 가지 미디어를 사용해야 하는 것입니다. 과거에는 이 규칙이 말 그대로 서로 다른 종류의 미디어를 가리켰습니다. 가령 복사본 중 하나는 자기 기록 방식인 하드디스크를 사용한다면 다른 하나는 광학 기록 방식을 사용하는 옵티컬 디스크류에 기록하는 식입니다. 하지만 현대에 자기 기록 방식인 하드디스크가 기하급수적으로 발전했고 또 백업이 필요한 데이터 크기 역시 늘어났습니다. 반면 자기 기록 방식이 아닌 나머지 기록 방식의 발전은 필요에 비해 심각하게 더딥니다. 광학 방식은 적어도 개인 사용자 입장에서는 완전히 소멸했고 같은 자기 기록 방식 중 콜드스토리지에 주로 사용되는 LTO[^Linear Tape-Open]는 개인이 접근하기에 가격이 너무 높고 또 관리 복잡도 역시 너무 높습니다. 이런 상황에서 두 가지 다른 미디어에 복사본을 유지하는 것은 사실상 실천 불가능합니다. 그래서 두 가지 미디어는 두 곳 이상의 스로 다른 스토리지에 독립적으로 백업을 유지하는 것으로 변경했습니다. 마지막으로 그런 두 곳 중 하나는 물리적으로 완전히 다른 장소여야 합니다. 원본과 모든 백업이 같은 장소에 있다면 화재나 도난이 발생하면 백업 역할을 할 수 없게 됩니다. 그래서 복사본 세 개 중 하나는 물리적으로 완전히 독립된 위치에 있어야 하고 여기에는 외부 서비스를 사용합니다. 지난 크래시플랜을 사용하지 마세요에서 소개한 크래시플랜 역시 이런 오프사이트 백업을 제공하는 곳이었습니다.

기계를 여러 대 사용합니다. 일단 게임 용도가 핵심이지만 글도 쓰고 영상도 보고 이것 저것 다양한 역할을 하는 메인 윈도우 기계가 있습니다. 랩탑이 두 개 있고 홈랩도 있습니다. 여기까지만 해도 이미 윈도우 기계 하나, 맥이 세 개입니다. 이들을 모두 제각각 백업하는 것은 복잡도가 너무 높다고 생각했습니다. 그래서 이 중 한 대에 데이터를 집중시키고 그 한 대만 백업하는 전략을 선택했습니다. 디지털 휴먼 API (2025)에서 개인적으로 파일 버전 관리와 여러 기계에 걸친 동기화에 퍼포스를 사용하고 있다고 소개했습니다. 그냥 드랍박스나 원드라이브를 사용하면 훨씬 단순하지만 저에게는 파일 각각의 버전이나 어느 시점의 경로 구조를 기록하고 만약 필요하다면 그 시점으로 복원하거나 이전 버전을 획득해야만 하는 일이 종종 일어났기에 이를 명시적으로 안전하게 처리할 도구가 필요했습니다. 인터넷에서는 깃이 거의 표준으로 사용되지만 개인적으로는 제가 일하는 업계에서 널리 사용하는 퍼포스가 훨씬 익숙했고 또 깃은 분산형 버전관리 도구로 오프라인 상태에서도 동작해야 하기 때문에 파일을 포함한 전체 데이터베이스를 로컬에 가지고 있어 리파지토리가 커질수록 필요한 로컬 스토리지가 눈에 보이는 스토리지의 최소 두 배 이상이 필요해져 제 요구사항에는 어울리지 않았습니다. 퍼포스는 계정 다섯 개 까지는 무료로 사용할 수 있고 눈에 보이는 파일 크기 이외에는 모두 서버에 의존해 추가 스토리지를 요구하지 않아 훨씬 유리하다고 판단했습니다. 그래서 홈랩에 퍼포스 서버를 구동하고 나머지 기계에서는 퍼포스 클라이언트로 필요한 파일을 동기화해서 사용하며 모든 파일은 다시 퍼포스에 서브밋(커밋)했습니다. 그러면 각각의 기계는 운영체제와 사용하던 소프트웨어를 복원하고 나면 나머지 모든 데이터는 퍼포스 서버로부터 다운로드 받으면 됩니다. 현재에 운영체제는 대체로 인터넷 연결이나 외부 미디어 없이도 복원할 수 있기 때문에 백업할 필요가 없습니다. 그래서 만약 도난이나 파손 같은 상황이 발생하더라도 일단 운영 환경을 복원하고 나서 그냥 서버로부터 파일을 받아오기만 하면 되니 백업은 기계 한 대에만 집중하게 되었습니다.

백업 소프트웨어로 Arq Backup[^Cloud backup software for Mac and Windows : Arq]을 사용합니다. 이 백업 소프트웨어를 처음 알게 된지는 굉장히 오래 되었는데 중간에 부침이 좀 있었습니다. 처음 이 프로그램을 알게 된 다음 한동안은 아이클라우드 드라이브나 드랍박스 같은 프로그램과 궁합이 좋지 않아 원하지 않는 결과를 자주 만들어냈기 때문입니다. 특히 로컬에 파일을 다운로드 하지 않고 있다가 요청할 때 파일을 다운로드하는 방식으로 운용할 때 아주 골아픈 문제들을 일으켰습니다. 그래서 한동안 다른 백업 소프트웨어를 사용해보기도 했고 올해 특히 여러 가지 시도를 해봤습니다. 하지만 결국 이만한 대안이 없다는 사실을 깨달았습니다. 일단 Arq Backup은 3-2-1 규칙에서 2와 1, 즉 로컬 복사본과 원격 복사본 모두를 한 가지 솔루션을 통해 해결할 수 있습니다. 맥의 운영체제 수준에서 제공하는 타임머신은 단순하고 단단하게 동작하지만 결정적으로 원격에 백업이 불가능하지는 않지만 그 설정이 아주 피곤했고 이는 애초부터 이 솔루션이 원격 백업을 고려하지 않고 만들어졌음을 의미합니다. 로컬 백업과 원격 백업을 서로 다른 솔루션에 의존하고 싶은 생각이 별로 없었습니다. 이는 관리 부담을 극적으로 증가시키기 때문입니다. 백업은 정말 한번 설정해 놓으면 문제가 일어나기 전까지는 저에게 아무 말도 하지 말고 조용히 돌아가기를 원하는데 여러 가지 백업 솔루션을 사용한다는 것 자체가 이 요구사항을 제대로 수용하지 못함을 의미하기 때문에 타임머신을 핵심 백업 도구로 사용하지 않을 수 있다는 점에서 일단 의미있습니다. 그렇다고 타임머신을 아예 사용하지 않는 것은 아닌데 이 이유는 뒤쪽에서 설명하겠습니다. Arq Backup의 장점은 일단 다양한 원격 스토리지를 지원한다는 점, 그리고 파일시스템 수준의 스냅샷을 지원한다는 점입니다. 스냅샷 지원의 중요성은 바로 이어서 설명하겠습니다.

스냅샷은 파일시스템이 어느 특정 시점에 스토리지 전체의 파일 상태를 남겨두고 이어지는 변경사항을 별고로 기록하는 기능입니다. 특정 시점에 스냅샷을 생성하면 이 시점의 모든 파일에 현재 시각의 타임스탬프를 찍은 다음 이 시점 이후에 같은 파일에 변경이 일어나면 겉으로 보기에는 이전과 똑같이 같은 파일을 수정하는 것처럼 보이지만 파일시스템 내부에서는 타임스탬프가 부여된 시점의 파일을 남겨두고 이후 변경사항은 논리적인 다른 파일에 기록합니다. 그러다가 스냅샷을 제거하면 이전의 타임스탬프를 가지고 있는 파일 중 변경이 없는 파일은 그대로 유지하고 변경이 있어 다른 파일에 변경사항이 기록된 파일은 이전 스냅샷 파일을 제거하는 방식으로 동작합니다. 여러 백업 솔루션들은 파일시스템의 스냅샷 기능을 사용하지 않는데 이는 분명 소프트웨어 개발을 더 단순하게 만들고 여러 환경에 대응하는 별도의 소프트웨어를 개발할 필요를 없애 준다는 점에서 분명 개발자 입장에서 선호되는 방법일 거라고 생각합니다. 하지만 개인 사용자, 그것도 백업과 복원 과정의 복잡성을 최소화하고 싶고 또 기술력이 부족한 입장에서는 스냅샷을 사용하지 않는 것은 받아들일 수 없습니다. 디지털 휴먼 API (2025)에 소개한 대로 홈랩에는 여러 도커 컨테이너가 돌고 있는데 특히 이들 중에는 데이터베이스도 있습니다. 데이터베이스를 안전하게 백업하는 방법은 데이터베이스를 덤프해 그 결과를 저장하는 것 뿐입니다. 하지만 매번 백업 시점마다 데이터베이스 각각의 덤프를 생성하고 이를 백업하는 것은 백업의 복잡도를 올리고 미래에 이를 복원할 때도 복잡도를 올리는 요소로 작용할 거라고 예상합니다. 그래서 이런 짓 할 필요 없이 파일시스템 수준에서 그냥 데이터베이스 파일을 백업하고 복원할 때도 그냥 파일을 덮어쓰거나 복사해 오기만 하면 되도록 하고 싶었습니다. 여기에 필요한 것이 바로 파일시스템 수준의 스냅샷을 사용해 백업하는 것입니다. 만약 스냅샷 없이 파일 단위로 백업이 일어난다면 계속해서 동작하고 있는 데이터베이스에서 각각의 파일을 백업하는 시점이 달라집니다. 그러면 파일은 모두 백업한 것처럼 보이지만 각 파일의 백업 시점이 달라져 데이터베이스 파일 전체의 일관성이 깨집니다. 어떤 인덱스는 15초 전에 백업되지만 어떤 데이터는 15초 후에 백업될 수 있습니다. 다행스럽게도 이런 일관성 불일치에도 불구하고 데이터베이스 소프트웨어가 무사히 기동될 가능성도 없지는 않지만 그렇게 기동된 데이터베이스를 사용하는 소프트웨어가 오동작할 수도 있습니다. Arq Backup은 여러 단순한 백업 소프트웨어들이 스냅샷을 사용하지 않는 것에 비해 스냅샷에 기반한 백업을 지원하고 이는 파일시스템의 특정 시점에 모든 파일의 일관성을 유지하게 해줍니다. 그러니 덤프 없이 데이터베이스를 그냥 백업할 수 있습니다.

Arq Backup의 이런 장점에 기반해 첫 번째 복사본과 두 번째 복사본 모두 이 소프트웨어로 생성합니다. 첫 번째 복사본은 홈랩 기계인 맥미니에 바로 연결된 외장 스토리지입니다. 이 외장 스토리지에는 4시간에 한 번 백업하도록 설정했습니다. 이전에 1시간 단위 백업으로부터 위기를 모면한 경험이 없지는 않습니다만, 외장 스토리지는 아무래도 24시간 동작할 것을 예상하고 만들어진 기계는 아닐 것이 분명하기에 너무 몰아붙이면 수명이 훨씬 빨리 끝날 것이 걱정되었습니다. 그래서 로컬 외장 스토리지에는 4시간에 한 번만 백업합니다. 어쩌면 6시간에 한 번 정도로 간격을 늘릴는지도 모르겠습니다. 한편 여러 백업 관련 안내에서 백업 스토리지는 백업할 원본보다 용량이 더 커야 한다고 주장하곤 합니다만, 개인적인 경험으로는 항상 그렇지는 않습니다. 특히 Arq Backup은 꽤 강력한 디듀플리케이션 기능을 지원합니다. 같은 파일이 백업된다면 당연히 중복해서 기록하지 않을 뿐 아니라 큰 파일에서 일부가 수정된 경우 델타만 백업해 스토리지 사용을 최소화합니다. 만약 200메가짜리 파일에 일부분만 수정되었다면 새로운 200메가를 백업하는 대신 수정된 몇 킬로바이트만 새로 백업하는 식입니다. 그래서 백업 대상 스토리지는 다 합쳐 10테라바이트 정도이지만 실제 잭업은 7테라바이트 수준에 머물고 있고 백업 스토리지 사용량 증가 속도는 백업 대상 스토리지에 비해 압도적으로 느린 편입니다. 그래서 백업 스토리지가 원본의 두 배 크기일 필요는 그리 크지 않습니다. 대략 원본과 같은 용량이면 꽤 오래 버틸 수 있을 겁니다. 원격 백업도 똑같이 Arq Backup을 사용합니다. 지금은 독일 소재의 Hetzner[^Hetzner]의 Storage Box라는 제품을 사용하는데 10테라바이트에 24달러의 고정 가격입니다. 여느 오브젝트 스토리지와 달리 입출력 행동이나 인터넷 전송량에 과금하지 않고 고정 금액만 과금하기 때문에 백업 비용을 예측할 수 있어 개인 수준에서 사용하기 좋습니다. 다만 이 서비스로 최종 안착하는 과정이 그리 순탄하지는 않았는데 Hetzner의 Storage Box에 안착하기까지 겪은 여러 시행착오가 2025년 백업 전략 회고의 가장 중요한 부분입니다.

2025년 초까지는 크래시플랜이라는 서비스를 사용했습니다. 크래시플랜 여러 달 사용기를 작성할 때만 해도 고정된 가격에 꽤 합리적인 서비스라고 생각했습니다. 고정 비용이 무제한 용량을 제공한다고 주장했는데 결국 실제로는 그렇지 않음을 너무 빨리 알게 되었습니다. 일단 서버 측에서는 무제한 용량을 제공한다고 주장했지만 실제로는 10테라바이트를 백업했던 어떤 유저가 회사로부터 환불해줄테니 서비스 사용을 중단하라는 요구를 받은 사례도 있었고 속도가 느려 하루에 백업할 수 있는 용량에 한계가 있었습니다. 한 시간 간격으로 백업하라도 설정한다 하더라도 네트워크 속도가 느려 얼마 되지 않는 변경사항을 1시간 안에 백업하기는 거의 불가능했습니다. 또 클라이언트 소프트웨어는 자바 기반으로 만들어져 있었는데 백업할 대상 파일 수가 100만이 넘어가면 제대로 동작하지 않았습니다. 이 문제를 해결하기 위해 클라이언트 소프트웨어 내부에서 자바 VM이 사용하는 메모리 크기를 직접 늘려줘야만 했고 이게 맞나 싶은 생각이 들었습니다. 그리고 여러 백업 서비스들이 ‘클라이언트가 자바를 사용하지 않는다’는 점을 왜 광고하는지 조금이나마 깨달았습니다. 또 클라이언트 소프트웨어는 임의로 ‘temp’ 같은 디렉토리를 무시했는데 이런 임의 예외를 유저가 직접 편집할 수도 없었습니다. 저는 저 이름으로 된 디렉토리가 퍼포스 아카이브 디렉토리 중에 하나여서 반드시 백업해야만 했고 고객지원과 메일을 몇 번 주고 받은 다음에야 이 예외를 제거할 수 있었습니다. 이런 문제 뿐 아니라 백업 소프트웨어는 스냅샷 없이 파일시스템을 백업해 높은 확률로 데이터베이스 복원에 문제를 일으킬 가능성이 높았습니다. 앞서 잠깐 설명했다시피 백업 대상의 크기는 10테라바이트를 한참 초과했고 저 역시 머지 않아 꺼지라는 메일을 받을 가능성이 높았습니다. 이미 클라이언트는 자신이 사용할 수 있는 메모리 부족으로 전체 백업에 지속적으로 실패하고 있었고 제 인내심은 바닥났습니다. 고정 비용은 맞지만 무제한 용량은 거짓이었고 백업 소프트웨어는 극도로 부실했습니다. 그래서 크래시플랜을 사용하지 마세요라는 결론에 도달했습니다.

그렇다고 해도 비용은 중요합니다. 아마존 S3가 대단히 훌륭하다는 사실을 알지만 여기에 백업했다가는 몇 달 안에 전 재산을 탕진하고 거리에 나앉게 될겁니다. 또 고정비용이어야 하는 점도 중요합니다. 사용량에 따라 비용이 오르내리거나 S3처럼 외부 전송 비용이 높으면 미래에 도난이나 화재 등의 원인으로 데이터를 복원해야 할 때 그렇잖아도 재무적으로 심각한 타격을 받았을 상태에서 데이터를 복원하는 과정에서도 큰 비용을 지불해야 할 겁니다. 이는 옳지 않았습니다. 그래서 이번에는 Backblaze Backup[^Backblaze Backup]을 시도해봤습니다. 이 서비스 역시 월 고정 비용으로 무제한 용량을 제공한다고 주장했는데 앞서 10테라바이트보다 더 많은 용량을 사용하면 쫓겨난다는 괴담이 흉흉한 크래시플랜과 달리 이곳에서는 그런 괴담이 없어 보였습니다. 하지만 이 서비스를 사용하기 전부터 클라이언트가 운영체제의 스냅샷을 사용하지 않는다는 점을 알고 있었습니다. 특히 이 서비스는 컨티뉴어스 백업 기능을 제공한다고 홍보했는데 이는 파일시스템을 관찰하다가 파일에 변경을 감지하면 바로바로 그 파일을 백업하는 기능입니다. 그런데 곰곰이 생각해보면 이런 백업 방식은 디렉토리 단위의 백업 시점의 일관성을 전혀 유지할 수 없는 방법입니다. 그렇잖아도 스냅샷 기반이 아니어서 위험한다 파일에 변경이 일어날 때마다 백업한다니 이건 더 위험했습니다. 각 파일이 언제 백업되었는지, 어느 파일이 먼저 백업되었고 어느 파일이 나중에 백업되었는지 파악할 기준 시간대도 없었습니다. 하지만 월 고정 가격에 무제한 용량을 백업할 수 있는 점은 여전히 매력적이라고 생각했기에 꼼수를 쓰기로 합니다. Arq Backup이 스냅샷 기반으로 백업해 로컬 백업 스토리지에 저장하면 백블레이즈 백업은 이 로컬 백업 자체를 백업하는 겁니다. Arq Backup에 의해 이미 암호화 되어 있고 4시간에 한 번 수행되는 백업은 4시간 안에 업로드 할 수만 있다면 파일시스템의 일관성 역시 유지할 수 있다고 생각했습니다. 이 체제를 한동안 유지했지만 이 방법이 지속 가능하지 않다는 점을 깨닫는데는 얼마 걸리지 않았습니다. 전체 복원 훈련은 아니지만 가끔 일부 파일을 복원하는 연습을 자동화하려고 했는데 백블러에지 븍업에는 Arq Backup이 생성한 파일을 백업하고 있었으므로 아무리 작은 파일이라도 원격으로부터 복원하려면 백업 파일 전체를 로컬에 복원한 다음 이 파일로부터 다시 복원해내는 이중 절차가 필요했습니다. 앞서 원격 백업에 손을 대는 상황은 제가 재무적으로 큰 타격을 입은 상황일 거라고 예상했는데 이와 함께 이런 복잡한 절차를 올바르게 수행해낼 정신상태일지도 의심스러웠고 이런 이중 절차는 백블레이즈 백업에 의존해서는 안되겠다는 교훈을 주었습니다.

크래시플랜과 백블레이즈 백업은 근본적으로 원격 백업 서비스는 서버를 제공하고 클라이언트는 제가 통제할 수 있어야 한다는 점을 깨닫게 해 주었습니다. 자바 기반으로 동작해 정상 동작하지 않거나 백업 시점을 특정할 수 없는 방식의 클라이언트가 서버와 함께 따라오면 이로부터 발생하는 문제를 해결할 방법이 없었습니다. Arq Backup은 처음부터 클라이언트 역할이 핵심이고 서버는 주로 오브젝트 스토리지를 별도로 사용하도록 만들어졌습니다. 한참 전부터는 그들 스스로 백업 스토리지를 제공하지만 백블레이즈 B2와 같은 가격이어서 별다른 가격적 메리트는 없습니다. 백블레이즈 B2가 오브젝트 스토리지 중에서는 가성비가 가장 좋다는 점을 알고 있었지만 여전히 1테라바이트에 월 6달러로 10테라바이트를 사용한다면 월 60달러를 내야 했고 이는 여전히 높은 가격이었습니다. 그래서 이번에는 S3 Glacier Deep Archive 클래스를 사용해보기로 했습니다. 이 클래스는 S3이기는 하지만 저를 패가망신 시키는 대신 1테라바이트 당 월 1달러를 요구했습니다. 그러니까 10테라바이트를 사용하더라도 월 10달러면 된다는 이야기입니다. 하지만 여기에는 댓가가 따르는데 이 서비스는 백업과 복구보다는 장기간의 아카이빙에 중점을 두고 만들어졌습니다. 이런 목적에 의한 가장 큰 특징은 콜드스토리지라는 점입니다. 백업은 정상적으로 수행되지만 이를 복원하려면 복원 신청을 하고 기다려야 합니다. 12시간에서 48시간까지 기다려야 하는데 기다리는 시간을 줄이고 싶으면 용량 당 비용을 추가로 지불하면 되는 식입니다. 콜드스토리지이기 때문에 이런 극단적으로 낮은 비용으로 백업할 수 있는 모양입니다. 또 복원을 요청하면 콜드스토리지로부터 파일을 S3에 복원해주는데 이를 인터넷을 통해 가져오는데는 다시 비용을 청구했습니다. AWS가 그렇듯 인터넷으로 데이터를 송신하는 비용이 굉장히 높았는데 10테라바이트 전체를 인터넷으로 송신할 경우 다운로드 기간 동안 S3 비용을 지불해야 하고 송신 비용도 제법 큰 금액이 필요햇습니다. 물론 백업 전체를 복원하는 일은 거의 발생하지 않을 테니 이를 고려해 단위 기간 당 총소유비용을 계산하면 오브젝트 스토리지 중 가성비가 가장 좋은 백블레이즈 B2에 비해 더 낮았지만 앞서 설명했듯 원격 백업에 손을 대야 하는 상황은 이미 제가 재무적으로 큰 타격을 입은 시점일테고 이 상황에 또 다시 이런 거대한 비용을 부담할 수 있을지 의심스러웠습니다. 결정적으로 S3 Glacier Deep Archive 클래스는 스토리지 비용만 요구한 것이 아니었습니다. 입출력, 클래스 전환 등에 비용을 별도로 요구했고 또 메타파일과 백업 인덱스는 여전히 S3에 저장해야 했기에 비용에 오버헤드가 있었습니다. 그래서 그들이 주장한 1테라바이트당 월 1달러와는 아득히 먼 비용을 지불해야 했고 특히 이 비용을 예측하기 어렵다는 점이 이 서비스를 장기적으로 원격 백업으로 유지하기 어렵겠다는 결론에 도달하게 만들었습니다.

이렇게 여러 서비스를 떠돌다가 마지막으로 안착한 곳은 독일 소재의 Hetzner라는 서비스입니다. 이곳은 AWS처럼 서버나 스토리지를 사용할 수 있는 곳인데 이곳에는 Storage Box라는 서비스가 있었습니다. 이는 오브젝트 스토리지는 아니지만 SFTP를 지원해 원격에서 파일을 읽고 쓸 수 있었습니다. 오브젝트 스토리지와 달리 최대 10테라바이트까지만 확장할 수 있고 확장 단위도 10테라바이트 또는 20테라바이트와 같이 고정된 용량만큼만 가능합니다. 또 동시 접속 수를 제한하는 등 오브젝트 스토리지처럼 사용할 만한 성능과 확장성을 제공하지는 않습니다. 하지만 10테라바이트 기준으로 월 24달러의 고정 비용으로 총소유비용을 완전히 예측할 수 있었고 또 테라바이트 당 가격 역시 굉장히 낮았습니다. 그래서 결국 클라이언트는 Arq Backup, 원격 스토리지는 Hetzner의 Storage Box를 선택했습니다. 지금은 10테라바이트에 월 24달러짜리 상품을 사용하고 있는데 백업 크기가 10테라바이트를 넘기게 되면 20테라바이트에 월 46달러짜리 상품으로 전환할 겁니다. 이보다 큰 상품은 없어 이보다 백업이 커질 경우 Storage Box 제품을 추가로 결제해야 해서 백업 체계를 좀 바꿔야 하겠지만 그 시점이 일찍 찾아오지는 않을 것 같습니다. 오브젝트 스토리지 계열보다는 반응이 느린 편이지만 앞서 소개한 크래시플랜에 비해서는 압도적으로 빠르고 파일을 가져오는데 추가 비용이 없다는 점은 굉장히 큰 장점입니다. 이는 원격 백업으로부터 대량으로 복원해야 하는 불행한 상황이 생겼을 때 그렇잖아도 재무적으로나 감정적으로 거덜나있을 저를 더 이상 추가로 거덜나게 만들지 않을 것이 확실합니다. 다만 이런 저렴한 가격에는 당연히 댓가가 있습니다. 앞서 소개한 모든 서비스들이 서버 측 암호화를 지원하지만 이 서비스는 서버 측 암호화를 제공하지 않습니다. 물론 Arq Backup이 파일을 원격 서버로 보내기 전에 암호화하므로 큰 문제는 아니지만 만약 암호화 기능이 없는 백업 솔루션을 사용한다면 이 점을 진지하게 고민해야만 할 겁니다. 또 S3가 리덴던시를 정확한 값으로 표시하고 있는 반면 이 서비스는 그저 레이드 기반으로 운영된다고만 말하고 리덴던시를 어느 정도 수준으로 지원하는지 알 수 없습니다. 이 곳의 데이터에 문제가 생길 가능성은 제 로컬 스토리지에 문제가 생길 확률보다 훨씬 낮겠지만 백블레이즈 B2가 데이터센터 단위의 리덴던시를 고객이 직접 추가 비용을 지불해 확보할 수 있도록 한 마당에 아예 아무 안내도 없다는 점은 좀 아쉽습니다.

Hetzner Storage Box의 장점 중 하나는 스냅샷 기능이 있다는 것입니다. 아무리 3-2-1 규칙에 따라 백업을 한다 하더라도 랜섬웨어 사고가 발생하면 높은 확률로 로컬 백업은 오염될겁니다. 특히 제 첫번째 백업은 홈랩에 썬더볼트 케이블로 그냥 연결되어 있기 때문에 랜섬웨어 사고가 발생하면 로컬 백업은 반드시 오염됩니다. 그런데 백업 소프트웨어는 이런 상황을 모른 체 오염된 상태를 백업해 문제를 악화시킬 가능성이 높습니다. 랜섬웨어 사고가 발생해 원격 백업으로부터 파일을 복원했지만 여전히 랜섬웨어 사고가 난 상태를 복원해버릴 수 있습니다. 그런데 서버 측 스냅샷 기능은 앞서 설명한 파일시스템 수준의 스냅샷과 똑같습니다. 다만 저는 APFS 기반의 스냅샷을 로컬에서 사용한다면 Storage Box는 서버 측에서 ZFS 기반의 스냅샷을 제공합니다. 스냅샷을 1주일에 한 번 생성하게 해 두면 현재 파일시스템 상태를 기록하고 그 후에 새로 기록되는 파일만 별도로 기록합니다. 그래서 로컬에 랜섬웨어 사고가 발생하고 이들 중 일부터 백업에 포함되었으며 이 시점을 특정하기 어려운 상황이라면 그냥 스냅샷을 통째로 복원해 아예 랜섬웨어 사고가 발생하기 이전으로 백업 전체를 되돌릴 수 있습니다. 아마도 높은 확률로 스냅샷의 도움을 받지 않아도 백업 소프트웨어 수준에서 랜섬웨어 사고 이전 시점을 특정할 수 있겠지만 어떤 이유로든 이게 불가능해지더라도 여전히 살아날 방법은 있습니다. 다만 이 서비스가 오브젝트 스토리지가 아니라는 점은 백업을 밸리데이션 해야 하는 필요를 만들어냅니다. 동시에 백업이 커지면 그 밸리데이션이 거의 불가능해진다는 것을 의미하기도 합니다. 디지털 스토리지는 완벽하지 않습니다. 여러 가지 원인으로 파일의 극히 일부, 혹은 단일 비트가 손상될 수 있습니다. ZFS는 이런 손상을 스스로 해결할 능력이 있지만 가장 좋은 방법은 오브젝트 스토리지가 스스로 파일의 손상 여부를 확인하는 것입니다. 그래서 Arq Backup은 오브젝트 스토리지에 백업하면 밸리데이션 옵션을 아예 제공하지 않습니다. 그럴 필요가 없으니까요. 하지만 Storage Box는 오브젝트 스토리지가 아니기에 밸리데이션이 필요한데 수 테라바이트에 걸쳐 밸리데이션을 수행하는데는 엄청난 시간이 걸립니다. 특히 Arq Backup은 밸리데이션 작업과 백업 작업을 서로 분리해 별도 동시 수행하지 않기 때문에 밸리데이션이 길어지면 다음 백업 잡들이 모두 딜레이됩니다. 이 문제가 너무 심해 백업이 하루 이상 지연되기도 해서 위험을 감수하고 밸리데이션을 꺼버렸습니다. 이 점은 오브젝트 스토리지처럼 파일을 명시적으로 검사하지 않는다는 점에서 아쉽고 또 백업 소프트웨어가 클라이언트 측에서 백업 잡과 밸리데이션 잡을 구분하지 않는다는 점에서 아쉽습니다.

3-2-1 규칙에 따라 홈랩 원본, 이와 분리된 외장 스토리지의 첫 번째 백업, 그리고 Storage Box에 두 번째 원격 백업이 있습니다. 그리고 홈랩 원본은 스토리지가 물리적으로 고장나더라도 다운타임을 최소화하기 위해 레이드 1로 구성했습니다. 이는 백업은 아니지만 적어도 하드디스크 두 개 중 하나가 고정났을 때도 여전히 서비스를 제공할 수 있게 해줍니다. 하지만 어떤 이유로 홈랩의 운영체제가 고장나 리셋이 필요한 상황에서는 상당한 귀찮음이 발생할 수밖에 없습니다. 운영체제를 재설치하는데까지는 인터넷을 통해 처리할 수 있지만 이후 홈랩의 이전 상태와 같이 다시 구성하는 것은 상당히 고통스러울 겁니다. 이럴 때 운영체제 설치 과정에서 직접 사용할 수 있는 타임머신 백업이 절실합니다. 그래서 지금은 더 이상 사용하지 않는 5테라바이트짜리 외장하드를 연결해 운영체제가 설치된 볼륨 하나만 타임머신으로 백업합니다. 이는 데이터를 백업하기 위한 목적보다는 운영체제의 현재 상태를 백업했다가 운영체제를 복원하는 과정을 단순하게 만들기 위한 것입니다. USB 케이블로 직접 연결되어 있어 운영체제 설치 과정에 바로 나타나 운영체제 설치와 동시에 이 백업을 사용하도록 할 수 있어 운영체제 재설치와 운영 환경 복구를 동시에 할 수 있습니다. 복구가 끝나면 그냥 외장 스토리지들을 연결해 서비스를 시작하기만 하면 됩니다. 이렇게 두 가지 솔루션을 통한 백업이 마음에 들지는 않습니다만, 운영체제 수준에서 제공하는 백업이 있으면 무조건 편리하기에 하는 수 없이 이 체계를 유지하려고 합니다. 하지만 이 백업은 오직 운영체제 환경 백업만을 목적으로 하므로 3-2-1 규칙에는 포함되지 않습니다.

정리하면 여러 기계를 사용하지만 퍼포스를 사용해 데이터를 홈랩 기계 한 대로 집중시켜 백업은 이 기계 한 대만 신경쓰면 되도록 했습니다. 운영 환경의 원활한 복구를 위해 타임머신으로 외장하드에 운영체제가 설치된 스토리지 하나만 백업하고 있고 이와 별개로 Arq Backup으로 로컬 외장하드 하나와 원격 스토리지 하나에 각각 하나씩 홈랩 전체 백업을 하고 있습니다. 로컬 백업은 일반적으로 백업 대상인 전체 스토리지의 2배 정도를 요구하곤 하지만 실제로는 디듀플리케이션 때문에 백업 대상 스토리지와 비슷한 수준만 있어도 운영할 수 있습니다. 원격 백업은 비용 통제가 중요한데 여러 가지 솔루션이 있지만 지금은 Hetzner의 Storage Box라는 서비스를 사용하고 있으며 제가 지금 사용 중인 제품은 10테라바이트에 월 24달러 고정 비용이며 여기에는 입출력 및 인터넷 전송 비용이 모두 포함되어 있어 비용 예측이 굉장히 간단합니다. 단 최대 용량은 20테라바이트 월 46달러까지만 있어서 이보다 더 큰 백업은 백업 체계의 변경을 필요로 하지만 당분간은 별 무리 없어 보입니다. 한동안은 이렇게 유지하려고 합니다.

앞으로의 개선 방향은 Arq Backup 자체입니다. 개인용 백업에 아직까지 이보다 나은 방법을 찾지 못했습니다. 다른 여러 가지 솔루션들이 있지만 특히 파일시스템 스냅샷 기능에 근거해 백업하며 동시에 원격 오브젝트 스토리지나 SFTP를 자체적으로 제공하는 솔루션을 찾기는 쉽지 않았습니다. 대체로 스냅샷에 근거하지 않고 또 원격 스토리지 접근에 별도의 솔루션을 요구하는 등 복잡도를 낮게 유지하기 어려운 모양으로 만들어진 경우가 많았습니다. 하지만 장기적으로 한 가지 솔루션만으로 백업을 유지하는 것은 복잡도를 줄이기는 하지만 근본적으로 아주 안전한 방법은 아니라고 생각합니다. 특히 Arq Backup은 먼 과거부터 현대에 이르기까지 단 한 사람이 개발하고 있다고 알려져 있는데 그 단 한 사람이 소프트웨어를 개발해 수익을 내고 생계를 안정적으로 유지할 수 있다는 점에서 소요 비용이 낮다는 점은 긍정적이지만 버스 팩터 측면에서는 안전하지 않습니다. 그래서 Arq Backup 사용을 유지하더라도 장기적으로는 백업 솔루션을 추가해야 할 거라고 예상합니다. 가장 단순한 방법은 로컬 백업을 타임머신으로 대체해 타임머신과 Arq Backup을 각각 로컬과 원격에 사용하는 것입니다. 다만 Arq Backup의 청크 단위 디듀플리케이션에 비해 타임머신의 파일 단위 디듀플리케이션은 더 단순하고 빠르지만 스토리지를 압도적으로 더 많이 사용한다는 점에서 좀 더 생각해볼 문제이기는 합니다. 어쩌면 로컬 백업을 두 개로 만들어 하나는 타임머신, 다른 하나는 Arq Backup을 사용하는 것이 이상적인 방법일는지도 모르겠습니다.

올해에도 여전히 중요한 사진이 폰에 들어있는데 폰이 안 켜져 복구 업체 신세를 지거나 중요한 데이터가 오직 단 하나의 스토리지에만 저장되어 있다고 말하는 분들의 사례를 여럿 봤습니다. 이런 사례가 안타깝기는 하지만 그 데이터가 정말로 중요하다면 그에 걸맞는 대우를 해야 한다고 생각합니다. 어떤 데이터가 정말로 소중하다면 하드웨어와 소프트웨어 그 어느쪽도 신뢰해서는 안됩니다. 모든 스토리지는 기계적으로 고장날 수 있고 스토리지 집적도가 늘어날수록 기계적인 고장 한 방에 사라질 데이터의 크기는 더 커집니다. 소중한 사진을 보관하기에 우리들의 스마트폰은 수명이 짧고 폰을 교체할 때마다 데이터를 이전하는 과정에서 무슨 일이 생길지 모릅니다. 스토리지 가까이에 배터리가 붙어 있고 각자가 뿜어내는 열은 언제 어떤 방식으로 데이터를 망가뜨릴지 예측하기 어렵습니다. 불행하게도 기술 수준이 낮은 개인들에게 진짜 사용 가능한 백업을 제공하는 서비스는 없어보입니다. 윈도우 운영체제는 원드라이브에 의존한 백업을 제공하지만 사전적 의미로 이들이 제공하는 것은 백업이 아니라 파일 동기화 서비스입니다. 마이크로소프트는 이를 백업이라고 주장해 사람들을 헛갈리게 만들고 랜섬웨어 사고 상태를 그대로 동기화해 다른 기계에 전파하기까지 합니다. 맥OS라고 별로 다르지 않습니다. 타임머신 백업을 제공하지만 별도의 스토리지 기계를 필요로 하며 대부분의 유저에게 맥에 멀쩡한 내장 스토리지가 있는데 왜 다른 스토리지가 필요한지 이해시키기는 어렵습니다. 그들이 아이폰 백업에 아이클라우드 드라이브를 요구하는 것을 고려할 때 맥OS에 원격 백업을 스스로 제공하지 않는다는 점은 납득하기 어렵습니다. 스마트폰도 마찬가지입니다. 안드로이드도 아이폰도 별도 스토리지를 구독하지 않으면 제대로 된 백업 솔루션이 없습니다. 특히 아이폰은 아이클라우드 스토리지를 구독하지 않으면 폰 전체를 안전하게 백업할 방법은 오직 다른 컴퓨터에 연결하는 것 뿐입니다. 이는 백업 과정을 귀찮게 만들어 백업을 등한시하게 만들 뿐입니다.

이런 현실 속에서 어쨌든 제가 중요하다고 생각하는 데이터를 절대로 잃어버리지 않기 위해 여전히 백업에 관심을 가지고 있습니다. 특히 올해에는 원격 백업에 여러 차례 시행착오를 거쳤습니다. 일단 지금까지는 최종 상태가 나쁘지 않습니다만, 개선 여지도 많습니다. 내년 이맘때 다시 비슷한 이야기를 꺼내 그 때는 백업을 얼마나 개선했을지 다시 이야기해보겠습니다. 여튼 지금까지는 백업을 잘 유지하고 있고 종종 작은 규모로 백업으로부터 큰 도움을 받고 있습니다.