최근에 하드 드라이브가 충돌하여 명령을 실행해야 했습니다 fsck. 많은 파일이 이 폴더로 이동되었으며 lost+found중요한 파일을 사용하고 검색했지만 SQL 데이터베이스를 찾을 수 없습니다.findgrep
질문
- Lost+found 디렉토리에서 InnoDB 데이터베이스를 어떻게 찾을 수 있나요?
- fsck가 내 SQL 데이터베이스를 저장하지 않았을 가능성이 있습니까?
- 그렇다면 이 파일을 복구할 수 있나요?
답변1
시도 #1:
아마도 아직 거기에 있을 수도 있지만 이름이 fe /lost+found/#3456254 등으로 변경되었습니다. 귀하의 입장에서 나는 innodb를 grep하여 file -szL모든 것을 반복했습니다 /lost+found.
find /lost+found -type f|xargs -P 1 -n 500 file -szL|grep -i innodb
innodb 데이터베이스도 있으면 데이터를 저장할 수 있습니다. 행운을 빌어요!
시도 #2:
데이터베이스에 텍스트 데이터가 많으면 섹터 기반 16진수 검색도 도움이 될 수 있습니다.
답변2
문제의 파일은 삭제되었기 때문에 fsck를 통해 재구성할 수 없습니다. fsck 프로그램은 최선의 노력을 다해 파일을 복구하고 재구축하려고 시도합니다. 그러나 이는 결코 어떤 종류의 백업도 아닙니다. fsck가 수행하는 모든 작업은 기본적으로 되돌릴 수 없습니다.
"lost+found" 디렉토리에 포함된 MySQL 데이터베이스 부분을 사용하려고 할 때 매우 주의해야 합니다. 데이터베이스는 하나의 파일에 포함되어 있지 않고 여러 파일에 포함되어 있기 때문입니다. 파일로 데이터베이스를 복원하길 바랍니다. 어떤 종류의 신뢰성이나 데이터 무결성에도 패턴이 없습니다.
파일 복구에 관해서는 죄송합니다. 데이터가 중요하기 때문에 수행 중이던 백업으로 돌아가야 합니다. 그렇지 않으면 정말 운이 좋지 않습니다.
데이터가 매우 중요하다면 다양한 데이터 복구 서비스 중 하나에 도움을 요청해 볼 수 있습니다. 비용이 많이 들고 결과가 완벽하지 않습니다.
답변3
나는 당신에게 운이 없다고 믿습니다. 유일한 옵션은 lost+found디렉토리를 탐색 하고 각 파일을 시각적으로 검사하여 원래 이름에 대한 단서를 찾는 것입니다.
미래
다음과 같은 제목의 블로그 게시물이 있습니다.업데이트: 손실된 파일과 찾은 파일의 자동 복구에서는 이러한 상황에 도움이 될 수 있는 두 가지 도구에 대해 설명합니다.
make-lsLR.sh- 이 함수(cron)는 주기적으로 호출되어 /root/에 저장된 필수 파일을 생성합니다. 물론 위치를 쉽게 변경하고 다른 디렉터리를 검색에서 제외할 수도 있습니다.
check_lost+found.py- fsck가 파일을 스크램블하여 Lost+found 디렉토리에 저장할 때 두 번째 스크립트가 실행됩니다. 3가지 매개변수가 필요합니다: 1) 엉망인 Lost+found 디렉토리가 있는 소스 디렉토리, 2) 데이터가 저장될 대상 디렉토리, 3) 테스트 실행이 아닌 실제로 실행할 스위치.
두 스크립트는 함께 작동하며, 첫 번째 스크립트는 시스템에 있는 파일의 인벤토리를 구축하기 위해 주기적으로 실행되어야 합니다. 디렉터리 에서 파일을 복원해야 하는 경우 lost+found두 번째 스크립트는 이 매니페스트를 사용할 수 있습니다 .