안녕하세요. SQLER의 코난 김대우입니다. 
이번 강좌에서는, 13-2. 백업과 복원 - 백업과 복원 전략을 진행 하겠습니다.

SQLER에서 진행되는, 챗GPT와 함께 배우는 SQL Server 강좌 목록

이번에 진행할 강좌는 백업과 복원 - 백업과 복원 전략입니다.

TL;DR

전체 백업, 로그 백업, 차등 백업 시나리오와 장단점을 설명합니다. 세 가지 복원 전략을 비교하여 데이터베이스의 특성에 따라 적절한 전략을 선택하는 방법을 소개합니다.

백업과 복원 전략

이제 백업과 복원의 중요한 전략을 수립해야 합니다. 전체 백업 / 로그 백업 / 차등 백업에 대해서 살펴보겠습니다.

1. 전체 백업만 진행할 경우

먼저 이러한 타임라인을 생각해 보세요. 주단위 타임라인이며, 월요일 / 화요일 / ...  패턴입니다. 시간은 08시부터 24시간이 표시되어 있습니다.

전체 백업만 하루에 한 번 진행하면 어떻게 될까요? 

전체 백업은 매일 아침 08시 업무가 시작되기 전에 진행됩니다. 이렇게 전체 백업만 수행해 운영하는 분들이 대단히 많을 겁니다. 

자 그럼, 장애 상황을 가정해 보겠습니다.

1. 로그를 백업하지 않으므로 로그가 계속 증가하는 상황이 발생할 수 있다.

로그는 데이터의 변경 본입니다. 백업하면 비워지지만 지우지 않으므로 데이터는 50메가인데 로그는 1기가 이런 상황이 발생하며, 로그로 인해 시스템이 느려질 수 있습니다.

2. 장애 발생 시 복구 가능한 데이터가 가장 적다. 

실제 장애 상황을 가정하겠습니다.

자 이렇게 12시 30분에 하드웨어 장애로 데이터베이스가 깨졌다고 가정해 봅시다.(비상 로그 백업 불가 상황)

언제까지 데이터로 복구가 가능할까요? 가장 최근의 전체 백업본이 월요일 08시이니, 기본적으로 월요일 08시의 데이터로만 복구 가능합니다. 물론 한 번도 전체 백업을 한 적이 없다면 복구 불가 합니다. 

08시부터 4시간 30분간의 데이터는 복구가 불가해지는 겁니다. 아득한 상황이지요.

이런 조치는 어떨까요? - "그렇다면 풀백업을 한 시간에 하나씩 받으면 어떨까요?"
좋은 아이디어이지만 맹점이 있습니다. 

전체 백업 작업을 온라인상에서 백업을 진행해도 큰 무리 없이 처리 가능하지만, 대부분 데이터의 용량은 크기가 대단히 큽니다. 데이터가 수기가 또는 수백 기가를 훌쩍 넘기도 합니다. 만약 한 시간에 한 번씩 전체 백업을 한다면? 대단히 많은 부하가 걸려 백업만 하다가 시스템 리소스를 다 소진할 수도 있습니다. 

만약, 대단히 적은 데이터이지만, 매우 빈번하게 수정되고, 전체 데이터는 적게 유지되는 경우(주식 상황판 업데이트를 생각해 보세요) 이런 전체 백업 전략을 고려할 수 있지만, 아쉽게도 대부분의 경우, 전체 백업은 좋은 솔루션이 아닙니다.

다른 방법으로 풀백업 + 로그 백업의 방법이 있습니다.

2. 전체 백업과 로그 백업을 진행할 경우

이러한 백업 패턴을 생각해 보세요. 매일 아침 08시 전체 백업을 수행하고, 매 시간마다 로그를 백업하는 패턴입니다. 

로그를 백업해야 하기 때문에 당연히, SQL Server의 DB는 단순 복구 모델이 아닙니다. SQL서버의 데이터베이스가 단순 모델이면? 로그 백업이 불가합니다. 복구 모델이 전체 모델 또는 대량 로그(Bulk Load) 모델이어야 합니다. 

"저렇게 한 시간에 한 번씩 로그를 백업하는 것도 부하가 대단히 크지 않나요?"

