다양한 내부 SATA 드라이브를 사용하여 Ubuntu 18.04를 설치했는데 몇 달 동안 원활하게 실행되었고 모두가 행복했습니다. 그러던 어느 날, 단순 정전이 발생했습니다. 문제 없습니다. 우리는 전에 이런 일을 겪었습니다. 전원이 다시 켜진 후 서버가 SSH에 응답하지 않았습니다. 때로는 지하실로 가서 상자에 있는 버튼을 눌러 다시 켜야 했습니다. 이렇게 했는데 몇 분이 지나도 여전히 SSH를 통해 액세스할 수 없습니다.
이제 저는 상자에 연결된 작은 모니터와 키보드를 가지고 지하실에 있습니다. 재부팅 후 오랫동안 Ubuntu 로고가 표시되어 키를 누르고 ⬆부트로더를 보니 시간이 초과된 것 같습니다. 시간은 이렇습니다.
A start job is running for dev-disk-by\x2duuid-914d3b77\x2d06c4\x2d4514\x2d8fee\x2d1fc6eb81bbd9.device (51s / 1min 30s)
실제로 초반에 2개의 오류가 있었는데 둘 다 1분 30초가 지나면 타임아웃이 되는 것 같습니다. 또 다른 시간 초과 된 부팅 작업이 UUID=a158e6ec-1433-454c-9cd2-10f7306fde82./etc/fstab
1시 30분 후에 Enter 키를 눌러 루트 명령 프롬프트로 들어가서 실행 vim /etc/fstab하고 2개의 오류에 해당하는 줄을 주석 처리했으므로 이제 파일은 다음과 같습니다.
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=6f90b496-401e-475f-add0-3c6d3bcae7a0 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=BFE0-55D4 /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
UUID=bc731122-7e4e-47d9-b6a5-db1f703f96a8 /media/Tre ext4 defaults 0 0
UUID=6c7b175d-b80b-4069-bbbe-f82aeb302200 /media/Sam ext4 defaults 0 0
#UUID=a158e6ec-1433-454c-9cd2-10f7306fde82 /media/Hex ext4 defaults 0 0
#UUID=914d3b77-06c4-4514-8fee-1fc6eb81bbd9 /media/Wes ext4 defaults 0 0
파일을 저장한 후 rebootUbuntu를 실행했는데 빠르게 재부팅되었습니다. 나타나지 않고 로그인 화면으로 이동합니다. 나는 어두운 지하실 서버 벽장에서 기어나와 소파에서 SSH를 통해 다시 들어왔습니다.
blkid나는 Wes라고 불리는 드라이브의 UUID가 내가 가지고 있던 UUID와 다른 것 같다는 것을 사용 하고 발견했습니다 /etc/fstab. 그래서 백업을 만들고 UUID를 해당 줄의 UUID로 편집하고 blkid해당 줄의 주석 처리를 제거했습니다. 또 하나 reboot, 이제 Wes가 돌아왔습니다. 이제 저는 Hex라고 부르는 대형 6TB 드라이브가 없어졌습니다. 제 /etc/fstab모습은 다음과 같습니다.
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=6f90b496-401e-475f-add0-3c6d3bcae7a0 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=BFE0-55D4 /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
UUID=bc731122-7e4e-47d9-b6a5-db1f703f96a8 /media/Tre ext4 defaults 0 0
UUID=6c7b175d-b80b-4069-bbbe-f82aeb302200 /media/Sam ext4 defaults 0 0
#UUID=a158e6ec-1433-454c-9cd2-10f7306fde82 /media/Hex ext4 defaults 0 0
UUID=bc731122-7e4e-47d9-b6a5-db1f703f96a8 /media/Wes ext4 defaults 0 0
Hex 줄의 주석 처리를 제거하면 동일한 작업이 1시 30분에 시간 초과되기를 기다리는 무한 루프에 빠지게 됩니다. 로그를 보고 journalctl -xe문제가 있다고 생각되는 곳으로 이동하면 다음과 같은 빨간색 오류가 표시됩니다.
zen systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-a158e6ec\x2d1433\x2d454c\x2d9cd2\x2d10f7306fde82.device
이는 동일한 16진수 드라이브에 해당하는 것으로 보입니다.
드라이브가 손상될까봐 걱정되어 옷장에서 상자를 꺼내서 열고 특정 하드 드라이브를 제거했습니다. 나는 그것을 책상으로 가져가서 SATA-USB 포트에 연결하고 전원을 공급했습니다. 드라이브가 회전하기 시작했고 이를 Mac 노트북에 연결했습니다. 디스크 유틸리티를 열면 하드 드라이브가 보이지만 용량이 1.8TB에 불과하고 파티션도 볼 수 없습니다.
6TB 드라이브를 포맷하기 위해 특별한 조치를 취해야 했던 기억이 있는 것 같아서 이 부분이 맞을 수도 있을 것 같은데, 혹시 맥이 못 볼 수도 있지 않을까요? 어쨌든 저는 드라이브를 보고 영감을 받아 다시 서버에 넣기로 결정했습니다.
더 많이 읽고 더 많이 검색했는데 이 사이클에 갇히게 되었습니다. 항목을 주석 처리 /etc/fstab하고 시스템에 SSH를 적용하거나 주석 처리를 해제하고 중단을 다시 시작할 수 있습니다. 들어가면 최상위 폴더와 파일이 몇개 보이긴 하는데 cd,/media/Hex넓은대부분의 파일 구조가 사라지거나 보이지 않는 것 같습니다.
Hex를 정상으로 되돌리는 방법은 무엇입니까?
답변1
defaults옵션을 noauto,x-systemd.automount다음으로 바꾸십시오 /etc/fstab.
UUID=a158e6ec-1433-454c-9cd2-10f7306fde82 /media/Hex ext4 noauto,x-systemd.automount 0 0
Archlinux 위키에서:systemd를 사용하여 자동 마운트
파티션이 더 큰 경우, fsck가 확인할 때 이에 의존하지 않는 서비스가 시작되도록 허용하는 것이 더 효율적일 수 있습니다. 이는 파티션의 /etc/fstab 항목에 다음 옵션을 추가하여 수행할 수 있습니다.
noauto,x-systemd.automount이는 처음 액세스할 때 파티션을 fsck하고 마운트하며, 커널은 준비될 때까지 모든 파일 액세스를 버퍼링합니다. 예를 들어 /home 파티션이 매우 큰 경우 이 방법이 적합할 수 있습니다.
답변2
최상의 시나리오: 시스템이 단순히 파일 시스템에 대해 로그 복구 및/또는 파일 시스템 검사를 실행하려고 시도하는데 Hex, 파일 시스템이 너무 크기 때문에 1분 30초 이상 소요됩니다. 이 경우 시스템의 나머지 부분이 부팅된 후 파일 시스템 검사를 수동으로 실행하는 것이 가장 좋습니다. 아래 지침을 참조하십시오.
최악의 시나리오: 하드웨어 수준에서 디스크 오류가 발생할 수 있습니다.
주석 처리된 줄이 있는 일부 파일과 폴더가 /media/Hex표시되고 /etc/fstab수동으로 마운트하지 않은 경우 일부 프로그램이 마운트 지점으로 간주되는 빈 디렉토리에 기록되었을 수 Hex있으며 실제 Hex파일 시스템이 제거되었습니다. 이는 실제 파일 시스템의 파일 상태와는 아무런 관련이 없지만 파일 시스템의 현재 문제가 해결되면 Hex실제 파일 시스템으로 다시 병합하는 것은 약간 어려울 수 있습니다 .Hex
지금은 해당 행을 주석 처리하세요 /etc/fstab. Hex시스템이 가동되어 Hex시스템에 연결 되면 blkid이전과 같이 명령을 사용하여 Hex현재 장치 이름을 식별합니다. 이를 알고 나면 추가 진단을 시작할 수 있습니다.
파일 시스템을 포함하는 장치 (여기서Hex의 이름이 파일 시스템은 전체 디스크 장치에 직접 존재하는 것으로 보고됩니다 .)/dev/sdX1/dev/sdXblkid/dev/sdX
좋은 첫 번째 단계는 실행하는 것입니다 sudo smartctl -H -a -f brief -l error /dev/sdX. 즉, 디스크의 전반적인 상태, SMART 속성 및 디스크 자체에 의해 기록되었을 수 있는 하드웨어 수준 오류를 보고해야 합니다. 하드웨어 수준에서 디스크가 정상임을 나타내면 계속 진행할 수 있습니다. (결과를 해석하는 방법을 잘 모르는 경우 원래 질문을 편집하고 결과를 추가하세요.)
디스크에 하드웨어 오류가 표시되면 결정을 내려야 합니다. 오류가 발생한 디스크에 중요한 데이터가 포함되어 있으면 직접 수리하려는 시도를 중단하고 디스크를 데이터 복구 전문가에게 보내는 것이 가장 좋습니다. 전문적인 복구에는 약간의 비용이 들 수 있지만 데이터를 성공적으로 복구할 가능성은 가장 높습니다. 이 작업을 수행하기로 선택한 경우 디스크에 추가 작업을 직접 수행하지 마십시오. 디스크에 물리적으로 오류가 발생한 경우 디스크 전원을 켜두면 문제가 더 악화되고 복구가 더 어려워질 수 있습니다.
하드웨어 수준에서 디스크에 아무런 문제가 없거나 디스크에 있는 데이터가 "전문적인 복구 비용을 들일 가치는 없지만 갖고 있으면 좋을 것"인 경우 다음 단계는 파티션에 무슨 일이 일어나고 있는지 이해하는 것입니다. 6TB 디스크라고 하셨으니 아마도 GPT 파티셔닝을 사용하고 있을 겁니다. 다음 명령 중 하나가 파티션 레이아웃을 표시해야 합니다.
sudo parted /dev/sdX print
sudo gdisk -l /dev/sdX
sudo fdisk -l /dev/sdX
(나는 Ubuntu 18.04가 GPT 파티션을 이해할 만큼 충분히 새롭다고 생각 fdisk하지만, 다른 명령이 전체 6TB를 표시하는 동안 1.8TB 파티션과 같은 것을 보고한다면 그것은 아마도 실제 문제가 아닐 것입니다.)
이 파티션 정보를 추가하려면 원래 질문을 편집하십시오. 다음 단계는 이러한 검사 결과에 따라 달라집니다.
ddrescue디스크에 SMART 오류 표시가 있는 경우 다음 단계는 동일하거나 더 큰 크기의 새 디스크를 구입하고 비슷한 도구를 사용하여 가능한 한 빨리 전체 내용을 새 디스크에 복사하는 것입니다 . 이 작업이 완료되면 데이터가 더 이상 악화되지 않습니다.
디스크의 SMART 진단이 정상이고 파일 시스템이 인식되면 만일을 대비하여 계속하기 전에 디스크를 새 디스크에 복제하는 것이 좋습니다. 그런 다음 파일 시스템에 다음과 같은 내용이 포함되어 있다고 보고하는 장치에서 파일 시스템 검사를 실행할 수 있습니다 sudo fsck.ext4 -f -C0 /dev/sdX1. 대용량 디스크에서는 이 작업에 꽤 시간이 걸릴 수 있습니다. 이 -C0옵션은 파일 시스템 검사기가 실행 중 완료율을 제공하도록 지시합니다.
파일 시스템 검사가 성공하면 다음 단계는 수동으로 마운트를 시도하는 것입니다. 예를 들어 파일이 사용 중이라고 sudo mount /dev/sdX1 /media/Hex표시되면 설치를 수행할 때 해당 마운트 지점을 사용하고 있을 수 있는 모든 서비스를 중지해야 합니다./media/Hex/media/Hex
설치 후 정상적으로 보이면 /media/Hex안도의 한숨을 쉬고 수동으로 제거하고( sudo umount /media/Hex) 해당 행의 주석 처리를 /etc/fstab해제한 후 시스템을 재부팅할 수 있습니다. 이제 파일 시스템이 검사되고 완전히 마운트 해제되었으므로 정상적으로 다시 부팅되어야 합니다.
실제 파일 시스템(현재는 실제 파일 시스템 "아래"에 숨겨져 있음)을 마운트한 후 마운트 지점 디렉터리에 남아 있는 모든 파일을 정리하려면 Hex다음을 수행할 수 있습니다.Hex
sudo mkdir /mnt/Hex_oops
sudo mount --bind / /mnt/Hex_oops
cd /mnt/Hex_oops/media/Hex
...그런 다음 그 안에 있는 파일과 디렉터리가 /mnt/Hex_oops/media/Hex중요한지 확인하세요. 그렇다면 이제 Hex실제 파일 시스템의 올바른 위치로 이동할 수 있습니다. 일부 응용 프로그램에서 자동으로 생성된 빈 디렉터리인 경우 삭제할 수 있습니다(루트 파일 시스템에서 쓸데없이 공간을 차지하므로). 그런 다음 이 임시 배열을 삭제하세요.
cd /
sudo umount /mnt/Hex_oops
sudo rmdir /mnt/Hex_oops