데이터베이스 백업 대 데이터베이스 복제
백업과 복제는 서로 다른 목적을 가지고 있지만, 종종 혼란스럽습니다. 복제는 일반적으로 고가용성 및 읽기 확장을 위해 데이터베이스의 동기화된 복사본을 별도의 서버에 유지합니다. 기본 서버에 장애가 발생하면 복제본이 거의 즉시 작업을 인수할 수 있습니다.
그러나 복제는 백업이 아닙니다. 손상된 테이블, 실수로 인한 데이터베이스 삭제 명령 또는 Ransomware 암호화 이벤트는 합법적인 변경만큼 빠르게 대기 상태로 복제됩니다. 복제는 하드웨어 장애로부터 보호해 줍니다. 백업은 데이터 손실을 방지합니다. 엔터프라이즈 환경에는 두 가지가 필요합니다.
RTO 및 RPO: 데이터베이스 백업 전략 계획
복구 시간 목표(RTO)와 복구 Recovery Point Objective(RPO)의 두 가지 지표가 모든 백업 전략을 뒷받침합니다.
RTO는 데이터베이스 복원 및 장애 후 작업 재개에 허용되는 최대 시간을 정의합니다. RPO는 데이터 손실의 최대 허용량을 정하며, 시간 단위로 측정됩니다. 1시간의 RPO는 최대 1시간의 트랜잭션 손실을 견딜 수 있음을 의미합니다.
이 두 가지 지표는 백업 빈도, 유형 및 스토리지 위치에 대한 모든 결정을 주도해야 합니다.
- 거의 제로에 가까운 RPO는 몇 분마다 연속 트랜잭션 로그 백업 또는 스토리지 수준의 스냅샷을 수행해야 합니다.
- 표준 디스크 기반 복원으로 4시간 RTO를 달성할 수 있으며, 1시간 미만의 RTO는 일반적으로 사전 준비된 복제본 또는 즉각적인 복구 기술을 요구합니다.
- 예산과 인프라 제약은 무엇이 현실적인지 결정합니다. RPO 0은 기술적으로 동기식 복제를 통해 달성할 수 있지만, 비용과 지연 시간에 따른 영향이 모든 워크로드에 타당하지 않을 수 있습니다.
비즈니스 중요도에 따라 데이터베이스를 계층으로 분류한 다음, 각 계층에 RTO 및 RPO 목표를 할당합니다. 모든 데이터베이스가 동일한 수준의 보호를 보장하는 것은 아니지만, 모든 데이터베이스에는 계획이 필요합니다.
3-2-1-1-0 백업 규칙
기존의 3-2-1 백업 규칙, 즉 3개의 데이터 복사본, 2개의 다른 미디어 유형, 1개의 오프사이트 복사본은 수년 동안 절대적인 표준이었습니다. 사진 작가 Peter Krogh는 테이프가 여전히 주요 백업 대상이었고 Ransomware가 주요 관심사가 아니었던 2009년에 이를 대중화했습니다.
현대적인 3-2-1-1-0 규칙은 오늘날의 위협 환경을 위해 구축된 두 가지 추가 기능으로 이 프레임워크를 확장합니다.
- 데이터 사본 3부(원본 및 백업 2개 이상)
- 2가지 미디어 유형(예: 디스크 및 클라우드 오브젝트 스토리지)
- 오프사이트 사본 1부(기본 데이터센터와 지리적으로 분리)
- 오프라인 또는 변경 불가(랜섬웨어가 암호화 또는 삭제할 수 없는 에어갭 또는 쓰기-원 스토리지) 1부 Ransomware
- 오류 0개(정기적인 복구 테스트를 통해 확인되므로 백업이 실제로 작동한다는 것을 알 수 있음)
변경 불가한 1개의 요소는 중요한 업그레이드입니다. 현대적인 공격은 특히 백업 저장소를 표적으로 하여 프로덕션 데이터를 암호화하기 전에 복구 옵션을 제거합니다.
데이터베이스 백업 모범 사례
일관된 자동화 및 예약
수동 백업은 안정적이지 않습니다. DBMS의 내장 스케줄링 도구(SQL Server Agent, pg_dump가 있는 cron 작업, RMAN 스케줄링) 또는 중앙 집중식 백업 플랫폼을 사용하여 일관된 스케줄을 적용하세요. 일반적인 패턴: 매일 차등을 사용하는 주간 전체 백업 및 15~30분마다 트랜잭션 로그 백업.
정기적인 복구 테스트
복구한 적이 없는 백업은 신뢰할 수 없는 백업입니다. 미션 크리티컬 데이터베이스에 대해 최소 월 1회 분기별 복구 테스트를 예약하세요. 별도의 환경으로 복구하고, 데이터 무결성을 확인하며, RTO 목표에 대한 실제 복구 시간을 문서화합니다.
REST 및 전송 중인 백업 암호화
데이터베이스 백업에는 프로덕션 시스템과 동일한 민감한 데이터가 포함됩니다. REST면 중인 백업 파일에 AES-256 암호화를 적용하고, 네트워크에서 이동하는 백업 데이터에 TLS를 사용합니다. 암호화는 HIPAA, GDPR 및 PCI DSS와 같은 규정에 따른 규정 준수 요건입니다.
장애 모니터링 및 경고
백업 작업은 대부분의 팀들이 실현하는 것보다 더 자주 조용히 실패합니다. 누락된 백업 창, 실패한 작업 또는 예기치 않은 백업 크기 변경에 대해 경고하는 모니터링을 구성합니다. 백업 크기가 갑자기 감소하면 아직 감지되지 않은 데이터 손실을 나타낼 수 있습니다.
보존 정책 정의 및 시행
보존 정책은 백업 복사본을 재활용하거나 삭제하기 전에 얼마나 오래 보관하는지 결정합니다. 올바른 보존 기간은 규정 준수 요건, 스토리지 용량 및 탐지되지 않은 문제로부터 복구해야 하는 시간에 따라 달라집니다. 많은 조직에서 매일 백업을 30일 동안, 매주 백업을 90일 동안, 매월 백업을 1년 동안 유지합니다.
프로덕션 환경에서 백업 스토리지 분리
프로덕션 스토리지와 물리적 및 논리적으로 분리된 인프라에 백업을 저장합니다. 즉, 스토리지 어레이, 네트워크 세그먼트, 지리적 위치가 다릅니다. Ransomware가 프로덕션 스토리지를 암호화하고 백업이 동일한 SAN에 있는 경우, 두 가지 모두 손상됩니다.
일반적인 데이터베이스 백업 문제
잘 계획된 백업 전략도 실질적인 장애물로 이어집니다. 이러한 도전과제를 미리 이해하면 이러한 도전과제를 중심으로 설계할 수 있습니다.
- 대용량 데이터베이스는 백업 기간을 확장합니다. 멀티 테라바이트 데이터베이스는 백업하는 데 몇 시간이 걸릴 수 있으며, 특히 네트워크 스토리지를 통한 기존의 전체 백업을 통해 백업할 수 있습니다. 블록 수준의 증분 백업, 스토리지 수준의 스냅샷 및 병렬 백업 채널은 백업 창을 압축하는 데 도움이 됩니다.
- 백업 스프롤은 비용을 증가시킵니다. 명확한 보존 정책 및 중복 제거 없이 백업 스토리지 비용은 프로덕션 데이터보다 더 빠르게 증가합니다. 계층화된 스토리지(고속 디스크에 핫 백업, 저렴한 오브젝트 스토리지에 노후 백업)와 결합한 중복 제거 및 압축은 지출을 제어하는 데 도움이 됩니다.
- 다중 데이터베이스 환경은 복잡성을 증가시킵니다. 대부분의 기업은 SQL Server, Oracle, PostGreSQL, MySQL 및 MongoDB와 같은 점차 증가하는 NoSQL 시스템을 혼합하여 운영합니다. 각 제품에는 자체 백업 툴링 및 복원 절차가 있습니다. 여러 데이터베이스 엔진을 지원하는 중앙 집중식 백업 플랫폼은 운영을 간소화하고 격차를 줄여줍니다.
- 클라우드 네이티브 데이터베이스는 다양한 접근 방식을 필요로 합니다. Amazon RDS, Azure SQL Database 및 Google Cloud SQL과 같은 매니지드 서비스는 자동 백업을 처리하지만, 조직은 여전히 기본 보존 기간, 지역 간 복제 옵션 및 특정 시점으로 복구하는 방법을 이해해야 합니다. RPO 및 보존 설정을 사용자 지정하지 않고 공급자의 기본값에 전적으로 의존하는 것은 일반적인 감독입니다.
데이터베이스 백업의 미래
데이터베이스 백업은 예정된 작업 기반 운영에서 지속적인 스토리지 통합 보호로 전환되고 있습니다. 지속적인 데이터 보호(CDP)는 데이터베이스의 모든 변경 사항을 실시간으로 캡처하여 마지막 예약된 백업 창뿐만 아니라, 모든 순간에 Point-in-Time Recovery를 가능하게 합니다.
스토리지 네이티브 스냅샷은 백업의 경제성도 변화시키고 있습니다. 스냅샷 기술은 전체 데이터 세트를 복사하는 대신, 변경된 블록만 캡처하여 데이터베이스 크기에 관계없이 몇 초 안에 완료됩니다. 이 접근 방식은 변경 불가능한 스냅샷 정책과 결합되어 Ransomware 보호 기능이 내장된 거의 제로에 가까운 RPO를 제공합니다.
AI 기반 이상 탐지는 또 다른 방어 계층으로 부상하고 있습니다. 이러한 시스템은 백업 메타데이터 패턴, 즉 크기, 기간, 변화율을 분석함으로써 백업 복사본으로 전파되기 전에 비정상적인 활동(Ransomware 암호화 이벤트 등)을 표시할 수 있습니다.