라고 생각하실 수도 있지만, 로그는 그 크기가 대단히 작습니다. 예를 들어, 애플리케이션이나 웹사이트 게시판을 생각해 보세요. INSERT / UPDATE / DELETE 작업은 대단히 적은 비율이지만, 조회는 매우 빈번합니다. 즉, 로그 데이터가 적은 경우가 대부분입니다.

그럼, 장애 상황을 또 가정해 보겠습니다. 

이런 경우 언제까지 복구가 가능할까요? 

08시부터 12시 20분까지 이렇게 데이터 변경이 진행되었습니다.

08시 - 전체 백업본이 있습니다. 전체 백업본을 복원하면 데이터는 어떻게 될까요?

네 맞습니다. 위와 같이 08시 데이터가 살아납니다. 그러면, 우리는 여기까지만 복원이 가능한 걸까요? 아닙니다! 우리에겐 로그 백업본이 있습니다. 

09시의 로그 백업본을 복원하면?

네 맞습니다. 이렇게 데이터가 수정된 상태로 복원이 됩니다. 로그는 데이터의 변경입니다. 로그 백업을 적용시켜, 데이터 변경을 그대로 반영하면, 최종 데이터가 생성됩니다. 이 과정을 로그 데이터 REDO라고 부릅니다.

그렇다면, 여기서 문제입니다. 9시, 10시, 11시, 12시 로그를 잘 복원했습니다. 그렇지만, 12시 20분 데이터는 로그를 백업하지 못해 복원이 불가합니다. 만약, 전체 복구 모델이고 로그 백업이 가능하다면, 12시 20분은 물론, 장애 발생 직전 12시 29분까지 복구가 가능합니다. 하지만, 장애로 인해 로그가 깨져서 로그 백업이 불가하다면 가장 최근 로그 백업까지만 복원 가능합니다.

마지막으로, 차등 백업에 대해서 간략하게 알아보겠습니다.

3. 차등 백업(Differential backup)

앞에서 공부한 로그 백업의 범위는 이렇습니다.

정확히 마지막 로그 백업 이후 로그 데이터만 백업합니다. 즉, 09시의 로그 백업은 08시~09시 사이의 데이터 변경만 백업합니다. 

하지만 차등 백업은 이 범위가 약간 다릅니다.

차등백업은 가장 최근의 전체 백업본 이후 발생한 모든 변경을 백업합니다. 즉, 09시의 차등 백업본은 08시~09시까지 데이터 변경을 백업하며, 12시의 차등 백업본은 08시~12시까지 데이터 변경을 백업합니다. 약간 복구 속도를 높일 수 있는 장점이 있고, 전체 백업본과 가장 최근 차등 백업본 총 2개만 유지하면 되기 때문에 백업본 관리가 비교적 수월합니다.

차등 백업을 받고 있을 때 마찬가지로, 12시 30분에 데이터베이스가 장애 발생 상황을 가정해 보겠습니다. 차등 백업을 수행할 때에는 전체 백업본과 가장 최근 차등백업본을 복원합니다.

즉, 08시의 풀백업본을 리스토어 합니다. 이어서 12시의 차등 백업본 하나만 복원을 하면 가능한 모든 데이터가 복구됩니다.

백업과 복원 전략 정리

이렇게, 대표적인 세 가지 복원 전략을 차근차근 소개해 드렸습니다.

일반적인 조회가 매우 빈번하고, 데이터 변경이 적은 상황에서는 전체 백업 + 로그 백업 조합을 여러 장점이 있기 때문에 더 선호합니다. 데이터는 적으나 변경이 매우 빈번하다면 전체 백업과 차등 백업을 고려할 수도 있으며, 운영하는 서비스의 데이터 패턴에 따라 적합한 방식의 백업 전략을 수립하시길 바랍니다.

다음 강좌에서는 실제 쿼리로 백업과 복원 전략을 실행하겠습니다.
 

SQL 강좌 책 구매

강좌가 도움이 되셨다면, 책으로 구매 가능합니다. 책 판매 수익금은 전액 코딩 교육 사회공헌 활동에 기부되며, 아래 링크에서 구매하시면 더 많은 금액이 기부됩니다. 

책구매 링크: 챗GPT와 함께하는 마이크로소프트 SQL Server 2022