Skip to content

필사 모드: 오픈소스 백업 툴 2026 완벽 가이드 — Restic · BorgBackup · Kopia · Duplicati · Rclone · Bacula · Amanda · Veeam 대안 심층 분석

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 백업은 따분하다, 데이터가 사라지기 전까지는

회사에 있는 모든 사람이 한 번쯤 한다는 대화.

엔지니어: "DB가 날아갔어요."

PM: "백업은요?"

엔지니어: "있어요. 작년 11월 거요."

PM: "...복원해 본 적은 있어요?"

엔지니어: "아니요."

이게 2026년에도 매일 어디선가 벌어지는 풍경이다. 백업을 한다는 것과, 복원할 수 있다는 것은 **다른 일**이다. 그리고 백업 시스템을 운영한다는 것은 — **단순히 cron으로 tar 떠서 NAS에 던지는 것**과는 완전히 다른 문제다.

이 글은 2026년 현재 오픈소스 백업 도구 생태계의 지도다. Restic·BorgBackup·Kopia·Duplicati 같은 파일 레벨 도구부터, rclone·rsnapshot 같은 sync 기반, Bacula·Bareos·Amanda 같은 엔터프라이즈 OSS, Velero·Kasten 같은 K8s 백업, pgBackRest·WAL-G 같은 DB 백업, 그리고 LTO 테이프·B2·Wasabi·Storj 같은 콜드 스토리지까지.

1장 · 3-2-1 규칙 — 그리고 2026년의 3-2-1-1-0 변형

백업 전략의 골든 룰은 1980년대에 사진작가 Peter Krogh가 정립했다고 알려진 **3-2-1 규칙**이다.

- **3** copies — 원본 + 백업 2개

- **2** media types — 서로 다른 매체 (예: SSD + 테이프, NAS + 클라우드)

- **1** offsite — 한 개는 물리적으로 떨어진 곳에

2020년대 후반 랜섬웨어 시대에 들어서면서 업데이트된 변형이 **3-2-1-1-0** 이다.

- **1** immutable / air-gapped — 변경 불가능하거나 물리적으로 격리된 사본

- **0** errors — 정기적 검증으로 에러 0

랜섬웨어가 백업까지 암호화하는 시대에서, "변경 불가능한 사본 1개"는 더는 사치가 아니다. AWS S3 Object Lock, B2 Object Lock, immutable tape, write-once optical 같은 게 다 이 범주다.

핵심 통찰: **백업의 가치는 복원에 있다.** 복원해 본 적 없는 백업은 백업이 아니다 — 그냥 디스크 공간을 차지하는 파일이다.

2장 · 백업 유형 — 풀·증분·차분·synthetic full

용어부터 정리한다. 같은 단어를 다른 의미로 쓰는 게 백업 업계의 못된 전통이다.

| 유형 | 설명 | 복원 시간 | 저장 공간 | 백업 시간 |

| --- | --- | --- | --- | --- |

| Full | 전체 데이터를 매번 복사 | 빠름 (1세트만) | 크다 | 길다 |

| Incremental | 마지막 백업 이후 변경분만 | 느림 (full + 모든 incr 필요) | 작다 | 짧다 |

| Differential | 마지막 full 이후 변경분만 | 중간 (full + 마지막 diff) | 중간 | 중간 |

| Synthetic full | 기존 백업들을 서버 측에서 합쳐 가상 full 생성 | 빠름 | 크다 (논리적) | 매우 짧다 |

| Forever incremental | incremental만 영원히, dedup으로 압축 | 가변 | 작다 | 매우 짧다 |

Restic·Borg·Kopia 같은 현대 도구들은 **forever incremental + content-defined chunking + dedup** 모델이다. 매번 "full"을 뜨는 것처럼 동작하지만, 실제로는 변경된 청크만 저장한다. 이게 2020년대 백업 도구의 표준이 되었다.

3장 · Restic 0.18 — Go 진영의 표준

**Restic** (2014년 출시, Alexander Neumann)은 Go로 작성된 오픈소스(BSD 2-clause) 백업 도구다. 2026년 현재 0.18 버전이 공식 안정 버전이며, 자가 호스팅과 SRE 커뮤니티에서 사실상 표준에 가깝다.

특징.

- **암호화 기본** — AES-256-CTR, Poly1305-AES MAC, scrypt KDF

- **콘텐츠 정의 청킹 + dedup** — Rabin fingerprinting, 평균 1 MiB 청크

- **다양한 백엔드** — Local, SFTP, REST server, S3 호환 (AWS S3, Minio, Wasabi, Backblaze B2, ...), Azure Blob, Google Cloud Storage, OpenStack Swift, rclone(50+ 클라우드)

- **단일 정적 바이너리** — Go 빌드라 의존성 zero

- **스냅샷 기반** — 각 백업은 immutable한 snapshot

기본 사용 흐름.

