만약 데이터 백업을 이미 가지고 있다면, 분할 영역을 다시 만들 수 있도록 분할 영역 정보를 보존하는 것도 필요하다.
스크립트 make.fdisk는 하드 드라이브의 분할 영역의 정보를 조사하고 그것을 두 개의 파일에 저장한다. 하나는 실행 가능한 스크립트이고 make.dev.x로 불리운다. 다른 것은 fdisk로 분할 영역을 만드는데 필요한 명령어들이 들어 있고 dev.x로 불리운다.(여기서 x는 장치 파일의 이름이다. 예, hda). 여러분은make.fdisk에 연관된 장치 파일을 인수로 전달하게 함으로써, 어느 드라이브에서 작동하는 스크립트를 만들고 있는지를 명확하게 표시해야 한다. 예를 들어, 보통의 IDE 시스템에서는,
bash# make.fdisk /dev/hda |
라고 입력하면, 스크립트 make.dev.hda와 fdisk를 위한 입력 파일, dev.hda가 만들어 진다.
덧붙여, 만약 make.fdisk가 FAT32나 혹은 FAT를 만나게 되면 그 분할영역의 부트 섹터를 dev.xy라고 이름 붙여진 파일에 보관한다. 여기서 x 는 드라이브의 장치 이름(예, sdc, hda)이고 y는 분할 영역의 번호이다. 부트 섹터는 분할 영역의 첫 번째 섹터, 512 바이트이다. 이 섹터는 make.dev.hda 스크립트에 의해서 파티션이 다시 만들어 질 때 동시에 복구 된다.
다행히도, 선거 이후에 정치인에 대한 대중의 신뢰도가 떨어지는 만큼이나 빠른 속도로 하드 드라이브의 가격이 수직 하락하고 있다. 그래서, 출력 파일이 텍스트이고 일일이 편집 가능하다는 것은 좋은 일이라고 할 수 있다. 지금 당장에는, 더 큰 대체 드라이브에 다시 복구를 하는 유일한 방법이다. (해야할 일들 목록을 보라.)
다른 메타데이터들은 save.metadata 스크립트에의해 보존된다. 그 스크립트는 ZIP 드라이브의 루트에 있는 fdisk.hda 파일 내에 분할 영역의 정보를 저장한다. 이 파일과 여러분의 /etc/fstab을 출력하는 것은 훌륭한 생각이며, 그 출력물을 이용해서 여러분은 분할영역 데이터를 여러분의 손으로 복구할 수 있을 것이다. 여러분은 두 개의 가상 콘솔을 토글하면서 하나는 fdisk를 실행시키고, 다른 하나에서는 /etc/fstab이나 /fdisk.hda를 출력하면서 위치 정보를 저장할 수 있을 것이다. 그러나, 그렇게 하는 것은 오류가 발생하기 쉽다.
여러분은 또한 복구 방법에 관련된 파일을 보존하기를 원할 것이다. 예를 들어, 데이터를 저장하기 위해서 nfs를 사용한다면, 여러분은 hosts.allow, hosts.deny, exports 등등의 파일도 보존할 필요가 있을 것이다. 또한, 여러분이 어떤 네트워크를 이용한 백업 시스템, Amanda나 Quick Restore을 사용한다면, 여러분은 HOSTNAME, hosts같은 네트워크 파일과 소프트웨어 위치 정보에 관련된 파일을 보존할 필요가 있게 될 것이다.
이것들 혹은 이와 비슷한 것들을 다루는 가장 간단한 방법은 etc 디렉토리 전체를 보존하는 것이다.
100MB ZIP 드라이브로는 요즘의 서버 설치용 리눅스 배포판을 담기는 힘들다. 그래서, 단순히 전체를 보존하기 보다는 좀더 선택적으로 골라야만 한다. 우리가 필요한 것은 무슨 파일인가?
부트 디렉토리.
/etc 디렉토리와 하부 디렉토리들.
부트시에 필요한 디렉토리들
/dev에 있는 장치 파일들.
부트시에 필요한 파일을 결정하기 위해서는, 부트 초기화 파일 /etc/rc.sysinit를 보면 된다. 거기에는 경로를 다음과 같이 설정하고 있다.
PATH=/bin:/sbin:/usr/bin:/usr/sbin export PATH |
시행착오를 거치면 /dev와 같은 다른 디렉토리를 필요로 한다는 것을 알 수 있다. 리눅스에서는 장치 파일 없이 아무 것도 할 수 없다.
save.metadata스크립트를 읽을 때, 절대 경로로 파일을 저장할 필요는 없다는 것을 알아두길 바란다.
제대로 작동하는 백업 스크립트를 얻기 위해서, 우리는 백업, bare metal restore시험, CD로부터 재설치 그리고 다시 시도하는 일련의 과정을 반복적으로 해야할 수도 있다. 내가 이 HOWTO에 대해 작업하는 동안, 나는 위와 같은 과정을 다섯 번 반복한 후 성공적으로 복구할 수 있었다. 이것이 비록 사용 가능할 때일지라도 왜 스크립트 사용에 주의해야 하는가에 대한 한가지 이유이다. 충분히 시험해보라.
이 백업 과정은 여러분이 백업할 때 만 ZIP 디스크를 필요로 한다. 만약 충분히 하드 드라이브가 넉넉하다면, 여러분은 ZIP 디스크의 내용물을 디렉토리에 만들거나, 네트워크로 저장할 수 있다. 그후, 복구를 할 때 저장된 파일로 부터 ZIP 디스크를 만들면 된다.(cp -rp를 사용)
백업 과정이 더 빨라질 것이지만, 만든 파일이 ZIP 디스크에 적절히 들어가는지 점검해야 한다(du -hs $target.zip를 사용). 여러분은 save.metadata에 있는 변수 zip의 정의를 수정해야만 할 것이다.
내 랩탑은 네트워크 카드와 ZIP 드라이브를 동시에 실행시킬 수 없었기 때문에, 이 방법을 사용해서 백업을 한다.
또는, 하드 드라이브에 여러개의 ZIP 디스크를 만든 후에 복구 대상의 시스템으로 공급하는 방법이 있다.
2개의 1단계 스크립트,restore.metadata와save.metadata를 분리함으로써, 여러분은 1단계 metadata를 여러개의 ZIP 디스크에 나누어 둘 수 있다.
1단계 저장 자료로 부터 몇 메가바이트가 안 되는 자료를 뽑아낼 필요가 있을 때, 특히 ZIP 디스크의 용량 제한에 맞춰야 할 때가 있다. save.metadata 스크립트에 있는 crunch의 역할은 tar에 여러개의 인수를 주는 것이다. --exclude 매개변수 또한 줄 수 있다. 그래서, 예를 들면 아래와 같이 해서 emacs와 gs를 추출할 수 있다.
crunch etc etc --exclude etc/samba --exclude X11 |
왜 그들 둘을 뽑아내는가? 왜냐하면, 그들이 하드 드라이브 공간만 많이 차지하고 부트 시에는 필요가 없기 때문이다.
어떻게 추출해 낼 후보를 잘 골라낼 수 있을까? 각 파일에 대해서는 ls -alSr를 이용하고, 디렉토리에 대해서는 du | sort -n로 나열해서 살핀다.
만약 여러분의 시스템이 부트하기 위해 RAM 디스크나 initrd를 사용한다면, save.metadata가 /initrd 디렉토리를 만드는지 확인해라.
SCSI 드라이브로부터 부트한다면, 여러분의 시스템은 initrd를 사용하거나, 혹은 ext3fs 분할영역에 root를 가질 것이다. 호출하는 것을 알기 위해서는 /etc/lilo.conf를 점검하라.