오류나 작동 실수 등으로 인해 소중한 데이터가 손실되는 경우가 있을 수 있으므로, 평소에 백업을 해두는 것은 중요합니다. 하지만 데이터 백업은 단순히 파일을 다른 장소에 복사하는 것만으로는 충분하지 않을 수 있습니다. 소프트웨어 엔지니어 알렉산들르 필리포프스키 씨가 백업 메커니즘을 구축하면서 늘어나는 과제를, 자신의 경험을 바탕으로 설명하고 있습니다. 백업은 단순하지 않습니다. https://filipovski.net/2026/09/16/backups-arent-simple 필리포프스키 씨는 “사람에게는 2가지 종류가 있다. 파괴적인 데이터 손실을 경험한 사람과, 앞으로 경험할 사람이다”라는 시스템 관리자 사이에서 전해 내려오는 말을 소개합니다. 이는 “데이터 손실은 생각하는 것보다 더 쉽게 발생하고, 많은 사람은 충분히 대비하지 않고 있다”는 것을 의미합니다. 필리포프스키 씨 자신도 가족 사진을 잃어보낸 경험이 있다고 합니다. 자택의 PC 용량을 늘리기 위해 가족 사진을 외장 HDD에 모아두던 중, 아버지가 그 HDD를 TV용 셋톱박스 저장 장치로 사용하기 위해 포맷해버리셨습니다. 그 결과, 파일의 인덱스가 삭제되어 HDD는 외관상 공허해졌습니다.
그러나 필립포프스키氏は、사진 데이터가 사라져가는 것은 아버지의 책임만은 아니라고 지적하며, 사진을 1ヶ所に 모아두고 백업을 취하지 않았고, 또한 세트톱박스에 “포맷하면 데이터가 손실될 수 있음을 명확히 전달하는 경고”가 나타나지 않았다는 점이 원인이라고 설명했습니다. 더 나아가, 기술에 밝지 않은 사람이 포맷의 의미를 알고 있다고 기대하는 것 자체에도 의문을 제기했습니다. HDD 사진은 다행히 복원된 것으로 알려졌지만, 필립포프스키시는 “이 경험을 통해 얻은 교훈은 중요한 데이터를 1ヶ소에 두지 않는 것이었다”라고 말합니다. HDD는 고장나거나 도난당할 수도 있으며, 사용하지 않고 보관해도 기록을 담당하는 자기 상태가 변화할 수 있습니다. SSD에서도 데이터를 유지하는 전하가 손실되어 데이터가 손상될 수 있습니다. 따라서 우선 필요한 것은 “다른 장소에 파일의 복사본을 준비하는 것”입니다.
하지만, 복사본이 있다면 모든 문제를 해결하는 것은 아닙니다. 연결 중인 드라이브는 랜섬웨어에 암호화될 가능성이 있으며, 사용자가 잘못된 파일을 삭제하거나 모든 것을 0으로 덮어쓰는 스크립트를 실행할 수도 있습니다. 원본 드라이브의 변경 사항을 그대로 반영하는 메커니즘에서는 잘못된 작동의 결과까지 복사본에 반영됩니다. 그래서 중요한 것은 복사하고 있는 것인지 뿐만 아니라 “과거 상태로 되돌릴 수 있는 메커니즘”입니다. 필리포프스키氏は、同じ 데이터를 여러 드라이브에 쓰는 RAID 1과 같은 미러링만으로는 이 목적을 달성하지 못하며, 특정 시점의 상태를 저장하는 “스냅샷”이 필요하다고 주장합니다. 스냅샷을 저장하는 과정에서 문제가 되는 것은 “얼마くらいの 빈도로 저장하는가”입니다. 어떤 시점까지의 데이터를 복구할 수 있도록 하는 목표를 “RPO(목표 복구 시점)”라고 부르지만, 필리포프스키氏は“중요한 금융기관에서는 30초 미만, 소규모 기업에서는 24시간 이상 등 필요한 RPO 수준은 다르다”고 설명합니다. 예를 들어, 지금까지 모아둔 가족의 사진을 백업하는 경우에는 “최대 6일과 23시간 분의 데이터를 잃는 것을 허용할 수 있다”는 판단도 내릴 수 있습니다.
하지만, 백업 빈도를 결정하면 이번에는 저장 용량 문제가 됩니다. 매일 스냅샷을 만들어도 오래된 것을 삭제하지 않으면 스냅샷은 1주일이면 7개, 1년이면 365개에도 됩니다. 그대로는 백업 데이터만으로 엄청난 저장 용량이 필요하게 되므로, 오래된 스냅샷을 순차적으로 삭제하는 운영 방식이 필요합니다. 예를 들어 “최근 14일분만 남기고 새로운 것을 만들 때마다 가장 오래된 것을 삭제한다”는 방식도 고려할 수 있지만, 이 방법에서는 데이터 손상에 2주 이상 인지하지 못한 경우 손상 이전의 백업이 남아있지 않을 가능성이 있습니다. 반면에 1년 분량의 백업을 모두 남기는 것은 용량 면에서 어려우며, 오래된 시기에 대해서도 그렇게까지 세부적인 기록이 필요하지 않을 수도 있습니다. 그래서 필립코프스키 氏は、「최근의 백업은 세밀하게 남기고 오래된 것은 간격을 넓혀 저장한다」는 방법을 소개합니다. 예를 들어, 일일 백업을 14일 분, 주간 백업을 7주 분, 월간 백업을 12개월 분 남기는 방식이 효과적입니다. 이렇게 스냅샷을 일, 주, 월의 3세대에 나누어 저장하는 방식을 “GFS(Grandfather-Father-Son)”라고 부릅니다.
더욱이, 저장할 내용의 중복도 줄일 수 있습니다. 백업되는 파일의 대부분은 변경되지 않으며, 극히 일부 파일이 빈번하게 업데이트됩니다. 따라서 변경된 파일만 저장하면서 이미 저장된 데이터를 참조하면 용량을 절약할 수 있는 것입니다. 그 방법 중 하나가 동일한 파일의 실체를 여러 장소에서 참조하는 “하드 링크”입니다. 각 스냅샷이 동일한 실체를 참조하기 때문에, 오래된 스냅샷을 삭제해도 다른 스냅샷에서 참조되고 있는 데이터는 남아 있습니다. 중복 제거는 저장 용량 절약뿐만 아니라, 다른 기계로 데이터를 전송할 때의 통신량도 줄일 수 있다는 장점도 있습니다. 특히 클라우드 서비스를 저장소로 사용하는 경우에는 데이터 전송의 통신량이 운영 비용에 직접 연관됩니다. 필립코프스키 氏は、これまでまでの 메커니즘은 파일 전송 툴인 “rsync”와, 처리를 주기적으로 실행하는 “cron”을 조합하여 구축할 수 있다고 소개했습니다. 이 백업 방법은 이전과 변경되지 않은 파일을 하드 링크로 공유하는 증분 저장과 GFS 방식의 세대 관리를 갖추고 있으며, 저장소의 기계를 추가할 수도 있습니다. 더욱이 파일의 접근 권한이나 소유자 같은 부수적인 정보도 유지할 수 있습니다. 그러나 이 메커니즘을 가정 서버 환경에 적용하면 다른 문제가 발생합니다. 예를 들어 10개의 Docker 컨테이너를 실행하는 경우, Docker 컨테이너가 관리자의 root를 소유자로 하는 파일을 생성하는 한편, 백업 처리를 일반 사용자의 권한으로 실행하면 파일을 읽을 수 없어서 백업에 실패할 수 있습니다.
또한, 데이터베이스는 단순한 파일 복사만으로는 문제가 발생할 수 있습니다. 데이터베이스는 처리를 빠르게 하기 위해 데이터를 일시적으로 메모리에 보관하고, 한 번에 디스크에 기록할 수 있습니다. 복사 시점에 따라 일관성 없는 상태가 저장되어 복원 실패로 이어질 수 있습니다. 따라서, 데이터베이스의 내용을 백업용으로 내보내는 “덤프”를 생성하고, Docker의 데이터 저장 영역을 읽어들이기 위한 권한도 확보해야 합니다. 저장 장비나 장소에도 주의해야 합니다. 특정 HDD 제품에서 고장 발생이 다발하게 되는 경우를 고려할 때, 다른 종류의 기록 매체에 저장하는 것이 대책이 됩니다. 더 나아가, 클라우드나 가족의 집 등 먼 곳에도 복사본을 두면 전력 이상, 홍수, 화재 등으로 인해 모든 것을 잃을 위험을 줄일 수 있습니다. 이러한 “데이터를 3개 준비하고, 2종류의 매체에 저장하며, 그 중 1개를 다른 장소에 두는” 방식이 “3-2-1 백업”입니다. 예기치 않은 상황에서 중요한 데이터를 잃는 것을 방지하는 “3-2-1 백업 규칙”은 무엇입니까? - GIGAZINE
그러나, Amazon S3와 같은 원격 저장소를 보관 위치로 선택할 경우, 이러한 메커니즘을 그대로 활용할 수 없습니다. 파일을 그대로 업로드하는 것만으로는 접근 권한이나 소유자 등의 정보가 이관되지 않으며, 작은 파일을 대량으로 전송할 경우 업로드 요청에 소요되는 비용 또한 증가합니다. 따라서 여러 파일을 tar 형식의 아카이브로 묶으면 부가 정보를 유지하면서 업로드 횟수를 줄일 수 있습니다. 다만, 모든 것을 하나의 거대한 아카이브로 만들면 하드 링크를 이용하여 변경 부분만 저장하는 메커니즘의 장점이 상실됩니다. 필리포프스키氏は 50MB 정도의 덩이로 분할하는 방안을 제시했지만, 안전성을 확인 가능한 형태로 구현하는 것은 간단한 일이 아닙니다. 필리포프스키氏は “이 단계까지 오면, 자작을 계속하는 부담은 면제할 수 없다”고 언급했습니다. 대신 제시하는 것이 “Borg backup” 또는 “Restic”와 같은 백업 툴입니다. 이러한 툴은 암호화 및 파일을 분할한 덩어리별 중복 제거, 데이터 손상 감지를 위한 체크섬 등에도 대응합니다. 필리포프스키氏は “이러한 복잡한 처리를 사용자가 쉽게 다룰 수 있는 형태로 만드는 데, 오픈소스 개발자들의 많은 시행착오가 있었다”고 언급했습니다. 그리고 백업을 생성했더라도 실제로 복원 가능한지 확인해야 의미가 없습니다. 따라서 백업 메커니즘을 구축하는 것뿐만 아니라, 반년마다 복원을 실행하는 등과 같은 복원의 확인도 필요합니다. 백업은 데이터를 실수로 삭제하거나 손상했을 경우를 대비하여 과거 상태를 유지하고, 저장 용량과 비용을 절감하면서 데이터의 일관성과 저장 위치의 안전성도 확보해야 합니다. 더 나아가 실제로 복원 가능한 것을 확인하는 작업까지 포함하면 단순한 복제로는 충분하지 않은 많은 과제가 발생합니다. 필리포프스키氏は “백업이 어려운 것은 파일의 복사본을 만드는 것뿐만 아니라, 필요한 때에 정확하게 복원될 수 있는 상태를 유지해야 하기 때문이다”라고 밝혔습니다.
원문 보기 | 출처: Gigazine