SQL Data Recovery 완벽 가이드: SQL 데이터베이스 및 삭제 파일 복구 방법

1. SQL Data Recovery가 필요한 대표적인 상황

실수로 테이블 또는 레코드를 삭제한 경우 --- DELETE 문, 잘못된 UPDATE 문, 테이블 삭제 등으로 필요한 데이터가 사라질 수 있습니다.

MDF·NDF·LDF 파일이 삭제되거나 이동된 경우 --- SQL Server 데이터베이스 파일이 원래 위치에서 사라지면 서비스가 정상적으로 데이터베이스를 불러오지 못할 수 있습니다.

BAK 또는 SQL 덤프 백업이 유실된 경우 --- 복구에 필요한 백업 파일이 외장 드라이브나 로컬 디스크에서 삭제되면 먼저 백업 파일 자체를 복구해야 합니다.

DB 파일 손상 또는 스토리지 오류가 발생한 경우 --- 갑작스러운 종료, 디스크 오류, 파일 시스템 손상 등으로 데이터베이스가 SUSPECT 상태가 되거나 열리지 않을 수 있습니다.

랜섬웨어·포맷·파티션 문제 이후 데이터가 사라진 경우 --- 이 경우 데이터베이스 엔진 안의 논리적 복구보다 저장장치에서 원본 파일을 되찾는 작업이 먼저일 수 있습니다.

2. 복구 전에 반드시 해야 할 4가지

• 삭제된 데이터가 있던 데이터베이스에 새로운 쓰기 작업을 최소화합니다. 로그나 디스크 영역이 덮어써지면 복구 가능성이 낮아질 수 있습니다.

• 현재 상태를 별도 사본으로 보존합니다. 특히 MDF/LDF 파일이 손상된 경우 원본을 직접 수정하기보다 복사본에서 작업하는 편이 안전합니다.

• 백업 위치와 보존 정책을 확인합니다. 최신 전체 백업, 차등 백업, 트랜잭션 로그 또는 덤프 파일이 있는지 먼저 찾습니다.

• 파일 자체가 삭제되었다면 해당 드라이브에 새 프로그램을 설치하거나 파일을 저장하지 않습니다. 가능한 경우 다른 드라이브에서 복구 도구를 실행합니다.

3. 방법 1: 최신 백업에서 SQL 데이터베이스 복원하기

가장 안전하고 우선순위가 높은 방법은 검증된 백업에서 복원하는 것입니다. 백업이 정상이라면 손상된 원본 데이터베이스를 직접 수정하는 것보다 복구 결과를 예측하기 쉽고, 운영 환경으로 되돌리는 절차도 명확합니다.

SQL Server의 경우

• SQL Server Management Studio(SSMS)를 열고 대상 서버에 연결합니다.

• Databases를 마우스 오른쪽 버튼으로 클릭한 뒤 Restore Database를 선택합니다.

• Device에서 .bak 백업 파일을 지정하고 복원 대상 데이터베이스와 경로를 확인합니다.

• 필요한 경우 Options에서 기존 데이터베이스 덮어쓰기 여부를 신중하게 확인한 뒤 복원을 실행합니다.

• 복원 후 애플리케이션 연결과 주요 테이블의 데이터가 정상인지 검증합니다.

MySQL / PostgreSQL의 경우

MySQL은 mysqldump로 생성한 SQL 덤프를 mysql 클라이언트로 가져올 수 있고, PostgreSQL은 pg_dump로 만든 백업을 pg_restore 또는 psql로 복원할 수 있습니다. 중요한 점은 백업 포맷에 맞는 도구를 사용하는 것입니다.

4. 방법 2: 트랜잭션 로그 또는 Point-in-Time Recovery로 되돌리기

백업 이후 특정 시점에 데이터가 잘못 삭제되었다면 "삭제 직전 시점"으로 복원하는 방법을 고려할 수 있습니다. 이 방식은 운영 중 발생한 실수로부터 일부 데이터를 되찾을 때 유용하지만, DB 엔진의 복구 모드와 로그 보존 설정이 사전에 갖춰져 있어야 합니다.

SQL Server: Full 또는 Bulk-Logged 복구 모델에서 전체/차등 백업과 트랜잭션 로그 백업 체인이 유지되어 있다면 STOPAT 옵션을 활용한 시점 복구를 검토할 수 있습니다.

MySQL: Binary Log가 활성화되어 있고 로그가 남아 있다면 전체 백업을 복원한 뒤 mysqlbinlog를 사용해 특정 시점까지 변경 내역을 재적용할 수 있습니다.

PostgreSQL: WAL 아카이빙과 베이스 백업이 준비되어 있다면 PITR(Point-in-Time Recovery) 방식으로 목표 시점까지 복구할 수 있습니다.

주의

