バックアップのベスト・プラクティス

VPCバックアップ・サービスを最も効果的かつ経済的に使用するために、以下の提案を検討してください。

一般的なベスト・プラクティス

  • バックアップ・ポリシーを作成する前に、データのタイプを評価します。 頻繁に変更される重要なデータは、静的データよりも頻繁にバックアップする必要がある可能性があります。 どのデータが最も重要で、どのデータをアーカイブすべきかを確認してください。

  • 他のリージョンでのバックアップスナップショットコピーの作成を含める必要がある場合は、慎重に検討してください。 コピーは、対象地域に新しいボリュームを作成し、事業継続を支援するのに役立つ。 しかし、大容量のデータを別のリージョンにコピーするには時間がかかるし、リモートコピーを作成するには、データ転送の料金とターゲットリージョンでのストレージ消費量が別途発生する。

  • データ損失を防ぐため、バックアップは必要な場所と期間に限定して保管し、コストを抑えましょう。 削除された、または破損した可能性のあるデータをリストアするためのタイムリーなバックアップを計画します。 どのような事態が起こり得るかを考えてみてください。 どの程度のデータ損失が許容されるかを確認します。 回答は、バックアップ間隔と保存ポリシーを決定するのに役立ちます。

  • データをどの程度迅速にリカバリーする必要があるかを確認します。 バックアップからボリュームまたは共有を作成し、フェイルオーバーをテストして、かかる時間の見当をつける。

  • 最適なパフォーマンスを得るには、バックアップ間隔の異なるバックアッププランを作成し、バックアップジョブを時差をつけて実行するようにしてください。 バックアップ・ポリシーごとに最大 4 つの異なるバックアップ計画を持つことができます。

  • 第1世代の大容量ボリュームについては、すべてのボリュームのバックアップが10 TBの上限を超えないよう、保存期間を短くすることを検討してください。

  • 異なるリージョンにボリュームがある場合は、リージョンごとに別個のバックアップ・ポリシーを作成します。 1 つのリージョンでは、アカウントごとのバックアップ・ポリシーは 10 個に制限されています。 この枠は増やすことができません。

  • バックアップ用にタグ付けしたブロックストレージリソースが、稼働中の仮想サーバーインスタンスにアタッチされていることを確認します。 切り離されたボリュームはバックアップできません。

  • バックアップポリシーに一意の名前を指定してください。 ボリュームの命名規則がある場合は、同様の規則に従ってバックアップポリシーに名前を付けることもできます。 ポリシーによって作成されるバックアップも、この規則に従うことができます。 バックアップの数が増えるにつれて、適切な命名規則を設けることで、それらをより識別しやすくなります。

  • 整合性グループのバックアップ: 同じ仮想サーバー・インスタンスに接続されている複数のボリュームのクラッシュ整合スナップショットを作成すると、短時間の入出力中断が発生し、数ミリ秒から数秒間続く可能性があります。 所要時間は、仮想サーバー・インスタンスに接続されているボリュームの数とサイズによって異なります。 パフォーマンスへの影響を最小限に抑えるため、自動バックアップジョブは利用が集中しない時間帯に実行してください。

  • ファイル共有のバックアップスケジュールは、レプリケーションペアのソース側でのみ設定できます。 レプリカ共有へのフェイルオーバー操作を選択すると、ソース共有とレプリカ共有の役割が切り替わります。 フェイルオーバーが実行された後、バックアップポリシーは以前のソースから削除され、現在のソース共有に適用される必要があります。

レプリカ共有のスナップショットの作成をスケジュールすることはできませんが、レプリカ共有にはスナップショットが存在する場合があります。 ソース共有のバックアップスナップショットを作成すると、そのバックアップスナップショットは次のレプリケーションサイクルでレプリカにコピーされます。

