[인프라 기초] 데이터 백업 vs 데이터 소산 개념부터 아키텍처까지

💾 데이터 백업과 데이터 소산: 소중한 데이터 지키기!

안녕하세요! 오늘은 우리가 컴퓨터나 스마트폰으로 찍은 사진, 열심히 쓴 일기, 그리고 재미있는 게임 저장 파일 같은 '데이터'를 안전하게 지키는 두 가지 방법에 대해 알아볼 거예요.

초등학생 친구들도 단번에 이해할 수 있도록 아주 쉽게 설명해 줄게요! 😉

1. 💾 데이터 백업 (Data Backup)

"혹시 모르니까 복사본 하나 더 만들어 두자!"

• 뜻: 내가 가진 소중한 데이터를 다른 곳에 똑같이 하나 더 복사해 두는 것을 말해요.
• 쉽게 생각하기: 학교에서 아주 중요한 알림장을 받았어요. 혹시나 잃어버릴까 봐 똑같은 내용을 내 수첩에 한 번 더 적어두는 것과 같아요. 원래 알림장을 잃어버려도 수첩을 보면 되니까 안심이겠죠?
• 왜 할까요? 스마트폰을 물에 빠뜨리거나, 컴퓨터가 갑자기 고장 나서 켜지지 않을 때 복사해 둔 데이터(백업본)가 있다면 원래대로 쉽게 되살릴 수 있어요.

2. 🚚 데이터 소산 (Data Dispersal)

"불이 나면 어떡해? 복사본은 멀리 다른 집에 보관하자!"

• 뜻: 백업해 둔 데이터를 원래 데이터가 있는 곳과 멀리 떨어진 다른 장소에 나누어 보관하는 것을 말해요. (여기서 '소산'은 한자로 '흩어버리다'라는 뜻이에요.)
• 쉽게 생각하기: 알림장을 복사한 수첩을 원래 알림장과 함께 가방에 넣어 두었다가 가방을 통째로 잃어버리면 어떻게 될까요? 둘 다 없어지겠죠! 그래서 중요한 수첩은 집에 있는 책상 서랍에 안전하게 두고 다니는 거예요.
• 왜 할까요? 만약 회사나 집에 불이 나거나 홍수가 나서 컴퓨터와 백업해 둔 장치가 모두 망가지더라도, 멀리 떨어진 다른 건물(또는 안전한 인터넷 세상인 '클라우드')에 보관해 둔 데이터는 안전하게 살아남기 때문이에요.

📊 한눈에 비교하기!

구분	💾 데이터 백업	🚚 데이터 소산
하는 일	똑같은 복사본 만들기	복사본을 멀리 떨어진 곳에 숨기기
지키는 방법	기계가 고장 나는 것에 대비해요.	불, 홍수, 지진 같은 큰 사고에 대비해요.
쉬운 예시	사진을 노트북과 USB에 각각 저장하기	USB 하나는 할머니 댁에 맡겨두기

💡 요약하자면!

우리의 소중한 추억과 자료를 지키려면 백업도 중요하지만, 그 백업한 데이터를 안전하게 멀리 떨어뜨려 놓는 소산까지 해야 완벽하게 데이터를 지킬 수 있답니다!

오늘부터 여러분의 소중한 사진이나 숙제 파일도 다른 곳에 한 번 더 저장(백업)해 보는 건 어떨까요? 👍




*조금 더 깊게 알아보기: 엔지니어를 위한 기술 아키텍처"

👨‍💻 엔지니어를 위한 백업 & 소산 기술 아키텍처

실제 기업용 엔지니어링 환경에서 데이터 백업과 소산은 비즈니스 연속성 계획(BCP)과 재해 복구(DR)의 핵심 요소입니다. 이를 이해하기 위한 기술적 메커니즘과 아키텍처를 소개합니다.

1. 💾 데이터 백업 (Data Backup)의 기술적 메커니즘

백업은 단순히 파일을 복사하는 것을 넘어, 시스템의 상태와 데이터 무결성(Data Integrity)을 특정 시점으로 얼려두는 작업입니다.

1) 백업의 3가지 유형

