Linux 장애 해결

1. /etc/fstab 

* /etc/fstab 파일을 수정하면 가능하면 재부팅후, 정상작동하는거 확인하는 것이 좋다.

 

1.1 /etc/fstab 파일의 파일시스템 장치명 문제 #​

* 원인

 - 각 행에 설정된 마운트 설정이 잘못된 것, (장치명 잘못지정되었을 가능성 있음)

 - /dev/sda2 or /dev/sdb1 같은 장치명의 오타, 잘못된 장치명으로 설정되어있을 수 있음

* 조치방법

 - 리눅스 설치 CD / 부팅 DVD 로 다시 부팅, linux-rescue 부팅후, /etc/fstab 파일 부분 수정 및 재부팅 (linux rescue 모드 는 거의 read-only 모드이다, 수정 후 저장이 안될 수 도 있다)

 - linux rescue nomount 로 부팅하여 작업

​

1.2 /etc/fstab 파일의 장치명에 대한 레이블명 오류 #

* 원인

 - /dev/sda1 or /dev/sdb2 등 장치명 대신 LABEL=/ or LABEL=/home 같은 레이블명으로 설정 (레이블 보다 장치명이 직관적이다)

 - 레이블명 : mke2fs , mkfs 등 포맷후, 파일시스템 생성때 지정가능,

* 조치방법

 - tune2fs 사용, 파일시스템의 레이블명 변경 ( tune2fs -L 레이블명 /dev/sda )

​

1.3 root passwd 까먹을 때 #

* 조치방법

 (1) GRUB 이용, 싱글모드 부팅후 root passwd 재설정.

 (2) linux rescue mode or linux rescue nomount 모드로 부팅후 passwd 재설정

1.4 /etc/passwd 파일의 UID , GID 문제 #

* NAS 는 거의 내부망에서 사용 - 해킹걱정 거의 없다. 

* 몇몇 공인IP 쓰는 플러그 디스크는 가능성 있음.

(필요한 포트만 open 해서 사용해서 해킹방지를 함, 그러나 해킹가능성은 존재)

* 원인 및 증상

 1) root 대신 Root 로 설정

 2) root UID 가 0 이 아닌 500 이상 (일반유저로 변경됨)

 3) 다른 일반계정 추가됨

 4) 추가된 일반계정의 UID 가 0 (UID = 0 이면, root와 동일한 권한 획득)

 5) 기존 존재했던 계정의 UID 값이 0 으로 설정

* 조치방법

 - linux rescue or linux rescue nomount 모드로 부팅 /etc/passwd 부분 수정

1.5 파일시스템 손상시 #

* 굉장히 흔하게 발생하는 유형

 - 파일시스템 손상시, 부팅시에 멈춤

 * 원인 - 비정상적인 시스템 종료가 원인일 가능성이 많음 ( File I/O 가 한참 발생하는데, 시스템 off / Mount 에 문제 / Disk block 이 BadBlock 이거나)

* 조치방법

 - 부팅과정에서 멈출 때

 (1) maintenance mode 로 부팅

 (2) 문제있는 파일시스템 대상, e2fsck 를 이용, 파일시스템 오류수정

 (3) 재부팅 

 

1.6 특정파일시스템의 수퍼블록이 깨졌을 때 #

* superblock 이 깨졌다는 것은, 애매한 실력으로 복구하다가 디스크 데이터를 완전히 날리는 실수에서 발생 

* 모든 파일 시스템에는 한개의 수퍼블록, 여러개의 백업수퍼블록이 존재

* 수퍼블록은 File System의 뼈대역할을 하는것으로써, 파일시스템 구조적인 정의를 하고있음.

각 데이터들이 저장될 수 있도록 블록형성, 블록구조 정의, 블록그룹을 정의, 각 블록 크기정의.

​

* 조치방법

 - maintenance mode 부팅, e2fsck 이용 수퍼블록 복구 ( -b 옵션 사용해야 복구 가능 )

 - e2fsck -b : 백업수퍼블록 이용하여 수퍼블록을 복구

1.7 최후방법인 시스템 업그레이드 #

* 시스템이 어디서부터 잘못된건가 파악 안될 때, 혹은 장애난 부분이 한두군데가 아닐대 사용

* OS 에서 원하는 부분만 새로 설치하는 방법

 

1.8 아파치 웹서버가 정상적으로 실행되지 않을 때 #

1.9 MySQL 이 정상적으로 실행되지 않을 때 #

