백업은 “파일이 어딘가에 있다”로 끝나지 않습니다. 실제 장애에서는 어떤 지점으로, 어떤 순서로, 어떤 검증을 거쳐 되돌릴지(롤백/복구 경로)가 준비되어 있어야 복구가 빨라집니다.
아래는 Ubuntu에서 Apache를 운영 중이라는 전제로, 빠른 복구(임시) → 근본 해결 → 재발 방지 흐름으로 정리한 실전 체크입니다.
0) 복구 전에 먼저: 현재 상태를 “고정”해두기(증거 보존)
복구를 서두르다 보면 원인을 놓치기 쉽습니다. 복구 시작 전에 최소한 이것만 확보해두면, 나중에 근본 원인 분석이 훨씬 쉬워집니다.
- 시간대 확인: 장애 시작 추정 시각(배포/설정 변경/자동화 작업 시각 포함)
- Apache 상태: systemctl status apache2 출력 저장
- 로그 스냅샷: /var/log/apache2/error.log, /var/log/apache2/access.log (가능하면 해당 시각 전후만 발췌)
- 최근 변경: /etc/apache2/ 하위에서 최근 수정된 파일 목록(예: find로 mtime 기준 확인)
이 단계는 “당장 서비스 살리기”를 방해하지 않게, 5분 안에 끝내는 수준이면 충분합니다.
1) 빠른 복구(임시): 가장 안전한 롤백 경로부터 선택
임시 복구의 목표는 단 하나입니다. 정상 트래픽을 가능한 빨리 받되, 추가 손상을 만들지 않는 것입니다.
우선순위 1: “바로 되돌리기”가 가능한 스위치
- 직전 설정으로 롤백: 백업해둔 /etc/apache2/ 스냅샷이 있다면 해당 시점으로 복원
- VirtualHost 단위 롤백: 문제 도메인만 이전 conf로 교체(전체 Apache 롤백보다 영향 범위가 작음)
- 문제 모듈/사이트 비활성화: a2dissite / a2dismod로 원인 후보를 최소 단위로 끊기
우선순위 2: “우회로”로 숨만 붙이기
- 정적 유지보수 페이지로 임시 전환: 앱이 죽었을 때 Apache가 최소 응답을 주도록 설정(원인 분석 시간 벌기)
- 이전 배포 아티팩트로 교체: 문서 루트가 릴리스 디렉터리를 가리키는 구조라면 심볼릭 링크를 이전 릴리스로 되돌리는 방식이 빠름
임시 복구 후 필수 검증
- 설정 문법 검사: apachectl configtest
- 재기동 대신 reload 우선: 가능하면 systemctl reload apache2로 영향 최소화(단, 프로세스가 꼬였으면 restart 필요)
- 1분 모니터링: error.log에 동일 에러가 계속 쌓이는지 확인
“일단 살아났다”는 상태를 만들고 나서, 그 다음에 근본 해결로 넘어가는 게 운영적으로 안전합니다.
2) 근본 해결: 백업으로만 해결되지 않는 원인들을 정리
백업 복구로 서비스는 올라왔는데, 곧 다시 터지는 경우가 있습니다. 이때는 “왜 깨졌나”를 좁혀야 합니다.
1) 설정/인증서(SSL)/권한 문제
- configtest는 통과했는데 500/503: VirtualHost, ProxyPass, Directory 권한(AllowOverride/Require) 변경 여부 확인
- SSL 갱신 직후 장애: cert 경로/권한, chain 파일 누락 여부 확인(에러는 보통 error.log에 명확히 남음)
- 권한/소유자: DocumentRoot 아래 파일 권한이 바뀌면 403이 반복됨(배포 스크립트/umask 변경 흔함)
2) 리소스 병목/프로세스 문제
- OOM / 메모리 부족: kernel log(journalctl)에서 OOM killer 흔적 확인
- Apache MPM 설정 변화: MaxRequestWorkers/ServerLimit 변경이 갑자기 연결 실패를 만들 수 있음
- 백엔드 연동: reverse proxy 뒤의 앱/Upstream 장애인지 분리(문제 도메인만 실패하는지 체크)
3) “복원은 됐는데 데이터가 어긋남”
- DB/파일의 시점 불일치: 웹 파일은 복원했는데 DB는 다른 시점이면 앱이 오작동할 수 있음
- 복구 시각 기록: 어느 시점 스냅샷을 복원했는지(타임스탬프) 운영 노트에 남겨야 후속 대응이 가능
근본 해결 단계에서는 “추정”이 아니라 로그와 시각을 기준으로 원인을 좁히는 게 핵심입니다.
3) 안전장치: 롤백/복구 경로를 평소에 만들어두는 방법
장애 때 즉석에서 경로를 만들면 늘 위험합니다. 아래는 Ubuntu + Apache 환경에서 효과가 큰 “복구용 레일”입니다.
- /etc/apache2 백업을 스냅샷처럼: 변경 전후로 tar.gz로 남기고, “언제/왜”를 파일명에 포함(예: YYYYMMDD-change-reason)
- 릴리스 디렉터리 구조: /var/www/app/releases/… + current 심볼릭 링크처럼 “즉시 되돌림”이 가능한 레이아웃
- 인증서/키 백업 분리: SSL 관련 파일은 접근권한을 유지한 채 안전한 위치에 별도 백업(복원 시 권한 깨짐이 흔함)
- 복구 검증 스크립트: configtest + 주요 URL 헬스체크(curl) 정도만 자동화해도 실수 크게 줄어듦
특히 “설정 백업은 있는데 어떤 파일을 어디에 덮어써야 하는지 모르는 상태”가 가장 흔한 복구 지연 원인입니다.
4) 재발 방지: 복구 리허설과 모니터링 포인트
재발 방지는 거창할 필요가 없습니다. 대신 정기적으로 작동 확인이 돼야 합니다.
- 복구 리허설: 스테이징 또는 트래픽 적은 시간대에 “설정 복원 → reload → 헬스체크”를 실제로 1회 수행
- 로그 알림 기준: error.log에 특정 키워드(SSL, AH0…, permission denied 등)가 급증하면 알림
- 변경 관리: Apache 설정/배포는 “누가/언제/무엇을” 남기기(최소한 커밋/배포 기록이라도)
- 백업 무결성 점검: 백업 파일이 실제로 풀리는지, 권한/소유자가 유지되는지 주기적으로 확인
백업은 “성공 로그”보다 “복원 성공”이 훨씬 중요합니다.
마무리
Ubuntu + Apache 운영에서 백업은 필수지만, 진짜 복구 시간을 줄이는 건 롤백/복구 경로(안전장치)를 평소에 만들어두는 일입니다.
다음 장애 때는 “무슨 백업이 있지?”가 아니라 “어떤 순서로 되돌리지?”가 먼저 떠오르게 해두면, 복구가 훨씬 차분해집니다.