모두
모두콘텐츠
얼마 전 사이트 이전을 돕다가 백업 파일이 들어 있는 nas 서버를 확인했는데, 마지막 백업 날짜가 8개월 전이었다. 장비는 멀쩡했고 디스크 상태도 정상이었다. 문제는 백업 작업이 중간에 실패한 뒤 아무도 알림을 받지 못했다는 점이다. NAS를 들일 때는 용량보다 먼저 무엇을 얼마나 자주 저장하고, 장애가 나면 어디서 복구할지 정해야 한다.
저장할 데이터와 복구 시간을 먼저 계산한다
웹사이트 운영용 NAS라면 서버 전체를 무작정 복사하기보다 복구에 필요한 데이터를 나눠 보는 편이 낫다. 업로드 파일, 데이터베이스 덤프, 설정 파일, 인증서, 배포에 쓰는 파일이 대표적이다. 데이터베이스는 사용 중인 파일을 그대로 복사하면 복구 시점에 내용이 맞지 않을 수 있으니, 사용하는 엔진의 백업 기능으로 덤프를 만들거나 일관성이 보장되는 방식으로 백업해야 한다.
예를 들어 업로드 파일 600GB, 데이터베이스 덤프 80GB, 기타 파일 20GB라면 현재 원본은 700GB다. 여기에 1년 동안 30% 늘어날 것으로 보고, 변경 이력과 스냅샷을 위해 여유를 잡으면 처음부터 700GB에 딱 맞춘 디스크를 살 이유가 없다. 반대로 하루마다 전체 700GB를 새로 보관한다고 가정해 디스크를 과하게 살 필요도 없다. 백업 프로그램이 실제로 얼마나 변경된 데이터를 쌓는지 확인해야 한다.
복구 목표도 적어 둔다. 하루치 데이터 손실을 감수할 수 있는 개인 블로그와 주문 한 건도 놓치기 어려운 쇼핑몰은 백업 간격이 다르다. 10분 안에 서비스를 되살려야 한다면 NAS에 파일이 있다는 사실만으로는 부족하다. 새 서버를 만들고 데이터를 되돌리는 데 걸리는 시간을 직접 재봐야 한다.
디스크 개수보다 고장 범위를 본다
2베이 NAS에 4TB 디스크 두 개를 미러로 묶으면 사용 가능한 용량은 대략 4TB다. 디스크 하나가 고장 나도 운영을 이어갈 수 있지만, 파일을 잘못 지우거나 랜섬웨어가 파일을 암호화하면 두 디스크에 그 결과가 함께 반영된다. 미러는 디스크 고장에 대비하는 구성이지 백업본은 아니다.
작은 사이트 한두 개의 백업을 모으는 용도라면 처음부터 CPU와 메모리가 큰 모델을 고집할 필요는 없다. 백업 용량, 동시에 접근할 사람 수, 스냅샷이나 암호화 기능을 실제로 쓸지를 먼저 본다. 사진 편집 파일을 여러 사람이 NAS에서 직접 열고 저장하는 환경은 다르다. 이때는 디스크 성능과 네트워크 속도가 체감 속도를 좌우한다. 장비 사양표의 최고 전송 속도보다 사무실 회선과 스위치가 1Gbps인지, 더 빠른 연결이 필요한지 확인하는 순서가 맞다.
용량을 계산할 때는 디스크 제조사가 표시하는 TB와 운영체제에 보이는 용량 단위가 다르다는 점도 기억해야 한다. 스냅샷, 파일 시스템, 백업 이력까지 쓰면 표시 용량 전체를 데이터로 채울 수 없다. 여유 공간이 거의 없는 NAS는 백업 실패나 성능 저하를 겪기 쉽다. 저는 예상 사용량이 디스크를 계속 밀어붙이는 구성이라면 증설 시점까지 함께 잡아 둔다.
NAS 밖에 사본을 하나 더 둔다
NAS가 서버와 같은 사무실에 있으면 서버 디스크 고장에는 도움이 된다. 하지만 침수, 화재, 도난, 잘못된 관리자 작업에는 함께 영향을 받을 수 있다. 그래서 NAS를 1차 백업 대상으로 쓰더라도 다른 장소의 저장소나 분리해 보관하는 외장 디스크에 사본을 둔다. 사이트 원본과 NAS가 같은 건물에 있다면 위치를 나눈 사본의 의미가 더 크다.
자동 백업을 설정한 뒤에는 보관 기간을 확인한다. 매일 새벽 백업을 14일 보관하는 정책이라면, 삭제 사실을 3주 뒤에 발견했을 때 필요한 파일은 이미 모든 백업에서 사라졌을 수 있다. 최근 파일은 촘촘하게, 오래된 시점은 간격을 넓혀 남기는 식으로 운영하면 용량을 덜 쓰면서 복구 선택지를 확보할 수 있다. 변경 이력이 큰 데이터베이스와 거의 바뀌지 않는 이미지 파일에 같은 보관 규칙을 적용할 이유도 없다.
백업 계정에는 백업에 필요한 권한만 준다. 평소 쓰는 관리자 계정을 서버에 저장해 두면 서버가 침해됐을 때 NAS의 오래된 사본까지 지워질 수 있다. 가능하다면 스냅샷과 삭제 방지 기능을 켜고, 관리 화면은 외부에 직접 공개하지 않는다. 원격 접속이 필요하면 접근 권한을 제한한 VPN을 쓰는 편이 운영하기 수월하다.
백업 성공 표시보다 복구 시험을 믿는다
장애가 나면 저는 먼저 백업 작업의 마지막 성공 시각과 파일 크기부터 본다. 성공 알림이 떠도 덤프 파일이 평소보다 지나치게 작거나 필요한 폴더가 제외됐다면 복구에 쓸 수 없다. 저장 공간 부족, 계정 권한 변경, 백업 대상 경로 변경도 흔한 실패 원인이다. 실패 알림은 NAS 화면 안에만 남기지 말고 평소 확인하는 채널로 받는 게 좋다.
한 달에 한 번 정도는 백업본 하나를 골라 별도 환경에 실제로 복구해 보는 편이 안전하다. 파일 몇 개를 열어 보는 데서 끝내지 말고 데이터베이스를 올리고, 이미지가 뜨는지, 로그인과 주요 화면이 동작하는지 확인한다. 필요한 암호와 복구 절차도 NAS 안에만 저장하면 NAS에 접근하지 못하는 날에는 꺼낼 수 없다.
NAS는 서버 운영을 편하게 해 주는 저장 장비다. 다만 장비를 샀다는 사실보다 백업이 계속 실행되는지, 다른 장소에 사본이 있는지, 실제로 몇 시간 안에 되돌릴 수 있는지가 사이트를 살린다. 작은 사이트라면 저렴한 구성으로 시작해도 된다. 복구 시험에서 시간이 부족하다는 사실이 확인될 때 사양과 백업 방식을 늘리는 편이 납득할 만하다.