저장소 초기화 (한 번만)

export RESTIC_REPOSITORY="s3:s3.amazonaws.com/my-backups"

export RESTIC_PASSWORD="strong-passphrase"

restic init

백업

restic backup /home/user --tag daily

스냅샷 목록

restic snapshots

복원

restic restore latest --target /restore

무결성 검증

restic check --read-data-subset=10%

보존 정책 (예: 일간 7개, 주간 4개, 월간 12개 유지)

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

장단점.

- 장점: 안전하고 빠르고, 백엔드 선택지가 풍부, 활발한 커뮤니티

- 단점: 단일 호스트에서 다중 작업 시 락 경합, prune이 느리다는 평이 있음(0.17부터 개선)

핵심: 처음 시작한다면 **Restic + S3 호환 백엔드(B2, Wasabi, Storj)** 조합이 2026년의 안전한 기본값이다.

4장 · BorgBackup 1.4 / 2.0 — Python 진영의 클래식

**BorgBackup**(2010년 Attic으로 시작, 2015년 fork되어 Borg가 됨)은 Python으로 작성된 BSD 라이선스 백업 도구다. 2026년 현재 1.4가 안정, 2.0이 베타 단계다.

특징.

- **클라이언트-서버 아키텍처** — SSH 위에서 동작, ssh-agent 통합

- **압축** — lz4, zstd, lzma 선택 가능

- **dedup + 청킹** — Buzhash 기반

- **암호화** — AES-256-CTR + HMAC-SHA256

- **append-only 모드** — 클라이언트가 과거 백업을 삭제하지 못함 (랜섬웨어 대비)

기본 사용.

저장소 초기화

borg init --encryption=repokey-blake2 user@backup.example.com:./backups

백업

borg create --stats --progress \

user@backup.example.com:./backups::myhost-{now} \

/home /etc /var

목록

borg list user@backup.example.com:./backups

마운트로 탐색 (복원 전에)

borg mount user@backup.example.com:./backups::myhost-2026-05-16 /mnt/borg

복원

borg extract user@backup.example.com:./backups::myhost-2026-05-16

보존 정책

borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=12 \

user@backup.example.com:./backups

**Borgmatic** — Borg의 declarative wrapper. YAML 설정 파일로 백업 스케줄, 보존 정책, hook, 알림을 통합 관리. systemd timer나 cron과 함께 가장 흔한 self-hosting 조합 중 하나.

Borg vs Restic 짧은 비교.

| 차원 | BorgBackup | Restic |

| --- | --- | --- |

| 언어 | Python | Go |

| 백엔드 | SSH 중심 (rsync.net 호환) | 다양한 클라우드 직접 지원 |

| 동시성 | 단일 클라이언트 권장 | 다중 클라이언트 |

| 압축 | lz4 / zstd / lzma | (없음, 0.16부터 옵션) |

| 마운트 | FUSE 지원 | FUSE 지원 (mount 명령) |

| 패키지 크기 | Python 의존성 | 단일 정적 바이너리 |

핵심: 단일 서버에서 SSH 백엔드(예: rsync.net, hetzner storagebox)로 쏘는 self-hoster들에게 Borg가 여전히 1순위. 다중 클라이언트나 클라우드 native 백엔드라면 Restic이 편하다.

5장 · Kopia 0.18 — GUI까지 가는 cloud-native

**Kopia**(2019년 Jarek Kowalski 시작, Apache 2.0)는 Go로 작성된 백업 도구로, GUI와 CLI를 모두 제공한다는 점이 차별점이다.

특징.

- **CLI + GUI(Desktop App)** — KopiaUI라는 일렉트론 기반 GUI 별도 제공

- **Content-addressable storage** — 사실상 git의 백업 버전

- **다양한 백엔드** — S3, B2, GCS, Azure, WebDAV, SFTP, Filesystem

- **압축** — zstd, gzip, s2 등

- **암호화** — AES-256-GCM

- **정책 기반** — 디렉터리별, 글로벌 정책 분리

기본 사용.

저장소 생성 (S3 백엔드)

kopia repository create s3 \

--bucket=my-kopia-backups \

--access-key=$AWS_ACCESS_KEY_ID \

--secret-access-key=$AWS_SECRET_ACCESS_KEY

백업

kopia snapshot create /home/user

목록

kopia snapshot list

복원

kopia snapshot restore <snapshot-id> /restore

검증

kopia content verify

정책

kopia policy set --keep-daily=7 --keep-weekly=4 /home/user

장점: GUI가 있어서 가족·소규모 팀이 쓰기 좋다, KopiaUI는 menu bar에 상주하면서 자동 백업 진행 상태 표시.

단점: Borg/Restic만큼의 운영 노하우 축적이 아직 적음, 일부 백엔드는 community 리포트.

핵심: **macOS/Windows에서 GUI로 시작하고 싶다면 Kopia**가 답에 가깝다.

