업무 중에 백업 솔루션을 검토하고 도입해야 할 상황들이 있었다.
보통은 엔터프라이즈 솔루션을 구매하면 총판 혹은 협력사 엔지니어가 방문하여 구성을 진행하게 되는데,
막상 이들에게 모든 것을 맡겼다가 난감한 경우가 있었다. 시스템 환경에 잘 녹이는 건 고객사나 주사업자의 임무이기 때문이다.
백업 대상 선정과 정책
Daily - 증분
Weekly - 전체
보관기간 - Full : 1달, Daily : 1주 구성이면 대부분의 업무용 시스템에 fit하겠지만, 게임이나 핵심 외부 서비스의 경우에는 얘기가 많이 달라진다.
k8s는 엔터프라이즈 솔루션 대신, k8s 전용 백업을 사용해야한다. 컨테이너든 베어메탈이든 VM이든 백업을 떴다 복구하더라도 클러스터 연동의 문제가 있다.
SLA와 RPO/RTO.
가상화 시스템을 백업한다고 관리 서버를 VM으로 만들거나 하는 행동은 썩 바람직해 보이지는 않는다. 여러 이유가 있지만, 백업 대상과 백업 솔루션은 장애 분리가 꼭 필요하다. 그리고 백업 관리 서버가 죽더라도, 백업본을 살리는 건 쉽고 신속하게 가능하여야 하며, 이것은 PoC 진행을 통해 반드시 검증하여야 한다.
- 모 솔루션은 관리 서버가 죽었을 때 VM의 복구가 불가능하다. 모 솔루션은 Rescue 이미지가 있고, 백업데이터를 파일 이름만 보고도 식별 가능하게 관리해주면, 마스터 서버의 장애 유무와 관계없이 독립적으로 복구가 가능하다.
RPO와 RTO에 대한 내용은 SI/SM을 불문하고 명확하게 정의가 되어 있을 것이다.
RPO는 간단하게, 데이터 손실이 발생할 수 있는 시간을 의미한다. 아래 그림에서 1시 05분에 장애가 발생했다면, 오전 10시에 스케쥴된 백업본을 가지고 복구를 하여야 하며, 10시~1시 5분 사이의 데이터는 복구할 수 없게된다. 백업 주기를 짧게 가져가면 이 시간은 점점 줄어들겠지만, 반대급부로 백업 데이터 용량과 피크타임 서비스 영향도가 커질 수 있다.
RTO는 장애 발생 시점부터 복구까지 걸리는 시간을 의미한다. 이 역시 PoC로 반드시 검증해야 할 부분이다.
어디에 저장할 것인가?
- Dedicated 로컬 디스크. 백업 전용 서버를 도입하고, 백업 데이터가 그렇게 많지 않을 경우 고려할 수 있다.
- 스토리지.
가상화 머신 백업 시, 보관기간 1주/Daily 증분/Weekly 전체 스케쥴일 때, 백업 대상 전체용량의 2~2.5배 정도 설계를 한다. 솔루션 불문하고 권고하는 용량이 대부분 비슷했다.
다만 Dedicated 로컬 디스크에 저장을 하겠다고 한다면, 아주 당연하게도 RAID 후 Usable 용량까지 계산에 포함시켜야 한다. 어느 미친놈이 백업을 하는 RAID 0 통짜로 묶어서 서비스를 하겠나...
중복제거 엔진은 벤더마다 명칭은 다르겠지만, 대부분의 솔루션에 존재할 것이다.
당연하다. 생각해보면 대부분의 파일들은 변하지 않는다. 그걸 중복으로 저장한다면 2.5배 산정? 동시에 보유하는 백업본 갯수*0.8 정도는 잡아야 할 거다.
아키텍쳐 구성 시 주의해야 할 부분
- nfs는 느리다.
- Dedicated 서버가 Windows라면 SMB를 활용하면 좋겠지만, 보안적으로 상당히 문제가 많다. 랜섬웨어 시대의 포문을 열었던 WannaCry는 SMB 취약점을 이용하기 때문이다. 속도 측면에서는 NFS보다 상당히 월등하기 때문에, 흔한 구성은 아니지만 SMB로 구성을 하면 좋다.다만 그 전에 OS 업데이트를 수행하고, 보안 취약점에 대한 검토 및 완화책을 충분히 준비하여야 한다. 여담이긴 한데 Windows OS의 대부분의 프로토콜들이 다 이런식인 것 같다. 레거시를 시원하게 걷어내지도 못한다. 그러니까 맥OS랑 꾸준하게 차이가 벌어지고, ARM 버젼 윈도우즈가 불안하지...
- SMB의 경우, 프로토콜의 한계인지 해당 폴더에 파일이 너무 많아지거나 용량이 커지면 속도에 악영향을 미치는 것 같다.
Dedicated 백업서버
DB 백업
- 일시적으로 리소스를 많이 먹기 때문에, DB 서버에 리소스가 충분한지도 검토가 필요하다.
- 대부분의 DB 백업 솔루션은 SQL에 내장된 덤프를 뜨는 방식으로 데이터 추출 후 중복제거하여 백업을 제거한다.
- DB백업을 위한 권한을 별도로 생성하면 좋다. MSSQL에는, NT AUTHORITY\SYSTEM 권한 요구. 고객사의 보안 정책에 따라 적용하기 어려운 부분이 있다. DB백업 전용 로컬 Windows 계정을 생성하는 등의 방식을 사전에 충분히 고려하여야 한다.
Agent 설치
- 특히 가상화 쪽 백업에서 두드러지는 고려사항이다. 대부분의 백업 솔루션은 최대한 기존 인프라에서 자체 제공하는 기술을 이용하려고 한다.(DB의 경우 DB에서 지원하는 덤프, VMware의 경우 백업 전 스냅샷을 생성하여 압축 및 중복제거를 통한 백업 수행)
- 운영 관점에서 Agentless 방식의 백업이 제일 좋겠지만, 지금까지의 경험으로는 VM 레벨의 백업 말고는 극히 드물었던 것 같다.
- Agent를 설치하기 위해서 Windows Server/Linux 각각의 요구사항이 있으며, 지나치게 오래된 OS(CentOS라던가... Windows Server 2008~2012가 현역이라던가...🤯)에 설치하기 전에는 Agent 설치 사전요건 - Windows의 경우 KB나 써드파티 프레임워크, VM의 경우 디스크 가상화 방식에 따른 제약조건 - 을 철저히 고려하는 편이 좋다.
댓글