개인 백업 전략

얼마 전 술자리에서 이런 저런 온갖 쓸 데 없는 이야기를 하다가 각자의 백업 전략에 대해 이야기했습니다. 컴퓨터를 사용해 생계를 지탱하는 직업을 가진 이상 컴퓨터를 통해 만들어낸 여러 가지 데이터를 안전하고 유지하는 일은 이전에 비해 좀 더 중요해졌다고 생각합니다. 게다가 이제는 커다란 파일을 만들어내는 기계가 많습니다. 우리들이 내 분신을 넘어 사실상 나 자신이나 다름 없는 스마트폰에는 고화질 사진과 영상을 만들어내는 카메라가 포함되어 있습니다. 우리들이 매일같이 재생하는 음악과 영상은 이전 시대에 비해 점점 더 커지고 있습니다. 아이들이 있는 집은 아이들이 자람에 따라 계속해서 만들어지는 사진과 영상을 안전하게 보관할 방법을 몰라 어려움을 겪기도 하고 또 이들을 안전하게 보관해줄 수 있을 거라고 믿었던 서비스가 실은 그리 믿을 만 하지 않았다는 사실이 밝혀지면서 의도하지 않은 큰 데이터 손실을 겪기도 합니다. 사실 현대에 개인 수준에서 1TB 수준의 데이터를 안전하게 보관하기는 그렇게 까지 어려운 일은 아닙니다. 그저 드랍박스, 원드라이브, 아이클라우드 드라이브 같은 서비스를 구독하고 착실히 매달 요금을 지불하면 내 컴퓨터에 무슨 일이 일어나더라도 그저 기계를 다시 구입하는데 비용을 지불하면 그 모든 데이터를 전혀 잃지 않고 복원할 수 있습니다. 그래서 개인적으로 이 정도 범위의 데이터를 보관하기 위해 복잡한 방법을 고민하기 보다는 간단한 서비스를 구독하는데 돈을 내는 쪽을 추천하곤 합니다.

함께 술을 마시던 아이들의 아버지로부터 구글 포토에 사진을 맡겼다가 예상치 못한 유실을 겪은 이야기를 들었습니다. 구글 포토는 처음 서비스를 시작할 때 사진을 제한 없이 올릴 수 있었습니다. 이 점이 너무나 강력한 나머지 초기에 고객을 많이 끌어모으지 않았을까 싶습니다. 꽤 긴 세월 동안 이 정책을 유지했기에 이 서비스에 아주 많은 사진을 의탁한 사람들이 있었고 저도 마찬가지입니다. 이 말이 과거형이 아닌 이유는 지금도 이 서비스를 특정 용도로는 사용하고 있기 때문입니다. 무슨 방법을 사용하든 무료로 거대한 스토리지가 필요한 사진 서비스를 계속해서 운영할 수는 없는 법입니다. 구글 포토는 몇 년 전 특정 시점까지 업로드 된 사진까지는 제한 없이 보관하는 정책을 유지하지만 그 다음부터는 스토리지에 요금을 지불하거나 사진과 영상을 압축해서 보관할 거라고 공지했습니다. 하지만 이런 공지는 실제 서비스를 사용하던 사람들에게 잘 가 닿지 않는 법입니다. 앱을 실행할 때마다 계속해서 이 공지가 나타나고 또 메일로도 여러 차례 공지가 전달되었습니다만, 우리들은 지난 오랜 세월에 걸친 컴퓨터 사용 경험을 통해 앱에 나타나는 예상하지 않은 모양의 메시지, 메일로 전달되는 메시지 따위는 보통 완전히 쓸모 없는 것으로 인식하도록 훈련되었습니다. 앱에 나타나는 메시지는 쓸데없는 이벤트인 주제에 ‘오늘 하루 안보기’ 같은 기만적인 체크박스를 내놓고 있어 내용에 관계 없이 무조건 인터페이스를 닫도록 훈련되었고 회사로부터 도착하는 메일은 대체로 전혀 쓸모 없는 개인정보 이용 내역 안내 같은 내용일 뿐이어서 즉시 삭제하도록 훈련되었습니다. 이렇게 주요 공지 전달 수단이 모두 오염된 상황에서 구글 포토의 서비스 변경은 모든 사용자들에게 잘 전달되지 않았을 겁니다. 이 이야기를 하고 있는 그 아버지에게도 이 사실이 잘 전달되지 않았고 별다른 대비를 하지 않았던 모양입니다.

