オープンソース・バックアップツール 2026 完全ガイド — Restic · BorgBackup · Kopia · Duplicati · Rclone · Bacula · Amanda · Veeam 代替の徹底比較

プロローグ — バックアップは退屈だ、データが消えるまでは

どの会社でも一度はあるという会話。

エンジニア:「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 — 1 つは物理的に離れた場所に

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

用語を整理する。同じ単語を別の意味で使うのがバックアップ業界の悪しき伝統である。

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 ビルドなので依存ゼロ
• スナップショットベース — 各バックアップは 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 年に Borg として fork)は 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 の宣言型ラッパー。YAML 設定で scheduling、retention、hook、通知を統合管理。systemd timer や cron と組み合わせて、もっとも多いセルフホスティング構成の一つ。

Borg vs Restic 短い比較。

要点: 単一サーバから SSH バックエンド(rsync.net、hetzner storagebox など)に投げるセルフホスターは Borg が依然第一候補。複数クライアントやクラウドネイティブのバックエンドなら Restic が便利。

5. Kopia 0.18 — GUI まである cloud-native

Kopia(2019 年 Jarek Kowalski 開始、Apache 2.0)は Go で書かれたバックアップツールで、GUI と CLI を両方提供することが差別化ポイント。

特徴。

• CLI + GUI(Desktop App) — KopiaUI という Electron ベース 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 はメニューバー常駐で自動バックアップの進行を表示。

短所: Borg/Restic ほど運用ノウハウが蓄積されていない、一部バックエンドは community 報告。

要点: macOS / Windows で GUI から始めたいなら Kopia が近い答え。

6. Duplicati 2.0 — .NET ベースのクロスプラットフォーム GUI

Duplicati(2008 年開始、LGPL)は .NET で書かれた GUI 中心のバックアップツール。2026 年現在 2.0 が安定段階(まだ「beta」の名残があるという批判もあるが、多くは production で使用)。

特徴。

• Web 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」

rclone(2014 年 Nick Craig-Wood 開始、MIT)は厳密にはバックアップツールではなく クラウドストレージ同期ツール だ。しかし 2026 年現在、あまりに多くのバックアップワークフローのコアコンポーネントになっているため外せない。

特徴。

• 50+ クラウドバックエンド — S3 互換、B2、GCS、Azure、OneDrive、Google Drive、Dropbox、pCloud、Mega、FTP、SFTP、WebDAV、Yandex、Box、…
• コマンド — copy、sync、move、mount、serve、bisync ほか
• crypt バックエンド — rclone crypt で他のバックエンド上に暗号化レイヤー
• dedup — rclone dedupe
• 帯域制限、並列転送、暗号化

代表的な活用。

• バックエンド — 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 年セルフホスターの標準。

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    # 毎時、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。より活発な開発、より良い Web 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 がエンタープライズ版を商用サポート。

特徴。

• 単一サーバが複数クライアントをバックアップ
• テープ・ディスク・クラウド媒体対応
• holding disk(ステージング)を使用
• tar、dump、samba など多様なバックエンドを活用

いつ使うか。

• レガシー運用環境(特に学術・金融)
• Bacula よりシンプルな構成を望むとき

短所: 現代的な UI 不在、新規採用はほぼ無し。

要点: 新規プロジェクトでは選ぶ理由が薄い。ただし既存運用資産があれば安定メンテナンス価値あり。

11. UrBackup — クライアント・サーバ統合ソリューション

UrBackup(2011 年 Martin Raiber、AGPL)はクライアント・サーバモデルで動作するバックアップツール。Windows VSS、image-level バックアップ、Web UI など一般ユーザフレンドリーな機能が多い。

特徴。