ユーザー・アクションのベスト・プラクティス

  • リソースに適用し、バックアップポリシーで指定するタグを整理します。 重複バックアップがトリガーされる可能性があるため、複数のポリシーがターゲット・リソースに同じタグを使用していないことを確認してください。 バックアップを実行するには、1つのタグに一致するだけで十分です。

  • リソース（ボリューム、共有、仮想サーバーインスタンス）にすでに割り当てられているタグを確認します。 リソースに複数のタグが設定されている場合は、それらのタグによって複数のポリシーで重複したバックアップが実行されないようにしてください。

  • タグの追加方法をお選びください。 まずバックアップ・ポリシーでターゲット・リソースのタグを作成し、それをボリューム、共有、または仮想サーバー・インスタンスに適用します。 あるいは、バックアップポリシー内で、そのリソースにすでに適用されているタグを指定することもできます。 既存のタグを使用する場合は、このポリシーでバックアップ対象外としたい他のリソースにも、同じタグが付けられている可能性があることに注意してください。

  • 1 つのバックアップ計画を作成するのか、複数のバックアップ計画を作成するのかを決定します。 たとえば、複数のプランで、それぞれ異なる間隔でバックアップが実行されるように設定できます。 あるボリュームや株式は毎月バックアップし、他のボリュームや株式は毎日または毎週の計画でより頻繁にバックアップしたいかもしれません。

管理者のベスト・プラクティス

ベスト・プラクティスの適用

バックアップ戦略を策定する際は、ベストプラクティスを適用してください。 以下の例は、バックアップソリューションをどのように設定できるかを示しています。

異なる部署に分散している10のボリュームがあると仮定します。 一部のボリュームには、1時間ごとにバックアップする必要がある、時間的制約のある情報が含まれている場合があります。 その他のボリュームにはあまり変更されないアーカイブ情報が含まれているため、週次でのバックアップを考えています。 ポリシーごとに 4 つのバックアップ計画を作成できます。

時間が重要なボリュームの毎時バックアップ計画を使用してバックアップ・ポリシーを作成します。

  • ポリシーを作成する際は、対象となるボリューム用のタグ（例： finance:hourly ）を作成してください。データの間隔や種類を反映したポリシー名を指定してください。 リスト内のポリシーと、それに関連するリソースを整理するのに役立つ。

  • ボリュームに新しいタグを追加します - タグを指定しますターゲットリソースにタグを適用するコンソールで入力するか、CLI または API で指定します。 これにより、毎時バックアップするすべてのボリュームが毎時バックアップ・ポリシーに含まれるようになります。

  • ボリュームにすでにタグが設定されている場合は、別のバックアップポリシーによってそのボリュームがすでにバックアップされていないか確認してください。 その場合は、余分なタグをボリュームから削除して、2 回バックアップされないようにし、余分なコストを発生させます。

  • 1000日を超えず、バックアップの総量が10TBを超えないように保持期間を設定します。 1時間ごとのバックアップの場合、毎日や毎週のバックアップに比べて、保存期間を短くする必要があるかもしれません。

アーカイブ・データの週次バックアップ計画を作成します。

  • 別のプランを作成し、バックアップの頻度を7日に設定してください。 ボリューム内のデータ量と予想される変更を評価します。 ジェネレーション1ボリュームの上限は10TBである。

  • アーカイブ・ボリュームの複数のコピーを持てるように、より長い保存期間を設定してください。 週次バックアップの場合は、バックアップを 1 カ月間保持することをお勧めします。

  • リモートリージョンコピーを追加して、データを別の場所に保管する。 ボリュームが3TBを超えていても、次のスナップショットコピーは、前の週の変更を含む増分スナップショットです。

保存ポリシーで存続期間とバックアップ数の両方を指定すると、スナップショットを削除するタイミングを決定する際に存続期間が優先されます。 このカウントは、最も古いスナップショットが存続期間の範囲内にある場合にのみ適用されます。

例えば、週次プランを作成し、保存期間を 365 日と指定する場合、最大カウント 8 を指定することもできます。 このシナリオでは、チェーン内で最大 8 個のバックアップを取得します。最も古いものは 8 週間前です。 あるいは、保持期間を30日間に指定し、バックアップの最大数を8に設定することもできます。 そして、5つ目のバックアップが作成される頃には、最初のバックアップは30日間の保存期間外であるため、削除されることになる。

次のステップ