서비스는 특정 날짜가 지난 다음에도 똑같이 동작하는 것처럼 보였을 겁니다. 의도하지 않게 몇 메가 짜리 사진을 올리면 몇 백 킬로바이트 수준으로 작게 축소되어 저장되고 있었지만 관심을 가지고 인터페이스를 지켜보지 않는다면 이를 인식하기는 쉽지 않습니다. 그렇게 한참 시간이 흐른 다음에 이 사진을 받아 다른 용도로 사용하려고 할 때 이 분은 비로소 사진들의 해상도가 인쇄에는 도저히 사용할 수 없는 수준으로 축소되었을 뿐 아니라 원본은 완전히 제거되었다는 사실을 깨닫습니다. 서비스에 올린 사진은 한동안 컴퓨터에 남겨 두다가 스토리지가 부족해질 때 오래된 순서대로 삭제했습니다. 그래도 괜찮다고 생각했습니다. 모든 사진은 여전히 구글 포토에 안전하게 보관되어 있고 원할 때 다운로드 할 수 있으리라 생각했으니까요. 사실은 그렇지 않았습니다. 몇 년에 걸쳐 올린 사진이 모두 모니터를 통해 보는 것 이외의 용도로는 사용할 수 없는 수준으로 축소되어 보관되고 있다는 사실을 깨달은 이 분은 지금부터라도 사진을 직접 관리하기로 마음먹습니다. 하지만 문제는 그리 간단하지 않았습니다. 들어갈 때는 마음대로였지만 나올 때는 그렇지 않았기 때문입니다. 구글은 테이크아웃 서비스를 제공하지만 컴퓨터를 전문적으로 다루지 않는다면 테이크아웃 서비스를 통해 돌려 받은 파일을 사용하기는 어렵습니다. 구글은 여러 가지 이유로 사진 파일 자체와 사진의 메타데이터를 구분해서 보관했을 겁니다. 그런데 테이크아웃 서비스를 통해 파일을 돌려줄 때도 이 상태 그대로 파일을 돌려줍니다. 사진과 메타데이터는 서로 분리되어 있습니다. 사진은 아무 메타데이터 없는 상태로, 이들이 가지고 있던 메타데이터는 별도의 파일에 기록되어 있습니다. 그리고 일반적은 수준에서 이들을 다시 합쳐 여러 서비스에서 자동으로 날짜와 시간에 따라 정리하고 또 사진이 찍힌 위치에 기반해 분류하는 서비스에 적용 시키기 위해서는 상당히 고통스러운 과정이 필요합니다.

사실 이 상황에 컴퓨터를 적당히 다루는 개인 수준에 사진을 보관하기에 가장 단순하고 안전한 방법은 그냥 구글로부터 스토리지를 구입해 구글 포토에 원본 사진을 업로드 하고 그대로 두는 것입니다. 애플이 사진 앱을 아무리 지지고 볶고 난리를 쳐도 여전히 구글 포토만큼 사진을 잘 정리해 주지도 않고 검색이 잘 되지도 않습니다. 앞서 구글 포토를 핵심 사진 저장 서비스로 여기고 있지 않으면서도 여전히 구글 포토에 사진이 압축된 상태로 보관된다는 사실을 알면서도 이를 사용하는 이유는 검색이 압도적으로 잘 되기 때문입니다. 그런데 스토리지에 돈을 지불하려고 마음 먹더래도 이들이 제시하는 가격은 썩 합리적이지 않습니다. 처음 몇 백 기가 단위에서는 나름 사용량에 맞는 합리적인 가격 정책을 제공합니다. 하지만 이 범위를 넘어서면 갑자기 테라바이트 단위의 큰 스토리지를 구입해야만 합니다. 그저 300기가에서 400기가로 올라가고 싶을 뿐이지만 이 사용 시나리오에 맞는 스토리지 상품은 없습니다. 이제 당장 사용하지 않더라도 테라바이트 단위의 이용 요금을 지불할 수밖에 없습니다. 사실 이건 구글만 이렇지는 않습니다. 애플 역시 200기가 요금제를 지나면 갑자기 2테라 짜리 요금제를 사용해야만 합니다. 다른 선택은 없습니다. 스토리지의 대부분이 비어 있지만 이렇게 사용되지 않는 공간에 대한 요금을 지불하는 것 외에는 방법이 없습니다. 만약 이런 매 달 지출을 감당할 수 있다면 여전히 그냥 구글에 돈을 내고 구글 포토를 유지하는 것이 가장 단순하고 안전한 방법인 것은 사실입니다만, 만약 이런 요금 체계에 문제의식을 가지고 이 서비스로부터 벗어나기로 마음먹는다면 그 다음부터는 아주 복잡한 고민이 기다리고 있습니다. 이제 술을 한 잔 더 마신 다음 아이들의 사진과 영상을 안전하게, 그리고 합리적으로 보관하기를 원하는 아버지의 이야기를 좀 더 따라가 봅시다.

