公開2026.09.03更新2026.09.27 Kubernetes・コンテナ

Veleroとは？Kubernetesのバックアップと移行の仕組み・導入手順を解説

Velero（旧Heptio Ark）は、Kubernetesクラスタのリソース定義と永続ボリュームのデータを一組にしてバックアップし、別のクラスタへ復元できるオープンソースツールです。ライセンスはApache-2.0で、CNCFのSandboxプロジェクトとして開発が続いており、2026年9月時点の安定版は1.18系（1.18.2・2026年6月26日公開）です。この記事では、velero serverとnode-agentが分担する内部構造、CSIスナップショットとfs-backupとData Moverの選び分け、velero installから復元テストまでの実行フローを実装目線で整理します。あわせて、resticの段階的廃止など1.17〜1.18系で変わった前提と、採用が見合う構成・過剰になる構成の条件も押さえます。

まとめ：Veleroの採用条件と復元設計の結論

Veleroを入れる価値が出るのは、ステートフルなワークロードを含むクラスタを、丸ごと別クラスタや別リージョンへ戻す必要がある場合に限られます。逆に、クラスタ内の資産がすべてGitで宣言的に管理されていて永続ボリュームを持たない構成なら、Veleroの導入は運用コストの純増になります。判断軸は「マニフェストの復元」ではなく「データの復元先とその整合性」に置いてください。

実装面の要点は3つに絞れます。1つ目は、永続ボリュームの取り方をCSIスナップショット・fs-backup（kopia）・Data Moverから明確に選ぶこと。2つ目は、resticが1.17系以降で新規バックアップに使えず、1.19系以降は復元もサポート外になる前提で移行計画を持つこと。3つ目は、バックアップの成功ログを成果と見なさず、別namespaceへの復元テストを定期的に回すことです。この3点を外すと、障害発生時に「バックアップはあるのに戻せない」状態に陥ります。

Veleroが担うバックアップ対象とアーキテクチャ構成の全体像

Veleroの理解は、対象の二層構造とコンポーネントの役割分担から入ると早くなります。

クラスタリソースと永続ボリュームを一括で扱う二層のバックアップ構造

Veleroが扱う対象は二層に分かれます。上層はDeployment・Service・PVCといったKubernetesのリソース定義で、Kubernetes APIから取得したJSONをtar.gz化してオブジェクトストレージへ置く形です。下層は永続ボリュームの実データで、こちらはスナップショットかファイル転送のどちらかで別途退避されます。velero backup createを1回叩けば、この二層が同じバックアップ名の下にまとまり、リストア時も一組で戻ってきます。

注意したいのは、Veleroがetcdを直接読まない点です。取得経路はKubernetes APIであり、etcdスナップショットのようなクラスタ内部状態の完全コピーではありません。そのためコントロールプレーン自体の復旧手段にはならず、対象は「APIで表現できるリソースとPVデータ」に限られます。Kubernetesのリソースモデルから先に押さえたい場合は、Kubernetesの仕組みとDockerとの違いが前提になります。

velero serverとnode-agentの役割分担と常駐リソース

Veleroは3つの要素で動きます。クラスタ上のvelero server（Deployment・単一Pod）が全体の制御を担い、ローカルのCLI（veleroコマンド）が指示を出し、node-agent（DaemonSet）が各ノード上でボリュームのデータ転送を担当します。node-agentが要るのはfs-backupとData Moverを使う場合だけで、CSIスナップショットのみの運用ならDaemonSetは不要です。

1.18系では、このvelero server側の安定性に手が入りました。バックアップリポジトリ操作を遅延実行させることでVeleroサーバーのOOM Killを防ぐ変更が入り、多数のバックアップを扱う環境でのメモリ枯渇が起きにくくなっています。加えてバックアップの並行処理に対応したため、複数テナントが同時にバックアップを発行する構成でも待ち行列が伸びにくくなりました。逆に言えば、1.16系以前でOOMやキュー詰まりに悩んでいた環境は、1.18系への更新自体が対処になります。

保存先を決めるBackupStorageLocationの設定項目

保存先は2種類のカスタムリソースで表現されます。BackupStorageLocationがリソース定義とfs-backupデータの置き場（S3互換のオブジェクトストレージなど）、VolumeSnapshotLocationがボリュームスナップショットの取得先です。どちらもVeleroが登録するCRDで、kubectl get backupstoragelocationのように通常のKubernetesリソースとして参照・編集できます。

