작은 서버는 구조가 단순해서 안전해 보입니다.
그런데 실제 장애는 보통 무엇을 백업해야 하는지 몰랐다거나 복구 순서를 적어두지 않았다는 데서 크게 터집니다.

특히 1코어 1GB 같은 작은 인스턴스는 복잡한 HA 구성을 붙이기 어렵기 때문에, 백업과 복구 절차가 사실상 가장 현실적인 안전장치입니다.

이 글은 2026년 5월 4일 기준 Oracle, NIST, CISA 공식 자료를 바탕으로, 작은 서버 운영자 기준의 복구 절차를 정리합니다.

1. 도구보다 먼저 “무엇을 잃으면 서비스가 멈추는지”를 적어야 합니다

백업에서 가장 흔한 실수는 디스크 전체를 어디선가 잘 백업해주겠지라고 막연히 생각하는 것입니다.

작은 블로그 서버라면 보통 중요한 것은 아래처럼 나뉩니다.

  • 소스 코드와 배포 스크립트
  • 콘텐츠 원본
  • 업로드 파일
  • 런타임 데이터
  • 환경 변수와 토큰
  • Nginx, systemd, 방화벽 같은 서버 설정

예를 들어 지금 같은 정적 Astro + 작은 Node API 구조라면, 우선순위는 대체로 이렇습니다.

  1. src/content/posts/ 같은 글 원본
  2. src/content/groups.json 같은 분류 정보
  3. public/uploads/ 같은 업로드 자산
  4. DATA_DIR 아래 JSON Lines 런타임 데이터
  5. 배포 경로, 서비스 설정, 비밀값

즉, VM 하나를 백업 대상으로 보는 게 아니라 서비스 복구에 필요한 조각들을 먼저 분리해야 합니다.

2. 부트 볼륨 백업만 믿으면 앱 상태까지 완전히 안전한 것은 아닙니다

Oracle 문서 기준으로 Block Volume 서비스는 부트 볼륨, 블록 볼륨, 볼륨 그룹을 백업할 수 있고, 붙어 있는 상태에서도 백업할 수 있습니다.
백업은 암호화되어 저장되고, 새 볼륨이나 기존 볼륨으로 복원할 수 있습니다.

여기서 중요한 해석이 있습니다.

  • 볼륨 백업은 강력하다
  • 하지만 디스크 시점 복사이지, 앱 의미를 자동으로 이해하는 것은 아니다

Oracle도 app-consistent backup을 위해서는 백업 전 서비스 pause, I/O 정지, 버퍼 sync, in-flight transaction flush 같은 조치를 고려하라고 안내합니다.

즉, 댓글 데이터나 업로드 중인 파일이 있는 서비스라면:

  • 그냥 스냅샷만 뜨는 것
  • 정리 후 시점을 맞춰 백업하는 것

은 복구 결과가 다를 수 있습니다.

3. 중요한 데이터는 가능하면 부트 볼륨과 분리하는 편이 낫습니다

Oracle 백업 모범 사례는 critical data를 가능하면 부트 볼륨보다 별도 블록 볼륨에 두는 편을 권합니다.
운영체제와 앱 데이터가 섞이면 복구 시 선택지가 줄어들고, 백업 크기도 불필요하게 커질 수 있기 때문입니다.

작은 서버에서는 처음부터 볼륨을 여러 개 나누기 어려울 수 있습니다.
그렇더라도 개념상으로는 분리해서 봐야 합니다.

  • OS와 패키지
  • 서비스 설정
  • 앱 소스
  • 업로드 파일
  • 런타임 데이터

예를 들어 업로드 파일과 DATA_DIR만이라도 별도 경로로 모아두면, 나중에 새 서버 + 데이터 복구 절차가 훨씬 단순해집니다.

4. 백업 주기와 보존 기간은 “장애 후 얼마나 잃어도 되는가”로 정해야 합니다

Oracle 문서는 백업 계획에서 frequency, recovery time, number of stored backups를 같이 보라고 설명합니다.
즉, 기술보다 먼저 아래 질문이 있어야 합니다.

  • 하루치 데이터 손실은 괜찮은가
  • 한 시간치 손실도 아픈가
  • 복구에 10분 걸려야 하는가, 반나절도 괜찮은가

작은 콘텐츠 사이트라면 보통 이렇게 시작하는 편이 현실적입니다.

  • 글 원본과 설정: 변경 직후 바로 원격 사본 반영
  • 업로드 파일과 런타임 데이터: 최소 하루 1회
  • 서버 볼륨 백업: 일간 정책 + 중요한 변경 전 수동 백업

