모두
모두콘텐츠
몇 년 전 고객 사이트를 새 서버로 옮기는데 백업 파일은 멀쩡한데도 복구가 안 된 적이 있었다. 데이터베이스는 전날 밤 것이고 업로드 파일은 당일 오후 것이었다. 글에 첨부된 이미지가 일부 사라졌다. 백업이 있다는 사실보다 어느 시점의 사이트를 되살릴 수 있는지가 중요하다는 걸 다시 확인한 사고였다.
먼저 복구할 범위와 허용 시간을 적는다
서버 백업 방법을 정할 때는 용량보다 두 가지 시간이 먼저다. 장애가 나면 몇 시간 전 데이터까지 잃어도 되는지, 서비스는 몇 시간 안에 다시 열어야 하는지다. 전자는 복구 시점 목표인 RPO, 후자는 복구 시간 목표인 RTO다. 하루 한 번 백업하면 최악의 경우 약 24시간치 변경분을 잃는다. 주문이 들어오는 쇼핑몰에는 큰 손실이지만, 주 1회 글을 올리는 블로그라면 받아들일 수도 있다.
백업 대상도 목록으로 적어야 한다. 보통 웹 파일, 업로드 파일, 데이터베이스, 서버 설정, 인증서와 개인 키, 예약 작업, 배포에 필요한 환경 설정이 들어간다. 소스 코드를 별도로 보관하더라도 운영 서버에서만 바뀐 설정이 있으면 복구 때 막힌다. 반대로 캐시와 다시 만들 수 있는 임시 파일은 백업에서 빼는 편이 낫다. 용량과 복구 시간을 함께 줄일 수 있다.
예를 들어 하루 방문자 3만 명인 사이트라도 글과 이미지가 거의 바뀌지 않으면 하루 한 번 백업으로 충분할 수 있다. 방문자가 300명이어도 예약이나 결제가 수시로 발생하면 더 촘촘한 백업이 필요하다. 트래픽 숫자만 보고 비싼 백업 상품을 고를 이유가 없는 셈이다.
데이터베이스와 파일의 시점을 맞춘다
운영 중인 데이터베이스 파일을 그대로 복사하는 방식은 조심해야 한다. 쓰기가 진행되는 도중 파일을 가져오면 복사본 내부의 시점이 어긋날 수 있다. 데이터베이스가 제공하는 논리 백업이나 백업 기능을 쓰고, 파일 시스템 스냅샷을 쓴다면 해당 데이터베이스가 안내하는 일관성 확보 절차를 따라야 한다. 스냅샷 버튼을 눌렀다는 이유만으로 복구 가능한 데이터베이스가 만들어지는 건 아니다.
워드프레스처럼 글 정보는 데이터베이스에, 사진은 디렉터리에 들어가는 사이트는 두 자료의 시점이 특히 중요하다. 가장 단순한 방법은 변경이 적은 시간에 쓰기를 잠시 멈추고 데이터베이스와 업로드 파일을 함께 백업하는 것이다. 중단이 어려우면 백업 시작과 종료 시점을 기록하고, 복구 후 그 사이에 올라온 파일과 글이 맞는지 확인할 절차를 둔다. 백업 완료 알림만 보고 시점 차이를 지나치면 실제 복구 때 누락이 드러난다.
전체 서버 이미지는 빠르게 되돌릴 때 편하지만, 잘못된 설정이나 악성 파일도 함께 되돌릴 수 있다. 이미지 백업과 별도로 데이터베이스 덤프, 업로드 파일, 설정 파일을 꺼내 볼 수 있게 보관하는 이유다. 서버 한 대를 통째로 복제하는 방식만으로는 특정 글이나 파일 하나를 되찾는 작업이 번거롭다.
서버 밖에 보관하고 보존 기간을 계산한다
같은 서버의 다른 디렉터리에 백업하는 경우를 자주 본다. 실수로 파일을 지웠을 때는 유용하지만 디스크가 고장 나거나 계정이 침해되면 원본과 백업이 함께 사라질 수 있다. 최소한 서버 밖 저장소에 사본을 두고, 가능하면 운영 계정이 백업을 마음대로 지우거나 덮어쓰지 못하게 권한을 나눈다. 클라우드 스냅샷도 원본과 같은 계정에만 있다면 계정 문제까지 막아 주지는 못한다.
보존 기간은 감으로 정하지 않는다. 백업 대상이 27GB이고 매일 전체 백업을 7개 남기면 단순 계산으로 189GB다. 여기에 주간·월간 사본과 전송 중 임시 공간을 더해야 한다. 증분 백업을 쓰면 저장량은 줄지만 복구할 때 어떤 전체 백업과 변경분이 필요한지 확인해야 한다. 하루 변경량이 작다면 작은 VPS나 저가 저장소로도 충분하다. 저장 비용보다 먼저 확인할 것은 보존 기간 동안 필요한 사본을 실제로 담을 수 있는지다.
백업 파일에는 회원 정보나 인증서 개인 키가 섞일 수 있다. 저장할 때 암호화하고, 복구용 암호와 키는 백업 파일과 분리해 보관한다. 암호를 아는 사람이 한 명뿐이면 그 사람이 자리를 비운 날 복구가 멈춘다. 누가 접근할 수 있는지, 퇴사나 담당자 변경 때 권한을 어떻게 회수할지도 운영 절차에 포함해야 한다.
복구 시험으로 백업을 검증한다
백업 작업의 성공 표시와 복구 성공은 다르다. 한 달에 한 번이라도 별도 환경에 백업을 풀어 사이트가 뜨는지 확인하는 편이 낫다. 데이터베이스가 열리는지, 최근 글과 업로드 파일이 보이는지, 로그인과 주요 기능이 동작하는지를 점검한다. 운영 중인 서버에 바로 덮어쓰며 시험하면 기존 데이터를 망가뜨릴 수 있으니 분리된 환경을 쓴다.
복구 시험에서는 시간을 잰다. 27GB 백업을 내려받는 데 40분, 데이터베이스를 넣는 데 30분, 설정을 맞추는 데 50분이 걸린다면 RTO 1시간은 현재 절차로 달성할 수 없다. 이때 필요한 것은 막연한 상위 요금제가 아니라 병목 확인이다. 전송 속도가 문제인지, 데이터베이스 복원이 느린지, 설정을 수작업으로 바꾸느라 지체되는지에 따라 개선 방법이 달라진다.
장애가 나면 원인 분석보다 백업을 먼저 덮어씌우고 싶어지지만, 그 전에 마지막 정상 시점과 최근 백업의 상태를 확인해야 한다. 침해 사고라면 감염된 시점 이후 백업에도 문제가 남아 있을 수 있다. 복구 대상 시점을 고르고 현재 상태를 따로 보존한 뒤, 검증한 절차대로 되돌리는 편이 안전하다.
제가 운영 현장에서 믿는 백업은 파일 개수가 많은 백업이 아니다. 필요한 시점의 데이터를 고를 수 있고, 다른 서버에서 정해진 시간 안에 다시 열 수 있는 백업이다. 작은 사이트라면 단순한 일일 백업과 정기적인 복구 시험부터 시작해도 충분하다. 실제로 되살려 본 기록이 쌓일수록 다음 장애 때의 판단도 빨라진다.
