Ubuntu VirtualBox Guest 복구

Virtual Box 4.3.18로 우분투 14.10 게스트 가상 머신을 EFI 모드 + btrfs 파일시스템으로 설치했는데 설치 후 부팅이 안되는 문제가 있었다. 우분투 14.10의 문제인지 버추얼 박스 문제인지는 확실하지 않다. 마침 어제 Virtual Box 4.3.20 update가 떠서 홈페이지 ChangeLog를 봤더니 EFI 수정사항이 있단다. 업그레이드하고 나서 그간 방치했던 우분투 14.10 게스트를 다시 돌려 봤으나 역시 안돌아 간다.

Virtual Box 4.3.20 Upgrade...

그런데, EFI 모드 + btrfs 파일시스템인 우분투 14.04 게스트 가상 머신은 호스트를 우분투 14.10으로 Clean Inastall 하고 나서도 잘 돌아가던 놈이다. Virtual Box Guest를 upgrade하려고 이놈을 부팅했더니 로그인 후 먹통이다. 콘솔 모드로는 로그인이 가능해서 Guest Additions를 설치하려고 했으나 [Device] > [Insert Guest Additions CD Image...] 메뉴를 사용하면 이미 mount 되어 있어서 mount가 안된다고 경고 창만 뜬다. 일단, 콘솔에서 강제로 아래와 같이 설치했다.

$ sudo mount /dev/cdrom /mnt
$ cd /mnt
$ sudo ./VBoxLinuxAdditions.run

$ sudo reboot

Virtual Box Guest에 발생한 문제들

재부팅하고 나니 문제가 더 심각해 져 있었다. EFI System Partition이 마운트가 안돼서 Skip하던지 Manual로 마운트 해 보란다. 놀랍게도 Skip을 하니까 부팅은 된다. 화면 크기 조정도 안되고 투명창 효과도 사라진 걸 보니 Guest Additions가 잘못 설치됐을 거란 생각이 들어 다시 설치하려고 iso 파일을 마운트하려고 했더니 황당한 오류가 발생...

$ sudo mount /dev/cdrom /media/cdrom

mount: unknown filesystem type 'iso9660'

EFI System Partiton을 마운트 하면 아래와 같은 오류 메시지가 나온다.

$ mount -t vfat /dev/sda1 /mnt

mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

$ dmesg | tail

[ 1605.267871] FAT-fs (sda1): IO charset iso8859-1 not found

또 다른 문제도 발생했는데 패키지 관리 시스템까지 망가진 것이다. apt-get install -f 하란다.

$ sudo apt-get install -f

....... 
E: Internal Error, No file name for libc6
W: Could not perform immediate configuration on 'multiarch-support:x86_64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
E: Sub-process /usr/bin/dpkg returned an error code (1)

음... 망가져도 이렇게 우분투가 망가지는 걸 본건 처음이다. 기왕 망가진거 우분투 설치 iso 로 부팅해서 복구해 보기로 했다.

우분투 설치 iso로 우분투 게스트 부팅 후 복구

버추얼 박스 Storage에 우분투 14.04.1 iso 이미지를 CD에 지정하고 재부팅한 후 터미널을 띄워서 Grub을 우선 복구했다. 참고로 /dev/sda2가 우분투가 설치된 btrfs 파일시스템이고, /dev/sda1이 EFI System Partition이다.

$ sudo -i

$ mount -o subvol=@ /dev/sda2 /mnt
$ mount -o subvol=@home /dev/sda2 /mnt/home
$ for i in /sys /proc /run /dev; do mount --bind "$i" "/mnt$i"; done

$ chroot /mnt
$ mount /dev/sda1 /boot/efi
$ grub-install /dev/sda
$ update-grub

그 다음은 패키지 관리 시스템을 복구했다. 먼저, 시스템 전체가 망가진것인지 확인하기 위해서 아래 명령이 정상인지 확인한다.

$ /bin/date

결과가 다행히 정상이다. 즉, 패키지 데이터베이스만 깨진 것이다. 패키지 status backup 파일 중 괜찮아 보이는 놈을 사용하기로 했다.

$ mv /var/backups/dpkg/dpkg.status.2.gz /var/lib/dpkg/
$ cd /var/lib/dpkg
$ mv status org-status
$ gunzip ./dpkg.status.2.gz
$ mv dpkg.status.2 status

$ reboot

여기 까지 하고 나서 재부팅해서 apt-get update 했더니 반응이 없다. 저장소 서버를 교체해 줄 필요가 있어 보였다. 소프트웨어 저장소 서버를 KAIST FTP에서 Main 서버로 교체했다.

