1

SQL Server 2012에서의 백업, 복원 및

DRA를 활용한 복원

(복원을 품은 백업)

2

강사소개

• 신대경

• dkshin@adconsulting.co.kr

• 현) ㈜에이디컨설팅

• 전) ㈜엑셈

• 전) ㈜예스이십사

3

• SQL Server 버전 별 백업 신기능 소개 – 2012의 새로운 기능 DRA (Database Recovery Advisor) – 2008의 새로운 기능 – 2005의 새로운 기능

• 복구 모델 • 백업

– 비상 로그 백업 – 백업 관련 유용한 팁 – 백업 권고 사항

• 복원 – 복원 단계 – 파일 즉시 초기화 – 복원 종류 – 특정 지점으로 복원 – 복원 관련 유용한 구문 – 다른 서버로의 복원 팁

• 일반적인 백업 복원 예 • 부분 백업, 증분 복원 • 요약

목차

4

이건 뭘까요?

5

불편한 진실 ???!!!

• 백업 전략은 있지만, 복원 전략은 없다 – 백업의 주된 목적 : 데이터베이스 손상 시 백업을 복원하여 데이터베

이스를 복구할 수 있도록 하기 위함 – 백업 전략 수립 시 복원 전략을 고려하지 않음

• 백업을 수행하기는 하지만, 복원 테스트는 하지 않는다 – 복원이 필요한 시점에서야 복원 방법을 모색함

• 백업을 수행하기는 하지만, 정작 필요할 때 백업으로 복구할 수 없는 경우가 발생한다 – 믿기 어렵겠지만, 실제로 다양한 이유에 의해 발생함

• 백업을 수행하기는 하지만, 백업 정책이 적합하지 않다 – 트랜잭션 로그 파일의 비정상적인 자동 확장으로 서비스 장애가 발

생하거나, 백업본의 관리 또는 복원에 어려움이 발생할 수 있음

• 백업의 다양한 기능에 대한 이해 부족으로 비효율적인 백업 정책을 고수(?)하고 있다.

6

SQL Server 버전 별

신기능 소개

7

SQL Server 2012에서의 신기능

• DRA(Database Recovery Advisor)

• Windows Azure Platform으로 스냅샷 백업 지원

8

DRA(Database Recovery Advisor)

• 데이터베이스 백업 기록과 사용자들의 데이터베이스 복구 가능 시점을 나타내는 시각적 타임라인 제공

• 데이터베이스를 특정 시간으로 되돌리기 위해 최적의 백업 미디어 집합을 파악하는 작업을 간소화하는 알고리즘 적용

• 페이지 수준의 데이터베이스 백업을 수행하기 위한 SSMS 내 페이지 복구 대화상자 제공

9

DRA(Database Recovery Advisor) (1)

• 데이터베이스 -> 태스크 -> 복원 -> 데이터베이스

• 복원 가능한 백업 세트 보여줌

• 해당 복원 세트로 복원 가능한 시간을 보여줌

10

DRA(Database Recovery Advisor) (2)

• 특정 시간 설정 기능

• 필요한 경우 비상 로그 백업 자동 수행

11

DRA(Database Recovery Advisor) (3)

• 비상 로그 백업이 자동으로 추가된 모습

12

DRA(Database Recovery Advisor) (4)

• 단일 사용자 모드 설정

• 비상 로그 백업 정보 확인

• 기존과 동일한 복원 옵션 사용 가능

13

DRA(Database Recovery Advisor) (5)

• 데이터베이스 -> 태스크 -> 복원 -> 페이지

• 손상된 페이지가 있는 경우 자동으로 표시해 줌

14

Windows Azure Platform으로 스냅샷 백업 지원

• SSMS에서 SQL Server 데이터베이스 사본을 Windows Azure Storage로 손쉽게 이동시키거나 SQL Azure Database로 직접 이동시킬 수 있음

• 온-프레미스 SQL 서버 데이터베이스용 클라우드 기반 스토리지 솔루션을 제공함

• SSMS에서 SQL Azure 데이터베이스 정보를 확인할 수 있음

15

DRA 데모

16

SQL Server 2008에서의 신기능

