서버가 비상 모드로 재시작되거나, 파티션이 마운트되지 않거나, 커널에서 ext4 오류가 발생하는 경우, 즉시 서버를 재시작하고 싶은 유혹이 들 수 있습니다. fsck 처음 발견된 장치에서 복구가 진행됩니다. 이는 반드시 피해야 할 상황입니다. 잘못된 볼륨이나 여전히 마운트된 파일 시스템에서 복구를 시도하면 손상이 더욱 악화될 수 있습니다.
fsck 이 프로그램은 파일 시스템에 적합한 도구를 호출하는 런처입니다. 수정 작업을 시작하기 전에 파티션을 식별하고, 유형을 확인하고, 더 이상 사용 중이 아닌지 확인하고, 사용 가능한 백업을 만들어 두어야 합니다. 저는 항상 쓰기 작업이 포함되지 않은 파티션 검사부터 시작합니다. 그 후에야 복구 작업을 진행합니다.
파티션과 해당 파일 시스템을 식별하십시오.
이름에만 의존하지 마세요 /dev/sdb1재부팅하거나 USB 장치를 추가하면 디스크 순서가 변경될 수 있습니다. 파일 시스템 유형, UUID, 모델, 일련 번호 및 마운트 지점을 표시합니다.
lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS,MODEL,SERIAL,TYPE
sudo blkid가이드 Linux에서 lsblk 실행 이 검증에 대한 자세한 내용을 확인하세요. LVM을 사용하는 경우 파일 시스템이 포함된 논리 볼륨을 대상으로 지정하세요. 예를 들어 /dev/mapper/vg_data-lv_archive아래에 위치한 물리적인 LVM 볼륨이 아닙니다. 이 글은 다음 주제에 관한 것입니다. LVM과 그 다양한 계층들 그것들을 구별할 수 있게 해줍니다.
다음으로, 소스가 어떻게 사용되는지 확인하십시오.
findmnt --source /dev/nvme0n1p2
findmnt --target /mnt/data출력 메시지가 나타나면 볼륨이 증가한 것입니다. 출력 메시지가 나타나지 않으면 확실하지 않으니 설명서를 다시 읽어보세요. lsblk 그리고 발견그다음 UUID를 확인하세요. 튜토리얼은 다음과 같습니다. 파일 시스템 UUID 이름이 비슷한 두 악보를 혼동하지 않도록 합니다.
마운트된 파일 시스템을 절대로 복구하지 마십시오.
커널은 메타데이터를 수정할 수 있습니다. fsck 이를 수정해 보십시오. 그러면 파일 시스템에 대한 두 가지 보기가 일치하지 않게 됩니다. 읽기 전용 마운트는 임시방편으로 복구하는 데 충분한 보장이 되지 않습니다. 해당 도구는 설명서에 명시된 조건에 따라 사용해야 합니다.
특정 용량의 데이터에 대해서는 해당 데이터를 사용하는 서비스를 중지하고, 해당 디렉터리 트리에 있는 터미널을 종료한 다음, 해당 디렉터리를 마운트 해제하십시오.
sudo fuser -vm /mnt/data
sudo umount /mnt/data
findmnt --source /dev/nvme0n1p2 상대방이 바쁘니 강제로 연결하지 말라는 응답이 나옵니다. 해당 프로세스를 식별하세요. 또는 그런 다음 해당 서비스를 적절하게 종료하십시오.
루트 파티션의 경우, 해당 파티션이 마운트되지 않은 라이브 미디어 또는 복구 환경을 사용하십시오. 단순히 단일 사용자 모드 또는 비상 모드로 전환하는 것만으로는 루트 파티션이 마운트 해제되었음을 보장할 수 없습니다. 원격 서버에서는 재부팅하기 전에 KVM 콘솔, IPMI 또는 호스팅 제공업체의 비상 액세스 권한이 있는지 확인하십시오.
쓰기 기능이 없는 수표부터 시작하세요.
다음 명령은 어떤 검사기를 보여주는지 보여줍니다. fsck 검사 과정을 거치지 않고 실행됩니다.
sudo fsck -N /dev/nvme0n1p2분해된 ext2, ext3 또는 ext4 시스템에서 강제 검사를 실행하고 제안된 모든 수정 사항에 “아니요”라고 답변하십시오.
sudo e2fsck -f -n /dev/nvme0n1p2
rc=$?
"코드 e2fsck: $rc"에 에코하세요.옵션 읽기 전용 제어 권한을 유지합니다. 옵션 -에프 파일 시스템이 깨끗해 보이더라도 전체 검사가 필요합니다. 대용량 디스크의 경우 이 검사에 상당한 시간이 소요될 수 있습니다. 디스크에서 입출력 오류, 시간 초과 또는 연결 끊김이 보고되는 경우, 먼저 읽을 수 있는 데이터를 백업한 후 하드웨어를 점검하십시오. fsck 이는 물리적으로 고장난 디스크를 복구하는 것이 아니라 논리적 구조를 복구하는 것입니다.
커널 메시지를 통해 이 시나리오를 확인할 수 있습니다.
sudo dmesg -T | grep -Ei 'I/O error|timeout|reset|EXT4-fs|XFS|BTRFS'
sudo journalctl -k -b -p 경고..알림가이드 dmesg 및 커널 오류 이러한 알림을 사건 발생 순서대로 다시 정렬하는 데 도움이 됩니다.
모든 곳에서 “예”라고 답하지 않고 ext4 볼륨을 복구하는 방법
검사 결과 불일치가 보고되면 백업을 확인하고 장치를 다시 확인한 다음 볼륨을 마운트 해제한 상태로 유지하십시오. 그런 다음 대화형 복구를 시작하십시오.
sudo e2fsck -f /dev/nvme0n1p2제출하기 전에 각 질문을 읽으십시오. 피하십시오. -와이
"코드 e2fsck: $rc"에 에코하세요.fsck 종료 코드를 읽으세요.
0이 아닌 오류 코드가 항상 수리 실패를 의미하는 것은 아닙니다. 주요 값은 다음과 같습니다.
공오류가 감지되지 않았습니다.일: 오류가 수정되었습니다.오류가 수정되었습니다. 재시작이 필요합니다.: 수정되지 않은 오류;팔테스터의 조작에 오류가 있었습니다.십육: 사용법 또는 구문 오류;백이십팔공유 라이브러리와 관련된 오류입니다.
이 값들은 비트처럼 작동하며 서로 더할 수 있습니다. 코드 사 읽기/쓰기 볼륨을 모든 것이 고정된 것처럼 늘리지 않아야 한다는 요구 사항입니다. 코드 팔 명령어, 파일 시스템 유형, 설치된 도구 및 표시된 메시지를 확인해 달라는 요청입니다.
XFS와 Btrfs는 자체 도구를 사용합니다.
fsck 모든 파일 시스템에 동일한 방법이 적용되는 것은 아닙니다. XFS의 경우, 마운트 해제된 볼륨을 수정 없이 스캔하는 것부터 시작하십시오.
xfs_repair항상 마운트에서 분리하여 사용하십시오. 사용하지 마십시오. 첫 번째 시도로 로그를 초기화하면 최근 메타데이터가 손실될 수 있습니다.
sudo btrfs check --readonly /dev/nvme0n1p2추가하지 않음 --수리하다 백업 없이, 그리고 관찰된 문제에 맞춰 조정된 절차 없이 Btrfs를 사용하는 것은 위험합니다. Btrfs 문서 자체에서도 경험자의 안내 없이 사용하지 말라고 경고하고 있습니다. 항상 확인하십시오. FSTYPE ~와 함께 lsblk -f 도구를 선택하기 전에.
ext4 복구 후 쓰기 작업이 필요 없는 검사를 실행합니다. 검사 결과가 이상이 없으면 볼륨을 다시 마운트한 다음 유형, 공간 및 새 커널 메시지를 확인합니다.
sudo e2fsck -f -n /dev/nvme0n1p2
sudo mount /mnt/data
findmnt /mnt/데이터
df -hT /mnt/data
sudo journalctl -k -b -p 경고..알림시작 시 제어되는 루트 파티션의 경우 이전 시작 시의 흔적도 확인하십시오.
저널ctl -b -1 | grep -Ei 'fsck|파일 시스템|I/O 오류|EXT4-fs|XFS|BTRFS'
systemctl --실패거기 fsck 맨 페이지 이 문서에서는 런처와 종료 코드를 설명합니다. ext4에 대한 자세한 내용은 다음을 참조하십시오. e2fsck특정 절차는 XFS 그리고 BTRFS