• Web UI(http://server:55414)
• Windows VSS 統合 — 使用中のファイルもバックアップ
• ファイル + イメージ(ディスク全体)バックアップの両方
• クライアント push/pull
• BTRFS/ZFS 活用可

長所: 家庭・小規模オフィスの Windows 環境に強い、インストール即使用可。 短所: 大規模・エンタープライズでは限界、一部ユーザがデータベース破損を報告。

要点: 家庭・SOHO の Windows 中心環境なら UrBackup が良い trade-off。

12. Veeam 代替 — 商用 vs オープンソース

Veeam Backup and Replication は VM バックアップ市場の事実上の標準だ。しかし高価でベンダーロックインがあるため、代替需要は常にある。

商用代替。

• 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・暗号化・検証・sync 対応
• Vinchin Backup and Recovery — VMware、KVM、Proxmox 等多様な hypervisor 対応、free edition あり
• Nakivo Backup and 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。

これらはベンダ管理のため運用負担は少ないが、ロックイン が本質的弱点。マルチクラウドなら cross-cloud OSS(Restic + マルチバックエンド)のほうがポータブル。

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 位だ。

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

データベースのバックアップは一般ファイルバックアップとは 別の問題 だ。動作中の DB のファイルを単にコピーすると inconsistent な snapshot になる。

PostgreSQL。

• pgBackRest — 差分・並列・増分、S3 互換ストレージ、暗号化、async archiving
• Barman — Postgres バックアップ・PITR マネージャ、streaming + file-based
• WAL-G — Postgres・MySQL・MongoDB マルチ DB、クラウドネイティブ

MySQL / MariaDB。

• Percona XtraBackup — ホットバックアップ、非ブロッキング、InnoDB フレンドリー
• mysqldump — 論理バックアップ、小規模 DB に適合
• MariaBackup — XtraBackup の MariaDB fork
• WAL-G(mysqlbinlog 活用)

MongoDB。

• mongodump — 論理バックアップ
• mongoshake — レプリカセットベース
• Percona Backup for MongoDB — 整合性のある分散バックアップ

Redis。

• RDB snapshot + AOF append-only file の組み合わせ
• レプリカをバックアップノードとして運用

要点: DB バックアップは PITR(Point-in-Time Recovery) 可能でなければならない。最終 full + その後の WAL/binlog アーカイブ → 任意時点の復元。単純な pg_dump は小規模 DB のみで十分。

16. K8s バックアップ — Velero · Kasten K10

Kubernetes ワークロードのバックアップは別次元。マニフェスト(YAML 状態)、PV(データ)、そしてクラスタ間マイグレーションまで。

• Velero(CNCF、VMware Tanzu)— 事実上 K8s バックアップの標準。CRD・PV snapshot・S3 バックエンド。CSI snapshot 統合。
• Kasten K10(Veeam 傘下)— エンタープライズ 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 snapshot + replication を UI から管理。

Synology Hyper Backup(DSM 7.2)、QNAP HBS 3 — 家庭用 NAS の統合バックアップソリューション。複数 destination(他 NAS、クラウド、USB 外付け)へ同時バックアップ。

要点: ファイルシステムレベル snapshot は「1 秒で昨日に戻る」には最強。ディスク・全システム消失には無力。snapshot + 外部バックアップ 両方あって初めて本当のバックアップ。

18. 暗号化 · 鍵管理 — 失えば終わるゲーム

バックアップ暗号化でもっとも重要な決定は 鍵をどこに置くか だ。

• 鍵をバックアップと同じ場所に置く → それは暗号化ではない(攻撃者は両方を奪う)
• 鍵を紛失する → バックアップも失った

選択肢。

1. パスフレーズベース — KDF(scrypt、argon2)で鍵を導出。Restic・Borg のデフォルト。
2. 公開鍵ベース — 受信者の公開鍵で暗号化、秘密鍵は別途保管。age、restic --pubkey(実験的)。
3. 外部鍵マネージャ — HashiCorp Vault、AWS KMS、GCP KMS、1Password Connect、Bitwarden Secrets Manager。
4. Yubikey + KDF — ハードウェアトークンベース。

原則。

• パスフレーズは紙に書いて別の金庫に — パスワードマネージャ単一依存はリスク
• 3 重バックアップの鍵自体もバックアップ — 鍵マネージャ自体のバックアップ戦略
• アルゴリズム: AES-256-GCM または ChaCha20-Poly1305 が 2026 年の標準
• 量子耐性? — データバックアップではまだ優先度低いが、long-term archive(20-30 年)では検討

要点: 鍵管理がバックアップシステム全体の単一障害点になり得る。パスフレーズ紛失 = データ紛失 — この命題を真剣に受け止めないバックアップシステムは未完成だ。

19. 検証 · リストア訓練 — バックアップの真の価値

リストアしたことのないバックアップはバックアップではない。この一行は絶対に忘れてはならない。

検証ステップ。

1. チェックサム検証 — ツール別コマンド
   • Restic: restic check --read-data-subset=10%
   • Borg: borg check --verify-data
   • Kopia: kopia content verify
2. サンプルリストア — ランダムファイルをいくつか復元してハッシュ比較
3. 完全リストア訓練 — 四半期に 1 回、クリーン環境に実際にリストア
4. 災害シミュレーション — 「DB がすべて飛んだ前提で 1 時間以内に復旧」のような game day

モニタリング。

• バックアップ成功・失敗アラート(Slack、Discord、PagerDuty、healthchecks.io)
• バックアップサイズ推移(突然 0 になったら事故)
• 最終バックアップ時刻(24 時間超アラーム)
• 検証結果(月 1 回自動)

healthchecks.io — 「バックアップが毎日 ping を送るべき」パターン。ping が来なければアラーム。cron + curl の組み合わせでもっとも単純な dead-man-switch。

要点: バックアップが早く失敗するならそれはラッキー。遅く失敗したら災害。可能な限り早く発見するシステムが良いバックアップシステム。

20. 日本 · 韓国のセルフホスティング — NAS 中心の文化

日本と韓国は家庭用 NAS の普及率が世界的に高い。特に Synology、QNAP、Buffalo、ASUSTOR のような NAS アプライアンスが発達。

日本のシナリオ。

• Buffalo TeraStation 普及率が高い(エンタープライズ NAS)
• Synology / QNAP 家庭用人気
• ニフクラ(Nifty Cloud)・さくらインターネット(Sakura)のような国内クラウドバックエンドを活用

韓国のシナリオ。

• 家庭用 Synology DS923+ + 外付け USB バックアップ + Synology C2 / B2 クラウド sync
• セルフホスター(コンテナ中心): Proxmox + ZFS + Restic to B2
• 写真・動画バックアップ: PhotoSync + Synology Photos + Glacier Deep Archive

共通パターン: 家庭 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. パスフレーズ紛失 — 鍵マネージャ単一依存。紙バックアップ必須。
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. 意思決定マトリクス — うちのチームは何を使うべきか

23. コスト — GB 当たりコスト換算

2026 年 5 月時点のおおよその価格(USD/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 (CISA) — https://www.cisa.gov/news-events/news/data-backup-options