6장 · Duplicati 2.0 — .NET 기반의 cross-platform GUI

**Duplicati**(2008년 시작, LGPL)는 .NET으로 작성된 GUI 중심 백업 도구다. 2026년 현재 2.0이 안정 stage(아직 beta 꼬리표를 떼지 못한 비판도 있지만, 사실상 대다수가 production에서 사용).

특징.

- **웹 기반 GUI** — `http://localhost:8200` 으로 접근

- **거의 모든 클라우드 지원** — 50+ 백엔드 (S3, B2, OneDrive, Google Drive, Dropbox, FTP, SSH, WebDAV, Mega, ...)

- **AES-256 암호화**

- **블록 기반 중복 제거**

- **Windows·macOS·Linux·Docker** 지원

장점: GUI 친화적, 일반 사용자 대상 마케팅. 작은 사이즈의 NAS·홈서버에 인기.

단점: .NET 런타임 의존성, 과거에 데이터베이스 손상 이슈 보고(2.0에서 많이 개선됨), 복원이 느리다는 평.

핵심: 비기술자가 GUI로 백업하고 싶다 → Duplicati. 단, 정기적인 검증과 테스트 복원이 더더욱 중요해진다.

**Duplicacy** — 이름이 비슷한 별개의 상용 도구. Personal $20 일회성. CLI는 OSS, GUI는 상용. Lock-free dedup이 차별점.

7장 · rclone 1.68 — "rsync for cloud storage"

**rclone**(2014년 Nick Craig-Wood 시작, MIT)은 엄밀히 말하면 백업 도구가 아니라 **클라우드 스토리지 sync 도구**다. 하지만 2026년 현재 워낙 많은 백업 워크플로의 핵심 컴포넌트가 되어서 빠뜨릴 수 없다.

특징.

- **50+ 클라우드 백엔드** — S3 호환, B2, GCS, Azure, OneDrive, Google Drive, Dropbox, pCloud, Mega, FTP, SFTP, WebDAV, Yandex, Box, ...

- **명령어** — `copy`, `sync`, `move`, `mount`, `serve`, `bisync` 등

- **암호화 백엔드** — `rclone crypt`로 다른 백엔드 위에 암호화 레이어

- **dedup** — `rclone dedupe`

- **bandwidth 제한, 병렬 전송, encryption**

대표적 활용.

- **백엔드** — Restic·Borg에서 `rclone:` 백엔드로 50+ 클라우드 지원

- **단독 sync** — `rclone sync /home gdrive:backup` 같은 단순 sync

- **암호화 레이어** — `rclone crypt`로 GDrive·OneDrive 같은 비암호화 저장소에 client-side 암호화

원격 설정 (한 번)

rclone config

동기화 (단방향)

rclone sync /home/user remote:backup --progress

양방향 (베타)

rclone bisync /home/user remote:backup

마운트 (read/write)

rclone mount remote:backup /mnt/cloud --vfs-cache-mode=full

크기 확인

rclone size remote:backup

핵심: **rclone은 백업 자체보다 백엔드 어댑터로 가장 강력**하다. Restic + rclone 조합이 사실상 2026년 self-hoster의 표준.

8장 · rsync + rsnapshot — 클래식, 여전히 유효

**rsync**(1996년 Andrew Tridgell)는 백업 도구 자체라기보다 파일 동기화 유틸리티지만, 가장 기본적이고 가장 널리 쓰이는 도구다.

기본 패턴.

로컬 → 원격 (SSH 위)

rsync -avzP --delete /home/user/ user@remote:/backup/user/

하드링크 기반 증분 (rsync 자체 기능)

rsync -avzP --delete --link-dest=/backup/2026-05-15 \

/home/user/ /backup/2026-05-16/

**rsnapshot**(Perl 기반)은 rsync를 활용해 시간대별 스냅샷을 자동 관리하는 도구. 설정 파일 하나로 hourly/daily/weekly/monthly 보존 정책을 선언적으로 운영. 2002년부터 거의 안 변한 안정적 도구.

/etc/rsnapshot.conf 예시 (탭 구분)

snapshot_root /var/backups/rsnapshot/

retain alpha 24 # 1시간마다, 24개 보관

retain beta 7 # 매일, 7개 보관

retain gamma 4 # 매주, 4개 보관

retain delta 12 # 매월, 12개 보관

backup /home/ localhost/

장점: 단순, 검증된 30년 노하우, 어떤 unix에서든 동작

단점: 암호화 없음(SSH 전송만), dedup이 파일 단위(블록 단위 아님), 압축 없음

핵심: 단순한 NAS-to-NAS 같은 단순 시나리오에서는 여전히 좋은 선택. 클라우드·암호화가 들어가면 Restic/Borg로 옮겨가는 게 표준.

9장 · Bacula / Bareos — 엔터프라이즈 OSS

