バックアップウィンドウが本番稼働時間に食い込んでしまう場合、その問題がVeeam単独に起因することはほとんどありません。ジョブの処理が遅い場合、その原因は通常、ストレージ、プロキシ、リポジトリ、ネットワーク、あるいはジョブの設計における競合にあります。Veeamのパフォーマンスチューニングにおける最良の方法は、まず実際のボトルネックを特定し、その後、スループットを低下させているコンポーネントをチューニングすることに重点を置くことです。
この特定作業は重要です。多くのチームは、ソース、転送経路、ターゲット、あるいはインフラストラクチャサービスのいずれが原因であるかを確認せずに、圧縮レベルの変更、並列タスクの追加、またはジョブの移動から始めてしまいます。事業継続性と復旧目標を支えるバックアップ環境において、推測憶測はリスクを生み出します。測定に基づいたチューニングを行うことで、バックアップ速度の向上と、より予測可能な復元が可能になります。
Veeamのパフォーマンスチューニングのベストプラクティスは、ボトルネック分析から始まります！
セッション統計を正しく活用すれば、Veeamはすでに強力な出発点を提供しています。設定を変更する前に、ジョブのパフォーマンスを確認し、ボトルネックがソース、プロキシ、ネットワーク、またはターゲットのいずれにあるかを特定してください。ボトルネックがジョブや時間帯によって変動する場合は、静的な構成の問題ではなく、共有インフラストラクチャの競合が原因である可能性があります。
多くの環境では、この点を誤って解釈しがちです。ボトルネックとして特定されたリポジトリが、必ずしもリソース不足であるとは限りません。ストレージコントローラーの過負荷、キャッシュパフォーマンスの低下、リポジトリへのタスク割り当て不足、あるいは過度な同時ジョブスケジューリングが原因である可能性もあります。同様に、ソース側のボトルネックは、Veeamの設定問題ではなく、スナップショットの処理、ハイパーバイザーへの負荷、またはゲストのI/O動作に起因している可能性があります。
実用的な教訓は単純です。証拠に基づいてチューニングを行うことです。本番環境のバックアップ設定を変更する前に、セッションデータ、インフラストラクチャカウンター、ストレージのレイテンシ、CPUのレディネス、ネットワーク利用率のすべてが、同じ結論を裏付ける必要があります。
他のチューニングを行う前に、プロキシの規模を適正化してください
バックアッププロキシは、パフォーマンスチューニングの効果が最も早く現れる場所です。プロキシの規模が小さすぎたり、割り当てが不適切だったり、配置が悪かったりすると、ストレージやネットワークの高速化を行っても、問題はほとんど解決しません。仮想化環境では、プロキシの設計が、Veeamによるバックアップデータの読み取り、処理、転送の効率に直接影響します。
まずは転送モードから検討です。設計が対応していれば、ストレージへの直接アクセスの方が一般的にパフォーマンスは向上しますが、あらゆる場面で自動的に最適な選択肢となるわけではありません。仮想アプライアンスモードは運用が容易であり、多くのVMware環境では十分です。ネットワークモードは通常、最も非効率な選択肢であるため、大容量のジョブがNBDにフォールバックしている場合は、直ちに調査が必要です。
CPUとメモリの割り当ても、実際の同時実行数に見合う必要があります。vCPUが少なすぎると並列処理が阻害される一方、負荷の高いホストで過剰に割り当てるとスケジューリングの遅延が生じます。これはプロキシのタスク数についても同様です。同時実行タスク数を増やすことでスループットは向上しますが、それはCPU、RAM、ネットワーク帯域幅、およびリポジトリのパフォーマンスがその増加を吸収できる場合に限られます。それらが対応できない場合、並列処理を増やしても、ボトルネックがより多くのコンポーネントに分散されるだけになります。
プロキシの配置も重要です。ソースストレージから遠く離れた場所にあるプロキシや、アクセスが集中したネットワーク経路を経由せざるを得ないプロキシは、ローカルリソースの状態が良好に見えても、パフォーマンスが低下します。大規模な環境では、保護対象のワークロードに近い場所に分散配置されたプロキシの方が、すべての処理を単一の階層に集中させるよりも、通常、より良好で安定した結果をもたらします。
リポジトリのパフォーマンスこそが、バックアップ速度の成否を左右する
リポジトリは、しばしば受動的な保存先として扱われますが、実際には能動的なパフォーマンス要素です。書き込み速度の遅さ、ランダムI/O処理の不備、不十分な容量計画は、バックアップボリュームの増加に伴いすぐに顕在化します。
WindowsまたはLinuxのリポジトリを使用している場合は、ディスクの種類、コントローラの設計、ファイルシステムの選択、およびタスク設定を総合的に見直してください。高速なCPUやコア数の多さは、圧縮、暗号化、合成アクティビティなどの処理に役立ちますが、リポジトリのストレージレイテンシが依然として全体的なパフォーマンスの大部分を左右します。十分なキャッシュや階層化のない容量重視のディスクで構築されたリポジトリは、負荷が軽い間は問題ないように見えても、同時実行ジョブや合成フルバックアップの作成時には機能不全に陥る可能性があります。
堅牢化されたリポジトリの場合、不変性はセキュリティ上の価値をもたらしますが、それでもパフォーマンスを念頭に置いて設計する必要があります。セキュリティ制御があっても、適切なサイジングの必要性がなくなるわけではありません。不変性ウィンドウ、保存ポリシー、および合成操作がすべて、処理能力の不足している同じターゲットに集中していると、バックアップ速度と運用上の柔軟性が損なわれます。
スケールアウト型のバックアップリポジトリは負荷分散に役立ちますが、性能の低いエクステントを回避する近道にはなりません。あるエクステントが他のエクステントよりも著しく遅い場合、配置やエバキュエーションの挙動によってパフォーマンスにばらつきが生じる可能性があります。エクステント間の一貫性は、その違いを意図的に考慮してポリシーが設計されていない限り、特性が大きく異なるストレージ階層を混在させるよりも、一般的に良好な結果をもたらします。
ジョブの設計が、回避可能な競合を引き起こすことがよくあります
一部の環境では、紙面上では十分なインフラ容量があるにもかかわらず、ジョブの構造が不適切であるためにパフォーマンスが低下しています。これは、パフォーマンスの見直しを行わずにバックアップポリシーが時間とともに進化してきた環境ではよくあることです。
大規模なジョブが必ずしも非効率であるとは限らず、小規模なジョブが常に優れているわけでもありません。それは、環境、プロキシの数、リポジトリの容量、およびリカバリモデルによって異なります。とはいえ、負荷の高いワークロードを同じスケジュールに詰め込みすぎると、リソース使用量が急激に増加する可能性があります。ジョブをバックアップウィンドウ全体に分散させることは、高度な設定を変更するよりも、多くの場合、総スループットの向上につながります。
合成フルバックアップ、アクティブフルバックアップ、バックアップコピージョブ、ヘルスチェック、およびSureBackup関連のアクティビティも、リポジトリへの影響を考慮してスケジュールする必要があります。すべての負荷の高い操作が同時に開始されると、プロキシがどれほど適切に調整されていても、リポジトリがボトルネックとなってしまいます。
アプリケーション認識型処理にも注意を払う必要があります。これは多くのビジネスクリティカルなシステムにとって不可欠ですが、コストがかかります。SQL Server、Exchange、およびドメインコントローラーのバックアップは、ゲスト処理が有効になっていると時間がかかる場合があります。特に、認証情報、VSSの動作、またはログ処理に一貫性がない場合はなおさらです。必要に応じて不要なオプションを無効にしますが、その際はビジネス要件およびコンプライアンス要件を検証した上で行ってください。
ネットワークのチューニングは重要ですが、適切な箇所に限る
ネットワークの変更は役立つ場合がありますが、過大評価されがちです。リポジトリが飽和状態にある場合やソースストレージの速度が遅い場合、帯域幅を増やしてもパフォーマンスは実質的に向上しません。ネットワークのチューニングが最も価値を発揮するのは、転送経路がボトルネックであると確認された場合です。
リンク速度、遅延、パケットロス、および共有使用パターンを確認してください。レプリケーション、ストレージトラフィック、または負荷の高いイースト-ウエスト方向のアプリケーショントラフィックと競合するバックアップトラフィックは、その性質上、不安定になります。バックアップトラフィックを分離することで、特にマルチサイト環境や大規模な仮想化環境において、安定性を向上させることができます。
データの遠隔転送については、WANアクセラレーションやバックアップコピーの最適化を検討する価値があるかもしれませんが、これらは実際の復旧および保存期間の目標に合わせて調整する必要があります。すべての環境において、その複雑さを正当化するほどの十分なメリットが得られるわけではありません。圧縮や重複排除の設定についても同様です。より積極的な処理を行うと転送データ量は削減されるかもしれませんが、CPU負荷も増加します。環境によっては、そのトレードオフが有利に働くこともありますが、他の環境ではジョブの処理速度が低下してしまうこともあります。
ストレージのスナップショットとソース側の状況には同等の注意を払う必要がある
バックアップチームは、Veeamを徹底的に調整することがありますが、実際の問題はソース側にある場合があります。本番用ストレージに負荷がかかっている場合、スナップショットの作成や削除に時間がかかりすぎたり、変更ブロックの追跡に一貫性がなくなったり、保護ウィンドウ中にゲストワークロードのレイテンシが上昇したりする可能性があります。
これは、変更頻度の高いシステムや負荷の高い仮想インフラストラクチャにおいて特に重要です。スナップショットによる「スタン」イベント、データストアの輻輳（ふくそう）、ストレージコントローラーの制限などは、データがプロキシに到達する前からバックアップ操作を遅らせる可能性があります。本格的なチューニングを行う際には、ハイパーバイザーの状態、データストアの設計、およびストレージのレイテンシを必ず確認する必要があります。
物理サーバーやNASワークロードの場合、ソース側の読み取りパフォーマンスの影響がさらに顕著になります。読み取りスループットが低い場合、下流側のチューニングではそれを補うことはできません。リカバリ目標に基づいて、ソース側の再設計が必要かどうかを判断すべきです。特に、狭いバックアップウィンドウ内で保護が困難なシステムにおいては重要です。
保存期間、暗号化、不変性をストレージ容量に合わせて調整する
Veeamのパフォーマンスチューニングに関する最良のヒントのいくつかは、実際にはポリシー上の決定事項です。保存期間、GFSの使用、暗号化、不変性はすべて、ストレージ消費量とジョブ実行時間に影響を与えます。これらの設定は、デフォルトの仮定ではなく、ビジネスニーズを反映したものであるべきです。
特にコンプライアンス重視の環境では、暗号化が必要となる場合が多いですが、それには処理オーバーヘッドが伴います。長期の保持期間や頻繁なフルバックアップ操作は、I/O負荷を増大させます。不変性はランサムウェアに対する耐性を高めますが、リポジトリのサイズ設定やライフサイクル計画をより慎重に行う必要もあります。これらの制御は、抽象的な観点ではどれも任意のものではありません。正しい答えは、復旧要件、脅威モデル、および予算によって異なります。
だからこそ、パフォーマンスのチューニングはガバナンスから切り離して考えるべきではありません。組織がより長い保存期間、より強力な分離、あるいはより多くの検証を必要とする場合、インフラストラクチャはそれらの目標をサポートできなければなりません。容量の変更なしに大規模なポリシーの拡張を吸収した設計から、バックアップの高速化を期待するのは非現実的です。
チューニング中は復元テストも実施する
ジョブがより早く完了したからといって、バックアップ環境が適切にチューニングされているとは限りません。チューニングの選択によって復元がより遅くなったり、複雑になったり、予測しづらくなったりする場合は、環境は後退してしまったことになります。
復元テストはプロセスの一部として継続すべきです。単にバックアップジョブの所要時間だけでなく、最も重要なシステムの復旧パフォーマンスを測定してください。リポジトリのレイアウト、チェーン設計、オフロードの挙動は、いずれもバックアップ速度とは異なる形で復元速度に影響を与える可能性があります。真のビジネス上の課題が「深夜にジョブがどれほど速く実行されるか」ではなく、「障害やランサムウェアの被害を受けた後、重要なシステムをどれほど迅速に復旧できるか」の場合、これは重要な点となります。
Veeamに大きく依存している組織にとって、最良の運用成果は通常、1回限りのチューニングではなく、定期的な見直しから得られます。ワークロードは変化し、保存期間は延長され、ストレージは老朽化し、バックアップウィンドウは狭まります。1年前に良好なパフォーマンスを発揮していた構成でも、現在では隠れたリスクを抱えている可能性があります。
チームがチューニングを、単なるバックアップの高速化ではなく、より広範な復旧準備の一環として捉えることで、より適切な意思決定が可能になります。ジョブの高速化は有用ですが、実際に重要なのは、プレッシャのかかる状況下でも予測可能な保護と復旧が実現できるかどうかです。