이 분은 컴퓨터와 저장장치에 대해 전혀 모르지는 않았기에 미래에 만들어질 아주 많은 데이터를 오랜 기간에 걸쳐 드라이브의 고장에 저항성을 가진 안정적인 저장장치로 시놀로지 기계를 선택합니다. 모르긴 몰라도 꽤 높은 초기 비용을 지출했을 겁니다. 이 회사 제품은 사실 그리 훌륭하지 않은 하드웨어와 이를 지탱하는 여러 소프트웨어로 구성됩니다. 구글 포토와 비슷하지도 않을 것이 분명하지만 일단 겉은 비슷하게 생겼을 사진 관리 소프트웨어를 제공했기 때문에 이를 믿고 구글 포토 사용을 종료할 결정을 내렸습니다. 하지만 앞서 테이크아웃 서비스가 사진과 메타데이터를 분리한 상태로 반환하기 때문에 이 사진을 그냥 올렸다가는 메타데이터를 보고 사진을 관리하는 서비스는 사진을 전혀 분리하지 못하고 사진을 몽땅 뒤섞어 버릴 겁니다. 세계에는 이와 비슷한 상황을 먼저 겪은 사람들이 있었기에 누군가 이미 분노에 차 만들어 둔 구글 테이크아웃 데이터로부터 사진과 메타데이터를 합쳐 주는 프로그램을 사용해 메타데이터를 복구할 수 있었습니다만, 완전하지는 않았습니다. 알 수 없는 이유로 상당량의 사진의 메타데이터는 유실되었고 대부분의 사진이 메타데이터에 기반해 분류되었지만 무시할 수는 없을 만큼의 사진은 뒤섞여 버린 탓에 이들을 수동으로 정리하는데 엄청난 시간과 노력을 사용해야만 했습니다.

개인적으로 과거에 이와 비슷한 경험을 플릭커라는 사진 서비스를 사용하며 겪은 적이 있습니다. 한때 플릭커라는 사진 보관 서비스가 있었는데 고정 요금을 지불하면 최대 1테라바이트 어치 사진을 업로드할 수 있었습니다. 업로드 환경은 쓰레기 같고 웹 인터페이스 역시 훌륭함과는 거리가 멀었지만 고정 비용에 당시로는 꽤 큰 스토리지를 제공 받을 수 있다는 점 때문에 이 서비스를 사용했습니다. 그런데 몇 년 지나기도 전에 문제가 있음을 깨달았는데 이 서비스는 사진을 업로드 하는 다양한 방법을 제공했지만 사진을 다운로드 할 편안한 방법을 제공하지는 않았습니다. 이 틈을 파고들어 여러 회사들이 플릭커로부터 사진을 다운로드 하는 유료 소프트웨어를 개발했고 저 역시 이들 중 하나를 구입해 사용했습니다만 이 경험 역시 썩 훌륭하지는 않았습니다. 플릭커는 근본적으로 상당히 느리게 동작했고 그저 몇 년 전에 일어났던 이벤트 사진 뭉치를 좀 다운로드 하려고 했을 뿐인데 하루 이상이 필요했습니다. 이런 경험을 몇 번 하고 나서 앞서 구글 포토 사용을 그만 둘 결심을 한 것처럼 저 역시 이 서비스를 장기적으로 사용해서는 안되겠다는 결론에 다다릅니다. 그리고 플릭커로부터 모든 사진을 다운로드 하기 시작했는데 다행히 이 서비스는 사진을 압축하고 원본을 제거하지는 않았습니다. 하지만 모든 사진을 다운로드 하는데 정말 기나긴 시간이 필요했습니다. 유료 다운로드 소프트웨어는 여러 차례 다운로드에 실패했고 실패한 부분을 다시 수동으로 재시도하는데 많은 시간과 노력을 들여야만 했습니다. 그나마도 모든 사진을 다운로드 한 것이 맞는지 확신할 수가 없었습니다. 그런 확인에 필요한 아무런 데이터도 제공하지 않았기 때문입니다. 꼭 이 사건 하나 때문 만은 아니지만 이런 일련의 사건을 겪으며 어떤 서비스를 사용하더라도 원본 파일을 반드시 보유하고 있어야겠다는 교훈을 얻었습니다. 하지만 파일을 그냥 곧이곧대로 가지고 있는 것은 생각보다 쉽지 않은 일이었습니다. 여러 시행착오 끝에 형상관리도구인 퍼포스에 완전히 정착했습니다.

한편 아이들 사진을 시놀로지 기계에 저장했다고 해서 고민이 끝난 것은 아닙니다. 직접 스토리지 하드웨어를 통제하기로 결정한 순간부터 그 스토리지 하드웨어를 관리하는 책임 역시 오롯이 개인에게 부여되기 때문입니다. 사실 우리들이 구글 포토 같은 서비스에 돈을 내는 이유는 그런 책임을 회사가 지는 대가이기도 합니다. 시놀리지 기계는 레이드 설정에 따라 동시에 하나 또는 둘 정도의 하드디스크가 고장 나는 상황에 저항이 있을 겁니다. 사실 하드디스크의 연간 고장률을 생각하면 개인 수준의 장비에서 한 번에 둘 이상의 하드디스크가 동시에 고장 나는 상황이 발생할 확률은 아주 낮습니다. 이론적으로 하드디스크가 고장 나면 일시적으로 서비스를 중단하고 새 하드디스크를 가져와 교체한 다음 레이드를 재구축하면 시간이 좀 걸리긴 하겠지만 데이터 손실 없이 서비스를 재개할 수 있습니다. 하지만 낮은 확률이라 하더라도 각 하드디스크의 고장은 완전한 독립 사건이 아니라는 사실 정도는 그 분도 저도 어렴풋이 짐작할 수 있습니다. 하드디스크가 어떤 이유에 의해 고장 났다면 그와 같은 환경에 있던 다른 하드디스크 역시 비슷한 이유로 고장을 일으킬 수 있습니다. 그렇다고 개인 수준에서 둘 이상의 하드디스크가 고장을 일으키는 발생 확률이 낮은 상황에 저항을 가지려면 높은 비용을 사용해야 할 뿐 아니라 지속적으로 모니터링하는 등의 관리가 필요합니다. 또한 하드디스크 고장 상황에서 서비스를 지속할 수 없기에 짧지 않은 시간에 걸쳐 데이터에 접근할 수 없는 문제도 있습니다. 레이드 설정에 따라 분명 패리티 정보로부터 고장난 하드디스크를 교체한 다음 재구축 할 수야 있겠지만 앞서 설명했든 시놀로지 제품은 그저 그런 하드웨어와 소프트웨어로 구성되어 있고 이런 이유로 재구축에는 상당한 시간이 필요합니다. 또한 재구축이 일어나는 시간 동안에는 추가적인 하드디스크 고장에 대한 저항성이 없어집니다. 아이들의 사진을 안전하게 보관하고 싶은 아버지는 스토리지를 직접 관리함에 따라 발생한 이런 고민을 안고 계셨습니다.