**Bacula**(2000년 Kern Sibbald 시작, AGPLv3)는 엔터프라이즈급 백업·복원·검증 시스템이다. 컴포넌트가 분리되어 있다.

- **Director** — 백업 작업 관리 (스케줄, 카탈로그)

- **Storage Daemon** — 백업 매체에 실제 쓰기/읽기 (디스크, 테이프, 클라우드)

- **File Daemon** — 클라이언트에서 실행, 파일 시스템에 접근

- **Catalog DB** — MySQL/MariaDB/PostgreSQL — 백업 메타데이터

**Bareos**(2010년 Bacula에서 fork, AGPLv3)는 Bacula의 오픈소스 친화적 fork. 더 활발한 개발, 더 나은 웹 UI, 더 빠른 RHEL/SUSE 패키지.

언제 쓰나.

- 수십~수백 클라이언트 환경

- 테이프 라이브러리 운영(LTO)

- 엄격한 RPO/RTO + 감사 요구

- VSS, BMR(Bare Metal Restore) 필요

- 기존 Bacula/Bareos 운영 경험 보유

단점: 학습곡선 매우 가파름, 컴포넌트 분리로 설정 복잡, "그냥 켜고 잊는" 도구 아님.

핵심: 50대 미만 호스트라면 Restic/Borg + 중앙 저장소가 더 간단. 100대 이상 + 테이프 + 감사 요구가 있다면 Bareos가 진지한 선택.

10장 · Amanda — 또 하나의 엔터프라이즈 클래식

**Amanda**(Advanced Maryland Automatic Network Disk Archiver, 1991년 메릴랜드 대학 시작)는 30년 넘은 백업 시스템. BSD 라이선스. Zmanda가 enterprise 버전을 상용 지원.

특징.

- 단일 서버가 여러 클라이언트를 백업

- 테이프·디스크·클라우드 매체 지원

- holding disk(스테이징) 사용

- tar, dump, samba 등 다양한 백업 백엔드 활용

언제 쓰나.

- 레거시 운영 환경(특히 학술·금융)

- Bacula보다 단순한 구성을 원할 때

단점: 현대적 UI 부재, 신규 채택은 거의 없음.

핵심: 신규 프로젝트라면 굳이 선택할 이유는 약하다. 다만 기존 운영 자산이 있다면 안정적 유지보수 가치.

11장 · UrBackup — 클라이언트·서버 통합 솔루션

**UrBackup**(2011년 Martin Raiber, AGPL)은 클라이언트-서버 모델로 동작하는 백업 도구. Windows VSS, image-level 백업, 웹 UI 등 일반 사용자 친화 기능 다수.

특징.

- 웹 UI (`http://server:55414`)

- Windows VSS 통합 — 사용 중인 파일도 백업

- 파일 + 이미지(전체 디스크) 백업 둘 다

- 클라이언트 푸시/풀

- BTRFS/ZFS 활용 가능

장점: 가정·소규모 사무실 Windows 환경에 강함, 설치 즉시 사용 가능

단점: 대규모·엔터프라이즈에선 한계, 일부 사용자가 데이터베이스 손상 보고

핵심: 가정·소호의 Windows 중심 환경 → UrBackup이 좋은 trade-off.

12장 · Veeam 대안 — 상용 vs 오픈소스

Veeam Backup & Replication은 VM 백업 시장의 사실상 표준이다. 그러나 비싸고 vendor lock-in이 있어 대안 수요가 늘 있다.

상용 대안.

- **Cohesity DataProtect** — converged 백업 어플라이언스, immutability, AI 검색

- **Rubrik** — SaaS 백업, Polaris 클라우드 컨트롤 플레인

- **Commvault Cloud (Metallic)** — 30년 베테랑, SaaS 전환 진행

- **Druva** — 100% SaaS, edge-to-cloud

- **Acronis Cyber Protect** — 백업 + 사이버 보안 통합

오픈소스 / 무료.

- **Veeam Community Edition** — 10 VM/머신까지 무료

- **Proxmox Backup Server (PBS)** — Proxmox VE용, dedup·encryption·verification·sync 지원

- **Vinchin Backup & Recovery** — VMware, KVM, Proxmox 등 다양한 hypervisor 지원, free edition 있음

- **Nakivo Backup & Replication** — VM-NAS-SaaS 백업, free edition 있음

특히 **Proxmox Backup Server**는 Proxmox VE 클러스터 운영자에게 사실상 표준. 별도 라이선스 없이 dedup, 증분, 검증, sync 모두 무료로 제공.

핵심: Proxmox 쓰면 PBS, VMware 쓰면 Veeam CE/유료, 멀티 hypervisor라면 Vinchin/Nakivo.

13장 · 클라우드 네이티브 백업 — AWS·Azure·GCP

