교내에서 운영하던 CMS 서버 PC의 파워 서플라이가 죽어 본체가 꺼졌고, 사이트가 내려갔다. 급한 건 “빨리 켜기”가 아니라 “무엇을 잃을 수 있는가”였다. DB 데이터는 죽은 PC의 디스크 볼륨에 있었고, 클라우드에 롤백용 스냅샷이 살아 있었지만 그건 이전 시점에서 멈춘 오래된 사본이었다. 라이브 볼륨·매일 백업·클라우드 스냅샷의 최신도를 비교하니, 파워만 갈아 그 디스크를 그대로 살리는 게 손실 0이자 제일 덜 번거로운 길이었다. 그리고 이 사고는 백업이 전부 같은 디스크에 있다는 사실을 뒤늦게 들이밀었다.

사건

온프레미스로 옮긴 지 얼마 안 된 CMS 서버 PC의 파워 서플라이(PSU)가 죽었다. 본체가 꺼졌고 aicms.pusan.ac.kr이 내려갔다.

파워가 나가면 손이 먼저 “빨리 다시 켜자”로 간다. 하지만 이건 실서비스였고, DB에는 학생 개인정보가 들어 있었다. 성급히 새 PC에 docker compose up부터 하면 빈 데이터베이스가 뜬다. 그래서 첫 질문은 복구 방법이 아니라 데이터였다 - 지금 최신 데이터가 어디에, 얼마나 온전하게 있는가.

데이터가 어디에 얼마나 최신으로 있나

세 군데를 놓고 최신도를 비교했다.

위치	최신도	손실
서버 DB 볼륨(죽은 디스크, 라이브)	지금까지 전부	0
같은 디스크의 매일 덤프	최대 하루 전	약 1일
클라우드 롤백 스냅샷	이전 전환 시점에서 멈춤	며칠치

여기서 중요한 게 하나 있었다. 클라우드 스냅샷이 살아 있다는 건 안심되지만, 그건 온프레미스로 넘어오던 시점 이후로 한 줄도 안 받은 오래된 사본이었다. 넘어온 뒤의 모든 쓰기는 죽은 디스크 안에만 있었다. 즉 클라우드는 셋 중 가장 오래된 축이라 최후의 수단이지, 우선순위가 아니었다.

그리고 PSU 고장의 성질을 짚었다. 파워가 죽는 건 디스크를 죽이는 경우가 드물다. 다시 말해 죽은 디스크 안의 데이터는 거의 확실히 멀쩡했다. 그렇다면 그 디스크를 살리는 게 손실 0이다.

선택지

디스크가 살아 있다는 전제에서 길은 세 가지였다.

파워만 교체. 같은 PC에 PSU만 갈면 데이터·설정·인증서·IP가 전부 그대로다. 사설 IP도 MAC도 안 바뀌니 교내망 쪽에 손댈 것도 없다. 데이터 손실 0, 가장 덜 번거롭다.

디스크만 새 PC로 이동. 부팅 디스크째 옮기면 OS·도커·볼륨이 다 따라온다. 데이터 손실은 0이지만, 다른 하드웨어로 부팅하는 순간 함정이 붙는다. 리눅스라 부팅 자체는 대체로 되지만, 네트워크 인터페이스 이름이 바뀌어 netplan을 고쳐야 하고, MAC이 바뀌니 교내망이 IP를 MAC에 묶어 뒀다면 IT에 새 MAC 등록을 요청해야 한다.

새 PC에 설치 후 클라우드 스냅샷에서 복원. 가장 오래된 사본으로 되돌아간다. 며칠치 손실.

고장이 PSU 하나뿐이라면, 파워 교체가 오히려 디스크 이동보다 덜 번거로웠다. 디스크 이동에서 걸리는 MAC·netplan·BIOS 부팅 모드가 파워 교체엔 아예 없다. 같은 기계 그대로이기 때문이다. 결론은 명확했다.

복구

파워를 교체하고 전원을 넣었다. 그다음은 내가 할 게 별로 없었다.

• Docker 데몬은 부팅 시 자동 시작되고, 컨테이너에 restart: unless-stopped가 걸려 있어 앱·DB 컨테이너가 알아서 다시 떴다.
• Caddy는 systemd 서비스라 자동 재시작됐고, HTTPS 인증서도 그대로였다.

즉 파워만 정상으로 돌려놓자 서비스가 스스로 복귀했다. aicms.pusan.ac.kr이 다시 열리는 것 자체가 “다 정상 복귀했다”는 증거였다. 사이트가 뜬 뒤 로그인해 데이터가 온전한지 확인했다. 비정상 종료였지만 PostgreSQL은 그런 종료를 스스로 복구하도록 만들어져 있어서, 화면이 뜨고 데이터가 보이면 정상이라고 봐도 됐다.

놓치고 있던 것

복구는 깔끔했지만, 이 사고가 들이민 진짜 문제는 따로 있었다. 백업이 전부 같은 디스크에 있었다. 매일 도는 덤프도, 라이브 볼륨도 다 그 한 장의 디스크 위였다. 이번엔 PSU만 죽어서 디스크가 살았으니 운이 좋았던 것이고, 디스크가 죽었다면 백업까지 통째로 사라졌을 것이다. 클라우드 스냅샷이 있었지만 그건 며칠 전에 멈춘 사본이라 그 자리를 대신하지 못한다.

그래서 하드웨어가 죽을 수 있다는 걸 눈으로 본 김에, 최신 덤프와 환경 설정을 디스크 바깥(다른 장비/저장소)으로 한 벌 빼 두는 걸 남은 일로 정했다.

교훈

• 장애 대응의 첫 질문은 “어떻게 켜지”가 아니라 “무엇을 잃을 수 있지”다. 특히 개인정보를 다루면, 성급한 재기동 한 번이 빈 DB를 만들 수 있다.
• “백업이 있다”와 “그 백업이 최신이다”는 다르다. 클라우드에 사본이 남아 있어도 이전 시점에서 멈춰 있으면, 그건 안전망이지 현재가 아니다. 최신도를 값으로 비교해야 판단이 선다.
• 가장 덜 번거로운 복구가 가장 안전한 복구이기도 하다. 고장이 PSU 하나면, 화려한 마이그레이션보다 부품 하나 교체가 데이터 손실도 0이고 부작용도 0이었다.
• 백업이 원본과 같은 디스크에 있으면 그건 백업이 아니다. 단일 장애점 위의 사본은, 그 장애가 오는 순간 원본과 함께 사라진다.

이 서버로 옮겨 오기까지의 과정은 학생 데이터를 교내로에 적어 뒀다.