第1弾の記事では VBR から VBA アプライアンスのデプロイを行い、第2弾の記事では S3 を External Repository として登録し、Rocky Linux のバックアップポリシー作成までを完了しました。

本記事は連載の総括として、作成したポリシーを手動実行し、「バックアップ処理中に AWS で何が起きているのか」「実スループット」「オリジナル容量と S3 保存容量・スナップショット容量の比較」を検証します。

第1弾記事：Veeam Backup for AWSの導入手順｜VBR 13からAWSへVBAアプライアンスを展開
第2弾記事：Veeam Backup for AWSの設定手順｜VBR 13からAmazon S3へEC2バックアップを構成

検証環境

対象となる EC2 インスタンス、および主要な構成のスペックは以下の通りです。

• VBR: Windows Server 2025 Datacenter / t3.xlarge (16GB RAM)
• VBA: Ubuntu Linux / t3.medium (4GB RAM)
• バックアップ対象EC2 (WP): Rocky Linux 9.6 / t2.small (2GB RAM / 50GiB EBS)
• 保管先リポジトリ (Linux): Amazon S3 バケット (vbr-ec2)

構成および動作概要を以下に図示します。

バックアップ対象の Rocky Linux の内部ファイル使用量

# df -h
ファイルシス        サイズ  使用  残り 使用% マウント位置
devtmpfs              4.0M     0  4.0M    0% /dev
tmpfs                 1.4G     0  1.4G    0% /dev/shm
tmpfs                 556M   50M  506M    9% /run
/dev/mapper/rl-root    44G   11G   33G   25% /
/dev/sda1             960M  485M  476M   51% /boot
tmpfs                 278M   32K  278M    1% /run/user/0

バックアップジョブの手動実行（VBRからのキック）

前回記事でスケジュールを “Off” にしたため、手動でジョブを開始します。

VBR コンソールの左側メニュー「Home」→「Jobs」→「Backup」を開き、作成した Backup-RockyLinux を右クリックして 「Start」 をクリックします。

ジョブを開始すると、ステータスが「Waiting for backup infrastructure resources availability」となり、バックアップインフラ（転送用の Worker など）の準備が自動的に始まります。

バックアップ処理中のAWS側の挙動とWorkerの諸元

ジョブが開始されると、AWS でどのようなリソース操作が行われるのかを EC2 マネジメントコンソールで追跡しました。

一時 Worker インスタンスの自動プロビジョニング

バックアップが開始されて数分後、EC2 インスタンス一覧に VBA_worker（i-0dffee9af12bc7826）というインスタンスが自動的に立ち上がってきました。

この Worker インスタンスは、EBS スナップショットを基に再作成された EBS ボリュームをアタッチし、そこからブロックデータを読み取るための一時的なワーカー VM です。読み取ったデータに対して Veeam Data Mover によるデータ処理を行い、Veeam 独自形式のバックアップファイルとして S3 リポジトリへ転送します。

バックアップセッションが完了すると、Worker インスタンスは自動的に削除（Terminate）されます。

Workerインスタンスのスペック

自動生成されたWorkerインスタンスを確認したところ、以下の仕様であることが分かります。

• インスタンスタイプ: c6a.large（2 vCPU / 4 GiB メモリ / AMD EPYCプロセッサ搭載のインスタンス）
• AMI名: al2023-ami-2023.12.20261102.0-kernel-6.1-x86_64
• ベースOS: Amazon Linux 2023（カーネル 6.1）
• IAMロール: VBR-VBA-VeeamInstanceBackupRestoreAccessRoleV1-*

VBA 自体は Ubuntu Server ベースですが、データ転送用の Worker には Amazon Linux 2023 公式 AMI が起動されていることを確認しました。この Worker のインスタンスタイプは、Veeam の Worker Profile に基づいて選択されます。

ネットワーク面では、一時的なパブリック IPv4 アドレスが割り当てられて S3 エンドポイントおよび VBA と通信を行っています。

EBSスナップショットの自動生成

同時に、AWS の「スナップショット」画面を確認すると、対象 EC2 ボリュームの EBS スナップショット（snap-0fb0a58e69cbeb70f）が自動取得されていました。

Description 欄には以下のようにポリシー名・ボリューム ID ・インスタンス ID が自動で記録されており、AWS コンソール上から見ても Veeam のどのジョブで生成されたかが識別できるようになっています。

Veeam snapshot. Policy: Backup-RockyLinux, Volume: vol-032aef7146966cd06, Instance: i-0ddb72c8f5f252585

以下、AWS コンソールのスナップショット状態。

実行結果とスループット検証

処理時間と実効転送速度

バックアップ処理はエラーなく正常終了（Success）しました。VBR のジョブ統計から確認できる主要メトリクスは以下の通りです。

実転送処理（7.7 GB transferred.）自体は 4分28秒 で完了しており、AWS のネットワーク帯域と c6a.large の処理能力を活かした高速なスループットを記録しました。
全体としては、Worker の起動・初期化などを含む総所要時間は 6 分 43 秒となります。

二重保護アーキテクチャの確認（スナップショット＋S3）

セッションログ（Last 24 Hours）を確認すると、VBA が2段階の保護を行っていることが分かります。

■Snapshot セッション（12:22～12:24 / 約2分）:
即時リストア用の EBS スナップショットを AWS ネイティブに作成。

■Backup セッション（12:22～12:28 / 約6分）:
スナップショットから Worker 経由で S3 へバックアップファイルを転送。

容量比較（OS 使用量 vs スナップショット vs S3 保存量）

今回のフルバックアップによって、各ストレージ層でどの程度の容量が消費されたかを整理・比較しました。

OS 上の実データ（約11.5GB）に対して、S3 への保存容量は 7.69GB まで圧縮・削減されています。ゼロブロックのスキップと Veeam 独自エンジンの高圧縮機能が効果的に機能していることが分かります。

なお、Veeam のオブジェクトストレージ書き込みは、大容量の単一ファイルをそのまま置くのではなく、数MB単位のブロックオブジェクトに細分化して並行アップロードを行うため、オブジェクト数が 16,000個超 へと大幅に増加している点もクラウドネイティブバックアップ特有の挙動です。

まとめ

3回にわたって検証してきた「VBR 13 とVeeam Backup for AWS による EC2 バックアップ」ですが、実際にジョブを実行してAWS の挙動を確認することで、アーキテクチャが理解できました。

■常時稼働コストの最小化:
データ転送を担う Worker インスタンス（c6a.large）はジョブ実行時のみ一時的に起動し、完了後は即時Terminate されるため、EC2 の無駄な常時稼働コストが発生しません。

■ハイブリッドなリカバリ設計:
直近の障害には高速な EBS スナップショットから数分で復旧し、中長期の保管やディザスタリカバリには安価なS3 バケット上のバックアップファイルを活用するという、異なる復旧方式を併用できる点が特徴です。

■オンプレミスと AWS の統合運用:
AWS 上のアプライアンスで完結する仕組みでありながら、オンプレミス・クラウドどちらの VBR コンソールからもスナップショットと S3 バックアップを一元管理・監視できる点は、ハイブリッドクラウド運用において重要な要素になります。

AWS 上における Veeam バックアップ環境を構築する際の参考になれば幸いです。