**AWS Backup** — EBS, EFS, RDS, DynamoDB, FSx, EC2 AMI, S3, Aurora, Neptune 등 통합 백업. 정책 기반, vault lock으로 immutable 가능.

**Azure Backup** — VM, SQL, SAP HANA, Files, Blobs 백업. Recovery Services Vault.

**Google Cloud Backup and DR** — Actifio 기반, application-aware backup.

이들은 vendor-managed라 운영 부담은 적지만, **lock-in**이 본질적 단점. 멀티클라우드라면 cross-cloud OSS(Restic + 멀티 백엔드)가 더 portable.

**Tarsnap** (Colin Percival, 2008년) — "online backups for the truly paranoid". 강력한 client-side 암호화, dedup, 가격 $0.25/GB/월 (compressed, deduped). 가격은 비싸 보이지만 dedup 후 실 청구가 매우 작다는 평. 보안 의식이 강한 개인·소기업에 인기.

**Backblaze B2** — $6/TB/월. S3 호환 API. Restic·rclone과 자주 조합됨.

**Backblaze Personal** — $9/월 unlimited (Mac/Win 데스크탑). 비기술자 대안.

**Wasabi** — S3 호환, $6.99/TB/월. egress 무료(공정사용 약관 있음). 콜드 스토리지 후보.

**Storj** — 분산형 S3 호환, $4/TB/월. 데이터가 여러 노드에 erasure coded로 분산.

14장 · LTO 테이프 — 2026년에도 살아있는 콜드 스토리지

테이프는 죽지 않았다. 오히려 2026년 콜드·아카이브 워크로드에서 GB/$ 효율이 단연 1위다.

| 세대 | 표준 용량(raw) | 압축 용량(2.5:1) | 출시 |

| --- | --- | --- | --- |

| LTO-7 | 6 TB | 15 TB | 2015 |

| LTO-8 | 12 TB | 30 TB | 2017 |

| LTO-9 | 18 TB | 45 TB | 2021 |

| LTO-10 | 36 TB | 90 TB | 2025 |

LTO-9의 실효 용량(raw, 18 TB)이 회사 백서에 따라 24 TB로 표기되는 경우도 있는데, 2026년 현재 LTO-9 카트리지의 표준 비압축 용량은 **18 TB**이다. LTO-10이 36 TB raw로 2024-2025년 출시되었다.

장점: 30년 아카이브 수명, 에어갭 본질, GB/$ 최저, 전력 0 (저장 시)

단점: 드라이브 비싸다(LTO-10 드라이브 수천 달러), 임의 접근 느림, 운영 오버헤드

핵심: 50 TB 이하 백업이면 클라우드 콜드 스토리지가 합리적. 500 TB+ 아카이브가 장기 보관되어야 한다면 테이프가 여전히 우월.

15장 · DB 백업 — pgBackRest · WAL-G · Percona XtraBackup

데이터베이스 백업은 일반 파일 백업과 **다른 문제**다. running DB의 파일을 그냥 복사하면 inconsistent snapshot이 나온다.

PostgreSQL.

- **pgBackRest** — 차분/병렬/증분, S3 호환 저장소, encryption, async archiving

- **Barman** — Postgres 백업/PITR 매니저, streaming + file-based

- **WAL-G** — Postgres·MySQL·MongoDB 멀티 DB, 클라우드 native

MySQL/MariaDB.

- **Percona XtraBackup** — 핫 백업, 비차단, InnoDB 친화

- **mysqldump** — 논리 백업, 작은 DB에 적합

- **MariaBackup** — XtraBackup의 MariaDB fork

- **WAL-G** (mysqlbinlog 활용)

MongoDB.

- **mongodump** — 논리 백업

- **mongoshake** — replica set 기반

- **Percona Backup for MongoDB** — 일관성 있는 분산 백업

Redis.

- **RDB snapshot** + **AOF append-only file** 조합

- replica를 백업 노드로 운영

핵심: DB 백업은 **PITR(Point-in-time Recovery)** 가능해야 한다. 마지막 full + 그 이후의 WAL/binlog 아카이브 → 임의 시점 복원. 단순 `pg_dump`는 small DB에만 충분.

16장 · K8s 백업 — Velero · Kasten K10

쿠버네티스 워크로드의 백업은 또 다른 차원이다. 매니페스트(YAML 상태), PV(데이터), 그리고 클러스터 간 마이그레이션까지.

- **Velero** (CNCF, VMware Tanzu) — 사실상 K8s 백업의 표준. CRD·PV snapshot·S3 백엔드. CSI 스냅샷 통합.

- **Kasten K10** (Veeam-owned) — 엔터프라이즈 K8s 백업, GUI, RBAC, multi-tenancy

- **CloudCasa by Catalogic** — SaaS 백업, K8s 전용

- **TrilioVault for Kubernetes** — application-consistent backup

- **Stash by AppsCode** — k8s-native, operator 패턴

Velero 기본 사용.

설치

velero install \

