백업?
데이터를 미리 임시로 복제하여, 문제가 발생해도 데이터를 복구 할 수 있도록 준비해 두는 것. 즉 데이터의 손실을 방지하는 것에 그 목적을 둔다.
이중화와의 차이점으로는, 백업은 데이터를 복제해서 별도의 저장소에 보관한다는 점이다. 그렇기에 복원(Restore)이나 복구(Recovery) 과정을 통해 데이터를 원래 사용하는 장소로 되돌리는 과정이 필요하다.
즉, 단순하게 여분의 데이터를 복사해 두는 것이 백업의 전부가 아니라, 적당한 백업의 취득 빈도나 복구 시점을 고려해서 백업을 설계해야 한다.
주요 개념
- RTO(Recovery Time Objective): 복구 목표 시간
- 시스템이 얼마나 빨리 복구되어야 하는가??
- 복구에 어느 정도 시간이 걸리는가??
- Hot Site, Warm Site, Cold Site등을 정하는 기준
- RPO(Recovery Point Objective): 복구 기준 시점
- 어느 시점까지 복구 할 것인가?
- 데이터의 손실을 얼마나(몇 시간) 감당할 수 있는가?
- 현재부터 가장 가까운 복원지점(백업시점)까지의 시간목표
- BCP(Business Continuity Planning): 업무연속성계획
- 각종 재해, 장애, 재난으로부터 위기관리를 기반으로 재해복구, 업무복구 및 재개, 비상계획 등의 비즈니스 연속성을 보장하는 계획
- 참고 - BCP
- 저널링(Journaling): 트랜잭션이나 변경되는 데이터의 이력을 남겨두는 것. 데이터 자체를 저장하는 것이 아니라 변경기록을 남기는 것. 장애 시 빠른 복구가 가능하고 데이터 복제보다 적은 리소스를 소모하지만, 저널링을 하기 위한 오버헤드가 발생한다.
물론 BCP도 중요하지만, 지금 다루기엔 지나친 감이 있어서 차후에 더 자세히 정리해야겠습니다. 그러므로 우선은 1, 2번에 대해서만 먼저 정리를 해 보겠습니다.
1번의 경우 우리의 서비스가 얼마나 빨리 복구되어야 하는지, 그리고 이를 위해 우리가 투자할 수 있는 자원이 어느정도인지에 따라서 그 요건이 달라집니다. 당연히 RTO가 짧을수록 설계의 난이도는 올라가고 필요한 자원은 증가합니다.
2번도 1번과 대체로 비슷한 요소에 의해서 그 요건이 달라집니다. 즉, RPO의 경우에도 손실을 짧게 하려면 설계 난이도는 올라가고 필요한 자원은 증가합니다. 그러나 RPO의 경우에는 일일 단위로 배치(Batch)처리되는 시스템등에서는 크게 문제가 없는 경우도 있습니다.
2번에서 잠깐 언급했다시피, 이 두가지 요소는 무조건 빠르고, 잦다고 좋은게 아니며, 비슷한 조건이라도 시스템의 성격에 따라서 생각보다 문제가 크지 않을수도, 더욱 커질수도 있습니다.
결론적으로 단순히 비용등의 문제 뿐 아니라, 사용자의 신뢰도나 정부 기관의 규제 등 여러 가지 외부 요인까지도 포함한, 우리 시스템에 대한 포괄적인 이해가 필요합니다.
백업의 종류
우리의 시스템에서 백업이 필요한 대상은 크게 두 가지가 있습니다.
- 시스템 백업(OS, 미들웨어 등)
- 데이터 백업(데이터베이스와 사용자 데이터 등)
1번의 경우, 한번 설치 해 두면 변경사항이 자주 발생하지 않습니다. 즉, 자주 백업 할 필요가 없습니다. 따라서 몇 가지 특수한 경우에만 백업을 해 주면 충분합니다.
- 초기 환경구축 후
- 이후 일괄 처리 적용 시
- 대규모 구성 변경 시
그렇다고 쉽게 볼 수 는 없는 것이, 불필요한 파일(임시 파일 등)이 포함되는 것을 막기 위해서는 시스템을 정지할 필요가 있기에 그만한 부담이 발생합니다.
2번의 경우, 시스템 백업과는 다르게 상대적으로 취득 빈도가 높습니다. 따라서, 시스템을 정지하지 않은채로 데이터를 취득 할 수 있는 체계를 구성 할 필요가 있습니다.
만약 이렇게 시스템을 구축한다면, 특히 데이터베이스 백업 시에는, 일관성을 꼭 보장해야합니다. 그렇기때문에 데이터베이스 백업시에는 데이터 자체에 대한 백업은 물론, 데이터 갱신 내역을 기록한 저널까지 모두 취득해야합니다.
- 참고
Crash Consistency
백업 수행 시점의 메모리 및 보류 중인 I/O 작업을 파악하지 않고 특정 시점의 디스크만 이미지화 하여 백업합니다.
따라서 비교적 높은 데이터 정합성이 필요하지 않은 운영 체제 백업에 적합합니다.
Application Consistency
백업 수행 시점의 메모리 및 보류 중인 I/O 작업을 파악하고, 대기 중인 작업을 디스크로 플러시(Flush)하여 백업합니다.
DB와 같이 데이터 정합성이 매우 중요한 응용 프로그램 백업에 적합합니다.
경험담
저같은 경우 처음으로 프로젝트를 맡았을 때, 아무래도 규모가 작은 어플리케이션이다 보니 체계가 전혀 없었습니다. 그렇기에 데이터가 백업되고있지도 않았고, 만약 프로덕션 서버에 있는 데이터가 손상된다면 그대로 사용자들의 데이터를 모두 잃는 구조였습니다.
그래서 막연히 데이터를 어떻게든 백업을 하긴 해야겠는데 이게 대체 얼마나 자주, 어떻게 해야하는지 감이 안잡혀서 그냥 막연히 일주일마다 하나씩 파일을 sql 파일을 덤프 했던 기억이 납니다..
그러다 언젠가, 사고로 데이터를 날렸다가 다행히 하루 전에 백업해 둔 데이터가 있어서 약 두 시간 만에 큰 손실 없이 사용자 데이터를 다시 복구했었는데, 지금 생각해보면 이 일이 RTO, RPO를 미리 고려해서 대처방안을 미리 세워두어야겠다는 필요성을 느끼는 계기가 된 것 같네요.
References
https://www.seagate.com/kr/ko/support/kb/what-is-a-backup/
https://ko.wikipedia.org/wiki/백업
https://library.gabia.com/contents/infrahosting/7241/
https://ko.wikipedia.org/wiki/저널링_파일_시스템
(도서)그림으로 공부하는 it 인프라 구조