• 시점 복구는 현재 운영 DB를 바로 덮어쓰기보다 별도 테스트 인스턴스에 먼저 복원해 필요한 데이터를 확인하는 것이 안전합니다.
• 로그 백업 체인이 끊겼거나 필요한 로그가 이미 삭제된 경우 원하는 시점으로 되돌릴 수 없을 수 있습니다.

5. 방법 3: SQL Server 데이터베이스 손상 검사 및 복구

데이터베이스가 SUSPECT 상태이거나 읽기 오류가 발생한다면 먼저 원본 파일과 백업 사본을 보존한 뒤 DBCC CHECKDB로 무결성을 확인할 수 있습니다. 다만 REPAIR_ALLOW_DATA_LOSS는 실제로 일부 페이지나 레코드를 제거할 수 있으므로 최후의 수단으로만 사용해야 합니다.

• 가능하면 손상된 MDF/LDF 파일과 최신 백업을 별도 위치에 복사합니다.

• DBCC CHECKDB를 실행해 오류 범위를 확인합니다.

• 백업에서 복원이 가능한 경우 복원을 우선합니다.

• 백업이 없고 다른 선택지가 없는 경우에만 Microsoft 문서와 DBA 검토를 바탕으로 복구 옵션을 신중하게 사용합니다.

• 복구 후 데이터 무결성과 주요 테이블을 반드시 검증합니다.

6. 방법 4: 삭제된 MDF·LDF·BAK·SQL 파일을 4DDiG Data Recovery로 복구하기

데이터베이스 내부의 레코드가 아니라 MDF, NDF, LDF, BAK, SQL 덤프 파일 자체가 삭제된 경우에는 데이터베이스 명령만으로 해결하기 어렵습니다. 이때는 저장장치에서 원본 파일을 먼저 복구한 다음 SQL Server, MySQL 또는 PostgreSQL의 복원 절차를 진행해야 합니다.

4DDiG Data Recovery는 삭제, 포맷, 파티션 문제 등으로 사라진 파일을 저장장치에서 스캔해 복구하는 데 사용할 수 있습니다. 데이터베이스 구조를 직접 "수리"하는 도구가 아니라, 복구에 필요한 데이터베이스 파일이나 백업 파일을 되찾는 단계에 적합합니다.

4DDiG로 SQL 관련 파일을 복구하는 단계

• 4DDiG Data Recovery를 실행하고 삭제된 SQL 파일이 원래 저장되어 있던 드라이브 또는 파티션을 선택합니다.

  

• 스캔을 시작한 뒤 파일 이름, 경로, 확장자 등을 기준으로 .mdf, .ndf, .ldf, .bak, .sql 파일을 찾습니다.

  

• 필요한 파일을 확인한 뒤 복구를 실행합니다. 복구 파일은 원래 드라이브가 아닌 다른 저장장치에 저장하는 것이 좋습니다.

  

• 복구된 파일을 바로 운영 환경에 덮어쓰지 말고 별도 테스트 환경에서 무결성을 확인합니다.

• 파일이 정상이라면 해당 DB 엔진의 Restore, Attach, Import 또는 Dump 복원 절차를 사용해 데이터베이스를 다시 구성합니다.

이 방법이 특히 유용한 경우

• 실수로 .bak 또는 .sql 백업 파일을 삭제한 경우

• SQL Server의 .mdf/.ldf 파일이 포맷이나 파티션 오류 후 사라진 경우

• 외장 SSD, HDD, USB에 보관하던 데이터베이스 백업을 잃어버린 경우

• DB 복원 전에 먼저 원본 파일을 확보해야 하는 경우

7. 방법 5: 복구한 SQL 파일을 안전하게 다시 연결하거나 가져오기

파일 복구가 끝났다고 해서 데이터베이스가 즉시 정상 상태가 되는 것은 아닙니다. 복구된 파일이 완전한지 확인한 뒤 DB 엔진이 요구하는 방식으로 연결하거나 복원해야 합니다.

SQL Server .BAK: SSMS의 Restore Database 기능을 이용해 별도 데이터베이스 이름으로 먼저 복원합니다.

SQL Server .MDF/.LDF: 파일이 일관된 상태에서 분리되었거나 정상적으로 복사된 경우 Attach를 검토할 수 있습니다. 손상 파일이라면 Attach를 반복하기보다 백업 복원과 무결성 검사를 우선합니다.

MySQL .SQL 덤프: 새 데이터베이스를 만든 뒤 mysql 클라이언트 또는 관리 도구에서 덤프를 가져옵니다.

PostgreSQL 덤프: plain SQL 형식은 psql, custom/tar 형식은 pg_restore를 사용하는 것이 일반적입니다.

8. SQL Data Recovery에서 피해야 할 실수

