크래시플랜 여러 달 사용기

백업에는 ‘3, 2, 1 원칙’이 있다고 합니다. 최소 세 개의 독립된 복사본이 있어야 하고 이들은 두 가지 서로 다른 미디어를 사용해야 하며 이 중 하나는 다른 장소에 있어야 하는 것입니다. 지난 개인 백업 전략에서도 이 원칙의 일부를 지키고 있지만 한 가지를 지키지 못했음을 설명했습니다. 적어도 세 개의 독립된 복사본은 두 개의 독립된 하드디스크에 타임머신을 사용해 만들었습니다. 나머지 하나는 크래시플랜이라는 유료 서비스를 통해 만들었습니다. 하지만 두 가지 미디어를 사용할 수는 없었습니다. 세 개의 복사본 중 첫 두 개는 서로 다른 하드디스크를 사용합니다. 크래시플랜을 사용한 마지막 한 개의 복사본은 제가 직접 확인할 수는 없지만 아주 높은 확률로 하드디스크를 사용할 겁니다. 아마존 클래셔처럼 직접 자기테이프를 사용한다고 알려진 서비스를 사용하지 않는 이상 고용량 하드디스크가 흔한 현대에 서로 다른 두 가지 이상의 미디어에 백업하라는 원칙을 지키지는 어려울 것 같습니다. 하지만 마지막 원칙인 한 복사본은 다른 장소에 위치해야 하는 것은 크래시플랜 서비스를 사용함으로써 달성하고 있습니다. 사실 이 서비스를 사용하더라도 정말로 이 서비스의 복사본이 마지막 하나 남은 복사본이어서 이를 기반으로 복원하는 일이 일어나지 않는 것이 가장 좋고 아마 대부분은 그럴 겁니다. 하지만 어떤 이유로 서비스 중인 스토리지, 두 개의 백업을 모두 사용할 수 없게 된다면 마지막으로 믿을 것은 크래시플랜 뿐입니다.

지난 백업 서비스 크래시플랜 사용기에서 이 서비스를 사용하기 시작한 다음 몇 주가 지난 다음 그 시점까지 제 경험을 공유했습니다. 몇 가지 눈에 띄는 단점이 있지만 근본적으로 고정 비용에 용량 제한 없이 백업할 수 있다는 장점이 자잘한 단점을 덮을 수 있다는 결론을 내렸습니다. 이 결론은 이 글을 타이핑하는 지금도 크게 변하지는 않았습니다. 하지만 지난번 몇 주 동안 사용할 때 가진 의견과 몇 달 동안 사용한 다음 가진 의견은 조금 달라졌습니다. 만약 지금 누군가가 오프사이트 백업 서비스로 크래시플랜을 추천하느냐고 묻는다면 금전적으로, 그리고 복구 과정을 단순하게 만든다는 측면에서는 추천하지만 오늘 이 글에 이야기할 여러 가지 특징과 단점을 살펴본 다음에 사용을 결정하라고 말할 것 같습니다. 결론부터 말하면 크래시플랜은 어느 정도 범위 안에서는 그들이 광고한 대로 동작하지만 백업 결과가 예상과 크게 다를 수 있으며 이를 검증할 적절한 방법을 제공하지 않습니다. 또 지독하게 느린 백업, 복원 속도는 복원이 가능하기는 하지만 생각보다 큰 인내를 요구할 수 있으며 온프레미스 환경에서 동작하는 퍼포스 서버를 효율적으로 백업하기에 크래시플랜의 동작이 잘 어울리지 않습니다. 크래시플랜 계약이 끝나면 비용이 증가하더라도 백블레이즈 B2와 Arq Backup 같은 일정 수준 이상의 품질이 보장되는 다른 방법을 고려할 계획입니다.

