NetBackup™ Web UI クラウド管理者ガイド
- クラウド資産の管理と保護
- クラウド資産の保護について
- 制限事項および考慮事項
- AWS と Azure の政府向けクラウドサポート
- Snapshot Manager を NetBackup で構成します。
- クラウド資産のインテリジェントグループの管理
- クラウド資産またはクラウド資産用インテリジェントグループの保護
- ストレージライフサイクルポリシーについて
- クラウド資産のポリシーの管理
- マルウェアのスキャン
- リソースグループを使用した Microsoft Azure リソースの保護
- クラウド作業負荷のための NetBackup アクセラレータ
- 保護計画を使用したクラウド作業負荷のバックアップスケジュールの構成
- クラウド作業負荷のバックアップオプション
- AWS スナップショットレプリケーション
- アプリケーションの整合性スナップショットを使用したクラウド内アプリケーションの保護
- VMware へのリカバリのための AWS VM または Azure VM の保護
- クラウド資産のクリーンアップ
- クラウド資産のフィルタ処理
- PaaS 資産の保護
- PaaS 資産の保護
- PaaS 資産を保護するための前提条件
- MySQL および MariaDB データベースのバイナリログの有効化
- Kubernetes でのバックアップとリストアの有効化
- Amazon RDS SQL Server データベースの資産を保護するための前提条件
- RDS Custom インスタンスの保護
- Azure Managed Instance データベースの保護
- 制限事項および考慮事項
- すべてのデータベース
- PostgreSQL の場合
- Azure PostgreSQL の増分バックアップの場合
- AWS RDS PostgreSQL および AWS Aurora PostgreSQL の場合
- AWS DynamoDB の場合
- AWS DocumentDB の場合
- AWS Neptune の場合
- AWS RDS SQL の場合
- Azure、AWS RDS、Aurora MySQL の場合
- Azure MySQL サーバーを使用した増分バックアップの場合
- GCP SQL Server を使用した増分バックアップの場合
- Azure SQL と SQL Managed Instance の場合
- Azure SQL と SQL Managed Instance の場合 (一時データベースなし)
- Azure SQL Server と SQL Managed Instance の増分バックアップの場合
- Azure Cosmos DB for MongoDB の場合
- Azure Cosmos DB for NoSQL の場合
- Amazon RDS for Oracle の場合
- Amazon Redshift データベースの場合
- Amazon Redshift クラスタの場合
- GCP SQL Server の場合
- GCP BigQuery の場合
- ネイティブクライアントユーティリティのインストール
- さまざまな配備のストレージの構成
- インスタントアクセス用のストレージサーバーの構成
- PaaS 作業負荷の増分バックアップについて
- Azure MySQL サーバーの増分バックアップの構成
- PaaS 作業負荷のアーカイブ REDO ログのバックアップについて
- PaaS 作業負荷の自動イメージレプリケーションについて
- PaaS 資産の検出
- PaaS 資産の表示
- PaaS のクレデンシャルの管理
- PaaS 資産への保護の追加
- クラウド資産のリカバリ
- 個別リストアの実行
- クラウド資産の保護とリカバリのトラブルシューティング
- クラウドの作業負荷の保護に関する問題のトラブルシューティング
- エラーコード 9855: 資産 <asset_name> のスナップショットのエクスポート中のエラー
- CMK を使用して暗号化されたディスクを持つ VM とその他の OCI 資産が、NetBackup UI で削除済みとしてマークされる。
- スナップショットからのバックアップジョブに予想より長い時間がかかる
- Snapshot Manager が Ubuntu ホストに配備されている場合、接続の問題によりスナップショットからのバックアップジョブが失敗する
- NetBackup UI でのエラーのあいまいさの排除
- 状態コード 150: 管理者から終了が要求されました
- PaaS の作業負荷の保護とリカバリに関する問題のトラブルシューティング
バックアップ間隔について
バックアップ間隔を決定するには、データを変更する頻度を考慮します。たとえば、ファイルを 1 日に数回、1 日に 1 回、毎週、または毎月変更するかどうかを判断します。
通常は、日々の作業内容を保護するために、毎日バックアップを行います。毎日バックアップを行う場合、ディスク障害が発生した場合に失われるのは、1 日分だけです。1 日の間に重要なデータの変更が頻繁に発生し、変更を再度構築することが難しい場合は、バックアップ間隔をさらに短くする必要があります。
日次バックアップは、通常、最後の差分増分バックアップまたは完全バックアップ以降の変更を記録する差分増分バックアップです。差分増分バックアップでは、完全バックアップに比べてストレージの使用量が少なく、時間がかからないため、リソースの節約になります。
完全バックアップは、通常は差分増分バックアップよりも実行間隔が長くなりますが、差分増分バックアップが連続して蓄積することを回避するのに十分な頻度で実行する必要があります。完全バックアップ間の差分増分バックアップの回数が多くなると、ファイルのリストアに時間がかかるようになります。時間がかかるのは、ファイルおよびディレクトリのリストア時にこれらの差分増分バックアップをまとめる必要があるためです。
完全バックアップの間隔を設定する場合、次の点を考慮します。
変更の頻度が少ないファイルの完全バックアップの間隔は空けるようにします。間隔を長くすると、使用するシステムリソースが少なくて済みます。また、完全バックアップ間の差分増分バックアップのサイズは小さいため、リストア時間が大幅に長くなることはありません。
頻繁に変更されるファイルの完全バックアップの間隔は短くします。間隔を短くすると、リストア時間が短くなります。完全バックアップの間隔を短くすると、使用するリソースも少なくなります。ファイル内の頻繁な変更に対応するのに必要な長時間の差分増分バックアップの累積の影響が軽減されます。
リソースを最も効果的に使用するために、現在のポリシーに含まれるほぼすべてのファイルが、同じ頻度で更新されていることを確認します。たとえば、ポリシーのバックアップ対象リスト内の半分のファイルが毎週の完全バックアップが必要となる程頻繁に変更されるとします。ただし、残り半分のファイルは変更の頻度が少なく、毎月の完全バックアップで十分であるとします。この場合、すべてのファイルが同じポリシー内にあると、すべてのファイルに対して毎週完全バックアップが実行されます。半分のファイルは毎月の完全バックアップで十分であるため、システムリソースを浪費することになります。バックアップを 2 つのポリシーに分けて、それぞれに適切なバックアップスケジュールを設定するか、または合成バックアップを使用すると改善されます。
ポリシー内のクライアントに対して複数の自動スケジュールが実行される予定である場合、バックアップ間隔によって、NetBackup に使用されるスケジュールが次のように決定されます。
常に、バックアップ間隔が長いスケジュールのジョブほど、優先度が高くなります。たとえば、バックアップ間隔が 1 カ月のスケジュールはバックアップ間隔が 2 週間のスケジュールより優先度が高くなります。
2 つのスケジュールをそれぞれ実行する必要がある場合、アルファベット順で最初のスケジュール名を持つスケジュールが最初に実行されます。アルファベット順の優先度は次の両方が該当する場合に適用されます。
各スケジュールが定義されている時間帯内にある。
各スケジュールが同じ間隔で構成されている。
NetBackup では、スケジュール例に対して次に示す順の優先度が設定されます。
表: スケジュールの間隔と優先度の例
スケジュール名 | 間隔 | 優先度 (Priority) |
|---|---|---|
|
monthly_full |
1 カ月 |
1 番目 |
|
weekly_full |
1 週間。 |
2 番目 |
|
daily_differential_incremental |
1 日 |
3 番目 |