--provider aws \

--bucket my-velero-bucket \

--secret-file ./credentials-velero \

--backup-location-config region=us-east-1

백업

velero backup create my-backup --include-namespaces=production

복원

velero restore create --from-backup my-backup

스케줄

velero schedule create daily --schedule="0 2 * * *" --include-namespaces=production

핵심: K8s 운영자라면 Velero는 거의 필수. 엔터프라이즈 환경에서 GUI·RBAC·멀티테넌시가 필요하면 Kasten K10.

17장 · OS 레벨 스냅샷 — ZFS · Btrfs · LVM · APFS · Time Machine

파일시스템 레벨 스냅샷은 가장 빠르고 가장 일관성 있는 "백업의 기반"이다. 단, **스냅샷은 백업이 아니다** — 같은 디스크에 있으면 디스크 고장 시 같이 죽는다. 스냅샷은 백업의 **출발점**이다.

**ZFS**.

스냅샷

zfs snapshot tank/data@2026-05-16

목록

zfs list -t snapshot

송신 (스냅샷을 다른 풀로 전송)

zfs send tank/data@2026-05-16 | ssh backup-host zfs recv backup/data

**Btrfs**.

스냅샷

btrfs subvolume snapshot -r /data /data/.snapshots/2026-05-16

송신

btrfs send /data/.snapshots/2026-05-16 | ssh backup-host btrfs receive /backup/

**LVM**.

lvcreate --snapshot --size 10G --name data-snap-2026-05-16 /dev/vg0/data

**APFS (macOS)** — Time Machine은 APFS local snapshot을 기반으로 시간대별 복원 지원. macOS 11+ 부터 매시간 자동 스냅샷.

**TrueNAS Scale 24.04**, **OpenMediaVault** 같은 NAS OS는 ZFS 스냅샷 + replication을 UI로 관리.

**Synology Hyper Backup**(DSM 7.2), **QNAP HBS 3** — 가정용 NAS의 통합 백업 솔루션. 여러 destination(다른 NAS, 클라우드, USB 외장)으로 동시 백업.

핵심: 파일시스템 레벨 스냅샷은 "1초 만에 어제로 돌아가기"엔 최강. 디스크·전체 시스템 손실엔 무력. **스냅샷 + 외부 백업** 둘 다 있어야 진짜 백업이다.

18장 · 암호화 · 키 관리 — 잃어버리면 끝나는 게임

백업의 암호화에서 가장 중요한 결정은 **키를 어디에 둘 것인가**다.

- 키를 백업과 같은 곳에 두면 → 그건 암호화가 아니다(공격자가 같이 가져감)

- 키를 잃어버리면 → 백업도 함께 잃은 셈

옵션.

1. **Passphrase 기반** — KDF(scrypt, argon2)로 키 유도. Restic·Borg 기본.

2. **공개키 기반** — receiver의 공개키로 암호화, secret key는 별도 보관. `age`, `restic --pubkey` (실험적).

3. **외부 키 매니저** — HashiCorp Vault, AWS KMS, GCP KMS, 1Password Connect, Bitwarden Secrets Manager.

4. **Yubikey + KDF** — 하드웨어 토큰 기반.

원칙.

- **passphrase는 종이에 적어 별도 금고에** — 비밀번호 매니저 단일 의존 위험

- **3중 백업의 키 자체도 백업** — 키 매니저 자체의 백업 전략

- **알고리즘**: AES-256-GCM 또는 ChaCha20-Poly1305가 2026년 표준

- **양자내성?** — 데이터 백업에는 아직 우선순위 낮음, 그러나 long-term archive(20-30년)는 검토

핵심: 키 관리가 백업 시스템 전체의 단일 실패점이 될 수 있다. **passphrase 분실 = 데이터 분실** — 이 명제를 진지하게 받아들이지 않는 백업 시스템은 미완성이다.

19장 · 검증 · 복원 훈련 — 백업의 진짜 가치

**복원해 본 적 없는 백업은 백업이 아니다.** 이 한 줄을 절대 잊어선 안 된다.

검증 단계.

1. **체크섬 검증** — 도구별 명령

- Restic: `restic check --read-data-subset=10%`

- Borg: `borg check --verify-data`

- Kopia: `kopia content verify`

2. **샘플 복원** — 무작위 파일 몇 개 복원해서 hash 비교

3. **전체 복원 훈련** — 분기에 1번, 클린 환경에 실제 복원

4. **재해 시뮬레이션** — "DB가 다 날아갔다고 가정하고 1시간 안에 복원" 같은 game day

**모니터링**.

- 백업 성공/실패 알림 (Slack, Discord, PagerDuty, healthchecks.io)

- 백업 크기 추이 (갑자기 0이 되면 사고)

- 마지막 백업 시각 (24시간 초과 알람)

- 검증 결과 (월 1회 자동)