먼저 크래시플랜에 대해 소개하면 월 고정 비용으로 용량 제한 없이 백업 할 수 있는 서비스입니다. 비슷한 서비스에는 백블레이즈 백업이 있습니다. 둘 다 월 고정 비용으로 용량 제한 없는 백업 서비스를 제공합니다. 영량 제한이 없다고 해서 온갖 스토리지에 있는 파일을 마구 업로드 할 수 있지는 않습니다. 이들이 용량 제한이 없다고 광고할 수 있는 이유는 이들이 제공하는 서비스가 아카이빙이 아니라 백업이기 때문입니다. 여기서 이 둘의 차이를 간단히 짚고 넘어가면 아카이빙은 파일을 실제로 옮기는 것입니다. 서비스에 직접 사용되는 빠르고 비싼 스토리지로부터 더 저렴한 스토리지로 파일을 옮겨 비용을 낮춥니다. 또 아카이빙은 아카이빙 시점과 범위를 사람이 직접 결정하고 작업을 수동으로 하며 이 과정은 자동화 할 수 없습니다. 가령 어떤 파일 뭉치에 자주 접근하지 않으리라는 판단은 사람이 직접 내려야 하며 이 판단에 따른 아카이빙 역시 수동으로 이루어집니다. 이에 비해 백업은 파일을 옮기지 않고 복사합니다. 어떤 파일을 복사할지 처음에 결정할 수는 있겠지만 한 번 결정하고 나면 그 다음에는 모든 작업이 자동으로 수행됩니다. 파일이 백업 되더라도 여전히 서비스에 직접 사용되는 빠르고 비싼 스토리지에 남아 있습니다. 파일을 실제로 옮기지 않기 때문에 작업을 자동화 할 수 있고 자동화 되지 않았다면 이를 백업이라고 말하기 어렵습니다. 크래시플랜은 백업 서비스로 파일을 복사하는 방식으로만 동작합니다. 때문에 아주 큰 데이터를 크래시플랜에 보낸 다음 로컬에서 삭제하는 식으로는 사용할 수 없습니다. 반드시 백업하려는 기계에 모든 데이터를 기록한 상태여야만 이에 근거해 백업이 동작합니다. 또한 양쪽 모두 네트워크 스토리지(NAS)를 지원하지 않습니다. 이런 특징 때문에 용량 제한이 없더라도 아주 많은 파일을 보내도록 설정하기는 쉽지 않습니다.

이런 서비스들이 수익을 내는 방법은 여러 가지 구독 서비스와 비슷합니다. 구독 서비스의 가격은 모든 고객들이 이 가격에 비해 더 적은 서비스만을 사용할 것을 감안해 책정됩니다. 가령 책을 무제한으로 읽을 수 있는 구독 서비스가 있다고 해 봅시다. 이 서비스는 고객들이 단위 기간 동안 새로운 책을 열 때마다 출판사에 일정 비용을 지불합니다. 하지만 고객이 단위 기간 동안 읽을 수 있는 책과 이로 인해 발생하는 비용에 비해 이용요금이 더 높아 이 차이로부터 수익이 발생합니다. 누군가는 자신이 지불한 비용에 비해 더 많은 돈을 출판사에 지불하도록 만들 수 있습니다. 하지만 이런 고객의 수가 많지 않기 때문에 결과적으로 수익이 나게 됩니다. 이런 용량 제한이 없는 백업 서비스 역시 마찬가지입니다. 가령 오브젝트 스토리지 서비스인 백블레이즈 B2 가격은 2024년 12월 말 현재 1테라바이트에 월 6달러입니다. 같은 시점에 크래시플랜의 이용 요금은 월 8달러입니다. 만약 크래시플랜이 백블레이즈 B2 같은 서드파티 오브젝트 스토리지를 사용한다고 가정하면 크래시플랜은 고객 한 명이 월 이용요금을 지불한 다음 월 약 1365기가바이트 미만의 스토리지를 사용하면 이 고객으로부터 수익을 낼 수 있습니다. 실제로는 스토리지를 직접 구축할 것이기에 원가는 이보다 더 낮아집니다. 고객들이 대체로 원가에 비해 더 적은 스토리지만을 사용하기에 수익을 내는 구조입니다. 특히 학교나 회사 같은 단체에서 서비스를 사용하면 더더욱 요금 대비 실제 사용하는 스토리지 양이 줄어들어 더 큰 이익을 낼 수 있습니다. 때문에 이 서비스는 어떻게든 고객이 더 적은 스토리지를 사용하도록 해야 합니다.

