모두
모두콘텐츠
얼마 전 서버 이전을 도왔는데, 백업 파일은 매일 쌓이고 있었지만 복구할 수 있는 상태는 아니었습니다. 데이터베이스만 저장해 두고 고객이 올린 파일은 빠져 있었거든요. 14년간 서버를 운영하면서 본 백업 사고는 저장 공간 부족보다 이런 누락과 복구 절차 미확인에서 더 자주 시작됐습니다.
무엇을 되살려야 하는지 먼저 적는다
데이터 백업 방법을 정할 때 첫 순서는 백업 프로그램 선택이 아닙니다. 장애가 났을 때 사이트를 다시 띄우는 데 필요한 항목을 적는 일입니다. 게시글과 주문 정보가 담긴 데이터베이스, 이미지와 첨부 파일, 애플리케이션 설정, 웹서버 설정, 예약 작업을 각각 확인합니다. SSL 인증서와 개인 키를 직접 관리한다면 재발급 절차나 안전한 보관 위치도 알아둬야 합니다.
운영 서버를 통째로 복사하는 방식은 편하지만, 불필요한 임시 파일까지 포함하기 쉽습니다. 반대로 데이터베이스 덤프만 남기면 파일 업로드가 사라질 수 있습니다. 저는 사이트마다 ‘복구에 필요한 목록’을 한 장으로 만들어 백업 작업과 대조합니다. 새 기능이 파일을 저장하기 시작했다면 그 목록도 바로 바꿉니다.
- 데이터베이스: 게시글, 회원, 주문처럼 다시 만들기 어려운 데이터
- 파일: 업로드 이미지, 첨부 자료, 사용자가 생성한 결과물
- 설정: 애플리케이션 환경값, 웹서버 설정, 예약 작업
- 접근 정보: 암호화 키와 복구 권한의 보관 위치 및 담당자
백업 주기는 허용 가능한 손실 시간으로 정한다
하루에 글 한두 개가 올라오는 블로그와 시간당 주문이 수십 건 들어오는 쇼핑몰에 같은 주기를 적용할 이유는 없습니다. 먼저 장애 시 몇 시간치 데이터를 잃어도 되는지 정합니다. 이를 복구 시점 목표인 RPO라고 합니다. 하루치 손실을 감당할 수 있다면 매일 백업이 출발점이 될 수 있지만, 한 시간치도 잃으면 안 된다면 더 짧은 주기나 데이터베이스 변경 기록을 함께 보관해야 합니다.
복구에 걸려도 되는 시간은 RTO입니다. 백업 파일을 가져오는 데 30분, 데이터베이스를 불러오는 데 1시간, 설정과 확인에 1시간이 든다면 복구 목표를 1시간으로 잡을 수 없습니다. 백업 파일 크기보다 실제 복구 시간을 한 번 재보는 편이 정확합니다. 저장 비용을 아끼려다 복구에 반나절이 걸리면 싼 백업이라고 보기 어렵습니다.
작은 사이트라면 이 정도부터 시작한다
예를 들어 데이터베이스 2GB, 업로드 파일 20GB인 블로그라면 매일 새벽 데이터베이스 백업과 변경된 파일 백업을 실행하고, 최근 14일의 일별 사본과 8주의 주별 사본을 남기는 구성이 출발점이 됩니다. 방문자가 적고 변경도 거의 없다면 주기는 더 느슨해질 수 있습니다. 반면 결제나 예약이 발생한다면 하루 한 번으로는 부족합니다. 트래픽 숫자보다 데이터가 바뀌는 속도와 손실 허용 범위를 기준으로 잡아야 합니다.
백업 저장소 용량도 대략 계산합니다. 매일 25GB를 압축 없이 통째로 14개 보관하면 350GB가 필요합니다. 여기에 주별 사본과 여유 공간까지 더해야 하죠. 변경분만 저장하면 사용량을 줄일 수 있지만, 복구할 때 기준 사본과 변경분이 모두 있어야 합니다. 보관 기간을 늘리기 전에 저장 방식과 실제 증가량을 확인합니다.
원본 서버와 다른 곳에 두고 복구까지 시험한다
같은 서버의 다른 폴더에 파일을 복사하는 건 장애 대비로 부족합니다. 디스크가 고장 나거나 서버 접근 권한을 잃으면 원본과 사본이 함께 사라집니다. 최소한 서버 밖의 독립된 저장소에 한 벌을 두고, 실수로 삭제하거나 덮어쓴 파일을 되돌릴 수 있도록 버전도 남깁니다. 서버 관리자 계정이 백업까지 지울 수 있다면 사고 범위가 커지므로 삭제 권한을 분리하는 편이 좋습니다.
백업 데이터를 외부에 보관할 때는 암호화와 키 보관 위치도 확인합니다. 키를 백업 파일과 같은 곳에만 두면 저장소가 노출됐을 때 보호 효과가 약하고, 키를 잃으면 복구 자체가 막힙니다. 자동 백업 작업에는 필요한 권한만 주고, 성공 알림만 믿지 말고 파일 크기와 완료 시각을 함께 확인합니다. 백업 작업이 성공했다고 표시돼도 내용이 비어 있는 경우가 있습니다.
복구 시험에서 확인할 순서
한 달에 한 번쯤 별도 환경에 최근 백업을 복원해 봅니다. 먼저 파일을 내려받고 압축을 풀 수 있는지 확인합니다. 다음으로 데이터베이스를 불러오고 업로드 파일을 제자리에 놓습니다. 설정값을 적용한 뒤 로그인, 게시글, 이미지, 주문 같은 주요 기능을 직접 눌러봅니다. 원본 서버에 바로 덮어쓰며 시험하면 운영 데이터가 손상될 수 있으니 시험 환경을 따로 둡니다.
장애가 실제로 나면 서두르기 쉽습니다. 그때는 마지막 정상 백업 시각부터 확인하고, 손상된 서버의 현재 상태도 보존합니다. 원인을 모른 채 최신 백업을 덮어쓰면 복구 가능한 데이터를 오히려 잃을 수 있습니다. 저는 백업이 매일 실행됐다는 보고보다, 지난달에 그 백업으로 사이트를 몇 분 만에 다시 띄웠는지를 더 믿습니다.
