주기적인 데이터베이스 백업이 필수인 이유
백업 다들 잘하고 계신가요? 서비스를 할 때 서비스 그 자체만큼이나 중요한 게 바로 백업입니다. 백업의 중요성에 대해서는 모르는 분이 없겠지만, 막상 꼼꼼히 제대로 하는 경우는 많지 않습니다.
백업이라 하면 크게 파일 백업과 데이터베이스 백업으로 나뉘는데 본 글에서는 '데이터베이스 백업'만을 다루도록 하겠습니다. 파일 백업에 대해서는 차후 별도의 글을 올리겠습니다.
이하 '백업'은 '데이터베이스 백업'을 의미하며, 특히 'Microsoft SQL Server'로 한정.
데이터의 주기적인 백업이 필수인 이유는 명확합니다. 백업에 전혀 신경을 쓰지 않거나 대충 하고 있다고 가정해보겠습니다. 디스크가 손상되거나, 바이러스 등으로 데이터의 무결성이 깨지거나, 실수나 고의로 대량의 데이터를 지우거나 수정하는 등 수년간 쌓은 데이터가 날아가거나 돌이킬 수 없을 만큼 변경된다면, 하루아침에 서비스를 접는 것 외에 다른 방법이 없습니다. 서비스 특성상 그냥 서비스를 접는 게 문제가 아니라 손해배상을 해야 하는 경우도 있습니다.
백업은 당연히 필수 요소이며, 제대로 백업을 하고 있다면 반드시 아래 조건을 충족해야 합니다.
삭제되거나 변경된 데이터의 단순 복구는 기본이며, 필요시 치명적인 문제가 발생하기 바로 직전, 즉 내가 원하는 그 어떠한 특정 시점으로도 복구가 가능해야 한다.
내가 원하는 특정 시점으로의 복구가 데이터베이스 백업의 진짜 이유이며 이에 맞게 전략을 잘 짜야합니다.
가장 먼저 확인해야 할 기본 사항
백업 종류 설명에 앞서 먼저 짚고 넘어가야 할 부분이 있습니다. 백업은 반드시 해당 데이터베이스 서버와 '물리적으로' 다른 공간에 해야 한다는 사실입니다. 이 역시 당연한 얘기지만 귀찮거나 괜찮겠거니 하는 안일함으로 같은 서버에만 저장해놓는 경우가 허다합니다. 같은 서버에 저장하는건 백업하면 자연스레 되는거니 그냥 놔두고 (주기적으로 오래된 파일 정리는 기본), 최소 하나의 다른 공간에도 복사를 해야 합니다.
전자제품인 서버는 소모품에 불과하기 때문에 언제 어디서든 이유 없이 망가질 수 있다고 늘 가정해야 합니다. 해당 서버가 있는 장소에 불이 나거나 물난리가 나는 등의 상황도 있기 때문에, 물리적으로 '그냥 다른 서버'가 아니라 아예 충분히 멀리 떨어진 '전혀 다른 공간'에 백업을 해야 합니다. Amazon Web Service나 Google Cloud Plaform 등 클라우드에 저장하는 걸 권장합니다.
주요 백업 종류 세 가지
백업 종류는 생각보다 많습니다. Microsoft 공식문서에서 모든 백업 유형에 대한 설명이 있으니 참조 바랍니다.
본 글에서는 가장 주요하게 사용되며 반드시 알아야 할 세 가지 백업에 대해 다루겠습니다. 대부분 잘 알고 있다고 생각하지만 그렇지 않은 경우가 많습니다. 핵심 사항에 대해 대충만 알고 있게 되면 엉뚱한 백업 전략을 행하게 되기 때문에 꼼꼼히 알아야 합니다. 엉뚱한 전략을 행하게 되면 막상 필요시 원하는 상태로 복원하지 못하게 되거나, 백업 파일이나 데이터베이스 파일 사이즈가 지나치게 커지는 최후를 맞이하게 됩니다.
1. 전체 백업(Full Backup)
용어 그대로 데이터베이스의 모든 것을 백업합니다. 즉, 테이블, 인덱스, 프로시져, 함수, 뷰 등 해당 데이터베이스 관련 모든 것을 하나도 빠짐없이 저장합니다.
모든 백업의 근원이 되는 백업이기 때문에 반드시 필요합니다. 전체 백업만 하는 건 가능해도, 전체 백업 없이 차등/로그 백업 등을 하는 것은 구조적으로 아예 불가능합니다.
2. 차등 백업(Differential Backup)
'가장 최근에 생성된 전체 백업'을 기준으로 모든 변경 사항을 누적해서 저장합니다.
'가장 최근에 생성된 차등 백업'을 기준으로 하지 않습니다. 백업을 할때마다 (이전에 했던 차등 백업을 완전 무시하고) 이전 전체 백업을 기준으로 비교해서 모든 변경 사항을 저장하기 때문에 백업 파일 사이즈가 계속해서 커집니다.
로그 백업과 혼동하는 경우가 있는데 둘은 전혀 다른 백업 방식입니다.
3. 로그 백업(Log Backup)
로그 백업은 대충 보면 단순해 보여도 그 특성에 대해 명확히 이해하지 못한다면 많은 불상사를 초래할 수 있는 묘한 친구입니다. 디스크를 꽉 채워서 데이터베이스 서비스를 불능 상태로 만들거나, 열심히 백업을 하긴 했는데 막상 복원해야 하는 시점에서 무용지물이 되거나 하는 등 생각보다 까다롭기 때문에 꼼꼼히 알아보겠습니다.
'최초의 전체 백업 혹은 바로 이전의 로그 백업'을 기준으로 이후 저장된 모든 트랜잭션 로그들을 저장합니다. 차등 백업과 다르게 기준 시점과 '비교'를 해서 그 차이를 저장하는 게 아니라 기준 시점 이후에 발생한 모든 트랜잭션 로그들을 계속해서 밑도 끝도 없이 저장하는 식입니다.
트랜잭션 로그 - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전.
ko.wikipedia.org
위 위키백과 링크를 통해 트랜잭션 로그의 자세한 설명과 구조를 확인하실 수 있습니다. 단순화해서 개념적으로 이해하자면 '데이터베이스 설정이나 데이터에 변경을 준 쿼리문의 집합체' 정도로 생각하면 될 거 같습니다.
전체 백업이나 차등 백업과 가장 크게 다른점은, 복원 시 내가 원하는 특정 시점(보통 원치 않은 중대한 데이터 변경이 있던 시점 바로 직전)으로 돌릴 수 있다는 점입니다. 서두에 언급했듯이 데이터베이스 백업의 진정한 이유이기도 하기 때문에 반드시 행해야 합니다.
로그 백업을 사용하기 위해서는, 복구 모델(Recovery Model)을 반드시 전체(Full) 혹은 대량 로그(Bulk logged)로 설정해야 합니다. 대량 로그(Bulk logged) 모델을 사용하는 명확한 이유가 없다면, 통상적으로 전체(Full)로 설정하면 무난합니다.
복구 모델을 이렇게 설정할 경우 주의할 점이 있는데, 복구 모델을 전체(Full) 혹은 대량 로그(Bulk logged)로 설정한 상태에서 로그 백업을 하지 않으면 로그 파일(.ldf)이 마냥 커지게 되어 디스크를 꽉 채우는 불상사가 발생합니다.
전체(Full) 혹은 대량 로그(Bulk logged) 설정 시, 특정 시점으로의 복구를 위한 모든 트랜잭션 로그가 쌓이기 때문에 간단(Simple) 설정과는 비교가 안될만큼 급속도로 로그 파일이 커지게 됩니다. 로그 백업시 자동적으로 로그 파일에서 해당 백업 부분을 삭제하게 되는데, 로그 백업을 안할 경우 자연스레 로그 파일은 마냥 커지기만 하는겁니다. 이런 경우가 생각보다 흔하게 벌어지는 만큼 전체(Full) 혹은 대량 로그(Bulk logged) 복구 모델을 선택했다면 반드시 주기적인 로그 백업을 행해야 합니다.
최적의 백업 전략은?
각 백업의 주기를 어떻게 하는게 가장 좋을지에 대해서는 사실 정답이 없습니다. 서비스의 중요도, 성향, 예산 등을 감안해서 각자 결정을 하게 됩니다. 만족스러운 전략을 짜기 위해서는 위에서 설명한 각 백업의 특성들에 대한 정확한 이해가 선행되야 합니다.
정답은 없지만 분명하게 말할 수 있는 부분은 있습니다. 전체 백업 주기가 가장 길어야 하며, 그 다음으로 차등 백업, 그리고 마지막으로 가장 짧은 주기로 로그 백업을 하는게 가장 정상적임과 동시에 이상적입니다.
백업 주기 비교: 전체 백업 > 차등 백업 > 로그 백업
트랜잭션이 촘촘하게 하루종일 발생하는 적당히 잘되는 서비스를 기준으로 할때 개인적으로 다음과 같이 백업을 하고 있습니다.
- 전체 백업: 24시간 주기
- 차등 백업: 6시간 주기
- 로그 백업: 10분 주기
전체 백업 주기와 차등 백업 주기는 간격이 더 넓어도 괜찮은 반면, 로그 백업 주기는 더 짧게 잡으면 잡을수록 유리합니다. 이를테면 다음과 같은 식이며 많은 전문가들도 이와 비슷한 주기를 추천합니다.
- 전체 백업: 1주일 주기
- 차등 백업: 24시간 주기
- 로그 백업: 1~5분 주기
로그 백업의 주기가 짧으면 짧을수록 문제 발생시 거의 잃을게 없이 정확히 원하는 시점으로 복원할 수 있는 가능성이 점점 더 커집니다. 예를 들어 10분 주기로 로그 백업을 하고 있는데 최종 로그 백업 이후 9분 37초에 해당하는 시점에서 오류가 발생했다면 이를 돌릴수 있는 방법이 없습니다. 1분 혹은 그 이하 주기로 로그 백업을 했다면 운이 어지간히 없지 않는 이상 원하는 시점으로 복원할 수 있는 가능성이 매우 높습니다.
하지만 극단적으로 짧은 로그 백업 주기에도 치명적인 단점이 있습니다. 백업 파일 하나에 필요한 모든 정보가 들어있어 하나씩만 있으면 복원이 가능한 전체나 차등 백업과는 대조적으로, 로그 백업을 복원하려면 복원을 원하는 시점까지 단 한 파일만 빠지거나 오류가 있어도 복원이 불가능합니다.
데이터 오류 발생시 대처 예
다음과 같은 상황을 예로 들어 좀더 자세히 알아보겠습니다. 개인적으로 최적의 주기는 아니라고 생각하지만 설명을 위해 편의상 다음과 같이 설정했다고 가정하겠습니다.
- 전체 백업: 24시간 주기
- 차등 백업: 3시간 주기
- 로그 백업: 1시간 주기
| 시간 | 백업 종류 |
| 00:00 AM | 전체 백업 (최초) |
| 01:00 AM | 로그 백업 |
| 02:00 AM | 로그 백업 |
| 03:00 AM | 차등 백업 |
| 04:00 AM | 로그 백업 |
| 05:00 AM | 로그 백업 |
| 06:00 AM | 차등 백업 |
| 06:25 AM | 오류 발생 |
| 07:00 AM | 로그 백업 |
| ... | ... |
| 00:00 AM (다음날) | 전체 백업 |
| 01:00 AM | 로그 백업 |
| ... | ... |
이중 최초 전체 백업은 전체(Full) 혹은 대량 로그(Bulk logged)로 설정한 이후의 최초 전체 백업을 의미합니다.
아직 미완 게시글이지만 마냥 미룰수 없어 일단 올립니다. 조만간 시간이 될때 이어서 쓰도록 하겠습니다.