크래시플랜을 사용하지 마세요

지난 크래시플랜 여러 달 사용기에 크래시플랜이라는 백업 서비스에 대한 나쁜 경험을 소개했습니다. 이 서비스는 제 개인 백업 전략의 일부로 소개한 적 있습니다. 지난 글에서 크래시플랜에 대한 신뢰를 잃게 만든 에피소드를 소개했었는데요, 이후 제 요구사항과 크래시플랜의 실제 동작, 만약 이 백업 서비스를 사용해 전체 복원을 시도할 때 실제로 발생할 수 있는 문제점을 고려할 때 이 서비스를 사용해서는 안된다는 결론에 도달했습니다. 이미 지난번에도 계약이 끝나면 더 이상 서비스를 연장하지 않을 작정이라고 이야기했었지만 그보다 더 빨리 이 서비스에 의존하는 상태를 벗어나야만 합니다. 크래시플랜은 아마도 그들이 구상한 어떤 평범한 시나리오에 기반해서는 잘 동작할른지도 모릅니다. 하지만 제 요구사항과 제 복구 시나리오에는 동작하지 않을 뿐 아니라 분명 의도한 대로 동작하더라도 저는 복구에 실패하는 상황을 맞을 수 있습니다. 그래서 저는 크래시플랜 사용을 중단하기 위해 백업을 옮기는 중이고 저와 시나리오가 비슷하다면 저와 비슷한 이유로 실질적인 복원에 실패할 수 있습니다. 저는 이 글에서 크래시플랜을 사용하지 말 것을 주장할 겁니다. 이를 위해 이 글은 이전에 이 서비스에 대해 설명한 글과 내용이 좀 겹칠 수 있지만 감수하고 제 요구사항부터 설명을 시작할 작정입니다.

저는 제 파일을 관리하는데 주로 게임 업계에서 사용하는 형상관리도구인 퍼포스를 사용합니다. 코드를 주로 다루는 분들께는 깃이 가장 널리 사용되는 형상관리도구임을 알고 있고 저 역시 깃을 개인 파일 관리에도 사용하는 시도를 한 적이 있었습니다만, 게임 업계에서 깃 대신 주로 퍼포스를 사용하는 것과 비슷한 이유로 깃으로는 코드가 아닌 여러 개인 파일들을 관리하는데 문제가 있었습니다. 깃은 주로 텍스트 파일을 다루는 시나리오에서는잘 동작했지만 바이너리 파일이 끼어들기 시작하면 여러 가지 오동작을 하기 시작했고 또 분산 모델을 기반으로 동작하는 덕분에 모든 데이터베이스를 로컬에 가지고 있어야만 하는 점 역시 개인 수준에서도 파일을 전적으로 관리하는데 문제를 일으켰습니다. 서버 없이 파일을 커밋 할 수 있었지만 서버가 있든 없든 항상 모든 데이터베이스를 로컬에 들고 있어 스토리지 낭비가 심했습니다. 그래서 게임 업계에서 수많은 바이너리 파일을 다루기 위해 퍼포스를 사용하는 것처럼 저 역시 개인 파일 관리에 퍼포스를 사용하기 시작했습니다. 퍼포스를 사용하기 시작할 때는 서버가 AWS에 있었습니다. 그래서 블록스토리지 비용이 증가하기 시작했는데 블록스토리지 뿐 아니라 매일 새벽 인스턴스 스냅샷을 남기는 비용 조차 점점 늘어났습니다. 일부 비용을 줄이기 위해 제가 자는 동안 서버를 중단하기도 해봤지만 비용을 크게 줄이지도 못했고 도리어 밤중에 동작해야 할 자동화가 동작하지 않아 오히려 불편해졌습니다.