아무리 시놀로지 기계가 한 두 개의 하드디스크 고장에 대한 저항성을 제공한다 하더라도 분명히 일이 완전히 잘못될 가능성이 있었고 이에 대비하기 위한 방법을 고민하기 시작하면서 이야기는 약간 이상한 방향으로 흘러갑니다. 시놀로지 기계는 이미 여러 대의 하드디스크를 묶어 동작하므로 개인 수준에서 이를 백업할 방법을 마련하기는 쉽지 않습니다. 저는 시놀로지 기계를 사용해본 적이 없지만 제가 사용해 본 ‘모든’ 스토리지 장비는 매뉴얼 어느 한 구석에 데이터 손실에 책임지지 않으니 반드시 백업하라는 문구가 적혀 있습니다. 그런데 하드디스크 하나가 들어 있는 장치라면 백업할 방법을 찾을 수 있겠지만 시놀로지 기계처럼 이미 그 스스로가 대용량인 장치를 개인 수준에서 백업할 안정적인 방법을 찾기는 어렵습니다. 극단적으로 똑같은 장비를 하나 더 구입해 복사본을 만들거나 앞서 매 달 지출되는 합리적이지 않은 비용을 피하고자 직접 스토리지 하드웨어를 관리하기로 결정했는데 오히려 이 장비를 백업하기 위해 매달 비용을 지출해야 할 수도 있는 상황에 처합니다. 이런 복잡한 상황을 해결하기 위해 이 분이 검토한 것은 광학 미디어에 파일을 복사해 두는 것이었습니다만, 예상 대로 이 계획은 성공적이지 못했습니다. 현대의 최신 광학 미디어는 적지 않은 용량을 기록할 수 있지만 여전히 하드디스크를 감당하기에는 너무 작습니다. 또 여러 미디어에 걸쳐 파일을 분산 보관하고 이를 관리할 솔루션이 뚜렷하지도 않습니다. 이 분은 그저 파일을 직접 용량에 맞춰 복사할 계획이셨던 것 같은데 이거 말이 쉽지 실제로는 대단히 복잡하고 어려운 일입니다. 근본적으로 광학 미디어는 현대 하드디스크를, 그것도 시놀로지 같은 여러 하드디스크를 묶어 동작하는 기계의 용량을 감당하기에는 너무나 작습니다. 또한 보관 기한도 너무 짧아 계속해서 상태를 확인하고 새 미디어로 옮기기를 반복해야 합니다.

이런 상황을 해소하기 위한 적당한 솔루션이 없지는 않습니다. 다만 이런 상황에 처한 개인의 상황은 맨 처음 권장한 드랍박스 같은 서비스를 사용하기에는 필요한 용량이 더 크고 기업을 대상으로 한 완전히 전문적인 솔루션을 사용하기에는 용량이 너무 작습니다. 이 사이에 있는 사람들이 선택할 수 있는 직접 통제할 수 있는 안전한 백업 솔루션은 사실 없다고 보는 것이 맞습니다. 또한 백업 환경은 점점 더 나빠지고 있다에 불평한 대로 여러 개인 고객을 대상으로 한 기업들이 인프라를 클라우드 서비스 우선으로 구축하기 시작하면서 개인이 선택할 수 있는 백업 솔루션의 폭은 계속해서 좁아지고 있습니다. 광학 미디어 다음으로 고려한 것은 LTO 드라이브였던 모양이지만 이 역시 개인이 선택하기에 적절한 방법이라고 보기는 어렵습니다. 일단 최신 스펙을 기준으로 어지간한 하드디스크는 충분히 커버할 만한 넉넉한 용량을 제공하지만 애초에 개인을 대상으로 한 제품이 아닌 덕분에 하드웨어 비용이 굉장히 높을 뿐 아니라 자기 테이프라는 매체 특성 상 단순히 하드디스크나 광학 미디어에 파일을 복사하는 것과는 또 다른 차원의 관리가 필요합니다. 백업 유지보수를 위한 전용 하드웨어나 소프트웨어가 있지만 이들 역시 개인 수준에서 접근하기에는 상당히 어렵습니다. 비록 LTO 미디어 자체의 오류율이 대단히 낮아 어떤 이유로 시놀로지 기계가 복구 불가능한 상황에 처할 때 마지막으로 기댈 여지가 있는 방법이 맞기는 하지만 개인이 안정적인 하드웨어나 소프트웨어의 지원 없이 자기 테이프 미디어에 파일을 전략적으로 유효한 모양으로 백업하고 있을 가능성은 그리 높지 않습니다. 결국 아이들 사진을 안전하게 보관하고 싶을 뿐인 아버지의 고민은 끝나지 않았습니다. 다만 여기서 술을 또 한 병 시킨 다음 그 분이 궁금해 하시는 제 백업 전략을 소개해 보겠습니다.

