끊임없는 노력의 경험 이틀, 마지막으로 프로덕션 서버 데이터 오용 한 번 삭제 다시 시작했다. 이 기록에서 사고 및 솔루션의 과정은, 자신을 알리고 모 제안 다른 사람이 실수를했다. 나는 문제를 해결하기 위해 영감의 흔적을 찾을 수 친구가 발생하는 문제를 바랍니다.
사고 배경
프로덕션 서버 오라클, 자매 가장자리 연구 쪽 설치에 설치 자매 정렬, 설치가 다시 설치를 제거 할 준비가 생각하지 않습니다. 이 명령은 다음과 같다 명령 줄은 Oracle 설치 디렉토리를 제거 실행되는 인터넷에서 제거 찾기 :
ORACLE_BASE 변수가 할당되지 않은 경우, 다음 명령이된다
등등, 여동생이 사용하지만, 루트 계정 아.
이러한 방법으로, 전체 디스크는 두 톰캣의 응용 프로그램, MySQL 데이터베이스 등 모든 파일을 삭제합니다. . . .
MySQL 데이터베이스는 완전히 제거하기 때문에 리눅스는? 실행중인 파일을 삭제할 수 있습니다? 실행, 그리고 마지막으로,이 파일이 너무 큰 것으로 추정하고, 때로는 성공적으로 삭제되지 않는 바람둥이 로그 파일을 남아 있지
동생이 눈을 후회 보는 것은, 책임 만, 다시 한 사람이 될 수있는 교육을받지 않은 상태에서, 분명 그녀에게 지분을 말씀과 아름다운 곰이 책임 만드는 방법 외에 않았다, 그녀가 할 수 있도록 내가 배열이 일이 ?
방으로 호출하면, 모든 파일이 서버가 실행되고 삭제됩니다 다른 서버, ssh를 상승세보기로 디스크를 중지하지만, 고객의 생산 시스템은, 아, 빨리 아로 복원, 6 개월 동안 실행되었습니다. 그런 다음 오프라인 데이터베이스 백업 전송, 백업 파일 (문제의 백업 스크립트의 crontab 실행되어), 다음 백업의 대부분은 정말 집 12 월 2013 년 지 확인 익숙한 mysqldump는 주석의 몇 라인 인 만 1킬로바이트 발견 끝없이 비 아. 그것을 생각 지도자는 경우가 말했다 : 생산 시스템이 중단되면, DVD는 긁힌 자국, 테이프 드라이브는 나쁜 모든 백업 질문이 발견 (수석 업계, 이전 추정치는 백업 CD-ROM을 ), 난 정말 내 몸을 충족 기대하지 않았다, 어떻게해야하는 ??
부서가 상황을 알고 머리 후, 최악의 플랜 B를 수행하고있다 : AA 고객이 리더십 통신에 도시 월요일 돌진 곳 개인적으로 일요일 주도 제품 리더십을, BB와 CC는 고객 관리자에게 방법을 찾기 위해 그곳으로 이동 고객을 설득. . .
밀짚 / ext3grep
정보를 신속하게 실수로 삭제 된 데이터 복구를 찾을 수있는 인터넷하려면 정말 ext3grep은 RM의 -rf, 우리 또한 EXT3 디스크 포맷에 의해 삭제 된 파일을 복구 할 수 있습니다 발견하고 많은 온라인 성공 사례가있다. 그래서 다시 작성 삭제 된 파일 섹터를 만들기 위해 방지하기 위해 디스크 언 마운트에 희망의 희미한 빛, 가능한 한 빨리를 점화. , ext3grep 다운로드 설치 (당분간의 힘든 과정을 컴파일하고 설치하는 것은 테이블 아니다). 우선 스캔 파일 이름 명령을 수행합니다 :
플랜의 B를 수행하지 않고, 기뻐하고 모든 삭제 된 파일 및 경로, 인쇄, 파일은에 있습니다. 디렉토리로 파일을 복원 할 수 있습니다이 소프트웨어는 모든 명령은 복구를 실행할 수 있습니다 :
디스크 공간의 현재 부족의 결과는 단지 파일을 복원 할 수있는 방법은, 부분적으로 성공적인 부분 실패 여전히 몇 개의 파일을 시도,하지만
당신은?가 디스크에 파일을 삭제 작성된되어, 감기에 도움이, 아, 그것은 몇 몇, 어쩌면 그냥 중요한 데이터 파일 MYD 파일을 복원 할 수 있습니다 카운트 복원 할 수 있습니다 회복의 기회가 거의 없습니다. 파일을 파일로 리디렉션 모든 파일 이름의 그래서 처음
저장 모든 MySQL의 데이터베이스 파일 이름을 필터링, mysqltbname.txt
스크립트 파일을 복구 :
실행은, 20 분, 40 개 이상의 파일 복구를 실행할 수 있지만 충분하지 아, 우리는 각 테이블 FRM은, MYD, myi 세 가지 문서가 어떻게 300 개 이상의 아에 대한가 말을 거의 100 테이블이! ! 777, 다시 시작 MySQL의에 파일 권한도 기존 데이터베이스에 첨부 된 파일을 다시 올 것이지만, 다시 데이터의 일부로 간주하지만, 고객은 (이 데이터는 고객이 말한다 출석 데이터, 데이터의 전화 측 보고서에 서명하는 것이 중요하다 할 수있다 아 돌아 오지) 직원의 성능을한다. 우리는? 중간에 생각과 기본적으로 같은 원리가 동일해야 ext3grep 문법과 다른 도구 extundelete을 시도했지만 잘 디렉토리로 복원을 시도해라고되어있다.
오른쪽 큐에 복구가 나오지 않습니다! ! ! ! ! ! ! ! 그 파일이 파괴되었다. 보고서, 지금은 계획 B의 구현의 리더십. . . 직장에서 집으로 절망 (주말, 방법을 생각 돌아가서 휴식을 취)
영감 / 바이너리 로그
第二天早晨一早就醒了（心里有事啊），背上电脑，去公司（这个周末算是报销了，不挨批，通报，罚款，开除就不错了，还过什么周末啊）。依旧运行ext3grep，extundelete，也就那几招啊，把系统架到测试服务器上，看看数据能不能想办法补一补吧。在测试服务器上进行mysqldump，恢复文件，覆盖恢复回来的文件，给文件加权限，重启mysql。wait,wait，不是有binlog吗?我们服务都要求开启binlog，说不定能通过binlog里恢复数据呢?
于是从dump出来的文件名里找到binlog的文件，一共三个，mysql-binlog0001,mysql-bin.000009,mysql-bin.000010，恢复一下0001
居然失败了。。。。。。再看另两个文件，mysql-bin.000010大概几百MB，应该靠谱一点，执行还原命令，居然成功了！！！！！！！！！！！！！赶快scp到测试服务器。执行binlog还原。mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p
输入密码，卡住了（好现象），经过漫长的等待，终于结束了。打开应用，哦，感谢cctv,mtv，数据回来了！！！！！！！！！！！！！！！
后记
经过此次事故，虽然数据很幸运能找回来了，但是过程却是惊心动迫。也为自己的错误所带来的后果，给同事和领导带来的连带责任而后怕。也希望谨记此次事故，以后不再犯同样的错误。事故反思如下：
本次安排MM进行服务器维护时没有提前对她进行说明厉害情况，自己也未重视，管理混乱，流程混乱。一个在线的生产系统，任何一个改动一定要先谋而后动。
自动备份出现问题，没有任何人检查。脱机备份人员每次从服务器上下载1k的文件却从未重视。需要明确大家在工作岗位上的责任。
事故发生后，没有及时发现，造成部分数据写入磁盘，造成不可恢复问题。需要编写应用监控程序，服务一旦有异常，短信告警相关责任人。
댓글 알림 플러스에 따르면 당신은 작동하는 루트 사용자를 사용할 수 없습니다. 당신은 서버에 사용자 권한의 서로 다른 레벨을 제공한다.
이 사건을 통해 여러 프로젝트와 사고와 그의 동료 테스트를하는 데 도움이되는 정보를 찾기 위해 도움이 와서 주도권을 쥐고, 어떤 관계를 가지고 있지 않은, 동료는 데이터 복구 테스트 13:00시에 도움이됩니다. 경우에 동시에 제품 관리자에 당황 개발자와 특정 연산자를 비난하지 않았다, 고객 대면 엄청난 압력을 기대하지만, 그래서 우리는 중지 및 솔루션을 생각할 수있다. 부서장은 적극적으로, 초과 근무 테스트 작업을 실시간으로 추적하는 과정을 우리 함께 할 수있는 방법을 찾는 데 도움이. 우리의 공동 노력을 통해, 비교적 성공적인 결론 다음주 월요일 아침이 공동으로 수업에 반영 마지막으로 뭔가 배운, 같은 사건은 큰 노력을 피하려고해야합니다.
"자바 핵심 지식 .PDF 마무리", "덮고있는 JVM, 잠금 장치 등 높은 동시성, 반사, 봄 원리, 마이크로 서비스, 사육사, 데이터베이스, 데이터 구조,"뿐만 아니라 Java208 포장 질문 (인터뷰 책을 공유하기 무료로 액세스 그룹 (자바 피트 길을 채우기) 659 655 594에 가입하는) 답변!