백업 파일은 복구 후보일 뿐 복구 성공의 증거가 아닙니다. 다른 권한 있는 담당자가 장애 난 시스템이나 한 사람의 노트북에 의존하지 않고 깨끗한 환경에 홈페이지를 복원하고 검증한 뒤 롤백할 수 있어야 합니다.

무엇을 복구해야 하는지 정의합니다

계층 백업 증거 복원 테스트
코드 저장소와 태그된 릴리스 새 복제본에서 예상 산출물 빌드
콘텐츠 CMS 내보내기 또는 원본 파일 페이지·메타·내부 링크 복구
DB 버전이 있는 암호화 덤프 스키마와 비민감 표본 복원
자산 객체 저장소·미디어 사본 참조 이미지와 다운로드 로드
설정 변수와 공급자 설정 문서 숨은 로컬 파일 없이 새 환경 실행
DNS·도메인 영역 내보내기와 등록기관 목록 권한자가 레코드를 안전하게 재구성
자격증명 승인된 보관소와 복구 담당자 두 명 이상이 필요한 시스템 접근

운영 비밀값을 백업 압축 파일이나 보고서에 넣지 않습니다. 이름과 승인된 복구 위치만 기록하고 비밀 관리자를 통해 주입합니다.

가장 작은 의미 있는 훈련을 실행합니다

  1. 복구할 릴리스와 목표를 정합니다.
  2. 운영 환경을 덮어쓸 수 없는 격리 대상을 만듭니다.
  3. 문서화된 원본으로 코드, 콘텐츠, DB, 자산, 설정을 복원합니다.
  4. 대표 페이지, 폼, 리디렉션, canonical, 메일과 접근 제어를 확인합니다.
  5. 시작·사용 가능 시각, 복원 시점, 실패, 수작업을 기록합니다.
  6. 임시 환경을 삭제하거나 보호합니다.
  7. 모든 결함에 담당자와 기한을 배정합니다.

NHN Cloud 랜섬웨어 대응 가이드는 복원 테스트와 문서화를 명시합니다. CISA도 저장된 사본을 믿는 데서 끝내지 말고 보호된 백업과 정기 검증을 권고합니다.

무결성뿐 아니라 독립성을 시험합니다

암호화 키, DNS 계정, 패키지 저장소, 빌드 설명이 같은 업체와 함께 사라지면 정상 압축 파일도 쓸 수 없습니다.

  • 복구 담당자가 둘 이상인가?
  • 백업 자격증명이 운영 자격증명과 분리됐는가?
  • 주 계정 삭제나 침해 후에도 사본이 남는가?
  • 실행 버전과 의존성이 고정됐는가?
  • 복구 중 도메인과 호스팅을 갱신할 수 있는가?
  • 허용 가능한 최근 데이터 시점이 정해졌는가?

허용 가능한 데이터 손실 시점과 허용 가능한 중단 시간을 사업 결정으로 적습니다. 콘텐츠 갱신이 드문 사이트와 거래 서비스가 같은 답을 가져서는 안 됩니다.

보고서에는 테스트한 사본, 환경, 담당자, 시간, 복원 시점, 통과 항목, 결함, 다음 훈련일을 남깁니다. 내려받기나 압축 해제만 했다면 “복구 검증 완료”라고 쓰지 않습니다.

NEXT PROJECT

홈페이지 제작, 어디서부터 정할지 막막하신가요?

현재 상황과 필요한 결과를 들은 뒤, 만들 범위와 다음 단계를 먼저 정리합니다.

함께 읽을 글

  1. workflows 홈페이지 제작사가 폐업했다면 재제작보다 도메인부터 복구하세요
  2. privacy 홈페이지 문의폼 개인정보 안내에 출시 전 꼭 들어갈 내용
  3. engineering 문의 전송은 성공했는데 이메일이 안 왔다면 전체 경로를 점검하세요