$ apt-get update
$ apt-get upgrade

교체 후 위 두 명령이 제대로 동작한다. 소프트웨어 upgrade가 동작하는 것을 보니 패키지 관리 시스템은 복구가 된 것이 분명하다.

문제는 앞서의 mount 오류가 여전히 발생하고 있다는 것이다. 그런데 upgrade 목록에서 새 Kernel이 마침 올라와 있어서 혹시나 하고 Kernel을 Uprade 한 후 재부팅 했더니 mount 문제도 해결됐다.

그리고 나서, Virtual Box Guest Additions도 다시 설치하고 재부팅하니 모든 것이 정상으로 돌아왔다.

복구 소감

어디서 부터 문제가 시작된 것인지는 너무 당황하고도 급하게 복구하느라 정확히 알 수 없지만 Virtual Box Upgrade를 앞으로는 좀더 신중하게 할 필요가 있겠다.

우분투 14.10이 EFI 모드에서 안돌아 가는 문제가 해결됐는지는 Virtual Box 14.10 저장소 버전이 나온 후 다시 시도해 볼 필요가 있겠다. EFI 문제인지 EFI + btrfs 파일시스템 문제인지도 확실하지 않다.

btrfs Snapshot을 이용한 Roll-back

btrfs 파일시스템이 나온지도 꽤 됐지만 올해 처음으로 VirtualBox에 우분투 설치하면서 btrfs 를 기본 파일시스템으로 설정해서 설치해 보았다. 몇 달 써 봤는데 역시 가장 실용적인 장점은 Snapshot 기능이었다. Snapshot을 만들어 두었다가 불안정한 Software를 설치 후 문제가 생겨서 roll-back 할 때 실제로 매우 유용하게 써먹고 있다. btrfs 파일시스템은 지금도 리눅스 kernel 단에서 활발히 개선되고 있다.

btrfs 파일시스템 사용에 대한 고려 사항

Snapshot 기능 외에 나중에 몇가지 테스트 해 보고 싶은 것은 Subvolume 압축과 Sanpshot을 다른 Machine으로 ssh를 이용해 send/receive 하는 기능이다. 이외에도 서버 사용자라면 btrfs 파일시스템이 LVM을 대체할 수 있고 RAID 구성도 가능하며, Subvolume quota 기능도 유용할 수 있다.

btrfs 파일시스템이 장점만 있는 것은 아니다. 일단, Meta 정보를 따로 관리해야 하기 때문에 디스크 용량이 실제 데이터 용량보다 더 많이 소모될 수 있다. 실제로 Snapshot을 과도하게 사용하다보면 Meta Data 량이 과도하게 증가한다. 또한, 파일시스템 특성 상 디스크 사용량을 실시간으로 정확히 파악하기 어렵다. 서버 사용자라면 Disk full이 언제 발생할지 예측하기 어렵다. 기존의 df나 du와 같은 디스크 용량 정보는 거의 의미가 없다. 가능한 디스크 용량을 정확히 계산하기 위한 Tool을 만들려고 노력은 하고 있단다. 또한, 디스크 성능 이슈도 발생할 수 있다. 성능이 개선되고는 있지만 ext4 파일시스템에 비해 빠르지는 않은 듯하다. 이외에도 파일시스템 안정성은 이미 크게 개선이 된듯하다.

btrfs Subvolume

btrfs 파일시스템에서는 Subvolume 단위로 파일시스템을 관리할 수 있는데 Snapshot도 일종의 Subvolume이다. 또한, Subvolume은 폴더와 비슷하게 관리할 수 있는 장점이 있다. Subvolume 내에 또 다른 Subvolume을 생성할 수 있는 구조이다. Subvolume에 대해 mv나 rm도 가능하지만 rm을 직접 사용하는 것은 권장하지 않는다. Subvolume 간의 작업은 독립적이다. 즉, Subvolume 내에 하위 Subvolume이 있어도 상위 Subvolume의 Snapshot은 하위 Subvolume을 포함하지 않는다. 

우분투에서 설치시에 파일시스템을 btrfs로 선택해서 설치하면 @와 @home 두 개의 Subvolume을 자동으로 만들어 준다. @는 /(root) 파티션에 해당하고 @home은 /home 파티션에 해당한다. 즉, OS와 사용자 데이터를 Subvolume으로 나누어서 관리하도록 해준다. 그리고, 예전에는 Grub이 btrfs 파일시스템을 지원하지 않아서 /boot 파티션을 ext4 등으로 따로 만들어야 했던 문제는지금은 해결이 됐다. 참고로, Subvolume명 앞에 @를 사용할 필요는 없지만 @를 앞에 붙이는 것이 관리상 편리하다.

