검색 엔진의 방문이 늘어나고 있군...

Posted
Filed under 프로그램과 명령어/관리와 유지보수
참조 원문 : 20 Linux Tips Worth Trying

  GRUB에 이상이 발생한 경우 복구하는 방법을 소개합니다. 먼저 GRUB 2를 지원하는 라이브CD/DVD(우분투 9.10 이상)로 부팅 후 터미널을 열어 fdisk -l 명령어로 복구할 GRUB 2의 설정 파일이 있는 파티션(과 루트 파일시스템의 파티션)을 확인합니다. 디폴트의 경우 첫 번째 파티션이 /boot 파일시스템, 두 번째 파티션이 루트 파일시스템을 담고 있으므로 여기서는 각각 /dev/sda1과 /dev/sda2로 가정하고 설명하겠습니다. 아래의 절차에 따라 복구를 진행합니다.
$ sudo mkdir /media/sda
$ sudo mkdir /media/sda/boot
$ sudo mount /dev/sda2 /media/sda/
$ sudo mount /dev/sda1 /media/sda/boot
$ sudo mount --bind /dev /media/sda/dev
$ sudo mount --bind /proc /media/sda/proc
  루트 파일시스템을 마운트한 위치에 chroot를 걸어줍니다.
$ sudo chroot /media/sda
  GRUB을 재설치합니다.
# grub-install /dev/sda
Installation finished. No error reported.
  에러가 발생한다면 아래의 명령어를 실행합니다.
# grub-install --recheck /dev/sda
  설치 후 chroot를 종료하고 GRUB을 복구하기 위해 걸었던 마운트를 해제한 뒤에 리붓을 합니다.
# exit
$ sudo umount /media/sda/proc
$ sudo umount /media/sda/dev
$ sudo umount /media/sda/boot
$ sudo umount /media/sda
$ sudo reboot
  이런 번거러운 작업을 해야 하는 이유는 설치할 GRUB의 설정 파일이 필요하기 때문입니다.

2013/08/14 14:23 2013/08/14 14:23
Posted
Filed under 프로그램과 명령어/커맨드 라인 트릭
참조 원문 : Reclaim Deleted Files and Repair Filesystems on Linux

1. e2fsck로 Ext2/3/4 파일시스템 검사
  이미 이전에도 많이 했지만 복습차원에서 또 갑니다. 가장 중요한 것은 e2fsck가 언마운트된 파일시스템만 검사할 수 있다는 겁니다. 검사 대상이 마운트된 상태라면 관리자 계정으로 아래 명령어를 사용하여 런 레벨을 1로 바꿉니다.
init 1
  런 레벨을 1로 바꿨으면 검사할 파일시스템을 언마운트합니다. 참고로 이왕이면 Knoppix나 Puppy Linux 같은 라이브 배포판을 이용해서 부팅 후 검사하는 것이 더 안전하긴 합니다.

  umount 명령어로 언마운트를 한 후 e2fsck 명령어로 검사를 합니다. 아래는 대상이 sdb1 장치라고 가정했을 때의 모습입니다.
umount /dev/sdb1
e2fsck -y /dev/sdb1
  e2fsck의 -y 옵션은 모든 질문에 yes로 대답하는 옵션입니다. 검사가 끝나면 한 번 더 검사를 실시하여 남은 에러가 없는지 확인합니다.


2. 프로세스가 사용 중인 상태에서 삭제한 파일 복구
  파일이 복구가 가능한 이유는 파일이라는 것이 실제로는 디스크에 있는 아이노드에 대한 링크일 뿐이기 때문입니다. 이 아이노드는 파일에 대한 모든 정보를 담고 있습니다. 파일을 지우면 실제로는 아이노드에 대한 링크만 끊어지기 때문에 데이터를 찾을 수 없게 될 뿐입니다. 실제 아이노드 자체는 디스크에 남는다는 것이죠. 단, 그냥 영구적으로 남는 게 아니라 일시적으로 남는 겁니다. 정확히는 어떤 프로세스가 지운 파일을 여전히 열고 있어서 해당 아이노드에 대해 쓰기가 불가능한 동안만 온전히 남게 됩니다. 그러므로 지금 소개하는 방법에는 시간 제한이 있으며 그 시간은 길 수도 있고 짧을 수도 있습니다. 이 복구의 핵심은 /proc 디렉토리입니다. 시스템에 있는 모든 프로세스는 /proc 디렉토리 내에 디렉토리를 하나씩 보유하고 있습니다. 'ls /proc' 명령을 실행해보면 숫자로 된 디렉토리들을 볼 수 있습니다. 이 숫자는 실행 중인 프로그램의 프로세스 ID(PID)들입니다. ps 명령어를 사용하면 원하는 프로그램의 PID를 확인할 수 있습니다.

  /proc 내에서 원하는 프로세스의 디렉토리를 찾았다면 그곳으로부터 데이터를 가져와 복구할 수 있습니다. 이를 시연하기 위해 test_file이라는 파일을 만들어 복구해보겠습니다. 먼저 아래의 명령어로 파일을 만듭니다.
echo "this is my test file" > ~/test_file
  이제 less 명령어로 이 파일을 출력시키고 프로그램이 끝나지 않은 상태에서 파일을 지우겠습니다.
  1. 'less test_file' 명령어로 파일 출력.
  2. 이 상태에서 Ctrl-z를 눌러 프로그램을 일시중단.
  3. 'rm ~/test_file' 명령어로 파일 삭제.
  4. 'lsof | grep test_file' 명령어로 아래와 같은 정보를 검색.
    less 14675 zombie 4r REG 8,1 21 5127399 /home/zombie/test_file (deleted)
  5. 출력 결과 중 PID(2번째 열)와 파일 디스크립터(4번째 열)이다.
  6. 이제 아래와 같은 방법으로 파일을 복구한다.
    cp /proc/14675/fd/4 ~/recovered_file
  위 복구 과정이 끝나면 파일의 내용이 원래 파일과 같은지 실제로 확인해보는 것이 좋습니다.


3. Scalpel을 이용한 복구
  Scalpel이란 툴을 이용하면 특정 확장자를 가진 파일을 지정하여 해당 확장자를 가진 파일을 더 쉽게 복구할 수 있습니다. 먼저 설치가 필요한데 우분투 10.10 데스크탑을 기준으로 터미널에서 아래의 명령어를 통해 설치가 가능합니다.
sudo apt-get install scalpel
  설치 후 /etc/scalpel/scalpel.conf 라는 파일이 생기는데 파일 내용을 보면 확장자들을 볼 수 있습니다. 이 중 복구 대상으로 삼고 싶은 확장자 앞에 있는 주석을 지웁니다. 저장 후 나와서 복구할 파일을 저장할 디렉토리를 하나 만듭니다. 여기에서는 ~/RECOVERED 디렉토리를 해당 디렉토리로 삼겠습니다. 이제 아래와 같이 명령어를 실행합니다.
sudo scalpel /dev/sd1 -o ~/RECOVERED
  작업이 완료될 때까지 상당한 시간이 소요될 겁니다. 작업이 끝나고 디렉토리로 가보면 지정한 각 확장자별로 서브디렉토리가 생기고 그 안에 복구된 파일이 있는 것을 확인할 수 있습니다.


2011/02/01 15:24 2011/02/01 15:24