2022월 7월 21일 오전 2시 15분 경에 서버 장애가 발생하였습니다.
현재는 무사히 복구되어 7월 24일 오전 2시 15분부터 체섭을 비롯한 다른 서버를 재개합니다.
아래는 이번 서버 불량에 관한 사후 분석입니다.
1. 서버 구성
삼국지 모의전투 HiDCHe는 여러가지 이유에서 제 홈서버에서 운영중입니다.
상시 동작하는 Windows 원격 머신이 필요해서, 리눅스 버전 변경 시 재 구성을 편리하게 하기 위해서 등의 이유로
서버의 주 OS는 Windows 11이고, Hyper-V를 이용해 리눅스를 운영하고 있습니다.
실제 OS는 Ubuntu 22.04이고, SSD(리뷰안 NX1200 M.2 NVMe 1TB)쪽에서 vhdx 파일들 여러개를 만들어 각각에 파티션을 주고 사용하였습니다.
HDD 4개는 passthough 모드로 리눅스에 연결하여 ZFS RAID가 구성되어 있습니다.
주목할 점 중에 하나는 디스크들에 Full Disk Encryption이 적용되어 있다는 겁니다.
SSD쪽은 Bitlocker + SecureBoot 조합으로 AES-XTS 암호화가 되어있으며,
HDD RAID쪽은 ZFS의 disk encryption(AES-GCM) 암호화가 되어있습니다.
각각은 부팅시에 자동으로 마운트되도록 설정되어 있고, 만일에 대비하여 두개의 키 모두 제가 개인적으로 사용하는 키 체인 프로그램에 적어두었습니다.
실제 애플리케이션들은 주로 리눅스에서 Docker를 사용하여 운영되고 있습니다.
미리 작성해둔 Docker compose script와 조합하여, bind 기능을 적극적으로 사용하고 있습니다.
가령 삼모전의 경우에는 전체 애플리케이션이 SSD쪽(즉, root partiton)에 bind 하도록 되어있으며,
(1) 애플리케이션 코드 - SSD 바인드
(2) DB - SSD 바인드
(3) 이미지, 첨부파일, 빌드된 js - HDD ZFS 바인드
가 되어있어 용량과 성능을 둘다 노리는 구성을 취하고 있습니다.
2. 장애 발생
2022월 7월 21일 오전 2시 15분 경에 NVMe SSD측에 장애가 발생했습니다.
모델은 리뷰안 NX1200 M.2 NVMe 1TB으로, 아마도 컨트롤러 자체보다는 웨어레벨링을 기록하는 셀이 불량이 나면서,
해당 셀 부근의 데이터와, 새로 기록된 모든 데이터가 손상되는 증상이 나타난 것으로 추정됩니다.
SSD 컨트롤러 내부에서 기록 불량을 감지하고, 스스로 Read-only 모드로 전환하였고,
이 때문에 가상머신을 포함하여 OS 전체가 쓰기 불량으로 인해 정지했습니다.
3. 진행 작업
3-1. 첫째날 전반
서버를 재부팅하였지만 파티션이 불량파티션이 되어, 아예 부팅이 되지 않았습니다. (Windows에서 Unable to mount boot volume 에러가 뜨며, 블루스크린)
Windows PE를 이용하여 복구 시스템 부팅 후 SSD 상태를 확인한 결과 (앞서 적은바와 같이) read only 상태로 되어 있었습니다.
다행히도 디스크 자체가 읽기 불량에 빠진 것은 아니고, 디스크 내의 파티션은 제대로 구분되어 있었으며, 특히 가장 중요한 메인 파티션이 정상적으로 bitlocker 파티션으로 인식되어 있었습니다.
(이때 bitlocker 복구 키를 대체 어디에 보관해두었는지 몰라 잠시 시간 지연이 있었습니다. 1차 멘붕 포인트! 꽤나 상식적인 위치에 있었는데, 당황했던 탓이겠지요)
문제는 bitlocker 키를 이용하여 락을 풀더라도, 안쪽에 파티션은 "Raw partition"으로 인식되어 흔히 자주 보는 '포맷이 필요합니다'가 뜨는 상태가 나타나 빠른 해결이 불가능하게 되었다는 점입니다.
따라서 PE를 이용하여 서버쪽에서 복구하는 대신 SSD를 제 컴퓨터에 옮겨 붙이고, 복구를 하기로 합니다.
디스크 불량일때 주로 사용하는 도구는 testdisk ( https://www.cgsecurity.org/wiki/TestDisk_Download )인데, 파티션이 raw partition으로 뜨는 상황에도 파티션 타입을 유추하여 파일 구조를 꺼내올 수 있는 훌륭한 도구입니다.
그러나 testdisk는 bitlocker를 지원하지 않아 위 상황에선 쓸 수 없었습니다.
대신하여 다양한 파일 복구 툴들을 이용해보았지만.... 마찬가지로 전부 실패했습니다.
가장 문제가 되는 증상은 Windows의 특징으로써, 디스크에서 읽기/쓰기를 시도하다가 timeout이 계속해서 발생하면 장치 연결을 재 설정해버리는 문제였습니다.
SSD는 망가져서 특정 구역을 읽거나 쓰려고 시도하면 응답을 하지 않는 문제가 있었고, 위처럼 전역 탐색을 시도하면 무조건 timeout이 발생할 수밖에 없습니다.
거기다 이 SSD bitlocker로 암호화되어 있고, 위 문제로 재 설정하면 bitclocker 인식이 풀리기 때문에, 이 상황에선 단위 복구 툴을 사용해도 데이터를 얻을 수 없다는 결론을 얻었습니다.
3-2. 첫째날 후반(새벽)
https://www.ntbrad.com/2020/09/22/recover-deleted-files-from-a-bitlockered-drive-or-partition/
bitlocker 관련 복구를 찾던 도중, 위 링크를 통해 리눅스 + Dislocker + testdisk 조합이 가능하다는 것을 알아냈습니다.
리눅스에서는 Disk IO timeout이 발생하는 경우에도 '다양한' 방법을 사용할 수 있기 때문에, 위 방법을 시도해보기로 하고,
메인 컴퓨터에 Hyper-V - 리눅스 설치(우분투) - Passthrough로 NVMe 연결을 해주었습니다.
놀랍게도 testdisk에서 복호화된 파티션에 잘 접근할 수 있었고, (리눅스의 diskmapper 모델은 최곱니다.)
Raw partition을 강제로 NTFS로 인식한 후 접근한 결과, 리눅스 vhdx 파일을 꺼내올 수 있었습니다.
SSD에 있던(=윈도우즈 쪽에 있는) 다른 자료들도 가져오려고 했지만, 이쪽에 타격이 심한 모양인지 별로 건져올 수 없었습니다.
vhdx 파일을 다시 Hyper-V를 이용하여 부팅을 해보았지만, 마찬가지로 이쪽 vhdx 파일도 파티션이 깨져 있어서 정상 부팅이 되지 않았습니다.
어쩔 수 없이 이 vhdx 파일을 아까 복구작업을 하던 우분투에 마운트하여 파일 복구를 시도했습니다.
다만... testdisk는 btrfs 파일 시스템을 지원하지 못하는 문제가 있었고,
다행히(?)도 btrfs는 자체 복구 명령어( btrfs restore )를 가지고 있어 복구 명령을 내렸습니다.
어쨌든 파일 복구가 되는 것을 확인하고, 남은 데이터를 정리해 마저 작업하기로 했습니다.
3-3. 둘째날 전반
구입한 SSD가 도착해 서버 OS를 다시 구축했습니다.
vhdx를 성공적으로 꺼낼 수 있었기 때문에, 기존과 같이 Windows 11 + bitlocker + Hyper-V 구성으로 설치하고,
하드디스크들도 다시 연결이 잘 되는지 확인했습니다.
ZFS는 안전성을 중시하는 파일 시스템인 덕분에, 마운트도 잘 되었고,
디스크 검사를 돌린 결과 역시 파일 깨짐 없이 멀쩡한 것을 확인했습니다.
다만, 백업 데이터가 하나도 없다는 것을 다시 확인했습니다. -_-
따라서 vhdx 파일에서 데이터를 꺼내지 못하면 리셋되는 상황임을 확인합니다.
3-4. 둘째날 중반
vhdx에서 btrfs restore 명령을 통해 복구한 파일들을 확인해보니 일부만 복구된 것을 확인하고, 어떤 데이터들이 남아있는지 확인하는 작업을 시작했습니다.
희한하게도 MariaDB 등 DBMS를 이용해 저장하는 데이터들만 제대로 인식이 안되는 걸 보고,
체섭을 기준으론 '명예의 전당', '연감', '왕조일람' 정도는 복구를 통해 sql query를 날릴 정도는 된다는 걸 확인합니다.
계속해서 테이블 하나하나 복구가 가능한지 확인 하던 도중에..
삼모전 유저 DB가 깨진게 아니라 '아예 파일 용량이 0'인 것을 깨달았습니다. (2차 멘붕 포인트)
유저 DB는 회원 가입에만 사용하기 때문에 날아갈 리가 없다고 생각하고 있었는데,
유저 DB, 유저 회원가입/로그인 로그 DB등이 모두 용량이 0이었습니다....
그럴리가 없다고 생각하여 다급하게 btrfs 명령어들을 확인해보다보니,
btrfs rescue super-recover 명렁으로 깨진 vhdx 파일 일부를 마저 살려내는데 성공합니다.
그리고 나서 다시 복구해보니 문제의 회원 DB 파일도 잘 살아났습니다 (휴...)
대부분의 파일이 복구되었음에도 불구하고 여전히 일부 파일은 깨져있었습니다.
MariaDB의 데이터 파일은 멀쩡한 대신, db ahead-logging 파일이 대부분 깨져 있었는데,
별 수 없이 강제 복구 모드를 켜고 sql 덤프 -> 다시 기록을 하기로 합니다.
복구 모드에서 테이블을 검사한 결과로는 DB에서 심각하게 깨진 부분은 없어서 바로 서비스 가능한 수준으로 복구가 가능할 것으로 보였습니다.
3-4. 둘째날 후반(종료)
DB 덤프를 완료한 이후의 작업은 크게 문제없이 '서버 이전' 작업처럼 진행했습니다.
모든 서비스들은 docker container이기 때문에, 다시 빌드하여 파일들을 다시 구성한 다음,
설정, DB 파일만 다시 이식하는 것을 반복했습니다.
삼모전 각 서버를 복구하고 나니, 깨진 데이터 없이 잘 복구된 것으로 보였고,
그 외에 다른 서비스들도 차례차례 복구하여 사소한 트러블들을 잘 해결하고, 복구 작업을 마쳤습니다.
4. 문제점 및 대응 방안
이번 서버 불량 사태에 대해 몇가지 심각한 문제가 있었습니다.
4-1. 백업 없음
4년이 넘게 이뤄진 서비스인데도 불구하고, 백업파일이 없었습니다.
삼모전 서비스 초반에는 백업 스크립트가 있어서 주기적으로 백업을 하고는 있었습니다만..
이번 서버 불량 시점에서는 보존된 백업이 없었습니다.
(1) Ubuntu 18.04 -> Ubuntu 22.04 업그레이드 과정에서 자동 백업 스크립트를 깜빡하고 이전하지 못했고,
(2) ZFS를 새로 암호화하는 과정에서, 디스크 전체 백업 -> 포맷 -> 암호화 설정 -> 백업파일 복원을 하면서,
그때 당시에 가장 만만해 보였던 삼모전 백업파일들(~2021년 데이터)을 날려버렸습니다.
백업 스크립트를 '나중에' 설정해야겠다는 마음은 있었는데, 그 전에 치명적인 불량이 발생했습니다.
늦었죠.
정말.. 복구가 된 것이 천만 다행입니다.
- 대응
서버 동작 여부를 확인하는대로, 자동 백업 스크립트를 작성해야합니다.
매일 새벽마다 삼모전의 DB를 sql파일로 만들고, 요일별로 sql 파일을 작성하도록 할 예정입니다.
작성한 sql 파일은 ZFS HDD에 따로 sub volume을 만들어 보관할 예정이고,
ZFS에서 제공하는 snapshot 기능을 더 활용하면, 훨씬 더 긴 기간의 파일을 쉽게 보관할 수 있을 것입니다.
4-2. SSD 기종 문제
이전에 사용한 리뷰안 NX1200 M.2 NVMe 1TB는 사실 서버에 사용하기엔 무리가 있는 기종입니다.
SSD에서 제공하는 TBW는 300TBW 정도로, 그때 당시에 600TBW 제품이 있는걸 고려했을 때, 수명이 상대적으로 짧은 모델이었습니다.
그리고 이번 SSD 불량은 120TBW에서 발생했으니, 운이 없었다는 걸 감안하더라도, 이런 모델을 선택해서는 안되었습니다.
이번에는 SSD를 새로 구입하면서 DRAM이 있고, 발열이 적으며, 잘 알려진 브랜드로 구입했습니다.
PCIe 4.0 모델을 구입할까 했지만, 컨트롤러 발열이 많은게 조금 고민이 되어서 배제했습니다.
그리고 전 실리콘 모션, 파이슨 컨트롤러를 좋아하지 않고, TBW를 충분히 높은걸 찾다보니,
삼성 970 Evo Plus 1TB로 구입했습니다.
(예를 들어 PNY XLR8 CS3030 M.2 NVMe 히트싱크 같은 모델은 파이슨 컨트롤러, 사온 칩일텐데, 혼자서 1,665TBW라는 믿지못할 수치를 보여주니... 거르기 딱 좋았습니다)
4-3. 암호화? vhdx? btrfs?
이번에 복구작업이 까다로웠던 이유에는 비트라커 암호화가 있었습니다.
그러나 dislocker + testdisk로 잘 복구 할 수 있었으며,
vhdx 파일은 따로 건져오기가 편해서 차라리 복구가 쉬웠습니다.
오히려 암호화 할 경우에는 1비트 오염 -> 4KB 블록 전체 오염이라는 특징을 가지고 있는게 어떤 면에선 도움이 된다고 생각하는데,
OS든 DB든 아니면 뭐가되었든간에 4KB가 통째로 오염되면, 보통 '즉시 뻗습니다.'
추가 피해를 막는다는 점을 고려하면 그대로 유지해도 별 문제없지 않을까 하는 생각입니다.
btrfs 파일 시스템의 경우에는 조금 고민인데,
ext4로 되어있으면, 복구 툴이 워낙 많아서 골라 쓸 수 있는데,
btrfs는 자체 제공하는 btrfs rescue, btrfs restore에 의존해야하는 문제가 있습니다.
이번 사태엔 복구가 잘 되었지만, 혹시나 몰라 ext4로 전환했습니다.
5. 결론 및 소감
다행히... 아주 천만 다행히...
백업이 하나도 없는데도!!
멀쩡히 잘 살아나서 다행입니다...
정기 백업 꼭 하고, SSD 좋은거 쓸겁니다....
+ testdisk 툴... 공짜인데 CLI라서 사람들이 잘 안쓰는데 아주 좋습니다... 일 터지면 써보세요.
+ Windows보다 Linux에서 NTFS 복구가 더 잘되는거 실화인가요...?
댓글 달기