**healthchecks.io** — "백업이 매일 핑을 보내야 한다" 패턴. 핑이 오지 않으면 알람. cron + curl 조합으로 가장 단순한 dead-man-switch.

핵심: 백업이 일찍 실패하면 — 그건 행운이다. 늦게 실패하면 — 그건 재앙이다. 가능한 한 일찍 발견하는 시스템이 좋은 백업 시스템.

20장 · 한국·일본 자가호스팅 — NAS 중심 문화

한국과 일본은 가정용 NAS 보급률이 세계적으로 높은 편이다. 특히 Synology, QNAP, Buffalo, ASUSTOR 같은 NAS 어플라이언스가 발달.

**한국 시나리오**.

- 가정용 Synology DS923+ + 외장 USB 백업 + Synology C2 / B2 클라우드 sync

- 자가호스터(컨테이너 위주): Proxmox + ZFS + Restic to B2

- 사진/영상 백업: PhotoSync + Synology Photos + Glacier Deep Archive

**일본 시나리오**.

- Buffalo TeraStation 보급률 높음(엔터프라이즈 NAS)

- Synology / QNAP 가정용 인기

- ニフクラ(Nifty Cloud)·さくらインターネット(Sakura) 같은 일본 클라우드 백엔드 활용

**공통 패턴**: 가정 NAS → 클라우드 sync (B2, Wasabi, S3) → 분기 1회 외장 디스크 복사 + 금고 보관. 3-2-1 규칙의 가장 흔한 실제 구현.

핵심: NAS는 단일 매체다 — RAID 5/6가 있어도 그 자체로는 백업이 아니다. RAID는 가용성을 위한 것이고, 백업은 별도여야 한다.

21장 · 흔한 함정 — 안 하면 백업이 아니다

2026년에도 반복되는 백업 사고의 90%는 다음 함정 중 하나에 빠진다.

1. **복원 테스트 안 함** — 가장 흔하고 가장 치명적. 분기 1회는 무조건.

2. **단일 매체** — NAS 하나에만, 또는 클라우드 한 곳에만. 3-2-1을 무시.

3. **암호화 없음** — 분실·도난 시 그대로 노출. 클라우드 백엔드라면 client-side 암호화 필수.

4. **모니터링 없음** — "어제 백업이 실패한 걸 6개월 뒤에 발견" 패턴.

5. **passphrase 분실** — 키 매니저 단일 의존. 종이 백업 필요.

6. **권한 오류** — `sudo` 없이 백업해서 일부 파일 누락. dry-run + 권한 검증.

7. **DB를 파일로 백업** — running DB의 datadir을 그냥 tar — inconsistent. pg_dump 또는 pgBackRest 사용.

8. **랜섬웨어 대비 없음** — 백업 서버가 클라이언트에서 그대로 보이면 같이 암호화됨. append-only 또는 air-gapped 필요.

9. **보존 정책 없음** — 무한히 쌓아두다가 스토리지 비용 폭발 또는 GDPR/개인정보 보관 한도 위반.

10. **클라우드만 백업** — 클라우드 계정 해킹 시 끝. 클라우드 데이터의 로컬 백업도 필요.

핵심: 위 10가지 중 5개 이상에 해당한다면, 백업 시스템을 처음부터 다시 설계할 시점이다.

22장 · 의사결정 매트릭스 — 우리 팀은 뭘 써야 하나

| 시나리오 | 1순위 | 2순위 |

| --- | --- | --- |

| 개인 노트북(Mac) | Time Machine + Kopia/Restic to B2 | Backblaze Personal |

| 개인 노트북(Linux) | Restic to B2/Wasabi | Borg + rsync.net |

| 가정 NAS | Synology Hyper Backup → 클라우드 | rclone + B2 |

| 자가호스팅 1-5대 | Borg/Restic + SSH 백엔드 | Kopia + S3 |

| 자가호스팅 5-50대 | Restic + 중앙 REST server | Bareos |

| 엔터프라이즈 100대+ | Bareos + 테이프 | Commvault/Veeam |

| K8s 클러스터 | Velero + S3 | Kasten K10 |

| Postgres production | pgBackRest + WAL archive | Barman |

| MySQL production | Percona XtraBackup + binlog | WAL-G |

| VM 백업 (Proxmox) | Proxmox Backup Server | Vinchin |

| VM 백업 (VMware) | Veeam (유료) 또는 CE | Vinchin/Nakivo |

| 사진/영상 (가족) | Synology Photos + Glacier Deep Archive | iCloud + 외장 |

| 장기 아카이브 (10년+) | LTO 테이프 + 별도 보관 | Glacier Deep Archive |

23장 · 비용 — GB당 비용으로 환산

2026년 5월 기준 대략적 가격(USD/TB/월).

| 옵션 | 가격(USD/TB/월) | 비고 |

| --- | --- | --- |

| Backblaze B2 (hot) | $6 | egress $10/TB |