• 전체 백업 (Full Backup): 변경 여부와 상관없이 선택된 모든 데이터를 백업합니다. 복구 속도가 가장 빠르지만, 스토리지 용량과 백업 시간이 많이 소요됩니다.
• 증분 백업 (Incremental Backup): 마지막 백업(전체 또는 증분) 이후 변경된 데이터만 백업합니다. 시간과 용량을 아낄 수 있지만, 복구할 때 전체 백업본과 그동안의 모든 증분 백업본이 차례대로 필요하여 복구 프로세스가 복잡해집니다.
• 차분 백업 (Differential Backup): 마지막 전체 백업 이후 변경된 모든 데이터를 백업합니다. 증분 백업보다 용량을 더 쓰지만, 복구 시 [전체 백업 + 마지막 차분 백업] 단 두 단계만 거치면 되므로 균형 잡힌 솔루션으로 쓰입니다.

2) 핵심 기술 키워드

• 스냅샷 (Snapshot): 스토리지 시스템에서 특정 시점(Point-in-Time)의 파일 시스템 파일이나 볼륨 상태를 그대로 포착하는 기술입니다. 데이터의 메타데이터 주소만 복사하므로 순식간에 생성되며, 백업의 원천 데이터 역할을 합니다.
• 중복 제거 (Deduplication): 백업 데이터 중 중복되는 블록을 찾아내어 하나만 저장하고 나머지는 포인터로 연결하는 기술로, 백업 스토리지 효율을 극대화합니다.

2. 🚚 데이터 소산 (Data Dispersal)의 아키텍처 디자인

기술적 관점에서 '소산'은 데이터의 지리적 격리(Geographical Isolation)를 의미하며, 주로 DR(재해 복구) 아키텍처와 맞물려 동작합니다.

1) 데이터 복제 방식 (Replication)

소산을 구현하기 위해 주 센터(Primary Region)에서 DR 센터(DR Region)로 데이터를 보낼 때 두 가지 방식을 사용합니다.

• 동기 복제 (Synchronous Replication):
  • 원리: 주 센터에 데이터가 쓰일 때, DR 센터까지 완전히 쓰기가 완료되어야 '성공' 인터럽트를 반환합니다.
  • 장점: 데이터 손실이 전혀 없습니다 ($RPO = 0$).
  • 단점: 네트워크 레이턴시(Latency) 때문에 두 센터 간의 거리가 멀면 주 시스템의 성능이 떨어집니다. (보통 100km 이내 권장)
• 비동기 복제 (Asynchronous Replication):
  • 원리: 주 센터에 먼저 데이터를 쓰고, 백그라운드에서 DR 센터로 데이터를 주기적으로 전송합니다.
  • 장점: 메인 시스템 성능에 영향을 주지 않으므로 수천 km 떨어진 대륙 간 소산이 가능합니다.
  • 단점: 재해 발생 시 아주 잠깐의 데이터 유실이 발생할 수 있습니다 ($RPO > 0$).

2) 클라우드 환경에서의 소산: Multi-Region 구성

최근 AWS, Azure 등 퍼블릭 클라우드에서는 멀티 리전(Multi-Region) 아키텍처를 통해 소산을 자동화합니다.

• Object Storage Replication: AWS S3의 CRR(Cross-Region Replication) 기능을 켜면, 파일이 업로드되는 즉시 수천 킬로미터 떨어진 다른 국가의 리전으로 암호화되어 자동 소산됩니다.
• Global Database: Aurora Global Database나 DynamoDB Global Tables를 사용하여 데이터베이스 레벨에서 실시간으로 지리적 소산을 처리합니다.

🎯 엔지니어가 반드시 기억해야 할 지표: RTO & RPO

백업과 소산 아키텍처를 설계할 때 비즈니스 요구사항에 따라 반드시 정의해야 하는 두 가지 핵심 지표가 있습니다.

[ 재해 발생 시점 ]
      │
◀─────┼─────▶
  RPO      RTO
(데이터)  (시간)

• RPO (Recovery Point Objective, 복구 목표 시점): "재해가 났을 때 어느 시점의 데이터까지 되돌릴 것인가?" 즉, 허용 가능한 데이터 유실량입니다. (예: RPO가 1시간이면, 최대 1시간 전 데이터까지는 유실을 감수한다는 뜻)
• RTO (Recovery Time Objective, 복구 목표 시간): "재해가 발생한 후 얼마 만에 서비스를 다시 켤 것인가?" 즉, 서비스 중단 허용 시간입니다. (예: RTO가 4시간이면, 4시간 안에 시스템을 복구해 정상화해야 함)

💡 결론: > 백업은 RPO를 줄이기 위해 주기와 방식을 쪼개는 기술이고, 소산은 대규모 재해 시 시스템을 신속하게 다른 곳에서 재가동하여 RTO를 최소화하기 위한 아키텍처입니다.