이를 위해 크래시플랜은 용령을 직접 제한하지는 않지만 여러 가지 제한을 통해 스토리지 사용량을 줄입니다. 먼저 위 규칙에 해당하는 파일을 백업하지 않으며 이를 백업하도록 설정할 수 없습니다. 사실 이 경로들은 모두 백업이 없어도 다운로드를 통해 재구축 할 수 있는 데이터이기 때문에 백업 되지 않아도 큰 상관 없는 것이 사실입니다. 다음으로 각 파일이 변경될 때 변경된 파일 전체를 업로드하고 저장하는 대신 파일을 작은 블록 단위로 나눠 변경된 블록만을 업로드하고 서버에서도 변경된 블록만 저장하는 방식으로 스토리지 사용량을 줄입니다. 크래시플랜 서버에서 한 파일은 파일 그대로 기록되지 않고 여러 블록으로 구분되어 저장된 다음 각 블록을 가리키는 정보로만 저장됩니다. 이 파일이 일부 수정되어 수정된 블록이 업로드 되면 파일의 새로운 버전은 변경되지 않은 블록과 변경된 블록을 가리키는 정보에 의해 저장됩니다. 이후 파일을 복원할 때 이 파일을 요청하면 서버는 저장된 파일 전체의 복사본을 줄 수 없습니다. 그렇게 저장하지 않으니까요. 대신 파일을 구성한 각 블록을 연결해 파일을 재구축 한 다음 이를 다운로드 하게 해 줍니다. 그래서 네트워크 속도에 관계 없이 크래시플랜으로부터 파일 복원은 느리게 동작할 수밖에 없습니다. 마지막으로 변경할 수 없는 리텐션 정책을 적용합니다. 삭제된 파일은 90일 동안 유지된 다음 삭제됩니다. 그래서 아주 오래된 파일이 계속해서 스토리지를 점유하는 상황을 방지합니다. 이런 방법들을 통해 크래시플랜은 월 고정 비용을 받으면서도 용량 제한 없이 운영할 수 있는 것 같습니다.

하지만 이런 동작 방식은 근본적으로 크래시플랜의 백업을 신뢰하기 어렵게 만듭니다. 최근에 저는 우연히 퍼포스 서버의 temp 경로가 백업에 없다는 사실을 발견했습니다. 원인을 살펴보니 앞서 소개한 크래시플랜의 백업 제외 정책에는 ‘temp’라는 이름의 디렉토리가 포함되어 있었는데 이 이름의 디렉토리는 일반적으로 임시 파일을 보관하는데 사용하므로 이 정책이 크게 이상하지는 않습니다. 다만 저는 이 이름의 디렉토리를 퍼포스 상에서 임시 디렉토리로 사용하고 있다는 점이 문제가 되었습니다. 퍼포스는 근본적으로 파일을 삭제하는 개념이 없습니다. 관리자 명령으로 파일을 삭제할 수 있기는 하지만 사용자 관점에서는 파일을 삭제하더라도 파일에 삭제되었다고 표시할 뿐 실제 서버에서 삭제하지 않습니다. 때문에 히스토리를 살펴보고 이전에 삭제한 파일을 아무 문제 없이 복원할 수 있습니다. 또한 퍼포스 서버는 서버 스토리지를 절약하고 또 속도 저하를 막기 위해 파일을 옮기더라도 데이터베이스에 옮겼다고 표시할 뿐 실제 파일을 옮기지 않습니다. 그들은 이를 ‘Lazy copy’라고 부릅니다. 어떤 파일을 ‘temp’ 경로에 추가한 다음 파일을 삭제하거나 다른 위치로 옮겨 퍼포스 클라이언트 상에 이 파일이 보이지 않더라도 서버에서 실제 파일은 여전히 그 자리에 있습니다. 그래서 ‘temp’ 디렉토리는 일반적으로 임시 파일을 보관하는 용도로 사용되며 이를 백업할 필요가 없지만 저는 이 디렉토리를 백업해야 했습니다. 이 경로를 통해 처음 추가된 파일은 계속해서 그 경로에 남아 다른 경로로 옮겨진 파일을 요청할 때 계속해서 사용되어야 하기 때문입니다. 이 상황을 해결하기 위해 지원 티켓을 발행해 지원팀에서 직접 백업 제외 규칙을 편집해 이 디렉토리를 포함하게 만들어야 했습니다. 지원 요청과 제외 규칙 변경은 무리 없이 이루어졌지만 어떤 디렉토리가 백업에 포함되고 또 포함되지 않을지 신뢰할 수 없게 만드는 사건이었습니다.

