최근에 HDD가 충돌하여 명령을 실행해야 했습니다 fsck. 많은 파일이 폴더로 이동되었으며 lost+found및 를 사용하여 중요한 파일을 검색했지만 findSQL grep데이터베이스를 찾을 수 없습니다.
질문
- Lost+found 디렉토리에서 InnoDB 데이터베이스를 어떻게 찾을 수 있나요?
- fsck가 내 SQL 데이터베이스를 저장하지 않았을 가능성이 있습니까?
- 그렇다면 이 파일을 복구할 수 있습니까?
답변1
#1을 시도해보세요:
아직 거기에 있을 수도 있지만 이름만 fe /lost+found/#3456254 등으로 변경되었습니다. 당신의 자리에서 나는 file -szL의 모든 것에 대해 재귀를 수행 /lost+found하고 innodb를 grep했습니다.
find /lost+found -type f|xargs -P 1 -n 500 file -szL|grep -i innodb
아직 innodb 데이터베이스가 있다면 저장할 데이터가 있는 것입니다. 행운을 빌어요!
시도 #2:
데이터베이스에 많은 텍스트 데이터가 있는 경우 섹터 기반 헥사 검색도 도움이 될 수 있습니다.
답변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) 테스트 실행 대신 실제로 이를 수행하는 스위치.
2개의 스크립트는 함께 작동하며, 첫 번째 스크립트는 시스템에 있는 파일의 인벤토리를 구축하기 위해 주기적으로 실행되어야 합니다. 그런 다음 두 번째 스크립트는 디렉터리에서 파일을 복원해야 하는 경우 이 인벤토리를 활용할 수 있습니다 lost+found.