# Tape Library
대규모 데이터 백업·보관·아카이브를 위해 설계된 자동화된 자기 테이프 저장 시스템이다.
여러 개의 테이프 드라이브와 수백~수천 개의 테이프 카트리지를 장착할 수 있는 랙 형태의 장치로 로봇 팔이 자동으로 테이프를 교체해 주는 기능을 갖는다.
관리자가 일일이 테이프를 교체하지 않아도 되도록 자동화된 방식으로 동작한다.
# VTL (Virtual Tape Library)
디스크 기반 스토리지를 테이프 라이브러리 또는 드라이브처럼 보이게 하여 기존 백업 소프트웨어와 호환되도록 하는 가상화 기술.
디스크 기반이므로 파일 단위로 복구, 중복 제거, 성능 안정성 면에서 우수하다.
💡 장점
백업/ 복구 처리 속도가 빠르다.
비용이 저렴하다.
❗ 단점
별도 소프트웨어/라이선스 비용이 발생한다.
테이프처럼 30년 이상 장기 보존에는 적합하지 않다.
디스크 기반이라 하드웨어 장애 발생 시 전체 데이터에 영향을 줄 수 있다.
# PTL LTO(Linear Tape-Open) (1, 2, 3, 4, 5, 6, 7, 8, 9)
개방형 표준 기반의 자기 테이프 저장 기술로 대규모 데이터 보관을 위한 업계 표준이다.
고용량·고속 전송을 지원하며 세대별로 용량과 성능이 발전해 현재는 수십 테라바이트 단위 저장을 제공한다.
💡 장점
LTO-1 ~ LTO-3
초기 세대이며 사실상 단종되었다. 중고 시장에서 비용이 저렴하다.
LTO-4 ~ LTO-6
본격적으로 대기업·기관에서 많이 도입된 세대이다. 암호화·WORM 지원이 시작되었다. 테라바이트급 용량
LTO-7 ~ LTO-8
대규모 데이터센터나 클라우드 사업자도 활용한다. 10TB 이상 대용량, 고속 전송 그리고 안정적인 공급
LTO-9
18TB(압축 시 45TB) 단일 카트리지, 400MB/s 전송. 초대용량, 클라우드 보관 대비 비용이 저렴하다.
❗ 단점
LTO-1 ~ LTO-3
용량·속도가 모두 부족하고 장기 지원이 없다.
LTO-4 ~ LTO-6
최신 소프트웨어/드라이브 호환성 점점 축소되고 있다.
LTO-7 ~ LTO-8
여전히 순차 접근 매체의 한계가 존재한다.
LTO-9
최신 장비/드라이브 가격이 높아 초기 도입에 부담이 있다.
| 세대 | 출시 시기 | 네이티브 용량 | 압축 용량 | 최대 압축 속도 | 비압축 속도 | 전체 테이프 최대 쓰기 시간(hh:mm) |
| LTO-1 | 2000 | 100 GB | 200 GB | 20 MB/s | 40 MB/s | 1:23 |
| LTO-2 | 2003 | 200 GB | 400 GB | 40 MB/s | 80 MB/s | 1:23 |
| LTO-3 | 2005 | 400 GB | 800 GB | 80 MB/s | 160 MB/s | 1:23 |
| LTO-4 | 2007 | 800 GB | 1.6 TB | 120 MB/s | 240 MB/s | 1:51 |
| LTO-5 | 2010 | 1.5 TB | 3.0 TB | 140 MB/s | 280 MB/s | 3:10 |
| LTO-6 | 2012 | 2.5 TB | 6.25 TB | 160 MB/s | 400 MB/s | 4:20 |
| LTO-7 | 2015 | 6.0 TB | 15 TB | 300 MB/s | 750 MB/s | 5:33 |
| M형(M8) | 2017 | 9.0 TB | 22.5 TB | 300 MB/s | 750 MB/s | 8:20 |
| LTO-8 | 2017 | 12 TB | 30 TB | 360 MB/s | 900 MB/s | 9:16 |
| LTO-9 | 2021 | 18 TB | 45 TB | 400 MB/s | 1,000 MB/s | 12:30 |
| LTO-10 | TBA | 30 TB | 75 TB | 1,000 MB/s | 2,750 MB/s | 12:07 |
# 바큘라(Bacula)
오픈소스 기반의 엔터프라이즈급 백업 설루션으로 주로 리눅스/유닉스 환경에서 많이 사용된다.
| 구성 요소 | 역할 |
| Director | 백업 작업을 관리·스케줄링 |
| Storage Daemon | 테이프, 디스크, 클라우드 등 저장 매체 제어 |
| File Daemon | 클라이언트 시스템의 데이터 수집 |
| Catalog | 백업 데이터 메타데이터 및 기록 관리(DB 기반) |
💡 특징
다양한 백업 대상 지원: 파일 시스템, 데이터베이스(MySQL, PostgreSQL 등), VM 등
테이프 라이브러리 연동 가능: PTL을 통한 자동화
백업확장성: 수백~수천 서버까지 관리 가능
유연한 스케줄링: 풀/증분/차등 백업 지원
보안: SSL/TLS 통신 지원, ACL 기반 접근 제어
# 백업 서버의 역할
백업 서버
백업 서버는 동일한 네트워크에 있는 여러 클라이언트 컴퓨터에 저장된 파일을 백업하기 위해 특별히 구축된 전용 서버이다.
💡 특징
중앙 집권 관리: 여러 PC, 서버, DB, VM의 데이터를 한 곳에서 수집·관리
다양한 백업 방식 지원: 풀 백업, 충분 백업, 차등 백업
스케쥴링 자동화: 정해진 시간에 자동으로 백업 수행
스토리지 다양성: 디크스, 테이프, 라이브러리, 클라우드 등 다양한 저장소 연동 가능
중복 제거 & 압축: 같은 데이터를 여러 번 저장하지 않아 공간 절약, 압축을 통해 저장 효율 극대화
복구 기능: 단일 파일부터 전체 시스템까지 다양한 단위 복구 가능, 빠른 복원(RTO 단축) 기능 제공
# 백업 클라이언트
백업 클라이언트는 데이터를 가진 시스템에 설치되어 백업 서버의 지시에 따라 데이터를 수집하고 전송하며 필요시 복원까지 지원하는 요소이다.
💡 특징
백업 대상: 사용자 PC, 서버, 데이터베이스 등 데이터가 존재하는 모든 시스템이 클라이언트이다.
데이터 전송: 클라이언트는 데이터를 직접 보관하지 않고 백업 서버/스토리지로 전송한다.
자동 백업: 지정한 정책(시간, 주기, 보관 규칙 등)에 따라 자동으로 데이터를 백업한다.
복원 지원: 데이터 손실이나 장애 발생 시 데이터를 원래 위치 또는 다른 위치로 복원합니다.
# 백업 vs 아카이브
백업
문서, 파일, 폴더, 시스템과 같은 데이터 소스의 사본을 생성해 이 데이터가 손실되거나 손상된 경우 이를 복원·복구할 수 있도록 하는 프로세스
백업과 원본 데이터 소스가 함께 존재하며 백업을 한다고 해서 원본 파일이나 폴더를 삭제하거나 백업 사본으로 대체하지는 않는다.
파일을 데이터가 손실되기 이전의 상태로 되돌릴 수 있어야 한다. 따라서 백업은 정기적으로 수행해야 하며 시점 복구가 가능해야 한다.
아카이브
변경값이 적은 데이터를 장기적으로 보관하는 데 사용된다.
파일을 아카이브 공간에 저장한 후 원하거나 필요할 경우 원본 버전을 삭제해도 되며 보통은 정기적으로 액세스 할 필요가 없는 데이터만 보존 형태로 저장한다.
데이터 아카이브의 주요 용도는 대체할 수 없고 보관이 필요하지만 자주 수정하거나 액세스 할 필요가 없는 파일을 장기적으로 저장한다.
| 구분 | 백업(Backup) | 아카이브(Archive) |
| 보관 목적 | 단기, 장기 보관에 적합 | 장기간에 걸친 데이터 저장에만 적합 |
| 대상 데이터 | 자주 사용하고 꾸준히 변경되며 정기적으로 접근하는 파일/폴더 |
보관 필요는 필요 있으나 자주 접근할 필요가 없는 파일/폴더 |
| 중요 요소 | 복구 속도가 중요 (신속한 복원 필요) |
속도보다 보존 자체가 중요 |
| 저장 방식 | 여러 개의 파일 사본 생성 (이전 버전 복구 가능) |
파일 사본 하나만 저장, 변경·수정 불가 |
| 활용 상황 | 원본 파일이 손실·손상되었을 때, 이전 버전 복구 및 복원 |
변경 이력이 없고 향후 수정할 필요 없는 데이터의 장기 보존 |
# 백업 정책
백업 작업의 일정, 실행 빈도, 보존 기간 등을 정의하는 규칙이다.
정책은 백업이 시간 창 내에서 실행되는 것인지 연속적으로 수행되는 것인지도 설정할 수 있다.
이러한 정책이 요구사항을 충족하면 해당 데이터는 규정 준수(compliance)로 간주된다.
# RPO(Recovery Point Object) - 목표 복구 시점
장애 발생 시 비즈니스 연속을 위해 어느 시점으로 백업할지 결정하게 될 지표
💡고려사항
데이터 손실을 얼마나 감당할 수 있는가
감내할 수 있는 데이터 손실의 양(시간)
현재로부터 가장 가까운 백업지점까지의 목표 시간이
# RTO(Recovery Time Object) - 목표 복구 시간
장애 발생 시 시스템을 원 상태로 복원하는 데 소요되는 시간
💡고려사항
시스템이 얼마나 빨리 복구되어야 하는가
서비스가 재개될 때까지 걸리는 시간

