외장하드에 파일을 옮겼다는 사실만으로 백업이 생기지는 않는다. 원래 파일을 지웠다면 저장 장소만 바뀐 것이다. 동기화도 설정에 따라 실수로 지운 파일을 다른 기기에서 함께 지운다. 개인 사진이나 작은 서비스의 데이터를 맡길 때는 저장 용량보다 먼저, 사고가 났을 때 어느 시점으로 돌아갈 수 있는지를 정해야 한다.
소프트웨어 엔지니어 알렉산다르 필리포프스키(Aleksandar Filipovski)는 2026년 9월 16일 글에서 가족 사진을 잃을 뻔한 경험과 홈랩 백업의 문제를 풀어냈다. 그의 가족은 컴퓨터 공간을 비우려고 사진을 외장하드 한 곳으로 모았다. 이후 아버지가 그 디스크를 TV 셋톱박스용으로 포맷하면서 파일 목록이 사라졌다. 사진은 나중에 복구했지만, 당시에는 다른 사본이 없었다. 저자는 한 사람의 실수보다 중요한 데이터를 한곳에만 둔 방식과 불충분한 경고 화면을 문제로 짚는다.
다른 디스크에도 있는데 왜 되돌릴 수 없을까
두 디스크에 같은 내용을 쓰는 RAID 1은 디스크 하나가 고장 났을 때 유용하다. 하지만 삭제 명령도 두 곳에 반영된다. 현재 상태를 맞추는 기능과 과거 상태를 보관하는 기능은 다르다. 동기화 서비스에 휴지통이나 버전 기록이 있다면 복구에 쓸 수 있지만, 삭제된 항목을 언제까지 보관하는지와 계정에 문제가 생겼을 때도 접근할 수 있는지를 따로 봐야 한다.
필요한 것은 사고 전 상태를 남기는 스냅샷, 즉 특정 시점의 파일 기록이다. 그 기록이 원본과 같은 디스크에만 있으면 디스크 고장 때 함께 잃는다. 원문이 소개하는 3-2-1 원칙은 원본을 포함해 사본 3개를 두 종류의 매체에 나누고, 그중 하나를 다른 장소에 두는 방식이다. 집 안의 다른 방은 화재나 침수에 대한 장소 분리가 되기 어렵다. 계속 연결된 저장장치는 랜섬웨어나 잘못된 삭제 명령의 영향도 받을 수 있어, 백업을 지울 권한이 원본과 함께 노출되는지도 살펴야 한다.
얼마나 잃어도 되는지와 얼마나 오래 남길지는 다른 질문이다
허용할 데이터 손실의 시간 범위를 복구 시점 목표(RPO)라고 한다. 매일 밤 한 번 백업하면 다음 백업 직전에 사고가 났을 때 거의 하루치 변경을 잃을 수 있다. 이는 매번 백업이 성공하고 그 사본이 복구 가능하다는 전제다. 예약 작업이 실패한 채 방치됐다면 손실 범위는 더 커진다.
필리포프스키는 가족 사진이라면 일주일마다 백업하고 6일 23시간의 변경 손실을 받아들일 수도 있다는 예를 든다. 금융기관은 30초 미만, 일부 소규모 기업은 24시간 이상이라는 수치도 제시한다. 모두 허용 손실이 업무마다 다르다는 설명이지 업종별 권장값이 아니다. 다시 찍을 수 없는 여행 사진과 다시 내려받을 수 있는 설치 파일을 같은 주기로 다룰 이유도 없다. 소규모 서비스라면 사라진 주문이나 예약을 다른 기록에서 재구성할 수 있는지부터 따져야 한다.
백업 간격을 줄여도 오래전에 생긴 손상을 늦게 발견하면 곤란하다. 매일 저장하되 최근 14일만 남겼는데, 한 달 전부터 파일이 손상됐다면 보관 중인 사본에도 문제가 들어 있을 수 있다. 원문은 최근 일별 기록 14일, 주별 기록 7주, 월별 기록 12개월을 남기는 예를 제시한다. 가까운 과거는 촘촘하게, 먼 과거는 드문 간격으로 남겨 저장 부담을 줄이는 방식이다. 오래된 기록에서는 특정 날짜의 상태를 되찾지 못할 수 있다는 대가가 있다.
실행 중인 데이터베이스는 폴더만 복사하면 될까
개인 파일에서 서비스 데이터로 넘어가면 복사할 대상부터 달라진다. 필리포프스키는 컨테이너 10개를 돌리는 홈랩 사례에서, 관리자 소유 파일을 일반 사용자 권한의 예약 작업이 읽지 못해 백업이 실패하는 상황을 설명한다. 백업 작업이 필요한 파일을 읽을 수 있는지, 실패 로그가 남았는지 확인해야 한다. 그렇다고 모든 백업 작업에 무조건 관리자 권한을 줄 필요는 없다. 필요한 경로를 읽을 권한을 정하고, 백업 저장소의 삭제 권한은 별도로 제한하는 편이 낫다.
데이터베이스는 복사하는 동안에도 내용을 바꾼다. 여러 파일이 서로 다른 순간의 상태로 모이면, 복사 자체는 끝나도 복원 후 데이터가 맞지 않을 수 있다. PostgreSQL 공식 문서는 단순 파일 복사 방식이라면 서버를 중지해야 하며, 접속만 막는 것으로는 충분하지 않다고 설명한다. 실행 중에도 가능한 일관된 스냅샷 방식은 별도로 있고, 필요한 변경 기록인 WAL까지 포함해야 한다. 데이터와 로그가 여러 볼륨에 흩어져 있다면 스냅샷 시점도 함께 맞춰야 한다.
따라서 운영 중인 데이터베이스는 그 제품이 지원하는 덤프나 온라인 백업 절차를 선택해야 한다. 덤프는 데이터를 나중에 다시 읽어 넣을 수 있는 형태로 내보내는 작업이다. DB 덤프만 정상이어도 업로드 파일이나 서비스 설정이 빠지면 앱은 온전히 돌아오지 않는다. 복구 대상으로 데이터베이스와 연결 파일, 실행에 필요한 설정을 함께 적어 두어야 한다.
구매 전에 복구할 파일 하나를 골라 보자
저자는 중복 제거와 보관 기록 정리를 직접 구현할 때 늘어나는 부담을 설명하며, 검증된 백업 도구를 쓰자고 권한다. 같은 내용을 중복 저장하지 않는 기능은 용량을 아끼지만, 어떤 손실을 허용하고 어떤 시점까지 남길지는 도구가 대신 결정하지 않는다. 상품을 비교할 때도 총용량만 볼 것이 아니라 삭제된 파일의 보관 기간, 버전 복원 범위, 전체 데이터를 다시 내려받는 비용과 절차를 확인해야 한다.
복원 시험은 운영 파일을 덮어쓰지 않는 별도 폴더나 격리된 환경에서 한다. 날짜를 골라 사진을 되살린 뒤 실제로 열어 보고, 서비스라면 DB를 불러와 필요한 파일과 함께 앱을 실행한다. 암호화 키나 복구 암호를 잃어버렸을 때 접근할 경로도 준비해야 한다. 성공 로그만 확인하는 것과 파일을 읽고 업무를 재개하는 것은 서로 다른 검사다.
허용 손실과 별개로, 서비스를 얼마나 오래 멈춰도 되는지도 정해야 한다. 이를 복구 시간 목표(RTO)라고 한다. 사본에 필요한 데이터가 전부 있어도 내려받고 서비스를 띄우는 데 하루가 걸린다면, 한 시간 내 재개가 필요한 운영에는 맞지 않는다. 복원 시험 때 걸린 시간을 남겨야 저장 위치와 복구 절차를 바꿀 근거가 생긴다.
원문은 6개월마다 복원해 보는 예로 글을 마무리한다. 그 간격을 모든 환경에 그대로 적용하기보다 데이터의 중요도와 변경 빈도에 맞춰 정하고, 저장 위치나 DB 버전, 인증 방식을 바꾼 뒤에는 시험을 다시 잡는 편이 좋다. 지금 쓰는 백업에서 지난달 파일 하나를 별도 위치로 되살려 보는 것부터 시작할 수 있다. 그때 선택할 수 있는 날짜, 필요한 권한, 실제 소요 시간을 기록하면 다음에 바꿀 설정이나 구매 조건이 구체적으로 드러난다.
출처: Aleksandar Filipovski, Backups aren't simple · PostgreSQL, File System Level Backup · restic, Restoring from backup · AWS, Disaster recovery options in the cloud