개인 파일 관리에 퍼포스를 선택한 순간부터 저는 이 도구를 앞으로 오랜 세월에 걸쳐 개인 파일 관리에 사용할 작정이었고 이를 비용 걱정 없이 안정적으로 사용하고 싶었습니다. 고민 끝에 낡은 맥미니 기계를 도입해 온프레미스 환경에서 이전까지 AWS에서 동작하던 서버 기능을 모두 가져옵니다. 이 때 까지는 스토리지 사용량이 AWS에서 블록스토리지를 사용하는 수준에 맞춰져 있어 구형 맥미니의 최대 스토리지 용량인 1테라바이트만으로도 충분하다고 생각했지만 블록스토리지 비용에 상관 없게 되자 퍼포스에 크게 의존하게 되었습니다. 디지털 - 휴먼 API (2024)에서 형상관리도구인 퍼포스를 사용할 필요가 없을 것 같은 용도에도 퍼포스를 사용하기 시작하는 바람에 스토리지 사용량이 급격히 늘어났습니다. 결국 맥미니 서버에 외장 스토리지를 설치해야 했고 이로써 퍼포스 의존과 스토리지 사용량은 더 늘어났습니다. 다행히 저는 영상을 만드는 사람은 아니어서 퍼포스에 의존성이 증가하더라도 스토리지 사용량이 크게 증가하지는 않았습니다. 제가 스토리지를 널럴하게 사용하며 퍼포스에 기반해 그 모든 파일들의 히스토리를 기록한다 하더라도 1년에 최대 1테라바이트보다 많은 스토리지를 사용할 가능성은 거의 없었습니다. 그래서 개인 백업 전략에 소개한 10테라바이트 짜리 외장 드라이브 정도면 앞으로 몇 년 동안 스토리지 비용에 대해서는 완전히 잊을 수 있을 거라고 예상했고 지금까지는 이 예상이 크게 틀리지 않은 상태입니다.

그런데 이렇게 로컬에서 본격적으로 이전에 비해 꽤 큰 용량의 스토리지를 사용하게 되자 대번에 백업에 문제가 생깁니다. 개인적으로 백업을 중요하게 생각해 왔고 백업의 일반 원칙을 준수하려고 노력하고 있습니다. 가령 3, 2, 1 원칙 중 두 번째 2를 제외한 나머지를 준수하고 있는데 3은 적어도 3개의 백업, 그리고 그 중 하나는 다른 장소에 있어야 하는 두 가지 원칙은 확실히 준수해 왔습니다. 구형 맥미니를 서버로 사용하고 있기 때문에 백업 세 개 중 두 개는 서로 다른 두 외장 드라이브에 타임머신을 사용합니다. 그리고 나머지 하나에 크래시플랜을 사용해 왔습니다. 이 서비스를 선택한 이유는 매월 고정 비용을 지불하면 이론적으로 용량 제한 없이 백업할 수 있었기 때문입니다. 이렇게 해서 세 번째 복사본은 서버가 위치한 집에서 태평양을 사이에 두고 아주 멀리 떨어진 미국 어딘가의 데이터센터가 위치하게 되었습니다. 이렇게 백업의 일반 원칙 두 가지를 준수하고 있지만 결국 두 번째 원칙인 두 가지 서로 다른 미디어에 백업하는 것은 달성하지 못했고 앞으로도 달성하지 못할 겁니다. 제 오프사이트 백업이 어떤 미디어에 기록되는지 제가 직접 확인하지 않았지만 높은 확률로 하드디스크에 기록되어 있을 겁니다. 또 제 첫 번째, 그리고 두 번째 백업은 타임머신에 의해 하드디스크에 기록됩니다. 제가 AWS VTL 같은 명시적으로 테이프를 사용하는 서비스를 사용하지 않는 이상 두 번째 원칙을 달성하지 못할 겁니다.

