Oracle Cloud 에서 Kernel panic난 인스턴스 복구 삽질기

우선, 이 글은 인스턴스 자체를 살리는 방법이 아닌 내부 웹서버 파일 (/var/www/html) 과 데이터베이스 (MySQL 8.x) 데이터를 건져내는 내용이다. 혹시 Kernel Panic이 발생하는 상황에서 웹서버가 아닌 다른 서비스의 데이터를 복구해야하는 상황이라면, 높은 확률로 이 글은 도움이 되질 못한다.

상황

Oracle Cloud는 평생무료 인스턴스를 지원한다. Single vCPU 및 1GB 메모리, 무려 서울 리전 조건이다.

클라우드 서비스 무료 이용

운영하던 가족 홈페이지를 EC2에서 Oracle Cloud로 옮겨 무료로 호스팅을 이용하던중, 무심코 Ubuntu Pro를 등록한 것이 화근이었다. (https://ubuntu.com/pro 참고) Canonical에서 제공하는 OS managing 서비스로, 제공하는 기능 중 Kernel 관련 기능이 있다. 이 기능이 Oracle 에서 제공하는 Ubuntu 의 Kernel 과 충돌이 나서 instance ssh 접속 및 부팅 자체가 불가능한 상황이 발생했다.

링크를 클릭하면 (놀랍게도) Metric dashboard 등이 아닌 도움말로 이동한다

Oracle에서 제공하는 Trouble shooting 기능을 이용해봐도, 부트로더에 바로 접근하는 등의 hardware 작업은 제공해주지 않는다. 클라우드 서비스라 예상은 했지만, 다른 방법을 찾아야했다.

예? 뭐가 패닉이라구요?

시도한 것들

Boot volume replication 후 신규 인스턴스 생성

Boot volume을 복사하고, 혹시나 시스템 영역과 일반 os 데이터 영역은 구분해서 저장하지 않을까라는 마음에 다른 인스턴스로 부팅해보았지만 결과는 똑같았다. 애초에 Boot volume이 시스템 영역, Block storage 가 데이터 영역을 담당하는데 귀찮음에 Boot volume을 maximum size로 잡고 모든 데이터를 여기에 저장한 탓이다. 만약 Block storage가 별도로 잡혀있고 웹서버 파일들이 여기에 저장되어 있었다면, 시스템 에러와 상관없이 Mount 해서 쉽게 복구할 수 있었을 것이다.

Support channel 에 도움 청하기

Support ticket을 생성하고, (무료 계정은 지원을 받을 수 없다. 울며 겨자먹기로 카드 등록 후 Paid 계정으로 전환했다. 전환하는 것 만으로는 별도 비용이 발생하지 않는 것으로 위안을 삼았다.) 현재 상황을 설명했다. 답변온 엔지니어에 따르면, 커널 롤백이나 fix는 성공할 가능성이 희박하다고 한다. 예상은 했지만 별다른 action item이나 hint를 주지 않아서 도움은 되지 않았다.

Boot volume을 다른 인스턴스의 storage 로 mount 시키기

Boot volume에 대한 암호화를 지정하지 않아서, 혹시 boot volume이 별도 storage로 취급된다면 다른 instance 에 mount 시킴으로써 내부 파일에 접근할 수 있을 것 같았다. MySQL도 data 파일만 있으면 데이터 복구가 가능하다고 한다.

Restoring MySQL database from physical files

우선 기존 instance의 Boot volume을 clone 한다.

그 후 새로운 인스턴스를 하나 생성해준다. 추가적으로 파일 시스템을 맞춰주는 일을 피하기 위해 같은 우분투로 설정했다. 인스턴스 세부로 들어가 Attached block volumes 를 들어간뒤, clone한 boot volume을 mount 한다.

Attach후 찍은 사진이라 디스크가 이미 존재하며, 신규 인스턴스는 없어야한다.

신규 인스턴스로 접속하여 fdisk로 디스크가 뜨는지 확인해준다.

BIOS랑 EFI만 교체해줘도 부팅은 가능하지 않을까 하는 생각

디스크는 뜨니, 리눅스의 특정 경로로 마운트 시켜야한다. fstab 파일 수정으로 디스크를 경로에 연결시켜줬다.

 

How do I add an additional hard drive?

해당 경로로 접근하면 문제가 되는 인스턴스의 파일들을 확인할 수 있다.

이 때 순간 울컥했다. 앞으로는 꼭 백업해둬야지

우선 rclone을 이용해 개인 구글 드라이브에 백업해두고, MySQL 8 데이터도 살려야한다.

MySQL 파일로 데이터 복구

데이터 폴더는 Ubuntu OS 기준 /var/lib/mysql/{테이블 명} 에 위치한다. 혹시 모르니 /var/lib/mysql 자체를 백업해두었다.

곧바로 새로운 인스턴스를 실행하고, `sudo apt install mysql-server` 를 통해 mysql-server를 설치해준다. 이 때 mysql-server는 데이터 파일 호환을 맞추기 위해 버전이 동일해야한다. 실행 직후 데몬을 정지해주자.

새로운 인스턴스에 mysql 설치 후 /var/lib/mysql 을 덮어쓴 모습

복사 후 소유권 또한 mysql:mysql 로 바꿔줘야한다. 나는 편의상 디렉토리 전체를 덮어써주었지만, 필요한 부분은 `ibdata1`과 이미지상 `hyunwoo1010` 으로 되어있는 데이터베이스 파일이다. (innodb 기준)

이 상태에서 다시 데몬을 실행하면, (`sudo service mysql start`) 아래와 같이 데이터베이스가 확인되며 데이터에도 정상 접근이 가능하다. 바로 mysqldump 명령을 통해 복구해주었다.

그리웠다.. hyunwoo1010

`mysqldump -u root -p {database} > dump.sql` 명령으로 덤프한 파일을 가지고 있으면, 데이터베이스 sql은 복구 가능하다.

복구 마무리

다행히 boot volume도 attachable 한 storage 로 제공해줘서 파일을 모두 복구할 수 있었다. 나중에 서포트 티켓으로 온 내용이지만, serial console 연결을 통해 GRUB 메뉴도 접근이 가능하다고 한다. 아마 이걸 좀 더 빨리 알았다면 커널 복구로 좀 더 빠르게 서비스를 복원할 수 있었을 텐데 싶다.