1.10 부트로더 (GRUB) 자체 문제로 부팅되지 않을 경우 #

ROM-BIOS 에서, GRUB 으로 제어권이 넘어오면서, 부팅이 진행됨. 대부분의 부팅과정은 GRUB이 관여.

Kernel 도 GRUB 이 로딩시킴, init 프로세스도 GRUB 에 의해 로딩. => GRUB 부트로더가 부팅시 모든걸 관여함

​

* 조치방법

 (1) 부팅시, GRUB 초기화면에서, GRUB 전용 명령어들을 사용하여, 상태 확인

 (2) /boot/grub/grub.conf 파일은 GRUB의 설정파일들. 이부분 조절

 (3) grub-install 명령어는 수정된 GRUB 를 적용 * 책에 GRUB 편에 잘 설명되어있음 

2. 복구보단 백업 우선

* 복구보다 백업을 우선하라, 甲이다.

* 어설픈 복구실력으로, 복구가능했던 데이터까지 날리기 보다는,

미리 백업하는게 최고이다. 

 

3. 파일시스템의 레이블명 확인과 변경

* 파일시스템 복구에는 이런것을 알아야 한다

 - e2fsck , fdisk, GRUB , 부팅과정이해, tune2fs, dumpe2fs

* tun2fs 의 파일시스템 레이블명 변경법

(1) dumpe2fs 로 레이블명 확인

- dumpe2fs /dev/sda | grep volume

(2) tune2fs -L 로 레이블명 변경

- tune2fs -L /레이블명 /dev/sda

 

4. 레이블명 오류로 인한 장애발생 조치방법 (p 1888) #

* maintenance mode 에서 수정 * 위의 방법대로 레이블명 확인 및 수정

 

5. 파일시스템 깨졌을 때 부팅불능조치 (p 1891) #

* 시스템 부팅시, " Give root password for maintenance" 메세지와 함게 멈출 때 있다.

- root passwd 입력하면, Repair file system 모드로 진입가능 - fsck , e2fsck 이용, 파일시스템 체크 및 복구 가능 

 

6. Rescue installed system 모드로 응급복구 (p 1893) #

fedora 에서 작업하는 화면이 있음.

NAS 에서는 해당 X (GUI 작업) 

 

7. 리눅스 서버 다운시 매직키 이용 응급조치 (p 1905) #

* 서버가 다운됬더라도 , sync 와 umount 는 해야 데이터를 안전하게 보호할 수 있다.

서버가 다운되라도 긴급하게 할 것이 sync , umount 이다 - Sync 작업을 하지 않은 상태라면, RAM 에 있는 데이터가 모두 날라가버림. - umount 작업을 하지 않았을 경우, 마운트 되어있던 파일시스템이 손상될 가능성이 매우 높음

* 방법 : (1) 리눅스 가상콘솔 이용 (Ctrl + Alt + F1F2,)

- 서버가 다운되었을 때는 가상콘솔이 인식될 가능성이 크지 않음.

(2) 리눅스 매직키 (Alt + SysRq + 매직문자) 이용방법.

- 몇가지 매직단축키가 존재함

1) ALT + SysRq + S : Sync 작업 2) ALT + SysRq + E : term SIG 작업 ( 현재 수행중인 작업들 모두 종료) 3) ALT + SysRq + U : umount 작업 4) ALT + SysRq + B : booting 작업 * 설정법 : /etc/sysctl.conf 에서 kernel.sysrq = 1 로 설정. echo 1 > /proc/sys/kernel/sysrq (NAS 에는 1로 설정, Cent 에는 0으로 설정되어있음) 

8 파일시스템 깨졌을 때 복구하는 방법 (p 1907) #

* e2fsck 를 이용하여, 파일시스템 복구법, 그외 여러기능

* 장애상황

- 파일시스템 문제로 부팅 X - File Write 안될 때

* 해결방안

- 파일시스템 점검툴로 정상복구 가능. - 수퍼블록이 깨진 경우, 백업 수퍼블록을 이용하여 복구.

* e2fsck : 리눅스 파일시스템 점검 및 복구하는 명령어 (fsck 의 확장)

* e2fsck 가 점검하는 항목들 1) inode 점검 5) 디렉토리 연결성 점검 2) blocks 점검 6) 파일 링크 정보 3) size 점검 7) 전체파일갯수 점검 4) 디렉토리 구조 점검 8) 전체블록중 사용중인 블록 점검 * e2fsck 사용법