일단 저는 영상을 만들지도 않고 사진을 많이 만들지도 않습니다. 다만 데이터 호더 마냥 저를 스쳐 지나간 여러 문서들을 함부로 없애지 않으려고 노력하기는 합니다. 제가 본 문서들, 웹페이지들, 생산한 여러 포멧의 파일들은 분명 자신의 역할을 마치고 더 이상 보관되어 있을 필요가 없는 것도 있을 수 있습니다. 스토리지 비용을 절약하는데 집중한다면 더 이상 필요하지 않은 파일을 분류해 이들을 삭제할 수도 있습니다. 하지만 저는 그런 판단을 하고 싶지 않습니다. 현대에 스토리지 비용은 제가 영상을 만들지 않는 이상 충분히 낮아졌습니다. 이런 세계에서 쓸모 있는 파일과 그렇지 않은 파일을 대체 어떤 근거에 기반해 실수 없이 분류해 삭제할 수 있을지 모르겠습니다. 저는 분명 바보 같은 실수를 할 것이고 실수했다는 사실을 한참 시간이 지난 다음에 깨달아 후회할 것이 분명합니다. 몇 달 전에 삭제한 파일은 사실 삭제하면 안됐습니다. 무론 그 파일에 지금 접근할 수 없다고 해서 뭔가 큰 문제가 생기지는 않을 겁니다. 하지만 그 파일이 있었다면 지금 하려던 일을 훨씬 더 빨리 할 수도 있었을 겁니다. 그래서 쓸모 없는 파일을 분류하는 행동을 원천적으로 하지 않기로 했습니다. 이런 이유로 저는 제가 사용한 파일들이 파일시스템에 직접 저장되어 여러 접근 경로로부터 불안정한 모양으로 기록되어 있는 대신 형상관리도구의 통제를 받기를 원했고 여러 고민과 시행착오 끝에 돌고 돌아 퍼포스를 사용하기로 했습니다. 퍼포스는 적어도 클라이언트 측에서는 근본적으로 어떤 파일을 영구적으로 삭제할 방법이 없습니다. 삭제 명령이 있지만 이는 파일에 삭제되었다고 표시할 뿐 파일 자체 뿐 아니라 히스토리가 남아있어 미래에 원한다면 아무 문제 없이 파일을 복원할 수 있습니다. 또한 제가 파일을 제출할 때마다 모든 버전을 유지해 주고 이 기능이야말로 이 도구의 근본적인 필요이기에 제가 명시적으로 제출한 이상 어떤 버전도 사라지지 않습니다. 일단 소프트웨어는 퍼포스에 의존합니다.

다음으로 이를 지탱하는 하드웨어를 설명해야 하는데 그에 앞서 잠시 제 스토리지 요구사항을 설명해야 합니다. 영상이나 사진을 만들지 않아 거대한 스토리지가 필요하지는 않지만 아무 파일도 삭제되지 않기에 시간이 흐를수록 계속해서 스토리지 사용량은 증가하기만 하는 특성이 있습니다. 장기적으로 비용을 낮추기 위한 온프레미스 전환한 다음 더 이상 매달 AWS에 돈을 내지 않아도 된다고 생각하면서부터 스토리지 사용량이 급격히 증가했는데 이는 그동안은 퍼포스를 통해 관리하지 않던 온갖 파일을 퍼포스를 통해 관리하기 시작했기 때문입니다. 그 이전에 AWS에 서버를 둘 때부터 시작해 온프레미스로 옮겨온 다음의 일시적인 스토리지 사용량 증가를 무시하면 저는 1년에 최대 1테라바이트 정도의 스토리지를 추가로 사용하게 될 거라고 예측했습니다. 이 예측은 아주 넉넉한 예측이어서 실제로는 매년 이보다 더 적은 스토리지를 사용하게 될 겁니다. 그렇다면 대략 10년에 한 번 정도 스토리지를 크게 교체하기로 한다면 10테라바이트 정도의 안전한 스토리지가 있으면 장기간에 걸쳐 퍼포스 서버를 유지하기에 충분하다는 결론을 내렸습니다.