この設計の実務的な意味は、バックアップの状態がすべてクラスタ内のカスタムリソースとして可視化される点です。Backup・Restore・Schedule・PodVolumeBackupといったCRがそのまま監査対象になるため、監視系との連携もCRのステータス監視で組めます。CRDによる拡張の仕組み自体はKubernetes APIのリソース構造とCRD拡張で整理しています。

CSIスナップショットとファイルシステムバックアップの選択基準

Velero導入で判断を誤りやすいのが、永続ボリュームの取り方の選択です。3方式の前提と整合性の差を、環境条件から逆に決めます。

CSIドライバのVolumeSnapshotを使う方式と前提条件

CSIスナップショット方式は、ストレージ側の機能でボリュームの時点コピーを作ります。前提はCSIドライバがスナップショットに対応していることと、クラスタにVolumeSnapshotClassが定義されていることです。ブロックレベルで一瞬で取れるため、数百GBのボリュームでもバックアップ時間はほぼ一定に収まります。

方式	必要な前提	データ整合性	主な用途
CSIスナップショット	CSIドライバと対応Class	ブロック単位で高い	大容量PVの短時間退避
fs-backup（kopia）	node-agentとPodマウント	ライブFSのため弱い	CSI非対応の環境
Data Mover	CSIとnode-agentの両方	スナップショット由来	別リージョンへの災対

弱点は保存先です。CSIスナップショットは多くの場合、元のボリュームと同じストレージ基盤上に置かれます。リージョン障害やアカウント削除でボリュームごと失われるため、この方式単独では災対要件を満たしません。

kopiaでファイル単位に転送するfs-backupの制約と除外対象

fs-backup（File System Backup）は、Podにマウントされたボリュームの中身をファイル単位で読み、オブジェクトストレージへ転送します。アップローダーはKopiaで、重複排除と暗号化を担います。CSIドライバがスナップショットに対応していないオンプレ環境や、NFSベースのボリュームを含む構成での逃げ道がこれです。

制約は公式に明文化されていて、設計段階で必ず突き合わせるべき内容です。

hostPathボリュームは対象外（ローカルPVは対応）
ボリュームはPodにマウントされている必要があり、孤立したPVCとPVの組は取れない
データベースのような大容量ファイルは重複排除スキャンに長時間を要する
ライブのファイルシステムから読むため、スナップショット方式より整合性が弱い
emptyDir等の非PVCボリュームは、Pod再スケジュールで増分の連続性が失われる

オプトアウトモードでは、デフォルトのサービスアカウントトークン・Secret・ConfigMap・hostPathが自動的に除外されます。暗号化キーは静的なため、保存先バケットのアクセス制御が実質的な機密境界になる点も見落とせません。

Data Moverでスナップショットを外部ストレージへ退避

Data Moverは、前述したCSIスナップショットの「同じリージョンに残ってしまう」問題を埋める仕組みです。まずCSIでスナップショットを取り、そこから一時的なPVCを起こしてnode-agentがデータをオブジェクトストレージへ転送します。整合性はスナップショット由来で保たれたまま、保存先だけを外部へ出せる構造になっています。

1.18系ではこのData Moverに実務的な改善が2点入りました。1つはキャッシュボリュームの指定で、従来はノードのエフェメラルディスクを消費して枯渇させることがあった処理に、専用のボリュームを割り当てられるようになりました。もう1つは増分サイズの観測で、増分バックアップでどれだけデータ量が減ったかを数値で確認できます。あわせて診断イベントが追加され、Data Mover Podが失敗した際の原因追跡は1.17系より短時間で済むようになっています。

resticの新規バックアップ停止とv1.19での復元サポート終了

resticを使っている環境は、移行の期限が決まっている点を把握してください。v1.17以降、新規バックアップでのrestic使用は禁止されました。既存のresticバックアップからの復元はまだ可能ですが、v1.19以降は復元もサポート対象外になります。

つまり、resticで取った過去バックアップを保持したまま1.19系へ上げると、その資産は復元手段を失います。取るべき順序は明確です。1.18系のうちにkopiaベースのfs-backupへ切り替えて新しい世代を作り、restic世代の保持期間が満了するのを待ってから1.19系へ上げてください。逆に、restic世代を長期保管する要件があるなら、Velero外の手段でデータを取り出して保管形式を変える判断が要ります。

velero installから初回リストア検証までの実行フロー

導入は3段階に分かれます。プラグイン付きのインストール、バックアップ定義、そして復元テストです。

プラグイン指定とcredentials渡しを含む初期導入手順

Veleroはクラウドごとの処理をプラグインに分離しているため、インストール時にどのプロバイダプラグインを入れるかを明示します。