| Wasabi (hot) | $7 | egress 무료(공정사용) |

| Storj | $4 | 분산형, egress 별도 |

| AWS S3 Standard | $23 | 가장 비싼 hot |

| AWS S3 Glacier Instant | $4 | retrieval $10/TB |

| AWS S3 Glacier Deep Archive | $1 | retrieval 12-48h |

| Azure Blob Cool | $10 | |

| Azure Blob Archive | $1 | rehydrate 시간 필요 |

| GCP Coldline | $4 | 90일 최소 보관 |

| GCP Archive | $1.2 | 365일 최소 보관 |

| 가정 NAS (감가) | $1-3 | 4-bay NAS + HDD 환산 |

| LTO-9 (감가) | $0.3 | 18 TB 카트리지, 대량 시 |

핵심: 1 TB 미만이라면 Backblaze Personal($9/월 unlimited)이 가장 싸다. 10-100 TB 범위는 B2/Wasabi/Storj가 합리적. 100 TB+ 장기 아카이브라면 Glacier Deep Archive 또는 LTO.

24장 · 미래 — 2026년 백업 트렌드

- **불변성 강화** — Object Lock, immutable snapshot, WORM. 모든 백엔드의 기본 옵션화.

- **AI/ML 통합** — 백업 데이터에서 PII 자동 검출, anomaly detection으로 랜섬웨어 조기 탐지.

- **K8s 백업의 메인스트림화** — Velero가 사실상 표준화, 멀티 클러스터·멀티 클라우드 복원.

- **분산 스토리지** — Storj, Sia 같은 P2P/분산 스토리지가 niche를 확장.

- **양자내성 — 일부 도구는 검토 중** — long-term archive에서 점진적 채택.

- **백업 = 데이터 거버넌스** — GDPR·CCPA·PII 검출이 백업 도구의 기본 기능으로 통합.

- **edge backup** — 엣지 디바이스(IoT, edge K8s)의 백업이 새로운 카테고리로.

핵심: 2020년대의 "백업"은 단순한 파일 복사를 훨씬 넘어, **데이터 보호·재해 복구·컴플라이언스의 통합 플랫폼**으로 진화하고 있다.

25장 · 결론 — 따분하지만 가장 중요한 일

백업은 정말 따분하다. 잘 돌아갈 때는 아무도 신경 안 쓰고, 실패할 때는 모두가 화를 낸다. 보상이 비대칭이다.

그러나 백업은 **인프라의 양심**이다. 백업이 잘 운영되는 팀은 다른 운영도 잘하고, 백업이 엉망인 팀은 곧 다른 사고도 터진다. 백업 시스템은 그 팀의 신중함의 척도다.

이 글을 다 읽었다면, 다음 한 가지만 오늘 하라.

**가장 중요한 데이터의 최근 백업을 — 정말로 — 복원해 보라.**

복원이 된다면 좋다. 안 된다면, 오늘 그걸 발견한 게 인생 최고의 행운이다.

부록 · References (real URLs)

1. Restic — https://restic.net/

2. Restic Documentation — https://restic.readthedocs.io/

3. BorgBackup — https://www.borgbackup.org/

4. Borgmatic — https://torsion.org/borgmatic/

5. Kopia — https://kopia.io/

6. Duplicati — https://www.duplicati.com/

7. rclone — https://rclone.org/

8. rsnapshot — https://rsnapshot.org/

9. Bacula — https://www.bacula.org/

10. Bareos — https://www.bareos.com/

11. Amanda — http://www.amanda.org/

12. UrBackup — https://www.urbackup.org/

13. Velero — https://velero.io/

14. Kasten K10 — https://www.kasten.io/

15. pgBackRest — https://pgbackrest.org/

16. Barman — https://pgbarman.org/

17. WAL-G — https://github.com/wal-g/wal-g

18. Percona XtraBackup — https://www.percona.com/software/mysql-database/percona-xtrabackup

19. Proxmox Backup Server — https://www.proxmox.com/en/proxmox-backup-server

20. Backblaze B2 — https://www.backblaze.com/cloud-storage

21. Wasabi — https://wasabi.com/

22. Storj — https://www.storj.io/

23. Tarsnap — https://www.tarsnap.com/

24. LTO Ultrium — https://www.lto.org/

25. healthchecks.io — https://healthchecks.io/

26. Veeam Community Edition — https://www.veeam.com/virtual-machine-backup-solution-free.html

27. Synology — https://www.synology.com/

28. QNAP — https://www.qnap.com/

29. TrueNAS — https://www.truenas.com/

30. 3-2-1 Backup Rule (US-CERT) — https://www.cisa.gov/news-events/news/data-backup-options

현재 단락 (1/382)

회사에 있는 모든 사람이 한 번쯤 한다는 대화.

작성 글자: 0원문 글자: 17,073작성 단락: 0/382