Restore 에 대하여...

DBA의 업무 중에 무엇하나 중요하지 않은 것이 없지만, 개인적으로 백업/복원은 가장 중요한 업무라고 생각 됩니다.

이번에 백업파일에 대한 이슈가 발생하면서 백업파일에 대한 확인을 꼭 해야하며, 백업 받은 파일을 주기적으로 복원하여, 복원에 문제가 없는지 확인해야 

한다는 것을 느꼈습니다. 

이슈는 다음과 같이 발생하였습니다.

NAS장비로 백업을 하여 이 백업을 다시 2차 백업 서버로 옮기는 솔루션이 압축을 하는데, 이 솔루션이 압축을 하고 다시 가져와서 복원 하고자 할 때

압축된 .bak 파일의 압축을 정상적으로 풀지 못하여 문제가 발생 하였습니다. 모든 .bak 파일이 그런것은 아니고, 크기가 3GB 이상의 파일만 깨지는 것을

확인 하였습니다. 아무래도 솔루션 자체적으로 용량이 일정이상 크기 이상이라면 압축을 하는 것으로 보여집니다. 

복원이 정상적일거라고 처음에 생각 한게 'RESTORE FILELISTONLY'는 잘 먹습니다.

RESTORE FILELISTONLY FROM DISK = 'D:\Restore_Test.BAK'

하지만 'RESTORE DATABASE'를 실행하면 복원 시 페이지가 깨져서 복원이 불가능 하다는 메시지가 나옵니다.

RESTORE DATABASE [Restore_Test]  FROM DISK ='D:\Restore_Test.BAK'
WITH MOVE 'PPURIO_MASS_EDW' TO 'D:\RESTORE_TEST\Restore_Test.mdf',
MOVE  'PPURIO_MASS_EDW_log' TO 'D:\RESTORE_TEST\Restore_Test.ldf'
GO

DB는 복원되지 않지만, (복원 중...)으로 표시됩니다. 하지만 아무런 작업도 할 수 없습니다. 

이후에 강제 복원을 시켜보았으나 역시 안됩니다. 결론적으로 해당 .bak 파일의 문제였으며, .bak 의 자체적 문제이므로 이것은 백업을 잘 하는 수밖에 없었습니다.

서론이 너무 길었는데, 결론적으로 이번 포스트는 .bak 파일의 체크 및 관리를 적어보고자 합니다.

1. RESTORE VERIFYONLY

실제 복원이 아닌 복원을 테스트 하는 용도로 사용 합니다.

RESTORE VERIFYONLY FROM DISK = 'D:\Restore_Test.BAK'
GO

위와 같은 구문으로 가능하며, 실제로 복원을 하지는 않습니다. 현재 처럼 백업파일이 정상적이지 않을 때 다음과 같은 메시지를 출력 합니다.

하지만 이 구문은 완벽하게 백업파일에 문제가 없음을 보장하지는 않습니다. MSDN에 보면 더욱 자세히 알 수 있지만, 영문 사이트에 본 바로는 데이터 구조를 전부 검사하지는 

않기 때문에 VERIFYONLY는 100% 신뢰 할 수 없다고 합니다. 그래서 이 방법 이외에 다른 방법을 사용하기를 권장하고 있습니다. 그 방법은 아래에 작성 하였습니다.

2. CHECKSUM 

이 방법은 아에 백업을 할 때 CHECKSUM을 걸어서 백업 파일을 체크 하는 것 입니다. 백업을 할 때 CHECKSUM 옵션을 주면, 복원시 CHECKSUM을 할 수 있습니다.

이 옵션은 VERIFYIONLY에서도 사용 가능 합니다. 하지만 앞서 말했 듯이 백업 시에 CHECKSUM 옵션을 줘야 합니다.

BACKUP DATABASE [WorkDB] TO  DISK = N'D:\MSSQL_BACKUP\WorkDB.bak' WITH NOFORMAT, NOINIT,  
NAME = N'WorkDB-전체 데이터베이스 백업', SKIP, NOREWIND, NOUNLOAD,  STATS = 10, CHECKSUM
GO