# 백업 종류
콜드 백업(cold backup), 핫 백업(hot backup) 비교
| 구분 | Cold Backup (콜드 백업) | Hot backup (핫 백업) |
| 정의 | 데이터베이스 또는 시스템을 중지한 상태에서 수행하는 백업 |
시스템이 운영 중(active 상태)일 때 수행하는 백업 |
| 가용성 | 서비스 중단 필요 (다운타임 발생) | 서비스 중단 없음, 실시간 서비스 유지 가능 |
| 일관성 | 완전히 정지된 상태에서 백업하므로 데이터 일관성 보장 |
운영 중 변경되는 데이터를 다뤄야 하므로 트랜잭션 로그 관리 필요 |
| 속도 및 효율 | 상대적으로 단순하고 빠름 | 처리 복잡도가 높아 백업 속도가 느릴 수 있음 |
| 적합한 환경 | 데이터 변경이 적고, 일정 시간 서비스 중단이 허용되는 환경 |
24/7 서비스가 필요한 은행, 온라인 쇼핑몰 등 고가용성 환경 |
| 복구 용이성 | 단순 구조로 복구가 용이 | 로그 기반 복구가 필요할 수 있어 상대적으로 복잡 |
| 예시 | 시스템 종료 후 전체 DB 파일 복사 | Oracle Hot Backup, SQL Server Full Backup |
# RMAN 백업 (Recovery Manager backup)
Oracle Database에서 제공하는 전용 백업·복구 관리 도구
백업과 복구를 자동화·관리하며 증분 백업·백업 세트·오브젝트 스토리지 연동을 통해 데이터 보호와 복구를 지원한다.
특징
| 기능 | 설명 |
| 백업 및 복구 | 전체 DB, 테이블스페이스, 데이터 파일, 특정 객체 단위 백업 및 복구 지원 |
| 증분 백업 (Incremental Backup) | 전체 백업 후 변경된 블록만 선택적으로 백업 → 시간·리소스 절감 |
| 백업 세트와 조각 관리 | 백업 데이터를 세트/조각 단위로 구성하여 효율적으로 관리 및 복구 수행 |
| 백업 설정 및 스케줄링 | 예약 실행, 정책 설정, 보관 기간 관리 가능 |
| 데이터베이스 복제 | 전체 또는 부분 복제 지원 → 다른 시스템으로 이관 가능 |
| 레지스트리 및 카탈로그 | 백업 정보를 DB 레지스트리 또는 외부 백업 카탈로그에 저장 |
| 클론 생성 | 테스트·개발 환경용 데이터베이스 클론 생성 가능 |
# VMWare 이미지 백업
VM(가상 머신)의 전체 상태를 이미지 형태로 백업하는 방식
VM을 운영체제(OS), 애플리케이션, 설정, 데이터까지 포함한 하나의 디스크 이미지(스냅숏과 유사한 형태)로 통째로 백업하는 것.
일반적으로 에이전트리스(Agentless) 방식으로 백업 소프트웨어가 하이퍼바이저(vSphere/ESXi)에 직접 연결해 수행합니다.
💡 장점
전체 복구 가능: 문제가 생기면 VM 전체를 그대로 복원할 수 있다.
별도의 OS 재설치나 애플리케이션 재구성 필요 없이 바로 실행 가능
❗ 단점
용량 문제: 전체 VM 단위라 데이터가 크면 스토리지 부담이 크다.
복구 한계: 원본 VM이나 백업 파일 자체가 손상되면 복구가 어려움
복원 시간 소요: 대용량 이미지 파일을 다루므로 백업/복원 과정에 많은 시간과 리소스 소모
# 백업 데이터 expire(만료)
특정 백업이 저장된 후 지정된 기간이 지나면 자동으로 삭제되거나 덮어 쓰여 더 이상 복구에 사용되지 않는 상태.
# 백업 유형에 따른 만료
Full Backup: 보존 기간이 길고 중요도가 높음
Incremental/Differential Backup: 상대적으로 짧은 보존 기간 Full Backup 없으면 복구 불가
Snapshot: 스토리지 공간 효율적이지만 expire 되면 데이터 복구 불가
❗주의사항
복구 가능 기간 확인: 중요한 데이터는 법적/업무상 요구 기간보다 짧게 expire 하지 않도록 주의
로그 및 모니터링: Expire 된 데이터와 남아있는 데이터 현황을 주기적으로 확인해야 한다
Incremental이나 Differential Backup은 Full Backup이 존재해야 복구 가능
만약 Full Backup이 expire 되면 해당 체인 전체가 복구 불가 상태가 될 수 있다
# SAN 백업
서버가 SAN에 연결된 스토리지에서 데이터를 백업 서버 또는 백업 장치로 전송하는 방식이다.
일반 LAN(Network) 기반 백업과 달리 데이터 전송이 SAN 네트워크 경로를 통해 이뤄짐 → LAN 부하를 줄이고 속도를 높임.
# Network 백업
서버의 데이터를 네트워크를 통해 별도의 백업 서버나 백업 스토리지로 전송하여 보관하는 방식이다.
일반적으로 기업 내 LAN(Network)을 활용해 데이터가 이동한다.
| 구분 | SAN 백업 | LAN 백업 |
| 데이터 경로 | 전용 스토리지 네트워크(Fibre Channel 등)를 통해 백업 장치로 직접 전송됨 |
업무망(LAN)을 통해 백업 서버로 이동 후 백업 장치로 전송됨 |
| 구성 방식 | SAN 스위치, HBA, 전용 스토리지 구성 필요해 비교적 복잡함 |
기존 LAN 장비만 활용하므로 구성 방식이 간단함 |
| 전송 속도 | 16G/32G FC 등 고속 전용 경로로 매우 빠름 |
업무 트래픽과 함께 사용되므로 상대적으로 느림 |
| 네트워크 부하 | 백업 트래픽이 SAN 내부에서만 흐르므로 LAN 부하 없음 |
업무용 LAN 대역폭을 점유하여 부하 증가 가능 |
| 확장성 | 대규모 환경에 적합, 많은 서버/대용량 백업에 유리 |
소규모·중규모 환경에서 적합 |
| 비용 | SAN 장비, FC 스위치, HBA 등으로 비용이 높음 |
기존 네트워크를 활용해 비용이 낮음 |
| 관리 난이도 | Zoning, LUN Masking, 멀티패스 구성 등으로 관리 난이도 높음 |
별도 SAN 구성 없이 관리가 쉬움 |
| 적용 환경 | 금융기관, 공공기관, 대용량 DB, 가상화 환경 등 고성능·고안정성 요구 환경 |
중소기업 서버 백업, 사용자 PC 백업, 원격지/클라우드 백업 |
| 복구 속도 | 스토리지에 직접 접근하므로 빠름 | 네트워크 경유 복구라 상대적으로 느림 |
'cloud' 카테고리의 다른 글
| DevStack (0) | 2025.12.17 |
|---|---|
| 백업 방식 (0) | 2025.12.02 |
| 서버 용어 정리 (0) | 2025.12.02 |
| RAID (Redundant Array of Independent Disks) (0) | 2025.12.02 |
| 스토리지 용어 정리 (0) | 2025.12.01 |