크래시플랜은 월 고정 비용에 이론적으로 제한 없는 스토리지를 제공합니다. 실제로는 약 10테라바이트를 넘어서면 성능에 문제가 생기기 시작하고 또 50테라바이트 이상을 사용하던 한 유저는 회사로부터 사용량을 줄이지 않으면 계정을 폐쇄하겠다는 메일을 받기도 했다고 합니다. 사실 제한이 없다는 말을 처음부터 신뢰하지 않았기에 놀라지는 않았지만 생각보다 그 제한이 가까이 있다는 점은 조금 신경이 쓰였습니다. 하지만 2025년 현재 압축하지 않은 전체 파일 사용량은 아직 3테라바이트를 조금 넘는 수준이고 앞서 예상대로 1년에 최대 1테라바이트 정도 증가한다면 앞으로 몇 년 동안은 이 서비스를 사용할 수 있을 거라고 예상했습니다. 이 서비스를 선택할 때 백블레이즈 백업 역시 거의 같은 서비스를 제공한다는 점을 알고 있었습니다. 그래서 이들 둘 중 하나를 선택해야 했는데 제 용도에는 크래시플랜 쪽이 더 어울렸습니다. 이는 단 한 가지 특징 때문인데 크래시플랜은 사용 중인 파일을 백업했고 백블레이즈 백업은 그렇지 않았습니다. 제가 백업하기를 원하는 기계는 맥미니로 운영되는 서버인데 항상 켜져 있는 관계로 여러 파일이 항상 사용 중인 상태입니다. 가령 같은 서버에서 동작하는 데이터베이스, 퍼포스 등은 항상 파일을 사용 중입니다. 사실 이런 상황에서 파일을 백업하는 더 안전하고 올바른 방법은 덤프를 만드는 것입니다. 퍼포스 역시 메타데이터 데이터베이스가 항상 사용 중이어서 이들을 일반적으로는 읽을 수 없습니다. 그래서 저널 로테이션과 체크포인트라는 일종의 덤프 기능을 사용해 데이터베이스의 현재 상태를 별도 파일로 만들어 줍니다.

하지만 저는 이렇게 하고 싶지 않았습니다. 제가 실제로 이 오프사이트 백업을 사용해 전체 복원을 시도하는 상황을 상상해봤습니다. 백업의 일반 원칙에 따라 저는 이미 두 개의 독립된 백업이 있고 이를 사용하면 훨씬 빨리 전체 복원을 할 수 있습니다. 이런 상황임에도 오프사이트 백업에 손을 댄다는 것은 이 백업을 모두 사용할 수 없는 상황일 겁니다. 오프사이트 백업 하나만 남은 상황일 테고 이런 상황을 맞이한 저는 어쩌면 침착하게 올바른 사고를 할 수 없는 상황일른지도 모릅니다. 간신히 서버를 운용할 장비와 외장 스토리지를 준비해 오프사이트 백업으로부터 복원을 시도하고 있을 텐데 이 때 저 자신이 덤프로부터 데이터베이스를 복원하는 절차를 올바르게 수행할 수 있을지, 또 이 과정이 별다른 문제 없이 진행될지 장담할 수 없었습니다. 저는 오프사이트 백업에 손을 댄 상황에 처한 저 자신을 믿을 수 없습니다. 그래서 복원 과정은 최대한 단순하기를 원합니다. 그래서 라이브 서버에서 실행 중인 프로세스에 의해 파일이 잠겨 있더라도 어쨌든 파일을 읽어 백업했다가 복원은 그저 모든 파일을 다시 가져온 다음 도커 컨테이너를 실행하기만 하면 되는 단순한 모양의 시나리오로 복원할 수 있어야 합니다. 크래시플랜은 이 시나리오를 지원했습니다. 아니, 정확히는 지원할 수 있을 것처럼 보였습니다. 그래서 오프사이트 백업에 크래시플랜을 선택했습니다.