btrfs-tools

모든 btrfs 파일시스템 관리는 btrfs 명령으로 이루어지는데 우분투에서는 btrfs-tools 패키지에 들어 있다. 설치 시에 btrfs 파일시스템으로 지정하면 기본으로 btrfs-tools가 설치되지만, ext4 등의 다른 파일시스템으로 지정한 경우에는 별개로 설치해 주어야 한다. 참고로, ext2~4 파일시스템은 btrfs-tools를 이용해 btrfs 파일시스템으로 전환할 수 있고, 이렇게 변환된 btrfs 파일시스템을 다시 ext2~4 파일시스템으로 재변환 할 수도 있다. 다만, 원래부터 btrfs 파일시스템으로 우분투를 설치했다면 ext2~4 파일시스템으로의 전환은 불가능하다.

btrfs Subvolume Snapshot 만들기

우분투 처음 설치했을 때의 btrfs Subvolume은 아래와 같이 확인할 수 있다.

$ sudo btrfs subvolume list /

ID 258 gen 2987 top level 5 path @home
ID 286 gen 2988 top level 5 path @

우분투 OS 부분만 Backup 해 두기 위해 아래와 같이 @에 대해 @backup 이라는 Snapshot Subvolume을 아래와 같이 만든다.

$ sudo btrfs subvolume snapshot @ @backup

Snapshot을 이용한 Roll-back

이제 불안정한 Software를 설치했는데 문제가 생겨서 원래 우분투 OS 설치 상태로 돌아가고 싶으면 앞서 만든 스냅샷을 이용해서 아래와 같이 복원할 수 있다.

먼저, 파티션이 여러 개라면 / 폴더가 위치한 파티션을 알아 둘 필요가 있다. 아래에서 /dev/sda2임을 알 수 있다.

$ df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        19G   12G  5.5G  69% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            991M   12K  991M   1% /dev
tmpfs           201M  888K  200M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none           1001M  152K 1001M   1% /run/shm
none            100M   52K  100M   1% /run/user
/dev/sda2        19G   12G  5.5G  69% /home
/dev/sda1       197M  8.2M  189M   5% /boot/efi

아래와 같이 /dev/sda2를 마운트해서 roll-back 작업을 수행한다.

$ sudo mount /dev/sda2 /mnt
$ cd /mnt && ls -l

drwxr-xr-x 1 root root 226  9월 24 21:12 @/
drwxr-xr-x 1 root root 204  6월 13 01:32 @backup/
drwxr-xr-x 1 root root  12  6월 26 18:04 @home/
drwxr-xr-x 1 root root  58  6월 13 01:25 ubiquity-apt-clone/
drwxr-xr-x 1 root root   6  6월 13 01:25 var/

문제가 있는 @를 @problem이라는 Subvolume으로 옮기고 나서,

$ sudo mv @ @problem

@backup 스냅샷에 대한 스냅샷으로 다시 @를 만들어 roll-back 함으로써 @backup 스냅샷을 계속 보존할 수 있다.

$ sudo btrfs subvolume snapshot @backup @

이제 원복한 파일시스템을 사용하기 위해서 재부팅이 필요하다.

$ sudo reboot

재부팅 후, 모든 것이 정상임을 확인한 후에 문제가 됐던 @problem Subvolume을 삭제하려면,

$ sudo btrfs subvolume delete @problem

btrfs 명령어 축약

btrfs 명령이 너무 길기 때문에 사용하기 불편한데 아래와 같이 명령어를 단축할 수 있다.

subvloume = sub, snapshot = snap, filesystem = file, delete = del

예를 들어, 위에서 @backup Snapshot을 만들 때의 명령은 아래와 같이 해도 동일하다.

$ sudo btrfs sub snap @ @backup

사실은, 하위 명령어가 중복되지 않는 범위에서 하위 명령어들을 최대한 축약해도 된다. 즉, 위의 명령은 아래와 같이 해도 된다.

$ sudo btrfs su sn @ @backup

기타 btrfs 명령어

$ sudo btrfs filesystem show

Label: LRoot  uuid: 7f51f770-fe96-4f1f-860d-95215173b0f2
    Total devices 1 FS bytes used 11.00GiB
    devid    1 size 18.80GiB used 17.04GiB path /dev/sda2

Btrfs v3.12

$ sudo btrfs filesystem df /

Data, single: total=14.01GiB, used=10.33GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=1.50GiB, used=691.88MiB
Metadata, single: total=8.00MiB, used=0.00

$ sudo btrfs filesystem defragment /


참고 사이트

https://btrfs.wiki.kernel.org