현재 제가 사용 중인 서버와 스토리지의 상태는 이렇습니다. 처음부터 이렇게 만들려던 것은 아닙니다. 처음엔 서버 기계 한 대와 외장하드 하나로 시작했다가 이 상태가 된 것인데요, 일단 맥미니 서버는 지난번 장기적으로 비용을 낮추기 위한 온프레미스 전환에 소개했으니 넘어갑니다. AWS의 아주 작은 서버를 사용하는데 매달 돈을 지불하다가 사양이 낮은 맥미니를 사용할 뿐인데도 이전에 비해 엄청나게 높은 사양에 기반해 여러 서비스를 구동할 수 있게 되었고 퍼포스 서버 역시 여기에 포함됩니다. 맨 처음에는 AWS에 스토리지 비용을 지불해야 했기 때문에 스토리지 사용량이 많지 않았습니다. 그래서 처음 맥미니를 사용해 온프레미스 환경으로 옮겨 올 생각을 하며 맥미니 자체에 1테라 스토리지면 충분할 거라고 예상했습니다. 하지만 매달 비용을 지불하지 않게 되자 퍼포스를 사용한 파일 관리 범위가 급격히 증가했고 외장 스토리지를 사용하지 않을 수 없었습니다. 만약 처음부터 이 판단을 했다면 맥미니에 큰 스토리지 옵션을 선택하느라 돈을 낭비하지 않아도 됐을 겁니다. 여튼 USB-C 케이블 하나로 간단히 연결되는 외장하드를 사용해 퍼포스 스토리지를 커버하기 시작했습니다. 하지만 앞에서 백업에 대해 그렇게 강조해 왔던 것처럼 이 체계는 그리 오래 가지 않습니다. 백업이 전혀 없는 채로 외장하드 하나에 덜렁 제 모든 퍼포스 스토리지를 의탁하는 것은 말이 안됐습니다. 그래서 이로부터 그리 오래 지나지 않은 시점에 위 그림에 timemachine1로 표시된 외장하드로 퍼포스 스토리지를 이전한 다음 timemachine2로 표시한 외장하드를 로컬 백업으로 사용하기 시작했습니다. 아직 백업 용량이 5테라바이트에 도달하지 않았기에 한동안 이 상태를 유지할 작정이었습니다.

제가 시놀로지 기계에 관심이 없는데는 두 가지 이유가 있습니다. 일단 저는 서버 기계가 있기 때문에 시놀로지 기계에서 돌아간다는 온갖 소프트웨어에 아무런 관심이 없습니다. 저 회사가 아무리 그 소프트웨어에 노력을 기울여 잘 개발한다 하더라도 근본적으로 이 소프트웨어들은 한계가 명확할 수밖에 없습니다. 이들이 사진 관리 소프트웨어를 아무리 잘 만들어도 구글 포토만큼 잘 만들 수 없고 이들이 아무리 파일 동기화 소프트웨어를 잘 만들어도 드랍박스만큼 잘 만들 수 없습니다. 굳이 이런 탑 클래스 플레이어들과 비교하지 않더라도 도커 컨테이너로 간단히 시작할 수 있는 오픈소스 소프트웨어들보다 잘 만들 수조차 없습니다. 일단 맥미니 서버에 도커 컨테이너를 돌리는 이상 시놀로지에서 동작하는 어떤 소프트웨어에도 관심이 없을 수밖에 없습니다. 다른 한 가지 이유는 제 스토리지 요구량이 영상을 만드는 사람들만큼 엄청나지 않은 덕분에 스토리지 구성을 복잡하게 만들 생각이 없다는 것입니다. 레이드 5, 6, 1+0 등 개인 수준에서 하드디스크 여러 개를 묶어 사용할 때 하드웨어 고장으로부터 저항성을 가질 방법이 있기는 합니다만, 앞서 짤막하게 이야기하고 넘어갔던 대로 근본적으로 숫자가 큰 레이드 레벨은 복잡도가 높고 가용성을 올려주지 않으며 하드웨어 고장 상황에 저항성이 있기는 하지만 문제를 해결하는 동안에는 그 저항성이 완전히 사라집니다. 가령 레이드 5 환경에서 하드디스크 하나가 고장났다고 해 봅시다. 패리티 정보가 분산되어 있으니 하드디스크를 교체하고 레이드를 리빌드하면 데이터를 유실하지 않을 겁니다. 그런데 이 리빌드 과정에 시간이 얼마나 걸릴지 예측하기도 어렵고 레이드를 리빌드 하는 동안 서비스를 중단해야만 합니다. 또한 레이드 리빌드 도중 또 다른 문제가 발생한다면 그 때는 겉잡을 수 없습니다. 이는 레이드 6 역시 똑같습니다.