지난 크래시플랜 여러 달 사용기에 밝힌 대로 크래시플랜은 여러 가지로 실제 사용하기에는 문제가 많았습니다. 일단 전송 속도가 놀라울 정도로 느립니다. 크래시플랜은 첫 한 달 동안의 트라이얼을 제공하는데 이 트라이얼 기간 안에 첫 백업을 마치지 못했습니다. 그래도 동작하겠거니 하고 결제하려고 보니 원화로만 결제할 수 있게 되어 있어 이 문제를 해결해야 했는데 이 과정에서 다음 한 달을 무료로 제공해 주었습니다. 하지만 그 때 까지도 첫 백업을 마칠 수 없었고 결국 처음으로 비용을 지출한 다음에야, 그러니까 백업을 시작하고 두 달 이상이 지난 다음에야 첫 백업을 마칠 수 있었습니다. 나중에 알아보니 여러 사용자들의 보고를 종합하면 크래시플랜 인프라는 한 사용자로부터 하루에 약 10기가바이트 정도의 데이터만을 전송 받을 수 있는 수준인 모양입니다. 그래서 여러 유저들은 크래시플랜이 의도적으로 전송 속도를 제한하는 것이 아닌가 하는 의심을 하기도 했지만 그들의 주장에 따르면 의도적으로 전송 속도를 제한하고 있지는 않다고 합니다. 그렇다면 그들의 인프라가 가진 근본적인 문제라고밖에 볼 수 없습니다. 다행히 제 경우에는 하루에 약 40-50기가바이트 정도를 보낼 수 있었는데 나중에 여러 상황에서 더 느리게 동작하는 상태로 미루어 모든 경험의 평균은 하루에 약 10기가바이트에 수렴할 수 있겠다는 생각이 들었습니다. 그래도 일단 첫 백업을 마치면 그 다음은 증분 백업을 수행하면 되니 이 정도 속도는 참을 수 있었습니다.

그런데 크래시플랜의 증분 백업 방식은 퍼포스 서버의 스토리지 포멧을 효율적으로 처리하지 못했습니다. 증분 백업은 말 그대로 이전 백업으로부터 변경된 파일만 추가로 백업해 네트워크 대역폭과 스토리지 사용량을 줄이는 전략입니다. 로컬 백업 두 개를 만드는데 사용하는 맥OS의 타임머신 백업 역시 매 백업 시점마다 변경된 파일을 새로 복사하고 변경되지 않은 나머지 모든 파일은 이전에 백업한 파일을 가리키는 심볼릭 링크를 만들 뿐입니다. 이에 비해 크래시플랜은 파일 단위로 증분하는 대신 블록 단위로 증분한다고 광고했습니다. 사실 일단 스토리지를 제한 없이 제공하기 시작하는 순간 그들이 증분 과정에서 스토리지를 얼마나 절약하는지는 사용자 입장에서 별 관심거리는 아니었습니다. 그들은 파일을 더 작은 단위로 나눠 비교한 다음 이전 상태와 변경된 단위만을 전송하는 방식으로 네트워크 대역폭과 그들의 스토리지를 절약한다고 말했고 크래시플랜이 실행될 때 작은 글씨로 미국 특허 번호를 표시하기도 했습니다. 이런 기술을 디듀플리케이션이라고 하는데 문제는 크래시플랜의 디듀플리케이션은 오직 같은 파일의 변화에만 적용된다는 점입니다. 가령 100메가바이트짜리 바이너리 파일이 있을 때 이 파일 전체에서 수 십 킬로바이트가 변경되었을 때 타임머신은 어쨌든 파일이 변경되었으니 100메가바이트짜리 파일을 복사하지만 크래시플랜은 파일을 여러 조각으로 나눠 비교한 다음 변경된 부분이 포함된 훨씬 작은 부분만 전송하고 기록합니다. 때문에 타임머신 백업이 100메가를 사용할 동안 크래시플랜은 실제로 변경된 수 십 킬로바이트가 포함된 단위 만큼만 사용합니다.

