MSSQL은 여러 백업 방법을 제공하고 이를 활용하여 적절한 백업 및 복원 전략을 세워보자.
백업 옵션에는 다음과 같이 여러 가지가 있다.
보통 1, 2, 3, 4 정도만 알아도 DB 운영에는 문제가 없어보인다.
1. full backup : 데이터베이스를 구성하는 모든 데이터 파일을 백업하고 백업이 진행되는 동안 기록된 트랜잭션 로그를 백업한다.
2. differential backup : 가장 마지막 전체 백업 이후에 변경된 데이터만을 백업한다.
(MSSQL은 내부적으로 풀백업 이후 변경된 데이터를 관리한다.)
3. transaction log backup : 트랜잭션 로그 파일을 백업하고 로그를 지운다.
4. tail-log backup : 현재 활성화된 로그, 즉 백업되지 않는 트랜잭션 로그를 백업한다.
5. file and file group backup : 특정 파일 또는 파일 그룹에 포함된 데이터 파일만을 백업한다. 복잡해서 많이 사용되지는 않는다.
6. partial backup : 파일 그룹 중에서 primary 파일 그룹과 읽기/쓰기 속성의 파일그룹, 그리고 명시적으로 지정된 읽기 전용의 파일 그룹만을 백업한다.
-데이터베이스가 읽기 전용 파일 그룹과 읽기와 쓰기가 가능한 파일 그룹이 있다면 전자는 자주 백업할 필요가 없다. partial backup은 파일 그룹 중에서 primary 파일 그룹과 읽기/쓰기가 가능한 파일 그룹을 백업한다. primary 파일 그룹만으로 구성된 DB는 partial backup이 의미가 없고, 또한 명시적으로 지정한 읽기 전용 파일그룹도 백업에 포함하여 백업할 수 있다.
7. copy only backup : 기존 백업의 흐름에 영향을 주지 않고 임시용으로 백업한다. 즉, 복사 전용 전체 백업은 이후의 differential backup에 영향을 주지 않으며, copy only backup은 이후의 로그 백업에 영향을 주지 않는다.
- 일반 적인 백업은 백업 시퀀스에 영향을 줘서 전체적인 복원 시나리오에 영향을 미친다. 하지만 copy only backup은 기존의 백업 시퀀스와 독립적으로 작용해서 특별한 용도로 백업을 수행해서 데이터 및 프로시저를 복원하는데 유용하게 사용할 수 있다. 풀백업하는데 소요되는 시간이 별로 안된다면 백업 시퀀스는 별거 아니겠지만 그게 아니라면 상당히 까다로울 수 있다.
시나리오...
∎매일 전체 백업
일월화수목금토 00시 - full backup
적합한 곳
1. 크기가 작은 데이터베이스
2. 개발이나 테스트용 데이터베이스
3. 데이터 변경이 거의 발생하지 않는 데이터베이스
4. 읽기 전용 데이터베이스
5. 단순 복구 모델 데이터베이스
6. 복구 시 데이터 유실이 크게 문제되지 않는 데이터베이스
7. 특정 시점 복원이 요구되지 않는 데이터베이스
※ 전체 복구 모델이나 대량 로그 복구 모델 데이터베이스에 데이터 변경이 많이 발생한다면 정기적으로 트랜잭션 로그를 지워주는 전략을 같이 수립해야한다.
∎전체 백업 + 차등 백업
일요일 00시 - full backup
월화수목금토 00시 - differential backup
적합한 곳
1. 데이터베이스 크기가 커서 매일 전체 백업이 부담스러울 때
2. 단순 복구모델 데이터베이스
3. 특정 시점이 복구 안되도 상관 없는 데이터베이스
4. 복구 시 데이터 유실에 크게 상관없는 데이터베이스
※ 이 역시 전체 복구 모델이나 대량 로그 복구 모델 데이터베이스에 데이터 변경이 많이 발생한다면 정기적으로 트랜잭션 로그를 지워주는 전략을 같이 수립해야한다.
∎전체 백업 + 트랜잭션 로그 백업
일월화수목금토 00시 - full backup
일월화수목금토 06시, 12시, 18시 - transaction log backup
적합한 곳
1. 데이터베이스 크기가 커서 매일 전체 백업이 부담스러울 때
2. 데이터 변경이 많이 발생하여 트랜잭션 로그가 많이 쌓이는 데이터베이스
3. 특정 시점의 복원이 요구되는 데이터베이스
※ 트랜잭션 로그 백업은 기본적으로 트랜잭션 로그를 지워주므로 트랜잭션 로그 파일이 계속해서 증가하는 문제 해결. 특정 시점으로 복원할 수 있는 장점이 있어서 일반적으로 가장 많이 사용되는 백업 전략.
∎전체 백업 + 차등백업 + 트랜잭션 로그 백업
일 00시 - full backup
일 12시 - transaction log backup
월화수목금토 00시 - differential backup
월화수목금토 12시 - transaction log backup
적합한 곳
1. 데이터베이스 크기가 커서 매일 전체 백업이 부담스러울 때
2. 데이터 변경이 많이 발생하여 트랜잭션 로그가 많이 쌓이는 데이터베이스
3. 특정 시점의 복원이 요구되는 데이터베이스
4. 데이터베이스 복원 과정을 단순하게 가져가고 싶을 때
※ 차등 백업이 있을 때는 데이터베이스를 복원할 때 전체백업과 차등 백업 사이의 로그 백업을 복원할 필요가 없다. 그래서 좀 더 수월하다.
복구 모델(Recovery Model)
복구모델은 단순 < 대량로그 < 전체가 있으며 부등호 방향은 복원가능한 정도를 뜻한다.
∎전체(full)
전체 복구 모델을 선택하면 모든 데이터 변경에 대한 로그를 트랜잭션 로그 파일에 기록한다. 하지만 많은 로그가 쌓여서 정기적으로 트랜잭션 로그를 백업해서 로그를 지워야 한다.
∎대량 로그(bulk-logged)
데이터 변경 작업 중에서 BCP, BULK INSERT, INSERT INTO... SELECT와 같은 작업을 대량 로그 작업이라고 하고 CREATE INDEX, ALTER INDEX REBUILD와 같은 작업을 대 로그 인덱스 작업이라고 한다.
복구 모델을 전체로 하면 엄청난 로그를 남겨 작업이 느리므로 복구 모델을 대량 로그 복구 모델로 설정하면 대량 로그 작업으로 발생하는 트랜잭션 로그를 최소화한다. 하지만 특정 시점으로 복원할 수 없는 단점이 존재한다. 요즘은 디스크 성능이 좋아져서 대량 로그 복구 모델을 많이 사용하지는 않는다.
∎단순(simple)
트랜잭션 로그는 전체 복구 모델이나 대량 로그 복구 모델일 때는 백업해야 지워지지만, 단순 복구 모델이면 트랜잭션이 완료되면 자동으로 지워진다. 그래서 트랜잭션 로그 파일이 무작정 커지는 문제는 거의 발생하지 않는다고 보면된다. 하지만 트랜잭션 로그를 백업할 수 없어서 트랜잭션 로그를 사용한 다양한 복원 작업을 할 수 없다. 특정시점 복원이라던지.. 그래서 운영 데이터베이스에는 적합하지 않고 테스트용, 개발용 또는 읽기 전용의 데이터베이스에 대한 복구 모델로 적합하다.
-- 데이터베이스 복구 모델 변경
ALTER DATABASE TESTDB01
SET RECOVERY FULL --전체
GO
ALTER DATABASE TESTDB02
SET RECOVERY SIMPLE --단순
GO
ALTER DATABASE TESTDB03
SET RECOVERY BULK_LOGGED --대량 로그
GO
데이터베이스 백업 방법
--전체백업
BACKUP DATABASE TESTDB01
TO DISK = 'F:\SQLBackup\TESTDB01_20170703_FULL.bak'
WITH NAME = N'TESTDB01- 전체 백업', COMPRESSION, STATS = 10
GO
NAME 옵션을 사용해서 백업에 대한 정보를 백업 파일의 헤더에 기록하고 STATS = 10을 지정해서 백업 진행 상황을 SSMS 쿼리 창에서 10% 간격으로 표시한다. 뭐 얼마나 걸리겠어?하며 사용하지 않는 경우가 많은데 이 옵션은 무조건 사용하자.
--차등 백업
BACKUP DATABASE TESTDB01
TO DISK = 'F:\SQLBackup\TESTDB01_20170703_DIFF.bak'
WITH NAME = N'TESTDB01- 차등 백업',
DIFFERENTIAL, COMPRESSION, STATS = 10
GO
--트랜잭션 로그 백업
BACKUP LOG TESTDB01
TO DISK = 'F:\SQLBackup\TESTDB01_20170703_LOG.trn'
WITH NAME = N'TESTDB01- 트랜잭션 로그 백업', COMPRESSION, STATS = 10
GO
댓글 없음:
댓글 쓰기