CLIを入れ、velero version --client-onlyでクライアント版数を確認する
保存先バケットと、そこへ書き込めるIAM資格情報またはワークロードアイデンティティを準備する
velero installにプロバイダプラグイン・バケット名・資格情報ファイルを渡して実行する
fs-backupまたはData Moverを使うなら--use-node-agentを付けてDaemonSetを展開する
BackupStorageLocationのフェーズがAvailableになることを確認する

CLIによるインストールのほかに、Helmチャート経由の導入も選べます。GitOpsでクラスタ構成を管理しているなら、values定義を宣言的に持てるHelm経由のほうが再現性で有利です。チャートとリリースの基本操作はHelmのチャート・リポジトリ・リリースの扱い方で確認できます。既存環境の更新では、CLIを入れ替えたうえでCRDを更新し、Deploymentとnode-agentのイメージを差し替える順序を守ってください。1.17系から1.18系へは段階を飛ばさない更新が前提です。

Scheduleによる定期実行とTTLで決まる保持期間の設計

単発のvelero backup createを手で叩く運用は続きません。Scheduleリソースにcron式を書き、そこにバックアップ仕様を埋め込みます。保持期間はTTLで決まり、期限が切れたバックアップはリソース定義もオブジェクトストレージ上のデータもGCで削除されます。TTLを長く取りすぎるとストレージ費用が線形に増えるため、復旧要件から逆算した値を置いてください。

対象の絞り込みでは、1.18系で入ったnamespaceのglobフィルタが効きます。従来は列挙が必要でしたが、ワイルドカードのパターンで一括指定できるようになり、命名規約でnamespaceを分けている環境ではSchedule定義が短く収まります。同じく1.18系のVolumePolicyはPVCフェーズを条件に使えるようになり、PendingやLostのPVCをスキップする指定が可能です。開発環境で放置された未束縛PVCがバックアップを落とす事故は、これで減ります。

復元テストを別namespaceで回す検証手順と合否の確認項目

バックアップの成功ログは、復元できる証拠になりません。検証はvelero restore createにnamespaceマッピングを与え、元と別のnamespaceへ戻す形で回します。本番namespaceを上書きせずに済むため、平日日中でも実施できます。

確認項目は4つです。Restoreリソースのフェーズが警告なしでCompletedになること、PVCが新しいPVにBoundされること、Pod内から実データの中身が読めること、そしてアプリケーションが起動して整合性チェックを通ることです。特に3つ目と4つ目を省略した検証は意味を持ちません。復元にかかった時間も併せて記録し、目標復旧時間との差分を追ってください。

Veleroの採用が見合う構成と過剰投資になる構成の判断条件

ここからは判断の章です。導入すべき要件と、入れても回収できない構成を条件付きで示します。

マネージドKubernetesでもVeleroが要る具体的な要件

EKS・AKS・GKEを使っていても、次の3要件のいずれかに当たるならVeleroを入れる価値があります。1つ目は、クラスタ間・リージョン間でワークロードを丸ごと移す予定があること。マネージドのバックアップ機能はクラスタ単位に閉じることが多く、別クラスタへの復元手段には向かないためです。

2つ目は、namespace単位やラベル単位の粒度で戻す要件があること。誤操作で1つのnamespaceだけ消えた場合、クラスタ全体を巻き戻す手段では復旧できません。3つ目は、Kubernetesのリソース定義とPVデータを同一時点の組として扱う必要があること。マニフェストはGit、データはストレージのスナップショットという分離運用では、両者の時点がずれて復元後に不整合が出ます。

Veleroを見送るべき構成とマネージドサービスで足りる条件

見送るべき構成もはっきり言えます。永続ボリュームを一切持たないステートレス構成で、マニフェストがすべてGitで管理され、クラスタ自体をIaCで再作成できる環境ではVeleroは不要です。復旧手段は「クラスタを作り直してGitから再適用する」で足り、バックアップすべき状態がクラスタ内に存在しません。

データがRDSやCloud SQLのようなマネージドデータベースに寄っている構成も同様です。この場合の復旧対象はデータベース側にあり、そこはデータベース自身のバックアップ機能で押さえるべき範囲になります。AWS環境で対象サービスと料金体系を先に確認したいなら、AWS Backupの対応サービスとバックアッププランを比較材料にしてください。判断の分岐点は「クラスタ内のPVに、他のどこにも複製がないデータが存在するか」の一点です。

バックアップは成功するのに復元で詰まる典型的な失敗パターン3件