그런데 퍼포스 서버의 스토리지 포멧은 특히 바이너리 파일을 처리할 때 크래시플랜의 파일 하나 단위의 디듀플리케이션 시나리오의 적용을 받을 수 없는 방식을 사용합니다. 퍼포스 서버는 텍스트 파일은 RCS 포멧으로 기록해 그 스스로 변경사항만을 한 파일에 계속해서 기록합니다. 그래서 이 파일을 크래시플랜이 백업한다면 한 파일의 변경된 부분 만을 백업하므로 디듀플리케이션이 의도한 대로 동작합니다. 하지만 바이너리 파일은 파일 경로와 이름으로 디렉토리를 만든 다음 그 안에 매 버전마다 체인지리스트 번호를 붙여 별도의 파일로 저장해버립니다. 이는 마치 타임머신 백업이 파일이 변경될 때마다 파일 전체를 새로 복사하는 동작과 비슷합니다. 이전과 똑같이 100메가바이트 짜리 파일의 일부를 수정해 다시 커밋하면 퍼포스는 100메가짜리 새 파일을 저장합니다. 퍼포스 서버는 ‘Lazy Copy’ 전략을 통해 스토리지를 절약하기는 하지만 속도에 영향을 주는 적극적인 디듀플리케이션을 하지 않고 이는 퍼포스 서버 입장에서 별로 신경 쓸 일도 아닙니다. 다만 이를 크래시플랜으로 백업하면 크래시플랜은 오직 같은 파일이 수정되는 상황일 때만 디듀플리케이션이 동작하므로 퍼포스 서버에서 같은 파일의 새 버전이 나타나 새 파일이 생길 때는 서로 다른 두 파일의 차이가 거의 없다 하더라도 디듀플리케이션이 동작하지 않습니다. 그들 입장에서 저는 같은 파일이 수정되는 대신 영원히 파일이 추가되기만 하는 이상한 형태의 사용자일 겁니다. 앞서 제한 없는 용량을 제공하는 상황에서 디듀플리케이션은 사용자 입장의 장점이 아니라고 했는데 이런 상황은 그들의 인프라가 하루에 평균 10기가바이트 정도의 파일을 보낼 수 있는 수준이라는 점과 합쳐져 평일에 일어나는 일상적인 퍼포스 서버의 변경사항을 그날 안에 처리하지 못하는 상황을 만들었습니다. 초기 설정은 15분마다 백업을 수행하는 것인데 실제로는 주말에 퍼포스 서버 사용량이 줄어드는 사이에 간신히 백업이 최신 상태를 따라잡을 뿐이었습니다.

또 다른 문제는 크래시플랜이 적극적으로 그들의 스토리지를 절약하기 위해 설정한 예외 규칙 때문에 어떤 파일이 백업되었고 또 어떤 파일이 백업되지 않았는지 신뢰할 수 없게 된다는 점입니다. 두 가지 문제 상황을 겪었는데 먼저 저는 퍼포스 리파지토리에 temp라는 이름의 디렉토리가 있습니다. 말 그대로 임시 파일이 잠깐 거쳐 가는 장소입니다. 크래시플랜은 이런 디렉토리 이름을 임시 파일이라고 생각해 백업에 포함하지 않습니다. 사실 임시 파일이라면 그래도 됩니다. 다만 저는 저 디렉토리가 퍼포스 리파지토리 안에 있었고 일단 저 위치에 커밋된 파일은 파일을 이동하거나 삭제하더라도 그 경로에 기록이 유지되어야 합니다. 특히 퍼포스 서버가 스토리지를 절약하는 방식인 ‘Lazy Copy’는 퍼포스 상에서 파일을 삭제하거나 경로를 변경하더라도 이를 데이터베이스에만 기록하고 실제 파일을 옮기지 않습니다. 때문에 퍼포스 클라이언트 상에서, 그리고 워크스페이스 상에서는 다른 경로에 파일이 나타나더라도 서버 상에는 파일이 처음 커밋 된 경로에 남아 있게 됩니다. 이런 상황에서 함부로 temp 디렉토리를 백업에서 누락하면 미래에 복원할 때 이 경로의 모든 파일을 잃게 됩니다. 실은 복원할 때 잃는 것이 아니라 그 이전에 단 한 번도 백업되지 않았을 뿐입니다. 이 문제를 발견한 다음 지원팀에 문의해 이 경로를 예외로 하는 규칙을 제거해 백업 대상에 포함 시켰지만 그들의 예외 목록의 어느 규칙이 의도하지 않은 누락을 만들어낼지 알 수 없었습니다. 특히 백업된 파일의 전체 목록을 얻을 수 없었기에 이를 제가 수동으로 확인할 수도 없었습니다. 이 시점에서 크래시플랜에 대한 신뢰를 많이 잃었습니다.

