끊임없는 노력의 이일 경험, 마지막으로 프로덕션 서버의 데이터를 한 번에 삭제 오용 다시 시작했다.
이 기록에서 사고 및 솔루션의 과정은, 자신을 알리고 모 제안 다른 사람이 실수를했다.
나는 문제를 해결하기 위해 영감의 흔적을 찾을 수 친구가 발생하는 문제를 바랍니다.
01 사고 배경
오라클은 프로덕션 서버에 설치 여동생을 마련, 자매 가장자리 연구 쪽 설치는 설치가 제거 다시 설치 준비가 생각하지 않습니다.
명령은 다음과되는 명령 줄은 Oracle 설치 디렉토리를 제거 실행되는 인터넷에서 제거 찾기 :
RM - RF $ ORACLE_BASE / *
ORACLE_BASE 변수가 할당되지 않은 경우, 다음 명령이된다 :
RM - RF / *
등등,하지만 내 동생은 루트가 아 계정 사용. 이러한 방법으로, 전체 디스크는 톰캣의 응용 프로그램, MySQL 데이터베이스 등을 포함한 모든 파일을 삭제합니다 ...... 그리고
MySQL 데이터베이스가 실행되지 않는 이유는 무엇입니까? 완전히 제거하고, 마지막으로 톰캣 로그의 파일을 남아 있기 때문에 리눅스는이 파일이 너무 큰 것으로 추정하고, 때로는 성공적으로 삭제되지 않습니다? 실행중인 파일을 삭제할 수 있습니다.
자매 변심에 눈을 보면서,이 일이 그녀가 할 수 있도록 내가 배열 된 말뚝은 어떤 교육을받지 않은 상태에서, 취소 그녀에게하지 않았다 책임은 오직 한 사람에 돌아올 수 있고, 아름다운 곰이 책임 만드는 방법 이외의 것입니다 ?
방에 전화가 다른 서버에 디스크를 걸어, 모든 파일이 삭제됩니다 SSH의 상승세보기,이 서버가 실행되지만, 고객의 생산 시스템은, 아, 6 개월 동안 운영하고 있으며, 가능한 한 빨리 아 등으로 복원되었습니다.
그런 의견을 잘 알고 mysqldump는 (crontab 명령이 질문에 실행되는 백업 스크립트)의 몇 줄 수있는 백업 파일 만 1킬로바이트을 찾을 데이터베이스의 오프라인 백업 전송, 가장 가까운 백업은 정말 새는 집 12 월 2013 년입니다 매일 밤 비 아.
그것을 생각 지도자는 경우가 말했다 : 생산 시스템이 중단되면, 모든 백업, DVD도 긁힌 자국, 테이프 드라이브는 (나쁜 수석 산업이다, 이전 추정치는 백업 CD-ROM을 할 질문이 찾을 수 ), 내가 어떻게 할, 정말 내 몸을 충족 기대하지 않았다?
상황 인식 머리, 최악의 계획 B 완료되었습니다 부서 후 : 제품 리더십과 개인적으로 주도 AA 일요일 고객이 리더십 통신에 도시 월요일에 돌진, BB와 CC를 고객 관리자에게 방법을 찾기 위해 거기 가서 고객 ...... 납득
02 짚을 : ext3grep 정말 ext3grep 복구 할 수 있습니다 정보를 찾기 위해 온라인을 서둘러 실수로 데이터 복구를 삭제하고, 파일 찾기는 온라인 RF RM은, 우리는 또한 EXT3 디스크 포맷 및 삭제 많은 성공 사례.
그래서 다시 작성 파일 섹터를 삭제하려면 방지하기 위해 디스크 언 마운트에 희망의 희미한 빛, 가능한 한 빨리를 점화. 다운로드 ext3grep 설치 (컴파일하고 당분간 수고를 아끼지 않는 과정을 설치하면 테이블하지 않습니다).
우선 스캔 파일 이름 명령을 수행합니다 :
ext3grep / dev에 / vgdata / LogVol00 - 덤프 - 이름
플랜 B를 수행하지 않고, 기쁨 모든 삭제 된 파일 및 경로, 인쇄, 파일은에 있습니다.
디렉토리로 파일을 복원 할 수 있습니다이 소프트웨어는 모든 명령은 복구를 실행할 수 있습니다 :
ext3grep / dev에 / vgdata / LogVol00 - 복원 - 모든
디스크 공간의 현재 부족의 결과는 단지 파일을 복원 할 수있는 방법은 아직 부분적으로 성공적인 부분 실패를 몇 개의 파일을 시도,하지만 :
ext3grep / dev에 / vgdata / LogVol00 파일을 복원는 / var / lib 디렉토리 / mysql을 / 미국 tb_b_attench.MYD
당신은이 디스크에 파일을 삭제 작성된되어, 감기에 도움이되지 수 있습니까? 복구 확률은 아, 당신은 몇 가지, 어쩌면 그냥 중요한 데이터 파일 MYD 파일을 복원 할 수있는 몇 가지 수를 복원 할 수 없습니다.
파일에서 파일로 리디렉션 모든 파일 이름의 그래서 첫째 :
ext3grep / dev에 / vgdata / LogVol00 - 덤프 - 이름> /usr/allnames.txt
mysqltbname.txt로 저장 모든 MySQL 데이터베이스 파일 이름을 필터링합니다.
스크립트 파일을 복구 :
반면 읽기 LINE 할 "에코 시작 하는 복원 파일을 $ LINE" ext3grep / dev에 / vgdata / LogVol00 - 복구 - 파일 $ LINE 경우 [ $를? ! = 0 ] 다음 "에코 복원 실패, 종료 " #의 출구 1 Fi를 수행 < . / mysqltbname.txt
20분에 대해 실행 실행, 40 개 이상의 파일 복구,하지만 충분하지 아, 우리는 거의 100 테이블이 각 테이블 FRM, MYD, myi 세 가지 문서, 방법에 대한 300 개 이상의 아가 말을!
이러한 데이터는 고객이 있다고합니다 (기존 데이터베이스에 첨부 된 파일을 돌아올뿐만 아니라 데이터 뒷면의 일부로 간주 할 수있다 (777)에 대한 파일 권한 다시 시작 MySQL은,에, 그러나 고객은 출석 데이터, 데이터의 전화 측 보고서에 서명하는 것이 중요 할 것이다 다시 아 오지) 직원의 성능을한다.
가정? 중동은 기본적으로 같은 원리가 동일해야 ext3grep 문법과 다른 도구 extundelete을 시도했지만 디렉토리로 복원 할 수 있다고합니다.
글쎄, 그것을 시도를 제공합니다 :
extundelete / dev에 / vgdata / LogVol00 - 복원 디렉토리는 / var / lib 디렉토리 / mysql을
오른쪽 큐에 복구가 나오지 않습니다! ! ! ! ! ! ! ! 그 파일이 파괴되었다. 직장에서 보고서, 지금은 계획 B의 구현 ...... 절망의 가정의 리더십. (주말은 방법을 생각 돌아가서 휴식을 취)
03 바이너리 로그가 : 생각했다
(이번 주말 비판, 통보하지, 상환 회사로 이동, 다음날 아침 (심장에 문제가 아) 아침에 일찍 일어 났는데, 컴퓨터의 뒷면을 , 벌금, 좋은에서 해고뿐만 아니라, 무엇 주말 아).
아직 테스트 서버 랙 시스템에 둘 것이다 ext3grep, extundelete, 아 조리법을 실행, 그것을 수선 할 수있는 방법을 찾기 위해 데이터를 볼 수 있습니다.
테스트 서버 mysqldump를 수행 위치, 파일을 복구 할 파일의 커버를 다시 복구, 파일, 다시 시작 MySQL의 권한을 추가 할 수 있습니다.
잠깐, 잠깐, 바이너리 로그 그것은이 없다? 당사의 서비스는 어쩌면 당신은 데이터 바이너리 로그를 복구 할 수 있습니다 오픈 바이너리 로그에 필요합니까?
그래서 총 세 중 파일 이름에서 바이너리 로그 덤프 파일을 찾을 수 :
- mysql을 - binlog0001
- MySQL의-bin.000009
- MySQL의-bin.000010
0001에 대한 복원
ext3grep / dev에 / vgdata / LogVol00 - 복원 파일을 var에 / lib 디렉토리 / mysql을 / mysql을-bin.000001 위
실제로 실패 ...... 다른 두 개의 파일에서 보면, MB 백 mysql을-bin.000010 아마 몇, 실제로 성공을 restore 명령을 수행, 조금 까다로운해야합니다!
SCP 즉시 테스트 서버에 가능한. 실행 바이너리 로그 복원 :
mysqlbinlog은 / USR / mysql을 - 빈. 000010 | mysql을 - uroot - P
긴 기다림이 마침내 끝난 후, 암호, 붙어 (좋은 기호)를 입력합니다. 데이터를 CCTV, MTV을 다시 감사합니다, 오, 응용 프로그램을 엽니 다!
04 포스트 스크립트는
또한 더 이상 같은 실수를하지 않습니다 염두에 사고를 유지하려는. 반사 사고는 다음과 같습니다 :
- 그들은 MM 상황 악화 설명이 서버 유지 보수의 그녀의 시간을 마련하기 위해 진행되지 않았고, 그는 혼돈 관리, 프로세스 혼란에 중요성을 첨부하지 않았다. 온라인 생산 시스템은 변경 먼저 계획 한 후 이동해야합니다.
- 자동 백업 문제, 아무도 확인합니다. 오프라인 백업 요원 서버에서 파일을 다운로드 당 1K, 그러나 결코 심각하게. 우리는 직장에서 분명한 책임이 필요합니다.
- 사고 후에는 복구 할 수없는 문제의 결과로, 디스크에 기록 된 데이터의 일부를 일으키는 원인이 발견되지 않았습니다. 쓰기 응용 프로그램 모니터링 프로그램 필요, 서비스에 이상이되면, SMS 알림 책임자.
- 댓글 알림 플러스에 따르면 당신은 작동하는 루트 사용자를 사용할 수 없습니다. 당신은 서버에 사용자 권한의 서로 다른 레벨을 제공한다.
아래이 사건 공유를 통해 도구 여기에 사용하고 있습니다 :
1. https://code.google.com/p/ext3grep/
2. http://extundelete.sourceforge.net/
유사한 원칙에 Ext3grep 기능도 유사해야합니다. 설치하는 방법에 인터넷을 검색 할 수 있습니다, 컴파일하고 더 종속성을 설치합니다. [불행하게도 하우투 저자가 벽을 받았다, 나는 더 나은 리눅스 파일 시스템의 이해를해야합니다 당신을 읽은 후, PDF 문서를 다운로드 하우투 FQ 것입니다. ]
이 도구는 오류가 발생한 후 아래로 실행되지 않습니다 버그가 있습니다 :
ext3grep : init_directories.cc : 534 : 무효 init_directories () : 어설`lost_plus_found_directory_iter ! = ALL_DIRECTORIES. 끝 () ' 실패했습니다.
오류 복구의 결과로, 저자는 패치 다운로드 주소를 출시 : 패치를 다운로드합니다.
마지막으로, 나는 동료 작은 친구는 결코 잘못된 코드를 노크 행복이 문서 이벤트를 기억할 수 있기를 바랍니다 -