또 다른 백업되지 않은 경로를 우연히 발견했는데 이번에는 백업 제외 규칙에 포함되어 있지 않은 경로였습니다. 원인을 찾으려고 한참 노력해 봤지만 제 수준에서는 더 이상 할 수 있는 일이 없어 이번에도 지원 티켓을 발행했습니다. 지원팀은 로그를 살펴보고 최근 전체 파일 스캔이 실패한 채 종료되었음을 발견하고 크래시플랜 클라이언트 앱이 사용하는 메모리 제한을 늘려볼 것을 제안합니다. 몇몇 백업 소프트웨어의 광고 문구에는 그들의 클라이언트 앱이 플랫폼 별 네이티브 환경에서 동작하도록 개발되었고 특히 자바 같은 서드파티 환경에 의존성이 없음을 강조하곤 합니다. 확실히 윈도우나 맥을 사용하면서 자바에 의존하는 앱을 사용하는 경험은 대체로 끔찍했습니다. 앱은 자바를 찾을 수 없다며 대책 없이 죽기 일쑤였고 이를 해결하기 위해 자바를 직접 설치하려고 보면 수많은 버전 중 어떤 것을 설치해야 할 지 알기 어려웠습니다. 인터페이스는 항상 쓰레기 같고 몇 박자 느리게 동작했으며 시도 때도 없이 제가 어떻게 할 수도 없는 자바 에러를 한 가득 쏟아내고 죽기 일쑤입니다. 그래서 ‘자바에 의존하지 않는다’는 문구는 꽤 의미 있는 것이었습니다. 크래시플랜은 그런 문구가 없었고 또 클라이언트 앱이 꽤 깔끔한 모양이었을 뿐 아니라 명시적으로 자바를 찾지 않았기 때문에 자바에 기반해 동작할 거라고 예상하지 않았습니다만, 지원팀이 저에게 크래시플랜 클라이언트 앱이 사용할 수 있는 메모리 제한을 확장하는 명령어를 입력해보라고 했을 때 저는 이 앱이 자바에 기반하고 있다는 사실을 깨달았습니다. 그들이 저에게 알려준 명령어는 java mx 4096 이었기 때문입니다.

크래시플랜은 온라인 문서 Adjust app settings for memory usage with large backups에서 1테라바이트 또는 1백만 파일 당 약 1기가바이트 정도의 메모리가 필요하다고 말합니다. 제가 크래시플랜을 사용해 백업하려는 기계는 현재 3테라바이트를 조금 넘게 사용하고 있고 파일 수는 3백만 파일을 넘고 있었습니다. 문서에 의하면 최소한 3기가바이트 이상의 메모리가 필요합니다. 그런데 크래시플랜이 사용하는 자바 환경은 물리 메모리 용량의 최대 25% 까지만 사용하도록 설정되어 있었고 이 기계는 M1 맥미니로 램은 8기가 뿐이었습니다. 때문에 크래시플랜은 약 2기가바이트 까지만 메모리를 사용할 수 있었고 이 때문에 파일 스캔에 실패하고 있었던 것 같습니다. 여러 가지 의문이 동시에 들었습니다. 일단 어지간한 소프트웨어는 파일시스템의 입출력 기록에 의존하기만 해도 변경되는 모든 파일의 목록을 얻을 수 있었습니다. 가령 파일 이름 검색 소프트웨어인 ‘Everything’은 아무런 인덱싱 없이 그저 파일시스템의 변경사항에 의존해 파일 이름을 순식간에 검색해 냅니다. 맥에서 타임머신 백업 역시 첫 백업 이후에는 변경된 파일을 순식간에 찾아내 이들만 백업합니다. 타임머신 백업이 파일시스템 전체를 스캔하는 일은 첫 백업 이후에는 없습니다. 하지만 크래시플랜의 온라인 문서를 보면 크래시플랜은 파일시스템의 변경사항에 의존하면서도 동시에 일정 기간마다 전체 파일을 스캔해 빠뜨린 파일을 찾아낸다고 합니다. 애초에 이 동작 자체를 이해할 수 없었습니다. 또 다른 의문은 백업 용량과 파일 수 증가에 따라 곧이곧대로 더 많은 메모리를 사용한다는 점입니다. 계속해서 용량이 증가해 개인 백업 전략에 소개한 메인 스토리지 용량인 10테라바이트를 백업하려면 10기가바이트의 메모리가 필요하다는 이야기인데 이건 이상해도 좀 많이 이상하다는 생각이 들었습니다. 또 파일 스캔을 하더라도 여기에 실패하면 사용자에게 어떤 방식으로든 피드백을 줬어야 합니다. 그냥 조용히 스캔에 실패하고 조용히 로그를 전송한 채 파일을 백업하지 않고 있으면 이 서비스를 백업 소프트웨어로써 신뢰할 수 있을까요?