두 번째 누락 사례는 inbox라는 디렉토리가 백업에 누락되어 있음을 이번에도 ‘우연히’ 발견한 것입니다. 이번에도 이전과 같은 원인일 거라고 생각해 그들의 예외 규칙을 주의 깊게 살펴봤지만 원인을 찾을 수 없었습니다. 이번에도 지원팀에 문의했는데 원인은 의외로 어이 없는 것이었습니다. 크래시플랜은 대략 1테라바이트 또는 100만 파일 당 1기가바이트의 메모리를 요구합니다. 가령 4테라바이트를 백업하기 위해 크래시플랜 클라이언트는 약 4기가바이트의 메모리가 필요합니다. 그리고 크래시플랜 클라이언트는 전체 가용 메모리 중 최대 25% 까지 사용하는 제한이 설정되어 있습니다. 제가 서버로 사용하는 구형 맥미니는 램이 8기가바이트 뿐입니다. 이는 부족하게 느껴질 수 있지만 제가 이 서버에서 수행하는 여러 작업을 별 무리 없이 수행해 냈습니다. 액티비티 모니터에 항상 메모리 압력이 높은 상태로 유지되고 거의 모든 시점에 최소 6기가바이트 이상의 스왑을 사용하고 있는 상황이기는 했지만요. 이 환경에서 크래시플랜은 가용한 램의 25%인 2기가바이트 까지만 사용할 수 있었고 이는 3테라바이트, 3백만 파일을 넘는 환경에서 전체 파일을 스캔해 목록으로 만들 수 없었습니다. 그래서 전체 파일을 스캔하다가 메모리가 부족해 스캔에 실패하기를 반복하며 특정 디렉토리가 누락되고 있었던 겁니다. 제가 우연히 발견한 디렉토리 뿐 아니라 다른 여러 경로가 메모리 부족에 의해 스캔이 중단되면서 누락되고 있었습니다. 지원팀으로부터 크래시플랜 클라이언트가 사용할 수 있는 최대 메모리 크기를 변경하는 커맨드를 안내 받아 문제를 해결했습니다. 그리고 이 과정에서 저는 크래시플랜이 자바 기반으로 동작한다는 점을 알게 되었습니다. 저는 크래시플랜 콘솔에 java mx 4096이라고 입력해 크래시플랜이 사용할 수 있는 최대 메모리 크기를 4기가바이트로 조정했습니다.

사실 이 정도면 좀 덜컹거리기는 했지만 매월 고정 비용을 지출하며 오프사이트 백업을 만들고 미래에 복원 시나리오를 단순하게 유지하는 목표를 달성했다고 평가할 수도 있습니다. 하지만 크래시플랜이 자바에 기반해 동작한다는 사실을 알게 된 다음 이 백업 소프트웨어가 백업 대상을 선택하고 이들을 실제로 백업하는 과정을 주의 깊게 조사하기 시작한 결과 크래시플랜의 파일 선택 과정은 미래에 이를 실제로 사용해 전체 복원을 하는 시나리오에 적용할 수 없다는 결론에 도달했습니다. 크래시플랜, 백블레이즈 백업 양쪽 모두 윈도우와 맥 환경에서 동작하지만 운영체제와 파일시스템이 제공하는 스냅샷 기능에 의존하지 않습니다. 윈도우에는 NTFS의 볼륨 쉐도우 카피, 맥에는 APFS의 스냅샷 기능이 있습니다. 이들은 어느 특정 시점에 스냅샷을 요청하면 파일시스템 전체에 걸쳐 그 시점의 파일을 얻을 수 있습니다. 백업 대상을 선택하고 백업을 수행할 때 파일시스템이 제공하는 스냅샷 기능에 의존해야 하는 이유는 상황에 따라 같은 앱이 사용하는 여러 파일이 서로 다른 시점에 백업 되어 일관성이 깨진 상태가 될 수 있기 때문입니다. 가령 퍼포스는 수 십 개의 데이터베이스 파일을 사용하며 상황에 따라 각기 다른 파일에 메타데이터를 기록합니다. 그래서 퍼포스 데이터베이스를 백업하려 한다면 모든 데이터베이스 파일에 걸쳐 특정 시점의 스냅샷에 의해 파일을 복사해야 합니다. 그렇지 않으면 어느 파일은 더 이른 시점에 백업이 완료되었지만 다른 파일은 더 늦은 시점에 복사를 시작해 미래에 이들을 복원해 퍼포스 서버를 시작하면 파일 간에 일관성이 깨져 복원에는 성공했지만 서비스를 복원할 수는 없는 상태가 될 수 있습니다.

