안정성 · 연속성
"백업이 있다"와 "복구된다"는 다른 말입니다.
우리는 복구를 전제로 백업을 설계합니다 — 문서상 백업이 아니라, 실제로 살아나는 백업.
이런 상황이라면
- 백업은 매일 돈다고 들었는데, 실제로 복구해본 적은 없습니다. 정말 살아날지 아무도 모릅니다.
- 모든 게 한 곳(한 서버실, 한 IDC)에 있습니다. 그 한 곳에 문제가 생기면 대안이 없습니다.
- 외부 사이트·재택과 사내망을 연결해야 하는데, 그때그때 임시로 뚫어 쓰고 있습니다.
- “장애 나면 몇 시간 안에 복구되나요?”에 숫자로 답하지 못합니다.
데이터 백업 & DR 컨설팅
복구를 전제로 백업을 설계합니다.
- 복구 목표(RPO/RTO)를 업무 중요도에 맞춰 정의
- 3-2-1 원칙 기반 다중 사본·오프사이트 분리
- 복구 리허설로 실제 살아나는지 검증 — 동작하는 백업
- 어디까지 잃을 수 있고 얼마 만에 돌아오는지를 숫자로 합의
이 영역은 기업 기간계 시스템(ERP·그룹웨어)의 백업·이중화·DR 정책을 직접 수립한 경험을 근거로 합니다. 멈추면 회사 전체가 멈추는 시스템을 다뤄봤기에, 중요도 분류와 트레이드오프 판단 기준이 분명합니다.
사이트 간 L3 VPN (IPSec / WireGuard)
본사–지사, 사내–IDC, 재택–사내를 안정적으로 잇는 사이트 간 L3 VPN 터널을 설계·운영합니다. 임시방편이 아니라 상시 연결을 전제로 라우팅·이중화·장애 시 우회까지 구조화합니다. 이중 사이트 구성과 DR이 만나면, 한 곳이 죽어도 업무가 다른 곳에서 이어집니다.