이 구문은 UI로도 할 수 있습니다. 

CHECKSUM을 걸어서 만든 백업파일은 RESTORE VERIFYLONLY 구문에서 옵션을 사용하여서 더욱 신뢰성있게 체크 할 수 있습니다.

RESTORE VERIFYONLY FROM DISK = 'D:\Restore_Test.BAK'
WITH CHECKSUM
GO

3. DBCC CEHCKDB

가장 좋은 방법으로 권장하는 것은 백업 파일을 가져와서 복원 한 뒤에 CHECKDB를 실행하는 것 입니다. 

해당 작업은 개발 서버 및 유저가 사용하지 않는 서버에서 이루어지는 것을 권장 합니다.

다음과 같은 방법으로 스케줄러를 만들어서 매번 복원 한 뒤에 CHECKDB를 돌려서 검증 하는 것 입니다. 그 순서는 다음과 같이 이루어 집니다.

㉠ DATABASE 백업

㉡ 백업 파일을 복원

㉢ 복원 된 파일 CHECKDB 실행 

위의 순서데로 스케줄러를 만들어 보겠습니다.

Step 1 - DATABASE 백업

- 크게 일반 백업과 다르지 않습니다. 사용자 편의에 맞게 새 작업을 클릭하여 직접 스크립트를 추가해도 되고, 사용자 편의데로 하면 됩니다.

  아래의 방법으로 하면 자동으로 스크립트가 생성되면서 새작업을 만드는 것과 똑같이 됩니다.

- 스케줄러의 고급탭에 성공한 경우 동작을 '다음 단계로 이동' 으로 꼭 바꿔주셔야 합니다.

Step 2 - 백업 파일을 복원

- 스케줄러에 단계를 추가하여 복원 스크립트를 넣습니다. 복원 위치는 기존의 MDF, LDF 파일의 위치가 겹치지 않도록 (I/O 성능 / 이름 겹치는 것 방지) 

  하는 것이 좋을 것으로 보입니다.

RESTORE DATABASE [Restore_Test]  FROM DISK ='D:\MSSQL_BACKUP\WorkDB.bak'
WITH MOVE 'WorkDB' TO 'D:\MSSQL_DATA\WorkDB.mdf',
MOVE  'WorkDB_log' TO 'D:\MSSQL_DATA\WorkDB_log.ldf'
GO

- 위의 구문을 사용자의 환경에 맞게 수정 한 뒤에 스케줄러의 다음 단계에 넣습니다.

Step 3 - CHECK DB

- 마지막으로 복원된 Database를 CHECKDB를 이용하여 문제가 없는지 확인 하는 단계 입니다.

DBCC CHECKDB(Restore_Test)

- 위의 구문을 사용자가 복원하고자 하는 DB의 명칭으로 변경하여 마지막 단계에 넣습니다.

최종적으로 3개의 단계가 생성 됩니다. 

스케줄러를 실행하여, 작업이 정상적으로 이루어지는 확인을 해보면 정상적으로 이루어 지는 것을 볼 수 있습니다.

이러한 작업은 자동으로 일정을 등록하여, 새벽 시간에 자동으로 복원하여 CHECKDB를 하는 작업을 할 수 있습니다. 

결론...

복원은 무조건 된다고 생각 했습니다. 백업만 하면 복원에는 전혀 문제가 없다고 생각하였는데 큰 착각이였습니다. DB상에서 백업시 문제가 될수도 있고

언제 잘못 될지 알수 없습니다. 하여, 복원작업을 수시로 하여 백업에 전혀 문제가 없는지 확인하며, 신경써야 합니다.

참조 

http://solutioncenter.apexsql.com/verifying-sql-database-backups-automatically/

https://www.mssqltips.com/sqlservertutorial/113/checking-to-make-sure-a-sql-server-backup-is-useable/

https://msdn.microsoft.com/ko-kr/library/ms188902(v=sql.120).aspx

http://www.dbguide.net/db.db?cmd=view&boardUid=13832&boardConfigUid=9&categoryUid=216&boardIdx=73&boardStep=1