이는 퍼포스 서버 뿐 아니라 같은 기계에서 돌고 있는 데이터베이스도 마찬가지입니다. 또 퍼포스 서버는 데이터베이스를 업데이트하고 스토리지 포멧에 따라 실제 파일도 기록해야 합니다. 만약 제가 파일을 디렉토리 단위로 정리하는 수준으로 사용한다면 파일시스템의 스냅샷 기능에 의존하지 않아도 별 문제가 되지 않습니다. 각 파일은 그저 어느 시점에 백업 되기만 하면 되고 그 시점이 서로 다르다 하더라도 이 파일들을 근거로 어떤 서비스가 동작하거나 별도의 메타데이터를 관리하지도 않으니 복원 후에도 아무런 문제도 일어나지 않습니다. 하지만 퍼포스에 의해 메타데이터와 실제 파일이 동기화된 모양으로 동작하는 상황에서 데이터베이스 파일끼리도 일관성이 깨질 가능성이 높을 뿐 아니라 데이터베이스와 실제 파일 사이에도 일관성이 깨질 가능성이 있는 방식의 백업을 용인할 수 없었습니다. 파일만 먼저 백업되고 데이터베이스가 나중에 백업되면 데이터베이스 상에 존재하지 않는 파일이 생기거나 그 반대의 상황이 일어나면 데이터베이스에만 존재하고 실제로는 찾을 수 없는 파일이 생길 수 있습니다. 크래시플랜은 파일시스템이 말하는 최근 변경된 파일을 모니터링하며 이들만 백업하지만 일정 기간마다 스토리지 전체를 스캔해 이전 과정에서 빠뜨린 파일을 찾는데 이런 과정이 필요한 이유 역시 파일시스템의 스냅샷 기능에 의존하지 않기 때문인 것 같습니다. 실은 백블레이즈 백업도 그렇고 여러 플랫폼을 지원해야 하는 입장에서 운영체제나 파일시스템에 종속된 기능을 사용하려면 소프트웨어의 유지보수에 더 큰 비용이 들 것을 예상할 수 있습니다. 그래서 유지보수 비용을 최소화 하기 위해 환경 별로 다른 파일시스템 기능에 의존하지 않기로 결정했을 수 있지만 적어도 제 시나리오에는 전혀 맞지 않았습니다. 이 오프사이트 백업은 이를 실제로 필요로 하는 상황에 파일 단위로 복원은 가능할 수 있지만 이를 기반으로 다시 서비스를 복구하는데는 실패할 수 있습니다.

아마 그저 디렉토리를 구분하고 각 디렉토리마다 파일이 있을 뿐인 대부분의 시나리오에는 크래시플랜과 백블레이즈 백업 같은 월 고정 비용으로 제한 없는 용량을 제공하는 서비스가 잘 동작하리라 생각합니다. 이런 상황에서는 파일 별로 백업 시점이 달라도 아무 문제 없이 복원할 수 있습니다. 일단 복원되기만 하면 이를 기반으로 서비스가 동작하거나 하지도 않으므로 여러 파일에 걸친 일관성이 필요하지도 않습니다. 하지만 제 시나리오는 규모가 크지는 않지만 라이브 서버를 백업하려고 했습니다. 그래서 사용 중인 파일을 백업할 수 있는 크래시플랜을 선택했습니다. 하지만 근본적으로 이 서비스는 파일시스템의 스냅샷 기능에 의존하지 않기에 파일을 백업하더라도 여러 파일에 걸친 일관성을 보장하지 못하며 이는 미래에 이 백업으로부터 실제 복원을 해야 하는 상황에서 파일을 복원하기는 했지만 정작 서비스를 재개할 수 없는 상황에 처하게 만들 가능성이 있습니다. 앞서 저는 오프사이트 백업으로 전체 복원을 해야 하는 상황에 처한 저를 믿을 수 없기에 복원 과정이 최대한 단순해야 한다고 말했습니다. 그래서 데이터베이스를 백업하는 일반적인 규칙 대신 그저 파일을 복원하고 서비스를 재개하면 되는 간단한 시나리오를 생각했습니다. 크래시플랜은 이를 달성할 수 있을 것처럼 보였지만 실제로는 그렇지 않을 가능성이 높고 저는 이 서비스를 오프사이트 백업에 계속해서 사용할 수 없었습니다.

