오늘 아침에 저는 개발 드라이브(하드 드라이브의 4개 기본 파티션 중 하나)를 정기적으로 백업하고 있었습니다. 내가 실행하는 스크립트는 다음과 같습니다.
filename="/home/Backups/Devi_"`eval date +%Y%m%d`".tgz"
touch $filename
tar cvzf $filename /media/Devi/
잠시 후 특정 파일을 찾을 수 없다는 tar 출력이 표시되기 시작했고 명령이 종료될 때까지 동일한 메시지가 점점 더 나타나기 시작했습니다. 확인해 보니 드라이브에 있는 모든 항목, 숨겨진 파일 등이 사라졌습니다. 관련될 수 있는 한 가지 사실은 실행 파일과 라이브러리가 드라이브에 있는 두 개의 qt 프로그램을 실행한다는 것입니다. 하지만 tar 명령이 사용 중인 파일 때문에 어떻게 그러한 삭제를 유발할 수 있는지 알 수는 없습니다. 디렉토리를 복원하기 위해 testdisk를 실행해 보았지만 최상위 파일/디렉토리만 찾고 그 아래에는 아무것도 찾지 못하는 것 같습니다. 이제 Photorec을 실행하고 파일을 찾고 있으므로 파일을 덮어쓰지 않았지만 파일 시스템이 확실히 손상되었습니다(fsk.ext4를 시도하여 드라이브에 있는 것보다 훨씬 적은 수의 파일이 포함된 깨끗한 파일을 얻었습니다).
해당 기간에 대한 내 시스템 로그(11:02에 삭제가 발생한 것으로 생각됩니다)는 다음과 같습니다.
Jul 26 10:17:01 GlaDux CRON[7004]: (root) CMD ( cd / && run-parts --report/etc/cron.hourly)
Jul 26 10:17:05 GlaDux kernel: [ 5835.406184] GLViewer[7032]: segfault at 0 ip 00007eff18138ee6 sp 00007fff24187158 error 4 in libc2.17.so[7eff17fe8000+1be000]
Jul 26 10:17:16 GlaDux kernel: [ 5846.856210] GLViewer[7059]: segfault at 0 ip 00007f470b838ee6 sp 00007fff999ec928 error 4 in libc-2.17.so[7f470b6e8000+1be000]
Jul 26 10:43:41 GlaDux NetworkManager[1141]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Jul 26 10:57:04 GlaDux dbus[1060]: [system] Activating service name='org.freedesktop.UDisks' (using servicehelper)
Jul 26 10:57:04 GlaDux dbus[1060]: [system] Successfully activated service 'org.freedesktop.UDisks'
Jul 26 11:12:25 GlaDux dbus[1060]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper)
Jul 26 11:12:25 GlaDux dbus[1060]: [system] Successfully activated service 'org.freedesktop.hostname1'
Jul 26 11:13:41 GlaDux NetworkManager[1141]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Jul 26 11:15:41 GlaDux NetworkManager[1141]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Jul 26 11:17:01 GlaDux CRON[8999]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
확인해 보니 cron.hourly에 예정된 작업이 없습니다. 그러나 내 생각에는 udisk가 그것과 관련이 있을 수 있다고 생각합니다. 또한 라이브 페도라 부츠에서 모든 작업을 시도했지만 아무런 차이가 없습니다. 또한 다른 슈퍼블록으로 설치를 시도했지만 성공하지 못했습니다.
그래서 두 가지 질문이 있습니다.
아직 언급하지 않은 방법을 사용하여 디렉토리 구조를 복원하는 방법이 있습니까? 백업이 있으므로 단일 파일 복원이 약간 과도한 것 같습니다. 트리의 나머지 부분도 가져올 수 있기를 바랍니다.
더 중요한 것은 간단한 tar 명령이 드라이브의 모든 내용을 정확히 어떻게 삭제합니까? 이것은 나를 완전히 당혹스럽게 만들고, 지금까지 운영 체제에서 겪었던 버그 중 최악이며, Linux 배포판에 대한 이전 경험에 어긋납니다. 가능한 모든 설명을 부탁드립니다.
저는 x64 시스템에서 3.8.0-23-generic과 cinnamint를 실행하고 있습니다. 문제의 파티션은 블록 크기가 4k인 52Gb 기본 ext4(디스크의 파티션 4개 중 1개, 중요한 경우 마지막 파티션)입니다.
편집하다:tar의 출력은 다음과 유사합니다.
/media/me/Devi/dir1/file1
/media/me/Devi/dir1/file2/
......
/media/me/Devi/dir100/file1
cannot find file or folder /media/me/Devi/dir101
cannot find file or folder /media/me/Devi/dir102
cannot find file or folder /media/me/Devi/dir102
또한 제거하기 한 시간 정도 전에 디스크가 마운트되었고 다음이 kern.log에 기록되었습니다.
Jul 26 09:14:16 GlaDux kernel: [ 2068.519913] EXT4-fs (sda3): ext4_orphan_cleanup: deleting unreferenced inode 663018
Jul 26 09:14:16 GlaDux kernel: [ 2068.519952] EXT4-fs (sda3): ext4_orphan_cleanup: deleting unreferenced inode 663017
Jul 26 09:14:16 GlaDux kernel: [ 2068.519961] EXT4-fs (sda3): ext4_orphan_cleanup: deleting unreferenced inode 663016
Jul 26 09:14:16 GlaDux kernel: [ 2068.519969] EXT4-fs (sda3): 3 orphan inodes deleted
Jul 26 09:14:16 GlaDux kernel: [ 2068.519970] EXT4-fs (sda3): recovery complete
Jul 26 09:14:17 GlaDux kernel: [ 2068.606194] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)