제가 원한 것은 하드웨어 고장에 대한 저항성, 그리고 가용성입니다. 현재 구성에 도달하기 위해 마지막으로 2베이 하드웨어를 도입하면서 데이터를 이전하느라 48시간 정도 서비스를 중단해야 했는데 평소에는 너무 자연스럽게 서버에 의한 여러 동작이 일어나니 잘 인식하지 못했지만 서비스가 중단되자 느끼지도 못했던 여러 가지 자동화 기능이 모두 멈췄고 생활에 여러 가지 불편함이 드러났습니다. 이미 이 이전 작업을 통해 가용성을 확보하면 더 이상 이런 일을 겪지 않을 것이 분명했지만 가용성 확보가 필요하다는 점을 다시 한 번 느낀 경험이었습니다. 높은 레이드 레벨은 여러 하드디스크가 고장에 대한 저항성을 가짐과 동시에 스토리지 하나처럼 동작하게 만들기 위해 필요합니다. 가용성 확보는 개인 수준의 높은 레이드 레벨로부터 달성할 수 있는 목표와 거리가 멉니다. 개인 수준에서 가용성을 확보하기 위한 유일한 선택은 레이드 1 뿐입니다. 그래서 총 20테라바이트 어치 하드디스크가 들어 있는 2베이 스토리지 기계를 레이드 1로 설정해 10테라바이트만 사용하기로 했습니다. 앞서 설명한 대로 이 정도 공간이면 앞으로 꽤 오랜 세월에 걸쳐 스토리지가 부족하지 않을 테고 또 스토리지를 확보할 목적으로 필요한 파일과 그렇지 않은 파일을 분류하는 바보 같은 짓을 할 필요도 없을 겁니다. 하드디스크 하나가 고장을 일으키면 이를 교체하고 똑같이 레이드 리빌드 절차를 거쳐야 합니다만, 높은 레이드 레벨과 달리 레이드 1은 리빌드 하는 동안에도 서비스가 일상에 가깝게 유지되어 가용성을 확보할 수 있습니다. 레이드 1의 리빌드는 더 높은 레이드 레벨에서 패리티 데이터에 근거해 데이터를 계산하는 것과 비교해 아주 단순합니다. 그저 블록 단위로 데이터를 복사할 뿐입니다. 여기에는 아무런 복잡한 연산이 필요하지 않습니다. 단순하고 또 가용성을 확보할 수 있다는 점 때문에 레이드 1을 선택했습니다.

백업은 3, 2, 1 원칙 중 두 번째 2를 제외한 나머지를 달성하는데 집중했습니다. 먼저 첫 번째 3은 적어도 세 개의 복사본을 유지하는 것입니다. 아직 제가 사용하는 전체 스토리지 크기가 5테라바이트에 도달하지는 않아 이전에 사용하던 5테라짜리 외장하드와 이전에 퍼포스 서버에 사용하던 16테라짜리 외장하드를 맥OS의 타임머신 백업에 사용합니다. 타임머신 백업에 둘 이상의 드라이브를 할당하면 각 드라이브에 전체 백업을 한 번 만든 다음 매 시간 증분 백업을 생성할 때 각 드라이브를 번갈아가며 사용합니다. 그래서 타임머신 백업에 드라이브 두 개를 할당하면 각 드라이브는 매 두 시간에 한 번만 켜져 증분 백업만 수행합니다. 윈도우 버전이 올라갈 때마다 쓸만한 백업 소프트웨어가 지속적으로 제거되어 온 것에 비해 맥OS의 백업 소프트웨어인 타임머신은 다행히 여전히 강력하고 또 단순하게 동작합니다. 타임머신 백업은 좀 어이 없을 정도로 단순하게 동작하는데 그저 접근 가능한 모든 파일을 한 디렉토리에 복사할 뿐입니다. 증분 백업은 또 다른 디렉토리에 복사하되 변경되지 않은 모든 파일에 대한 심볼릭 링크를 남깁니다. 그래서 백업이 수행된 시점의 디렉토리에 접근하면 그 시점의 변경된 파일과 변경되지 않은 파일을 모두 포함한 온전한 복사본에 접근할 수 있습니다. 파일 복사와 심볼릭 링크 외에는 아무런 숨겨진 동작이 없습니다. 타임머신 소프트웨어가 없어도 직접 파일을 복사해 복원할 수 있습니다. 효율적이지 않은 부분도 분명 있지만 단순한 점이 마음에 듭니다. 백업이 5테라바이트에 도달하면 외장하드를 사용할 수 없게 될테니 그 때 다른 드라이브를 마련해 로컬에 타임머신 백업 두 개를 계속해서 유지할 겁니다. 그리고 세 번째 백업은 크래시플랜에 있습니다. 만약 이 서비스로부터 파일을 복원한다면 인터넷을 통해 엄청난 시간이 걸릴 겁니다. 하지만 이 서비스를 사용해 복원해야 하는 상황이라면 아마 이 백업이 있어 다행이라는 생각이 속도가 느려 느끼는 불만보다 더 클 겁니다. 이로써 백업이 세 개 있으니 첫 번째 '3'을 반복합니다.