크래시플랜을 사용해서는 안된다고 생각하는 이유를 정리하겠습니다. 첫째. 전송 속도가 너무 느려 첫 백업이 너무 오랜 세월이 걸릴 뿐 아니라 파일 변경이 많을 경우 백업이 실제 상태를 따라잡지 못합니다. 둘째. 상황에 따라 이들의 디듀플리케이션이 거의 동작하지 않을 수 있는데 이는 첫 번째 문제인 느린 속도와 합쳐져 백업이 끝나지 못하게 만들 수 있습니다. 셋째. 백업 예외 규칙에 따라 의도하지 않게 백업 되지 않는 파일이 있을 수 있는데 이를 검증할 방법이 없어 백업을 신뢰할 수 없습니다. 넷째. 여느 백업 소프트웨어에 비해 훨신 많은 메모리를 요구하며 메모리가 부족해 작업에 실패하는 상황을 보고하지 않은 채 그냥 백업이 정상 동작하지 않는 상태를 유지합니다. 다섯째. 파일시스템이 제공하는 스냅샷 기능에 의존하지 않아 파일의 백업 시점 사이에 일관성을 보장할 수 없습니다.

마지막으로 이건 너무 지나친 의심일 수 있다고 생각하지만 보안 문제를 고려하면 한번 의심해볼 수밖에 없는데 이들은 백업을 암호화 하고 있다고 주장하지만 제가 사용한 ‘프로페셔널’ 요금제에서도 제가 암호화 키를 설정할 수 없었습니다. 이들의 주장에 따르면 백업은 암호화되며 암호화 키는 제 계정 정보로 암호화 된다고 합니다. 즉 제가 웹 기반의 로그인을 통해 올바른 크리덴셜을 제시하면 이를 기반으로 암호화 키를 복호화 해 백업과 복원에 사용한다는 겁니다. 이런 수준의 키 관리는 여러 가지 문제를 일으킬 수 있습니다. 일단 키가 저에게 있지 않고 그들의 서버에 있습니다. 또한 적당한 권한이 있는 누구라도 암호화 키에 대한 복호화 과정에 개입해 키를 입수할 수 있습니다. 또 제 크리덴셜은 분명 복구 과정이 있습니다. 이메일을 통해 링크를 받아 패스워드를 복구하는 과정이 있을텐데 이 과정에서 암호화 키는 큰 위험에 처하게 됩니다. 제 관점에서 근본적으로 이런 암호화 키 관리는 암호화를 하지 않는 것과 비슷합니다. 데이터센터에 대한 물리적인 침입이 일어나는 상황에 저항할 수 있겠지만 내부로부터 일어나는 공격에는 저항할 수 없습니다.

이런 고민과 걱정 끝에 크래시플랜을 사용하지 않기로 결정했고 오프사이트 백업을 이전하고 있습니다. 만약 저와 비슷한 시나리오에 기반해 백업하려 하거나 저와 비슷한 고민, 가령 백업 시점의 일관성, 실제 보안 사고에 저항할 수 있는 제대로 된 암호화에 신경이 쓰이는 분들이라면 크래시플랜을 사용해서는 안됩니다. 크래시플랜은 아주 좁은 시나리오에서만 정상 동작할 겁니다.