• 백업 압축

• 백업 압축과 TDE

17

백업 압축

• 백업 압축은 버전에 따라 지원되는 EDITION의 차이가 있음

– 2008 : Standard Edition은 지원하지 않으며 Enterprise Edition에서만 지원됨

– 2008 R2 : Standard Edition과 Enterprise Edition에서 모두 지원됨

• 백업 압축은 모든 Edition에서 복원할 수 있음

• 특징

– 백업 공간 감소

– 백업 및 복원 시간 단축

– I/O 자원 사용량 감소

– CPU 자원 사용량 증가

18

백업 압축 사례 – 국내 적용 사례

• 백업 압축 실행 시간 및 파일 크기 – 백업 압축 적용 전에 비해 백업 실행 시간이 각각 32%, 33% 단축됨

– 백업 파일 크기는 적용 전에 비해 66%, 69% 감소됨

• CPU 사용 – 백업 압축 수행 시 CPU 사용률이 약 8% 증가됨

– 서버 전체의 CPU 자원에 여유가 있으며, 전체 백업은 업무 부하가 작은 야간 시간대에 수행되므로 서비스에 영향을 미치지 않음

[사례 #1] 백업 압축 후 크기 66% 감소

[사례 #2] 백업 압축 후 크기 69% 감소

압축백업의 성능 개선 정도와 리소스사용 변화는 시스템 환경 및 데이터 성격에 따라 결과가 달라질

수 있음

19

백업 압축 사례 – 해외 적용 사례

*출처: 2010 Microsoft SQL Enterprise Architect Summit 자료

고객사 백업 압축 적용 후

공간 감소율 참고사항

NASDAQ 80%

Redprairie WMS 84% 백업 시간도 43% 단축됨

GE Healthcare 71% 환자 건강 기록 데이터베이스

SAP ERP 80%

Caregroup 85% 압축 전 백업 크기 = 110GB 압축 후 백업 크기 = 26GB

20

백업 압축과 TDE

• 암호화된 데이터는 압축률이 좋지 않음

• TDE 기능을 사용하는 DB 백업의 경우 압축되지 않은 백업 사용 권장

시스템 환경 및 데이터 성격에 따라 결과가 달라질 수 있음

21

SQL Server 2005에서의 신기능

• 부분 백업(Partial Backup) – 주 파일 그룹과 읽기/쓰기 파일 그룹만 백업

• 복사 전용 백업(Copy-only Backup) – 백업 전체에 영향을 주지 않는 특별한 용도의 백업

• 미러 백업(Mirror Backup) – 백업 복사본을 여러 개 생성하는 백업

• 데이터베이스 스냅숏(Database Snapshot) – 원본 데이터베이스의 읽기 전용의 정적인 뷰를 제공

22

복구모델

• 복구 모델의 구분

– 트랜잭션 로그의 유지 관리 제어 방식의 차이

• 복구 모델 종류

– 전체(FULL)

– 대량 로그 (BULK_LOGGED)

– 단순(SIMPLE)

23

복구모델 - 전체

• 모든 트랜잭션을 전체 로깅

• 트랜잭션 로그가 백업될 때까지 유지

• 로그 백업을 하지 않으면 지속적으로 로그 파일이 증가

• 데이터 손실 가능성이 가장 적음

• 트랜잭션 로그를 이용하여 특정 시간, 트랜잭션으로 복구 가능

• Create Index 작업이 포함된 경우 복구 시간이 빠름 (인덱스 생성 작업을 다시 수행할 필요 없음)

24

복구모델 - 대량로그

• 전체 복구 모델과 동일하게 작동하지만 대량 복사 작업에 대해서는 최소 로깅

• 최소 로깅 가능한 대량 로그 작업

– BULK INSERT, SELECT … INTO, BCP 등

• 수행 사실 및 공간 할당 정보만 기록

• BCM(Bulk Changed Map)

– 마지막 로그 백업 이후로 최소 로깅된 대량 작업에 의해 변경된 익스텐트를 기록

– 로그 백업 수행 후 모든 bit를 0으로 변경

• 대량 작업이 없으면 지정된 시간으로 복구 가능

25

복구모델 - 단순

• 완료된 트랜잭션에 대한 트랜잭션 로그 폐기

• 체크포인트가 발생할 때마다 로그를 비움

• 데이터베이스가 손상될 경우 상당한 작업이 손실될 가능성 있음

– 마지막 백업 이후에 변경된 내용은 보호되지 않음

• 로그 백업이 필요하지 않음

• 일반적으로 운영 데이터베이스에 대해서는 “전체” 또는 “대량 로그” 복구 모델을 설정하는 것이 적절

– “단순” 복구 모델은 전체 백업 이후에 발생된 데이터를 복원할 필요성이 없는 테스트 데이터베이스와 같은 경우에 적합

26

복구모델 - 요약

복구 모델 장 점 데이터 손실 지정 시간으로 복원

전 체

모든 트랜잭션을 로그에 기록. 가장 안전한 상태 유지.

손상 시점까지 복원 가능. 로그 파일 손상 시 최근 백업된 이후 손실.

지정 시간으로 복원 가능.

대량 로그 대량 로그 작업 시 성능 향상.

손상 시점까지 복원 가능. 대량 로그된 변경 내용이 백업되지 않은 경우 최근 백업된 이후 손실.

로그 백업에 대량 로그된 변경 내용이 있는 경우 불가.

단 순

대량 로그 작업 시 성능 향상. 로그 파일 크기를 최소로 유지.

최근에 백업된 이후 손실.

지정 시간으로 복원 불가.

27

복구모델에 대한 오해와 진실

• 단순 복구모델

– 단순 복구모델은 로깅을 하지 않는다 • 로깅을 한다. 하지만, 트랜잭션이 완료되면 해당 트랜잭션 로그를

폐기한다

– 트랜잭션 로그 파일은 매우 작아도 된다 • 완료되지 않은 트랜잭션에 대한 트랜잭션 로그는 삭제되지 않는

다. 그러므로, 대량 트랜잭션이 발생하는 경우가 있다면 그에 맞게 로그 파일 크기를 크게 고려해야 한다

• 단순에서 전체 혹은 대량 로그로 변경한 경우

– 로그 관리가 저절로 된다 • 그렇지 않다. 전체 백업을 수행하지 않으면 트랜잭션 로그를 관리

하지 않는다

28

백업 일반 사항 (1)

• 무엇을 백업할 것인가? – 사용자 데이터베이스

– 시스템 데이터베이스

이름 설명 백업 필요 여부

Master 인스턴스에 대한 모든 시스템 수준 정보 저장 필요

Msdb 에이전트에서 사용하는 작업 정보 저장 필요

Model 데이터베이스 생성 템플릿 필요

Distribution 복제 배포자로 구성된 경우 사용 필요

Resource 시스템 개체 정보를 저장하는 읽기 전용 데이터베이스

불가능 (파일복사만 가능)

Tempdb 임시 개체나 중간 결과 집합을 저장하기 위한 작업 영역

불필요

29

백업 일반 사항 (2)

• 백업의 종류

백업 종류 설명

전체 백업 전체 데이터베이스 백업

차등 백업 마지막 전체 백업 이후에 변경된 데이터 분에 대한 백업

부분 백업 주 파일 그룹, 모든 읽기/쓰기 파일 그룹 및 필요에 따라 지정된 읽기 전용 파일 그룹에 있는 모든 데이터의 백업

파일 백업 데이터베이스의 파일이나 파일 그룹을 개별적으로 백업

트랜잭션 로그 백업 트랜잭션 로그에 대한 백업

복사 전용 백업 백업 시퀀스에 영향을 주지 않으면서 백업하고자 하는 경우 사용하는 방식

30

백업 일반 사항 (3)

• 언제 백업할 것인가 ? – 사용자 데이터베이스 : 정책에 따라

– 시스템 데이터베이스

이름 백업 시기

Master

- 데이터베이스 생성, 삭제 - 서버 또는 데이터베이스 구성 값 변경 - 로그인 계정 추가, 수정, 삭제 - 기타 master 데이터베이스 변경이 일어나는 작업 후

Msdb - 에이전트 일정 추가, 수정, 삭제 - 기타 msdb 데이터베이스 변경이 일어나는 작업 후

Model - Model 데이터베이스 변경이 일어나는 작업 후

Resource

- 서비스 팩 설치 등의 작업을 앞두고 이전 버전의 파일을 복사하여 백업 - mssqlsystemresource.mdf, mssqlsystemresource.ldf 파일을 운영 체제에서 복사 방식으로 백업

31

비상 로그 백업

• 일반적으로 데이터베이스를 복원하기 전에 비상 로그 백업을 수행 – 작업 손실을 방지하고 로그 체인을 그대로 유지

• 데이터베이스를 실패 지점으로 복구할 때는 비상 로그 백업이 복구 계획의 마지막 백업

• 비상 로그 백업이 불필요한 경우 – 복구 지점이 이전 로그 백업에 포함된 경우 – 데이터베이스를 이동 또는 교체(덮어쓰기)하는 중인 경우 – 최신 백업 이후의 시점으로 이를 복원할 필요가 없을 경우

• 비상 로그 백업 수행 방법 – 데이터베이스가 온라인인 경우, 복원 시작 전에 수행

– 데이터베이스가 오프라인이고, 데이터베이스가 손상된 경우

BACKUP LOG database_name TO <backup_device> WITH NORECOVERY

BACKUP LOG database_name

TO <backup_device> [WITH { CONTINUE_AFTER_ERROR | NO_TRUNCATE }]

32

잘못된 사례

• 트랜잭션 로그 파일 백업, 관리

– 시스템 오픈 이후에 주기적인 로그 백업을 수행하지 않아서 로그 파일의 크기가 지속적으로 확장되어 디스크 공간이 가득 차게 됨 데이터베이스의 데이터 변경이 중단되는 장애 발생

– 자동 증가 속성으로 인해 가상 로그 파일 개수가 많아져 복구 시간이 길어짐

• 백업 파일의 위치

– mdf, ldf 파일과 동일한 디스크에 위치 디스크 손상으로 인해 데이터베이스 파일 손상 시 백업 파일도 함께 손상되므로, 백업 파일을 사용하여 데이터베이스를 복구할 수 없음

33

백업에 활용 할 수 있는 유용한 팁

• 분할 파일 백업

• 미러 백업

34

분할 파일 백업(Split File Backup)

• 백업을 여러 파일로 분할하는 기능

• 별도의 백업 파일이 서로 다른 디스크 상에 병렬로 작성되므로 단일 파일 백업보다 빠르게 실행될 수 있음

• 예) 전체 데이터베이스 크기 : 90GB

디스크 여유 공간 : D(50GB), E(50GB), F(40GB)

BACKUP DATABASE AdventureWorks

TO DISK = ‘D:\Backup\MultiFile\AdventureWorks1.bak',

DISK = ‘E:\Backup\MultiFile\AdventureWorks2.bak',

DISK = ‘F:\Backup\MultiFile\AdventureWorks3.bak'

GO

35

미러 백업(Mirror Backup)

• 백업 복사본을 여러 개(2 ~ 4개) 생성하는 백업

• 백업 세트나 백업 파일 손상을 대비할 수 있음

BACKUP DATABASE AdventureWorks

TO DISK = 'C:\Backup\MultiFile\AdventureWorks1.bak',

DISK = ‘D:\Backup\MultiFile\AdventureWorks2.bak',

DISK = ‘E:\Backup\MultiFile\AdventureWorks3.bak'

MIRROR TO

DISK = ‘F:\Backup\MirrorFile\AdventureWorks1.bak',

DISK = ‘G:\Backup\MirrorFile\AdventureWorks2.bak',

DISK = ‘H:\Backup\MirrorFile\AdventureWorks3.bak'

WITH FORMAT

GO

36

백업 권고 사항

• 백업 파일은 물리적으로 별도의 디스크에 저장할 것을 권고함

• 주기적인 트랜잭션 로그 파일 백업을 권고함

• 백업 파일에 대한 복원 테스트를 실시하여 검증할 것을 권고함

– 복원 테스트를 자주 할 수 없을 경우 백업 후 RESTORE VERIFYONLY 문 옵션 활용

• 정기적인 데이터베이스 백업 체계 수립을 권고함

37

복원의 사전적 의미

• 復元 [ 복원 ] 부서지거나 없어진 사물(事物)을 원래(原來)의 모습이나 상태(狀態)로 되돌려 놓는 것

• [IT용어]변경된 기기의 상태, 기억 장치나 레지스터의 내용을 원상태로 돌려놓는 작업

시간을 거슬러~~~

38

복원 단계

• 파일 생성 및 초기화 – 기존 데이터베이스가 존재하면 이 단계는 건너뜀 – 파일 생성 후 0으로 초기화 작업 수행 – 별도 계정에 권한 부여하면 파일 즉시 초기화가 가능

• 데이터/트랜잭션 로그 복사 – 데이터베이스의 백업 미디어에서 모든 데이터 페이지, 로그 페

이지 , 인덱스 페이지를 데이터베이스 파일로 복사하는 작업

• REDO(롤 포워드) – 기록된 트랜잭션을 백업에서 복사한 데이터에 적용하여 데이

터를 복구 지점으로 롤 포워드 – 이 지점에서 데이터베이스는 일반적으로 커밋되지 않은 트랜

잭션을 가지며 사용할 수 없는 상태

• UNDO(롤백) – 커밋되지 않은 트랜잭션을 롤백하고 사용자가 데이터베이스를

사용할 수 있게 온라인 상태로 변경 – 롤백 단계 이후의 백업은 복원할 수 없음

39

즉시 파일 초기화

• 데이터 및 로그 파일 초기화

• 기본적으로는 0으로 초기화 작업 수행

• 즉시 파일 초기화는 사용된 디스크 공간을 0으로 채우지 않고 기존 데이터를 덮어 쓰는 방식으로 재사용함

• 설정 방법 – SQL Server 서비스 계정을 Windows 계정으로 설정

– 해당 Windows 계정에 Windows SE_MANAGE_VOLUME_NAME 특수 권한 할당

– 이 권한은 Administrators 그룹에 기본적으로 할당됨

– 볼륨 관리 작업 실행 보안 정책에 Windows 계정을 추가

• 로그 파일, TDE 적용 데이터베이스는 즉시 초기화 불가

40

복구 옵션

• WITH NORECOVERY

– UNDO 단계를 생략하여 커밋되지 않은 트랜잭션을 유지

– UNDO 단계를 생략하면 추가적인 다른 백업을 복원하여 데이터베이스를 더 많이 REDO(롤포워드)할 수 있음

– 데이터베이스는 복구 중 상태로 접근이 불가능

• WITH RECOVERY

– REDO 단계와 UNDO 단계를 모두 포함하여 데이터베이스가 복구되며 데이터베이스를 온라인 상태로 복원

– 추가 백업에 대한 복원은 진행할 수 없음 (기본값)

41

수준별 복원 종류

수준 복원 종류 설명

데이터베이스 전체 데이터베이스 복원

- 전체 데이터베이스의 복원 및 복구 - 복원 및 복구 작업 기간 동안 데이터베

이스는 오프라인 상태

데이터 파일 파일 복원 증분 복원

- 데이터 파일 또는 파일 그룹의 복원 및 복구

- 복원 기간 동안 해당 파일을 포함한 파일 그룹은 오프라인 상태

- 오프라인 파일 그룹에 액세스하면 오류 발생

데이터 페이지 페이지 복원

- 전체 및 대량 로그 복구 모델에서 개별 페이지 복원 가능

- 온라인 페이지 복원은 SQL Server 2005 Enterprise Edition 이상에서 가능

- 손상된 페이지는 msdb의 suspect_pages 테이블에서 조회 가능

42

특정 지점으로 복원

• 특정 시간으로 복원 – STOPAT 옵션을 사용하여 특정 시간으로 복원

• 표시된 트랜잭션으로 복구 – SQL Server에서는 트랜잭션 로그에 명명된 표시를 삽입

하여 특정 표시 위치로 복구가 가능 • 트랜잭션 표시

• 표시 위치로 복구

• LSN(로그 시퀀스 번호)으로 복구 – 트랜잭션 로그의 모든 레코드는 LSN으로 고유하게 식별

되며 LSN은 변경이 발생한 순서에 따라 번호가 매겨짐

RESTORE LOG … WITH STOPAT = 'Apr 15, 2020 12:00 AM';

BEGIN TRANSACTION Tx1 WITH MARK 'description';

RESTORE LOG … WITH STOPATMARK = ‘Tx1';

RESTORE LOG … WITH STOPATMARK = 'lsn:<lsn_number>‘;

43

복원 관련 유용한 구문

• RESTORE FILELISTONLY

– 백업 세트에 포함된 데이터베이스와 로그 파일의 목록을 포함하는 결과 집합을 반환

• RESTORE HEADERONLY

– 특정 백업 장치의 모든 백업 세트에 대한 백업 헤더 정보를 모두 포함하는 결과 집합을 반환

• RESTORE VERIFYONLY

– 백업 파일을 확인, 복원하지는 않음

– 백업 세트의 완성 여부와 전체 백업을 읽을 수 있는지를 확인

44

다른 서버로의 복원 팁

• 백업 파일을 다른 서버에 복원하는 경우

– 로그인과 사용자의 매핑 확인

– 매핑되어 있지 않은 경우, 매핑 작업 수행

• SQL Server 2012인 경우 Contained Database 활용 시 로그인과 사용자 매핑이 필요하지 않음

USE AdventureWorks2008R2;

GO

EXEC sp_change_users_login 'Report'

EXEC sp_change_users_login 'Update_One', 'User1', 'Login1';

45

일반적인 백업 및 복원 예 (1)

일요일 월요일 화요일 수요일 목요일 금요일 토요일

트랜잭션 로그 백업

전체 백업 차등 백업 차등 백업

46

일반적인 백업 및 복원 예 (2)

일요일 월요일 화요일 수요일 목요일 금요일 토요일

4. 트랜잭션 로그 복원

2. 전체 백업 복원 3. 차등 백업 복원

1. 비상 로그 백업

5. 비상 로그 복원

47

부분 백업, 증분 복원

• 대용량 데이터베이스에 적용 가능

Big Database

Primary

Filegroup1 (ReadOnly)

Filegroup2 (ReadOnly)

Filegroup3

• 백업 전략

Primary를 포함한

READ_WRITE Filegroup 백업

Filegroup1 백업

Filegroup2 백업

주기적인 트랜잭션 로그 백업

• 복원 전략

Primary를 포함한

READ_WRITE Filegroup 복원

Filegroup1 복원

Filegroup2 복원

순차적인 트랜잭션 로그 복원

비상로그 백업 복원

비상로그백업수행

48

데모

• 전체 백업 후 증분 복원

• 부분 백업 후 증분 복원

49

백업, 복원 프로세스

1. 백업 정책 수립 2. 백업 정의, 일정 수립

5. 복원 테스트 및 복원 전략 수립

3. 백업 수행, 모니터링 4. 백업 파일 검증

0. 복구 모델 결정

- 전체 - 대량로그 - 단순

50

요약

• 백업도 설계가 필요하다 – 시스템 특성과 리소스 현황에 적합한 백업 전략 설계 필요 – 데이터베이스 현황, 사용 패턴, 하드웨어, 백업 미디어 등을 고려한

최적의 전략 수립 필요

• 백업과 복원은 일심동체이다 – 백업 전략과 더불어 복원 전략도 함께 수립

• 백업을 받는 것이 백업의 끝이 아니다 – 백업 파일에 대한 유효성 검사 필요 – 민방위 훈련하듯이, 복원 전략에 기반한 복원 테스트 필요 사용하

고자 하는 모든 유형의 백업에 대해서 테스트 !!!

• 백업이 필요할 때 백업의 진가를 발휘할 수 있어야 한다 – 데이터베이스와 백업은 서로 다른 장치에 배치 – 시스템의 요건에 부합하는 복원 절차가 가능하도록 백업 설계

• 백업에 대한 보안도 고려해야 한다 • 시스템 환경은 변화한다. 시스템 여건의 변화에 맞추어 백업

및 복원 전략도 진화해야 한다

51