(15장 ,p727 에도 나와있음) 

 

8. e2fsck 개론 #

e2fsck : ext2 ~ ext3 타입의 리눅스 파일시스템에 대한 이상유무 점검 및 이상시 조치까지 취하는 도구

시스템 부팅시 /etc/rc.d/rc.sysinit 스크립트에 의해 자동실행

e2fsck 가 보여주는 종료코드

0 - 정상종료 (에러 없음)

1 - 파일시스템을 복구했음

2 - 파일시스템이 복구되었음 + 시스템 재부팅필요

4 - 작업대상 파일시스템에 문제있음, 복구하지 않고 방치

8 - 실행에러

16 - 사용법 or 문법 에러

32 - e2fsck 작업이 사용자에 의해 취소됨

128 - 공유 라이브러리 (share library) 에러 의미

​

 e2fsck 수행시 점검항목

inode 점검 // block 점검 // sizes 점검 // 디렉토리주고 점검 // 디렉토리 연결성 점검 // 파일링크 점검 전체파일 개수 점검 // 전체 블록수중 사용중인 블록 점검

​

사용법 : e2fsck /dev/sd? (마운트된 시스템 대상 점검시 손상가능성 있음, 기본은 ext2 지원)

옵션	설명	예시
-f	강제적으로 파일시스템 점검	e2fsck -f /dev/sd?
-j	ext3 파일시스템의 점검 및 복구	e2fsck -j ext3 /dev/sd?  = fsck.ext3 /dev/sd?
-v	점검의 상세정보 확인가능	e2fsck -v /dev/sd?
-p	자동복구모드
-y	파일시스템 복구시 y/n 나오는 대답에 오로지 y 로 대답
-n	파일시스템 복구시 y/n 나오는 대답에 오로지 n 로 대답
-c	배드블록점검 먼저 수행후 파일시스템 체크
-b	백업슈퍼블록 이용하여 복구	-b 백업슈퍼블록번호 dumpe2fs /dev/sd? | grep superblock 하면 슈퍼블록 번호 나옴

* 백업슈퍼블록을 이용한 파일시스템 복구

- 메인수퍼블록 : 파일시스템의 매우 중요한 정보들 저장, 손상시 파일시스템 작동 X 

- 백업슈퍼블록 : 메인슈퍼블록의 백업본, 이 블록을 통해 메인슈퍼블록 복구 가능 

- 마운트 되어있는 상태에서는 실행 자제하는 것에 좋다. (원하지 않는 오류 발생가능성 있음)

 

9. 수퍼블록이 깨졌을 때 복구법 (p 1911) #

* 수퍼블록 : 파일시스템의 크기, 파일시스템정보에 대한 내용이 들어있음.

* 리눅스 파일시스템은 블록그룹이라는 것으로 기본구조를 이루고 있음,

몇개의 블록그룹에는 첫번째 수퍼블록이 망가졌을 때를 대비, 백업수퍼블록이라는 것을 가지고있음.

* 백업 수퍼블록 위치 파악 : dumpe2fs /dev/sd?

* 수퍼블록 복구 : e2fsck -b 32768 /dev/sd? // e2fsck -b -p (-y) 4096000 /dev/sd?

* mke2fs 파일시스템을 생성한 후에는 lost+found 라는 디렉토리 생성될 수 있다.

- 파일시스템의 점검작업결과, 연결되지 않은 파일에 대해 정보 저장하고 있는 장소.

(파일명 - 파일의 위치가 정확하게 파악되지 않아 임시보관해 놓은곳) 

 

10. 리눅스 휴지통 (safedelete)을 이용한 삭제파일 복구 (p 1915) #

* rm 명령어를 사용하여 파일 삭제시, 삭제된 파일의 inode 번호만 알고 있으면 복구 가능하다.

* safedelete , unrm, debugfs 툴 이용 복구. (nas 에는 debugfs 만 설치)

* safedelete 설치후, rm alias 로 safedelete 설정. (윈도우의 휴지통 개념 생각하면 이해가 빠름)

* unrm : rm 명령어로, 파일 삭제후, 할당되어 있지 않은 디스크 블록을 하나의 큰 파일로 덤프하여 파일을 복구.

(safedelete 보다 더 물리적인 방법, 복구가능성 ↓ )

* debugfs (p 1925)

- 나와있는 해당 command 들이 동작 X       

출처:http://jgenius.blog.me/220723161071