결국 지원팀이 알려준 명령어를 입력하고 크래시플랜 클라이언트를 재시작한 다음 파일 스캔이 끝날 때까지 몇 시간을 기다린 끝에 앞서 누락되어 있던 경로가 백업되기 시작하는 것을 확인했습니다. 백업 과정 역시 파일을 블록 단위로 나눈 다음 서버로부터 받은 블록 목록과 비교해 변경된 부분만 전송하는 과정을 거치기에 백업은 대단히 느리게 동작합니다. 인터넷 상의 다른 크래시플랜 사용 사례를 살펴보면 이들의 데이터센터 인프라의 한계로 하루에 약 10기가바이트 정도를 전송할 수 있을 뿐이어서 대용량 백업에 어려움이 있다는 내용이 있습니다. 정확히 속도를 확인해본 것은 아니지만 제 경우에는 3테라바이트를 백업하는데 약 두 달 정도가 소요되었는데 이를 속도로 환산해보면 하루에 약 50기가바이트 정도를 전송할 수 있었습니다. 이 역시 빠른 속도와는 거리가 너무나 멉니다. 속도야 어찌됐든 월 고정 비용에 용량 제한이 없다는 특징 만으로 사용하기 시작한 서비스이니 백업 속도에는 일단 불만을 가지지 않기로 했습니다. 몇 주에 한 번 시도하는 전체 복원은 이보다는 훨씬 더 빠른 속도로 동작했기 때문이기도 합니다. 하지만 앞서 겪은 임시 디렉토리 누락과 이어서 겪은 스캔 실패로 인한 특정 디렉토리 누락 사건은 이 서비스가 과연 제가 의도한 모든 파일을 백업하고 있는 것이 맞는지, 만약 정말 이 서비스를 통해 전체 복원을 시도해야 하는 상황이 발생할 때 이 서비스로부터 복원한 파일에 기반해 다시 서비스를 시작할 수 있을지 완전히 신뢰할 수 없게 되었습니다.