3, 2, 1 원칙 중 두 번째 '2' 원칙을 달성하지 못했습니다. 이는 두 가지 다른 종류의 미디어에 백업을 기록하라는 원칙입니다. 그런데 현대에 하드디스크 외에 다른 대용량 미디어를 백업에 사용할 여지가 별로 없습니다. 현대에 SSD는 하드디스크에 견줄만한 훌륭한 스토리지이지만 이 시나리오에 필요한 대용량을 확보하려면 아주 큰 돈을 지불해야 하며 겨우 10테라 정도의 용량을 단순히 SSD 하나를 구입해 달성하기도 아주 어렵습니다. 그래서 어쩔 수 없이 모든 백업은 결국 하드디스크에 기록되어 있습니다. 그 중 둘은 서버와 같은 위치에, 나머지 하나는 미국 어딘가의 데이터센터에 있습니다. 미국 어딘가의 데이터센터에 있는 백업 역시 하드디스크에 기록되어 있을 겁니다. 그래서 모든 백업은 같은 종류의 미디어에 기록되어 있습니다.

마지막 ‘1'은 백업 중 적어도 하나는 다른 장소에 있어야 한다는 것입니다. 사실 이 역시 개인 입장에서 달성하기 거의 불가능합니다. 물론 백업을 하나 만들어 미디어를 어딘가 창고 서비스에 보관할 수는 있을 것 같습니다. 하지만 백업은 계속해서 업데이트 되어야 하기에 완전한 오프라인 환경, 그리고 집이 아닌 다른 장소에 보관하기는 아주 어렵습니다. 그래서 제가 선택한 방법은 크래시플랜이라는 서비스를 사용하는 것입니다. 이 서비스는 월 고정 비용으로 그들의 주장에 따르면 '제한 없는’ 용량을 제공합니다. 하지만 사례를 살펴보니 약 50메타바이트 정도를 백업하고 복구한 사례가 최대인 것 같습니다. 여느 서비스가 용량에 따라 비용을 지불하는 것에 비해 제 관점에서는 합리적입니다. 거의 비슷한 서비스를 백블레이즈에서도 제공하는데 백블레이즈보다 더 느리게 동작할 뿐 아니라 JVM 위에서 동작하는 심각한 패널티를 가진 크래시플랜을 선택한 이유는 라이브 서버를 백업하기 원했기 때문입니다. 백블레이즈 백업 역시 월 고정 비용에 용량 제한이 없지만 사용 중인 파일을 백업하지 않습니다. 사실 퍼포스를 포함한 여러 데이터베이스들이 이런 환경에서 백업되기 위해 라이브 데이터를 덤프하는 기능이 있습니다만, 제 관점에서 이는 백업과 복구 과정을 복잡하게 만듭니다. 백업 과정을 자동화 하는 것은 그리 어렵지 않을 겁니다. 하지만 이를 복원하는 과정은 단순하지 않습니다. 때문에 라이브 서버에서 현재 사용 중인 파일을 그냥 백업할 수 있기를 원했고 이 요구사항은 크래시플랜이 만족했습니다. 크래시플랜은 현재 사용 중인 sqlite 파일이나 mysql 파일, 그리고 퍼포스 데이터베이스 파일을 그냥 백업합니다. 근본적으로 이런 방식이 백업이 일어나는 시차에 따라 파일들의 불일치를 만들 위험이 있음을 알고 있지만 감수할만 하다고 평가했습니다.

이게 전부입니다. 맥미니 서버에 도커 컨테이너를 사용해 제 생활을 도와주는 여러 서비스가 돌고 있고 이들이 사용하는 스토리지는 레이드 1로 구성된 10테라 하드디스크에 기록합니다. 이 장비는 레이드 1로 구성되어 있는 덕분에 단일 하드디스크 고장에 저항성이 있고 하드디스크 하나가 고장난 상황에서도 가용성을 확보할 수 있습니다. 백업은 맥OS의 타임머신에 의존해 같은 위치에 백업이 두 개 있고 외부 서비스를 사용해 다른 위치에 백업 하나가 더 있습니다. 타임머신 백업에 사용하는 드라이브 둘 중 하나는 조만간 용량 부족으로 더 이상 백업에 사용할 수 없는 시점이 올 겁니다. 그 때 다른 드라이브를 마련해야 하는 상황입니다.

제 백업 시나리오를 들은 그 분이 어떤 결정을 하실 지 아직 모릅니다. 하지만 관심을 가지고 지켜보고 있습니다. 가장 단순한 방법은 특정 서비스에 의존해 종속되는 것이지만 이 방법을 사용하지 않기로 결정하는 순간 문제는 아주 복잡해집니다. 또한 개인 수준에서 약 1테라보다는 크지만 수 십 테라보다는 작은 어정쩡한 규모를 직접 관리할 방법이 많지 않은 것이 사실이어서 다른 사례를 관찰하는 차원에서 결정을 기다리는 중입니다. 이 어정쩡한 요구사항을 가진 사람 입장에서 백업 환경은 점점 더 나빠지고 있다는 생각이 달라지지도 않았습니다. 여튼 현재 백업 환경을 앞으로 한동안은 유지할 작정입니다.