사건경위서

일단 무슨 일이 일어난 건지 말해야 할 것 같군요.

일단 요약하자면…. zfs 스냅샷을 이용한 백업을 테스트하다가 문제가 생겼습니다.

zfs snapshot -r System/iocage/jail@test

명령을 내려서 jail의 스냅샷을 뜬 다음

zfs send -R System/iocage/jail@test > /mnt/temp/test.snap

으로 스냅샷을 뜬 건 좋은데…

zfs destroy -r System/iocage/jail@test

명령을 내린다는게 그만

zfs destroy -R System/iocage/jail

명령을 내렸습니다.

….

그래서 dataset이 날아갔습니다.

….

그래서 DB도 같이 날아갔습니다.

그래도 전 스냅샷을 백업해놨죠. 복구를 하면 되겠죠?

zfs recv System/iocage/jail < /mnt/temp/test.snap

하지만 이것은 작동하지 않습니다.

cannot receive: local origin for clone pool/snap does not exist

이런 오류를 내면서 말이죠.

이유는 생각보다 간단하면서 골때리는데에 있는데,

iocage 의 jail 은 기본적으로 iocage/release/릴리즈 dataset 의 clone 을 뜨는 식으로 생성됩니다. 합리적입니다. 생성 속도도 빠르고 용량도 줄일 수 있으니깐 말입니다.

그런데 여기서 문제가 발생합니다. 제가 스냅샷을 찍은 부분은 System/iocage/jail 이고, 해당 dataset 은 파괴되었습니다. 당연히 clone 도 사라진 상태입니다.

그런 상태에서 recv 명령을 내리면, clone 의 원본이 없는 상태이니, 복구가 불가능하고, 결론적으로 펑!!!! 복구가 안됩니다!!!

짜잔! 백업을 잘못 뜬 것이였습니다!

하지만 전 현명한 관리자(라고 착각) 이니, DB의 백업을 떠놨습니다. DB 가 가장 중요하죠.

… 그런데 암호가 걸려 있습니다. 기억하시나요? openssl 로 암호화했던 거.

그래요. 암호야 풀면 그만이죠. 그런데 암호가 어디있냐고요?

/mnt/Sytem/iocage/jail/mariadb/root/root/.passwd

….

네 DB 비밀번호도 함께 날아갔습니다.

아 나는 병신이야. 병신이라고 구제할 길 없는 병신이야 엉엉.

자… 그런데 여러분 이상한 걸 느꼈을 것입니다. 메인 서버의 DB가 날아갔는데, AWS 에 있는 이 블로그는 왜 터진 거지?

그게 말입니다, AWS 에서 php와 nginx 가 돌긴 합니다만, DB는 메인 서버의 것을 사용합니다. 그래서 DB가 터지면서 다 함께 터져버렸어요.

시발.

결론적으로 저에게 남은 건 잘못 된 스냅샷 파일이고…

전 이걸 가지고 복구를 할려고 난리를 치다가… 복구에 실패하고… 복구 전문 업체에 맡겼습니다만…

잘 안풀렸습니다. 잘 안된다고 하더라구요. 사실 뭐 그럴 수 밖에 없다고 생각은 합니다. 처음 보는 케이스기도 할 거고, 그렇게 돈 되는 케이스도 아니고…

그래서 결국 제가 복구 프로그램을 만들어서 복구를 했습니다.

제 모토가 뭡니까 여러분! 꼬우면 직접 만든다!

심플하게 스냅샷 파일에서 .passwd 파일을 뽑아 내는 프로그램을 만들었죠. 그걸로 암호화된 DB 덤프를 해제하고… 복구를 했습니다.

그래서 이렇게 복구를 했습니다. 이젠 이런 실수 안 하도록 조심해야겠습니다.ㅠㅠ

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다