• 운영 DB에 바로 복구본을 덮어쓰기 --- 복구한 파일은 별도 인스턴스나 테스트 서버에서 먼저 검증하세요.
• 삭제된 파일이 있던 드라이브에 계속 저장하기 --- 새 데이터가 삭제된 파일 영역을 덮어쓸 수 있습니다.
• 로그와 백업 체인을 확인하지 않고 PITR 시도하기 --- 복구 시점에 필요한 로그가 없으면 복원이 중단될 수 있습니다.
• REPAIR_ALLOW_DATA_LOSS를 첫 번째 선택으로 사용하기 --- 이 옵션은 이름 그대로 데이터 손실을 일으킬 수 있습니다.
• 복구 후 애플리케이션 테스트를 생략하기 --- 테이블이 열려도 인덱스, 관계, 권한 또는 애플리케이션 의존성이 정상인지 확인해야 합니다.

9. 복구 성공률을 높이는 실전 팁

• 운영 DB와 백업 저장 위치를 분리하고, 최소 1개 이상의 오프라인 또는 별도 스토리지 백업을 유지합니다.

• SQL Server는 복구 모델과 로그 백업 주기를 실제 RPO/RTO 목표에 맞게 설정합니다.

• MySQL은 Binary Log, PostgreSQL은 WAL 아카이빙을 단순히 켜두는 것에 그치지 말고 정기적으로 복구 테스트를 수행합니다.

• 데이터베이스 파일을 복구해야 한다면 스캔 결과에서 파일 크기와 원래 경로를 함께 확인해 올바른 파일인지 판단합니다.

• 가장 중요한 DB는 정기적으로 "복원 테스트"를 실행해 백업 파일이 실제로 사용 가능한지 검증합니다.

10. SQL Data Recovery FAQ

Q1. 삭제된 SQL 데이터를 백업 없이 복구할 수 있나요?

가능 여부는 상황에 따라 다릅니다. 데이터베이스 내부 레코드 삭제라면 트랜잭션 로그나 DB 엔진의 복구 기능이 필요할 수 있고, MDF/BAK/SQL 파일 자체가 삭제된 경우에는 저장장치에서 파일을 복구한 뒤 DB 복원을 시도할 수 있습니다.

Q2. MDF 파일만 복구하면 SQL Server 데이터베이스를 열 수 있나요?

항상 그렇지는 않습니다. MDF와 로그 파일의 상태, 데이터베이스가 정상적으로 종료되었는지, 파일 손상 여부에 따라 결과가 달라집니다. 중요한 환경에서는 Attach를 반복하기보다 백업 복원 또는 DBA 검토가 더 안전합니다.

Q3. 4DDiG Data Recovery가 손상된 SQL 데이터베이스를 직접 수리하나요?

4DDiG Data Recovery는 저장장치에서 삭제되거나 유실된 데이터베이스 파일과 백업 파일을 찾고 복구하는 데 초점이 있습니다. 데이터베이스 내부 구조의 논리적 복구는 SQL Server, MySQL, PostgreSQL 등 각 DB 엔진의 도구를 사용해야 합니다.

Q4. SQL Server BAK 파일을 실수로 삭제했는데 어떻게 해야 하나요?

해당 드라이브 사용을 최소화한 뒤 파일 복구를 먼저 시도하세요. BAK 파일을 복구했다면 SSMS에서 별도 데이터베이스로 복원해 무결성과 데이터를 확인하는 것이 좋습니다.

Q5. 데이터베이스 복구 후 가장 먼저 확인해야 할 것은 무엇인가요?

주요 테이블의 행 수와 핵심 데이터, 인덱스 및 제약조건, 사용자 권한, 애플리케이션 연결을 확인하세요. 가능하면 운영 반영 전에 테스트 환경에서 검증해야 합니다.

Q6. SQL 데이터 복구를 앞으로 더 쉽게 하려면 어떻게 해야 하나요?

정기 백업, 로그 백업 또는 WAL/Binary Log 보존, 별도 저장소 백업, 그리고 실제 복원 테스트를 함께 운영하는 것이 가장 효과적입니다.

결론

SQL data recovery의 핵심은 손실 유형을 먼저 정확히 구분하는 것입니다. 레코드가 삭제되었다면 백업과 트랜잭션 로그를, 데이터베이스가 손상되었다면 DB 엔진의 무결성 검사와 복원 기능을 우선 확인해야 합니다. 반면 MDF, LDF, BAK, SQL 덤프 같은 파일 자체가 삭제되었다면 저장장치 사용을 멈추고 파일 복구를 먼저 진행하는 것이 중요합니다.

4DDiG Data Recovery는 이러한 "파일 자체가 사라진" 상황에서 데이터베이스 파일 또는 백업 파일을 다시 확보하는 데 활용할 수 있습니다. 복구 후에는 항상 별도 환경에서 파일 무결성과 데이터베이스 상태를 검증한 뒤 운영 환경에 반영하세요.