이렇게 한 번 깨진 신뢰는 크래시플랜에 백업된 모든 파일 목록과 백업 되는 기계의 모든 파일 목록을 하나하나 비교할 생각을 하게 만들었습니다. 하지만 크래시플랜은 어떤 방법으로도 백업된 모든 파일 목록을 텍스트 포멧으로 얻을 수 없었습니다. 온라인 문서에서 그저 복원 메뉴에 표시되는 파일 목록을 참고하라고 말할 뿐입니다. 이미 3백만 파일이 넘는데 이 모든 파일을 GUI를 통해 하나하나 확인하는 것은 말이 안 됩니다. 그나마 크래시플랜 클라이언트는 로컬에 백업 로그를 남겨 놓고 있어 이 로그에 기반해 백업된 파일을 확인해 보려고 했습니다. 하지만 이 로그 역시 지난 완료된 백업 이후 이번 세션에 새로 백업한 파일 목록을 가지고 있을 뿐이었습니다. 그래서 전체 파일 목록과 비교할 때 없는 파일이 엄청나게 많이 나타났고 이 데이터는 쓸모가 없었습니다. 이제 제가 가진 방법은 그저 크래시플랜이 그들의 백업 제외 정책과 사용자에게 말해주지 않는 스캔 실패에 따른 백업 누락 가능성에도 불구하고 제가 지정한 경로 전체를 예상대로 백업하고 있으리라고 믿는 것 이외에 다른 방법이 없으며 그나마 확인하고 싶으면 백업 전체를 복원한 다음 복원된 파일 목록과 비교하는 것이 거의 유일합니다. 여기에는 1테라바이트 당 거의 이틀에 달하는 복원 시간이 필요하기 때문에 현재 백업된 3테라바이트를 복원하는데는 거의 일주일이 필요하며 단순히 제 로컬의 파일 목록과 백업된 파일 목록을 비교하기 위한 환경을 갖추는데만 이 정도 시간이 필요합니다. 하지만 저는 이 절차를 통해 백업을 확인할 겁니다. 크래시플랜은 이미 백업에 대한 신뢰를 상실한 상태입니다. 이 확인이 끝난 다음에도 여전히 일정 기간마다 전체 복원을 통해 파일 목록을 비교하기를 반복할 겁니다.

크래시플랜은 월 고정 비용에 제한 없는 용량을 제공하는 오프사이트 백업 서비스입니다. 이들이 수익을 내는 방법에 대해 앞서 설명했는데 인터넷을 통해 검색할 수 있는 사용 사례들은 이들이 주장하는 ‘제한 없는 용량'에는 사실 제한이 있음을 드러냅니다. 10테라바이트를 넘어서면 급격한 성능 감소가 발생하며 50테라바이트를 백업했던 사용자는 회사로부터 백업 크기를 줄일 것을 권고 받았을 뿐 아니라 지정된 기한 내에 용량을 줄이지 않으면 계정을 정지할 거라는 메일을 받았다고 합니다. 사실 제한 없는 용량이란 존재할 수 없음을 이해합니다. 그렇다면 최대 사용 가능한 용량의 한계를 제대로 고지해야 한다고 생각합니다. 여기서 크래시플랜에 백업 가능한 최대 용량은 약 10테라바이트 선이라고 봐야 하는데 실제로는 이 선을 넘길 수 있지만 이 정도 용량을 넘어서면 급격한 성능 저하를 경험한 기록이 있다는 점이 문제입니다. 이들이 운용하는 인프라와 소프트웨어는 지속적인 용량 증가를 감당하지 못합니다. 이런 점을 종합할 때 크래시플랜은 월 고정 비용에 최대 약 10테라바이트 까지 백업할 수 있는 서비스이며 선택한 백업 대상의 모든 파일이 백업되었는지 여부를 확인할 방법은 오직 전체 복원을 시도한 다음 이들을 비교하는 것 밖에 없는 서비스입니다.

이런 납득하기 쉽지 않은, 그리고 당혹스러운 경험에도 불구하고 남은 몇 달에 걸쳐 크래시플랜을 계속해서 사용할 겁니다. 하지만 이 계약이 끝나고 나면 크래시플랜을 연장하지는 않을 생각입니다. 백블레이즈 백업은 사용 중인 파일을 백업하지 않아 복원할 때 복잡도를 높이는 문제가 있고 크래시플랜은 지금까지 언급한 온갖 이상한 문제가 있습니다. 결정적으로 백업을 신뢰할 수 없고 이는 오프사이트 백업으로써 치명적입니다. 현재 계획은 크래시플랜에 계약이 끝나면 비용이 증가하더라도 용량에 따라 비용을 지불하는 오브젝트 스토리지에 백업할 생각입니다. 뭔가 싼데는 이유가 있고 크래시플랜은 왜 이 서비스가 고정 비용에 용량 제한이 없다고 광고하는지 깊이 이해할 수 있었습니다. 크래시플랜은 월 고정 비용에 최대 10테라바이트 정도를 백업할 수 있으며 백업된 상태를 신뢰할 수 없는 서비스입니다. 만약 이 서비스를 사용하려고 한다면 이 점에 유념하세요.