MSSQL Server 2008 R2 테이블 삭제(Drop Table) 복구
MSSQL Sever 2008 R2 사용 중 싱수로 테이블을 삭제(Drop table) 하여 접수되었습니다. MDF, LDF 파일 모두 이메일로 접수하였고 용량은 1GB 이하이비니다. 데이타베이스 파일은 압축을 하면 90정도 압축율로 압축되어 1/10 크기가 되어 이메일로 접수를 받습니다
테이블 삭제나 레코드 삭제의 경우 로그파일(LDF) 을 통해서 복구하며 LDF 파일이 없거나 로그 기록을 하지 않도록 설정해 놓은 경우 복구가 불가합니다
로그파일(LDF) 를 분석하여 삭제된 테이블을 다시 데이타베이스에 100% 복원시켰습니다.
접수된 데이타베이스 파일은 용량이 적어서 당일 복구하여 고객에게 전달하였습니다
자세한 내용은 http://ingen.co.kr/ra_dr_db 클릭
오라클(Oracle 11g R2) 데이타베이스 복구
오라클(Oracle) 11g R2 데이타베이스가 설치된 시스템이 부팅이 되지않아 데이타베이스 파일 4GB를 다른 시스템으로 복사한 후 오라클에서 접속 시 접속이 불가한 상태로 접수되었습니다
데이타베이스 파일의 손상으로 데이타베이스 리페어(Repair) 를 실행하여 백업파일로 저장합니다
데이타베이스 손상의 경우는 소프트웨어 손상으로 데이타베이스 엔진과 연결이 안되거나 일부 테이블이나 레코드가 일부 보이지 않는 경우거나 하드디스크에 스크레치(Bad Sector)로 인해 일부 테이블이나 레코드가 일부 보이지 않는 경우입니다
[데이타베이스 복구 작업순서]
1. 작업 순서는 테이블을 복구하여
2. Oracle 에 Import 한 후
3. Oracle 에서 백업파일로 받아냅니다.
이 과정에서 Oracle에 Import 하는 과정 중 레코드가 손상되어 있는 경우 레코드 값이 엉뚱한 값이라 오류가 발생하여 멈추는 경우가 있습니다. 이 레코드를 삭제 후 다시 import 진행하여야 하므로 이 과정에서 시간이 상당히 소요됩니다.
Import가 완료된 후에도 레코드에 설정된 레코드 Type 과 다른 데이타가 저장된 경우 레코드의 데이타가 손상된 것으로 판단하고 이러한 레코드도 삭제합니다
접수된 데이타베이스 파일은 손상이 적고 용량이 적어서 당일 복구하여 고객에게 전달하였습니다
자세한 내용은 http://ingen.co.kr/ra_dr_db 클릭
IBM X3550 M3 RAID5 복구
IBM System X3550 M3 입니다
IBM MBF2300RC 300GB 10k 2.5" 6Gbps SAS Hard Drive
300GB SAS 2.5인치 4개로 RAID5 구성되어 사용 중으로 OS 는 WIndows Server 2012 R2 입니다
리부팅 후에 레이드에 장애가 발생하여 일부 폴더가 보이지 않는 증상으로 하드디스크 4개만 보내주셔서 접수되었습니다.
레이드 장애의 경우 손상된 하드디스크에 해당하는 LED 가 붉은 색으로 표시되어 장애를 확인할 수 있도록 되어있고 레이드 관리툴에서도 확인이 가능합니다. 접수된 레이드 장애의 경우 LED 나 관리툴에 표시된 하드디스크의 수보다 많은 하드디스크가 손상된 경우가 많습니다
[RAID 하드 접수방법]
1. 장애발생 후 시스템을 종료 후 추가의 작업을 진행하지 않습니다
장애발생 후 복구를 위해 레이드를 새로 구성한다거나 폴더가 보인다고 복구툴로 작업을하여
데이타를 저장하거나 하면 복구율이 현저하게 떨어집니다
2. 하드디스크를 시스템에서 빼는데 하드디스크 장착부분에 번호가 있으면 번호를 표시합니다
[접수 후 복구순서]
1. 모든 하드디스크의 물리적 손상여부를 확인하고 복제본을 작성합니다
정상인 하드디스크는 바로 복제본을 작성하며 이 과정에서 디스크 표면에 스크레치 여부도
확인됩니다
인식불가인 하드디스크는 손상된 부품을 교체하여 인식상태로 만들고 복제를 진행합니다
2. 복제된 하드디스크를 분석하여 원래 구성된 레이드 정보를 파악하고 레이드를 구성하여
데이타를 복구합니다
접수한 SAS 하드디스크는 물리적인 손상은 발견되지 않았고 복제된 하드디스크를 레이드로 재 구성하여 확인해보니 특정 파일이 없어져서 복구툴로 복구하여 찾아냈습니다
레이드에 데이타베이스(Oracle, MSSql, Mysql 등)의 DB 파일이 저장된 경우 복구 후 데이타베이스를 연결하여 손상 유무를 파악 후 손상된 경우 데이타베이스 복구를 추가로 진행합니다
이 경우 데이타베이스 복구는 별도의 복구비용이 청구됩니다
MSSQL 2008 R2 로 데이타베이스를 사용하여 어플리케이션과 연동하여 업무를 진행하는 고객으로 어플리케이션에서 일부 데이타가 나타나지 않아 복구 문의를 받은 경우 입니다
서버는 정상작동하여 외장하드를 연결하여 데이타베이스파일인 MDF 파일들을 복사하였고 MDF 파일의 총 용량이 343GB 입니다. 대용량 데이타베이스의 경우입니다
데이타베이스 손상의 경우 소프트웨어 손상으로 데이타베이스 엔진과 연결이 안되거나 이 경우처럼 일부 테이블이나 레코드가 일부 보이지 않는 경우거나 하드디스크에 스크레치(Bad Sector)로 인해 일부 테이블이나 레코드가 일부 보이지 않는 경우입니다
대용량 데이타베이스의 경우 테이블에 레코드 수가 많으면 복구 시간이 상당히 소요됩니다. 접수 시 총 예상시간은 1개월에서 1.5 개월로 산정하였고 급한 테이블부터 복구하여 고객에게 먼저 전달하여 어부의 지장을 최소화하기로 하였습니다
MDF 를 복구하여 확인하면 테이블수가 354개이며 테이블의 레코드 수가 2억개가 넘는 파일이 3개나됩니다.
[데이타베이스 복구 작업순서]
1. 작업 순서는 테이블을 복구하여
2. MSSQL에 Import 한 후
3. MSSQL 에서 백업파일로 받아냅니다.
이 과정에서 MSSQL에 Import 하는 과정 중 레코드가 손상되어 있는 경우 레코드 값이 엉뚱한 값이라 오류가 발생하여 멈추는 경우가 있습니다. 이 레코드를 삭제 후 다시 import 진행하여야 하므로 이 과정에서 시간이 상당히 소요됩니다.
레코드 수가 2억4천만 건인 테이블은 Import 시간만 3일 정도 소요되었습니다. 단, 레코드수도 중요하지만 레코드의 사이즈가 크면 시간이 더 소요됩니다
Import가 완료된 후에도 레코드에 설정된 레코드 Type 과 다른 데이타가 저장된 경우 레코드의 데이타가 손상된 것으로 판단하고 이러한 레코드도 삭제합니다
접수한 데이타베이스 복구는 고객이 우선 순위를 정해준 테이블부터 복구하여 순차적으로 전달하여 최종 마무리까지 예상한 시간인 1.5개월이 소요되었습니다
고객이 보관하고 있는 테이블, 레코드 리스트와 비교하여 판단하는 복구율은 90% 이상입니다. 아마도 하드디스크에 일부 스크레치로 인해 손상된 데이타가 있었던 것으로 판단합니다. 이 경우 시스템을 중지시키고 레리드가 구성되어 있는 하드디스크를 모두 빼서 보내주셨으면 복구율은 더 높았을 것으로 예상됩니다