Veleroの事故は、バックアップ工程ではなく復元工程で表面化します。実装時に踏みやすい失敗は次の3つです。

CSIスナップショットのみで運用し、リージョン障害でボリュームとスナップショットを同時に失う
fs-backupでデータベースのライブファイルを取り、復元後にアプリケーションが起動しない
復元先クラスタのCSIドライバやStorageClass名が違い、PVCがBoundされないまま止まる

3つ目は特に、移行目的で導入した環境で頻発します。対策は復元時のStorageClassマッピング指定を手順に組み込むことと、移行先クラスタで空のPVCを1つ作ってBoundを確認しておくことです。1つ目への対策はData Moverの併用、2つ目への対策はCSIスナップショットへの切り替えか、データベース側の論理バックアップとの併用になります。

復旧目標と運用体制から逆算するバックアップ運用設計の具体的な進め方

Veleroの設計は、ツールの機能比較から始めると必ず迷います。先に決めるべきは目標復旧時間と目標復旧時点の2つで、そこから保存先の数・TTL・取得方式が機械的に導かれます。目標復旧時点が1時間なら日次Scheduleでは要件を満たせず、目標復旧時間が30分ならfs-backupの転送時間が制約です。

次に決めるのは体制です。復元テストを月次で回し、Kubernetesの版数更新に合わせてVeleroの互換性マトリクスを確認する作業は、誰かの定常業務として置かないと必ず抜けます。1.18系のテスト済みKubernetesは1.33.7・1.34.1・1.35.0であり、クラスタを上げるたびにこの表と突き合わせる運用が前提です。この定常運用まで自社で回すのが難しいなら、Kubernetes基盤の保守運用と内製化支援で復旧設計から復元テストの手順化までを切り出す選択肢もあります。

よくある質問

Velero導入の検討時に実際によく挙がる質問を、実装上の前提とあわせて整理します。

Veleroは無料で使えますか？

Velero本体はApache-2.0ライセンスのオープンソースで、ライセンス費用はかかりません。CNCFのSandboxプロジェクトとして開発が続いています。ただし実費は発生します。バックアップデータを置くオブジェクトストレージの容量課金、CSIスナップショットの保持課金、Data Moverを使う場合のデータ転送料が主な内訳です。増分でどれだけ削減できているかは1.18系の増分サイズ観測で確認でき、TTLの設定値がそのままストレージ費用に反映されます。

VeleroとAWS Backupはどちらを使うべきですか？

対象の粒度が違うため、置き換え関係ではありません。AWS Backupはボリュームやデータベースといったリソース単位で扱い、Veleroはnamespaceやラベルで括ったKubernetesのリソース定義とPVを同一時点の組として扱います。Kubernetes上でステートフルなアプリケーションを動かし、namespace単位で戻したい要件があるならVeleroが要ります。データがRDSに寄っていてクラスタがステートレスなら、AWS Backup側だけで足りるはずです。

Veleroでetcdのバックアップはできますか？

できません。VeleroはKubernetes API経由でリソースを取得する設計で、etcdのデータストアを直接読むわけではないためです。したがってコントロールプレーンの障害復旧手段としては使えません。etcdスナップショットが必要な場合はetcdctlなどの手段を別に用意します。マネージドKubernetesではコントロールプレーンがクラウド側の管理範囲なので、そもそもetcdバックアップは利用者の作業対象になりません。Veleroが担うのはワークロード側の復旧です。

Veleroのバックアップはどこに保存されますか？

リソース定義とfs-backupのデータはBackupStorageLocationで指定したオブジェクトストレージ（S3互換ストレージなど）に置かれます。CSIスナップショットはVolumeSnapshotLocationの指定に従い、多くは元のボリュームと同じストレージ基盤上に作られます。この保存先の違いが災対設計を左右する分岐点です。リージョン障害に備えるなら、Data Moverでスナップショットのデータをオブジェクトストレージへ移すか、別リージョンのBackupStorageLocationを追加登録してください。

Veleroでクラスタ間の移行はできますか？

クラスタ移行はVeleroの主要な用途の1つです。移行元でバックアップを取り、移行先クラスタに同じBackupStorageLocationを読み取り権限で登録すると、バックアップ一覧が同期されて復元できます。実務上の詰まりどころはStorageClass名の不一致で、復元時のマッピング指定を手順に含めておく必要があります。Kubernetes版数が離れているとAPIバージョンの差でリソースが弾かれるため、移行元と移行先の版数差を小さく保つ段取りが前提です。