Oracle 문서도 중요한 볼륨은 하루에 여러 번 백업할 수 있다고 안내합니다.
반면 저장 공간과 복구 부담이 있으니, 전부 자주 백업보다 무엇이 자주 바뀌는가를 먼저 구분해야 합니다.

5. 같은 클라우드 안 백업만으로 끝내지 말고, 다른 위치 사본도 둬야 합니다

Oracle은 볼륨 백업을 다른 리전으로 복사해 재해 복구에 쓸 수 있다고 설명합니다.
NIST와 CISA 계열 자료도 오프사이트 사본과 정기적인 복구 테스트를 반복해서 강조합니다.

이걸 작은 서버 운영 관점으로 번역하면 이렇습니다.

  • 같은 인스턴스 안 사본만 있으면 부족함
  • 같은 리전 안 백업만 있어도 단일 장애 범위를 완전히 벗어나지 못할 수 있음
  • 최소한 한 벌은 다른 위치에 있어야 마음 놓고 복구할 수 있음

실무적으로는 보통 아래 조합이 현실적입니다.

  1. Oracle 볼륨 백업
  2. 별도 위치의 소스 저장소
  3. 업로드/런타임 데이터의 별도 압축본 또는 원격 사본

즉, 클라우드 백업이 있으니 끝이 아니라 다른 위치 복사본이 있는가까지 봐야 합니다.

6. 백업보다 더 중요한 것은 실제 복구 순서를 적어두는 일입니다

NIST는 복구 계획을 미리 세우고, 백업 뒤에는 실제로 복원이 되는지 시험하라고 권합니다.
백업 파일이 있다는 것과, 서비스가 다시 살아난다는 것은 다릅니다.

작은 정적 사이트 + API 구조라면 복구 순서는 보통 이렇습니다.

  1. 새 인스턴스를 준비한다.
  2. 런타임(Node, Nginx, systemd 등)를 다시 올린다.
  3. 소스 코드와 콘텐츠 원본을 복원한다.
  4. 업로드 파일과 DATA_DIR를 복원한다.
  5. 환경 변수와 토큰을 복원한다.
  6. 정적 빌드를 다시 생성하고 공개 경로로 배포한다.
  7. /health, 댓글, 관리자, 업로드 파일 URL을 점검한다.

이 순서가 문서로 없으면, 실제 장애 때는 “무엇부터 살아나야 하는지”를 현장에서 다시 생각하게 됩니다.

7. 최소 월 1회는 “진짜 복구 연습”을 해야 합니다

백업은 성공 로그가 아니라, 실제 복원 성공으로 검증해야 합니다.

NIST와 CISA 자료는 둘 다 복구 테스트를 정기적으로 하라고 권합니다.
Oracle 문서도 백업 시 일관성, 복구 시간, 보존 정책을 미리 계획하라고 설명합니다.

작은 서버 운영자라면 월 1회 아래만 해도 큰 차이가 납니다.

  1. 가장 최근 백업이 실제로 존재하는지 확인
  2. 글 원본과 업로드 압축본을 다른 위치에 복원해보기
  3. 새 경로에서 앱이 최소 부팅되는지 확인
  4. 댓글/통계 같은 런타임 데이터가 읽히는지 확인
  5. 복구 문서에서 막히는 단계가 없는지 수정

복구 연습을 한 번도 안 한 백업은, 사고가 날 때까지 품질을 모르는 백업입니다.

이 프로젝트 같은 구조에서 우선 백업할 것

지금 같은 저장소라면 우선순위는 아주 분명합니다.

  • 콘텐츠: src/content/posts/, src/content/groups.json
  • 업로드: public/uploads/
  • 런타임 데이터: DATA_DIR
  • 배포/운영 설정: Nginx, systemd, 환경 변수
  • 필요 시 볼륨 백업과 교차 리전 사본

반대로 dist/는 다시 빌드할 수 있다면 복구 우선순위가 더 낮습니다.
핵심은 다시 만들 수 없는 원본을 먼저 지키는 것입니다.

한 줄 결론

작은 서버 백업의 핵심은 “무조건 스냅샷”이 아니라 다시 만들 수 없는 원본을 분리해서, 실제 복구 순서까지 적어두는 것입니다.
백업은 파일을 남기는 작업이고, 복구는 서비스를 다시 여는 작업이라는 점을 끝까지 구분해야 합니다.

이어 읽기

출처