自動バックアップAutomated backups

SQL Database では、設定されている保持期間にわたり保存されるデータベース バックアップが自動的に作成され、Azure の読み取りアクセス geo 冗長ストレージ (RA-GRS) を使用し、データ センターを使用できない場合でもデータベース バックアップが確実に保存されます。SQL Database automatically creates the database backups that are kept for the duration of the configured retention period, and uses Azure read-access geo-redundant storage (RA-GRS) to ensure that they are preserved even if the data center is unavailable. これらのバックアップは自動的に作成されます。These backups are created automatically. データの不慮の破損または削除から保護するデータベース バックアップは、ビジネス継続性およびディザスター リカバリー戦略の最も重要な部分です。Database backups are an essential part of any business continuity and disaster recovery strategy because they protect your data from accidental corruption or deletion. セキュリティ規則で、長期間バックアップ (最長 10 年間) を利用できる必要がある場合は、Single Database と Elastic Pool で長期保有を構成できます。If your security rules require that your backups are available for an extended period of time (up to 10 years), you can configure a long-term retention on Singleton databases and Elastic pools.

注意

この記事は、デバイスまたはサービスから個人用データを削除する手順について説明しており、GDPR での義務を果たすために使用できます。This article provides steps for how to delete personal data from the device or service and can be used to support your obligations under the GDPR. GDPR に関する一般的な情報をお探しの場合は、Service Trust portal の GDPR に関するセクションを参照してください。If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.

SQL Database バックアップとはWhat is a SQL Database backup

SQL Database は SQL Server 技術を利用して、完全バックアップを毎週、差分バックアップを 12 時間ごと、そしてトランザクション ログ バックアップを 5 分から 10 分ごとに作成します。SQL Database uses SQL Server technology to create full backups every week, differential backups every 12 hours, and transaction log backups every 5-10 minutes. バックアップは RA-GRS ストレージ BLOB に格納され、この BLOB はデータ センターの停止に対する保護のためにペアのデータ センターにレプリケートされます。The backups are stored in RA-GRS storage blobs that are replicated to a paired data center for protection against a data center outage. データベースを復元するとき、どのバックアップを復元する必要があるかをサービスが判定します (完全、差分、トランザクション ログ)。When you restore a database, the service figures out which full, differential, and transaction log backups need to be restored.

これらのバックアップを使用して、以下を行うことができます。You can use these backups to:

  • 保持期間内の過去の特定の時点に既存のデータベースを復元する。その際、Azure portal、Azure PowerShell、Azure CLI、または REST API を使用します。Restore an existing database to a point-in-time in the past within the retention period using the Azure portal, Azure PowerShell, Azure CLI, or REST API. Single Database および Elastic Pool では、この操作により、元のデータベースと同じサーバーに、新しいデータベースが作成されます。In Single database and Elastic pools, this operation will create a new database in the same server as the original database. Managed Instance では、この操作により、同じサブスクリプションに、データベースのコピーか、同じ Managed Instance または異なる Managed Instance のコピーを作成できます。In Managed Instance, this operation can create a copy of the database or same or different Managed Instance under the same subscription.
  • 削除したデータベースを、削除された時点に復元する。また、保持期間内の任意の時点に復元することもできます。Restore a deleted database to the time it was deleted or anytime within the retention period. 削除されたデータベースは、元のデータベースが作成された論理サーバーまたは Managed Instance にのみ復元できます。The deleted database can only be restored in the same logical server or Managed Instance where the original database was created.
  • 別の地理的リージョンにデータベースを復元するRestore a database to another geographical region. geo リストアにより、サーバーやデータベースにアクセスできないときに、地理的な障害から復旧できます。Geo-restore allows you to recover from a geographic disaster when you cannot access your server and database. 世界中のどこでも、あらゆる既存のサーバーで新しいデータベースを作成します。It creates a new database in any existing server anywhere in the world.
  • 特定の長期バックアップからデータベースを復元する。データベースが長期アイテム保持ポリシー (LTR) で構成されている場合に、Single Database または Elastic Pool で復元できます。Restore a database from a specific long-term backup on Single Database or Elastic Pool if the database has been configured with a long-term retention policy (LTR). LTR により、Azure portal または Azure PowerShell を使用して、コンプライアンスの要求を満たすため、またはアプリケーションの古いバージョンを実行するために、古いバージョンのデータベースを復元できます。LTR allows you to restore an old version of the database using the Azure portal or Azure PowerShell to satisfy a compliance request or to run an old version of the application. 詳細については、「長期保存」をご覧ください。For more information, see Long-term retention.
  • 復元を実行するには、バックアップからのデータベースの復元に関する記事を参照してください。To perform a restore, see restore database from backups.

注意

Azure Storage の " レプリケーション " という用語は、ある場所から別の場所にファイルをコピーすることを表します。In Azure storage, the term replication refers to copying files from one location to another. SQL の データベース レプリケーション は、複数のセカンダリ データベースとプライマリ データベースとの同期を保つことを意味します。SQL's database replication refers to keeping multiple secondary databases synchronized with a primary database.

次の例を使用して、これらの操作のいくつかを試すことができます。You can try some of these operations using the following examples:

Azure ポータルThe Azure portal Azure PowerShellAzure PowerShell
バックアップ保有期間を変更するChange backup retention Single DatabaseSingle Database
Managed InstanceManaged Instance
Single DatabaseSingle Database
Managed InstanceManaged Instance
長期のバックアップ保有期間を変更するChange Long-term backup retention 1 つのデータベースSingle database
Managed Instance - N/AManaged Instance - N/A
Single DatabaseSingle Database
Managed Instance - N/AManaged Instance - N/A
特定の時点からデータベースを復元するRestore database from point-in-time 1 つのデータベースSingle database 1 つのデータベースSingle database
Managed InstanceManaged Instance
削除済みデータベースの復元Restore deleted database 1 つのデータベースSingle database 1 つのデータベースSingle database
Managed InstanceManaged Instance
Azure Blob Storage からデータベースを復元するRestore database from Azure Blob Storage Single Database - N/ASingle database - N/A
Managed Instance - N/AManaged Instance - N/A
Single Database - N/ASingle database - N/A
Managed InstanceManaged Instance

バックアップ頻度Backup frequency

ポイントインタイム リストアPoint-in-time restore

SQL Database では、完全バックアップ、差分バックアップ、トランザクション ログ バックアップを自動的に作成して、ポイントインタイム リストア (PITR) のセルフ サービスをサポートします。SQL Database supports self-service for point-in-time restore (PITR) by automatically creating full backup, differential backups, and transaction log backups. 完全データベース バックアップは毎週、差分データベース バックアップは一般的に 12 時間ごとに、トランザクション ログ バックアップは通常、5 - 10 分ごとに作成されます。頻度は、コンピューティング サイズとデータベース アクティビティの量に基づきます。Full database backups are created weekly, differential database backups are generally created every 12 hours, and transaction log backups are generally created every 5 - 10 minutes, with the frequency based on the compute size and amount of database activity. 初回の完全バックアップは、データベースの作成直後にスケジュールされます。The first full backup is scheduled immediately after a database is created. 通常この操作は 30 分以内に終了しますが、データベースのサイズが大きい場合はそれ以上かかることがあります。It usually completes within 30 minutes, but it can take longer when the database is of a significant size. たとえば、復元されたデータベースまたはデータベースのコピーでは、初期バックアップに時間がかかります。For example, the initial backup can take longer on a restored database or a database copy. 初回の完全バックアップ以降のバックアップは、すべて自動的にスケジュールされ、バックグラウンドで自動的に管理されます。After the first full backup, all further backups are scheduled automatically and managed silently in the background. データベースのバックアップの正確なタイミングは、全体的なシステムのワークロードのバランスを図りながら SQL Database サービスによって決定されます。The exact timing of all database backups is determined by the SQL Database service as it balances the overall system workload. バックアップ ジョブを変更または無効化することはできません。You cannot change or disable the backup jobs.

PITR バックアップは、geo 冗長であり、Azure Storage のリージョン間レプリケーションによって保護されます。The PITR backups are geo-redundant and protected by Azure Storage cross-regional replication

詳細については、「ポイントインタイム リストア」をご覧ください。For more information, see Point-in-time restore

長期保存Long-term retention

単一データベースとプールされたデータベースには、Azure Blob Storage に対する最大 10 年の完全バックアップの長期保有 (LTR) を構成するオプションが用意されています。Single and pooled databases offer the option of configuring long-term retention (LTR) of full backups for up to 10 years in Azure Blob storage. LTR ポリシーが有効になっている場合、週次の完全バックアップは自動的に別の RA-GRS ストレージ コンテナーにコピーされます。If LTR policy is enabled, the weekly full backups are automatically copied to a different RA-GRS storage container. さまざまなコンプライアンス要件を満たすために、毎週、毎月、毎年のバックアップに対して異なったリテンション期間を選択することができます。To meet different compliance requirement, you can select different retention periods for weekly, monthly and/or yearly backups. ストレージの使用量は、選択したバックアップの頻度とリテンション期間によって異なります。The storage consumption depends on the selected frequency of backups and the retention period(s). LTR ストレージのコストは、LTR 料金計算ツールを使用して見積もることができます。You can use the LTR pricing calculator to estimate the cost of LTR storage.

PITR と同じように、LTR バックアップは、geo 冗長であり、Azure Storage のリージョン間レプリケーションによって保護されます。Like PITR, the LTR backups are geo-redundant and protected by Azure Storage cross-regional replication.

詳細については、「Long-term backup retention」(長期バックアップ リテンション) をご覧ください。For more information, see Long-term backup retention.

バックアップ ストレージ消費量Backup storage consumption

単一データベースの場合、バックアップ ストレージの合計使用量は次のように計算されます。For single databases, the total backup storage usage is calculated as follows:
[https://login.microsoftonline.com/consumers/](Total backup storage size = (size of full backups + size of differential backups + size of log backups) – database size)Total backup storage size = (size of full backups + size of differential backups + size of log backups) – database size.

エラスティック プールの場合、バックアップ ストレージの合計サイズはプール レベルで集計され、次のように計算されます。For elastic pools, the total backup storage size is aggregated at the pool level and is calculated as follows:
[https://login.microsoftonline.com/consumers/](Total backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - allocated pool data storage)Total backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - allocated pool data storage.

保持期間を過ぎたバックアップはタイムスタンプに基づいて自動的に消去されます。Backups that are older than the retention period are automatically purged based on their timestamp. 差分バックアップとログ バックアップにはそれに先行する完全バックアップが必要であるため、それらも毎週まとめて消去されます。Because the differential backups and log backups require an earlier full backup to be useful, they are purged together in weekly chunks.

Azure SQL Database では、保持期間内のバックアップ ストレージの合計が累積値として計算されます。Azure SQL Database will compute your total in-retention backup storage as a cumulative value. 毎月末に消費量を計算する目的でこの時間あたり使用量を集計する役割を担う Azure 課金パイプラインにこの累積値が 1 時間おきに報告されます。Every hour, this value is reported to the Azure billing pipeline which is responsible for aggregating this hourly usage to calculate your consumption at the end of each month. データベースの削除後は、バックアップの時間経過と共に消費量が減少します。After the database is dropped, consumption decreases as backups age. バックアップが保持期間を過ぎると、課金が停止します。Once the backups become older than the retention period, the billing stops.

使用量の監視Monitoring consumption

各種バックアップ (完全、差分、ログ) はデータベース監視ブレード上で別個のメトリックとして報告されます。Each type of backup (full, differential and log) is reported on the database monitoring blade as a separate metric. 次の図では、バックアップ ストレージ消費量の監視方法が示されています。The following diagram shows how to monitor the backups storage consumption.

Azure portal のデータベース監視ブレードでデータベース バックアップ消費量を監視する

バックアップ ストレージ消費量を微調整するFine tune the backup storage consumption

超過のバックアップ ストレージ消費量は、個々のデータベースのワークロードとサイズに依存します。The excess backup storage consumption will depend on the workload and size of the individual databases. バックアップ ストレージ消費量をさらに減らす目的で、次の調整手法の中からいくつかを実践できます。You can consider implementing some of the following tuning techniques to further reduce your backup storage consumption:

  • 必要最小限までバックアップの保持期間を短縮します。Reduce the backup retention period to the minimum possible for your needs.
  • インデックスの再構築など、大規模な書き込み操作を必要以上に行うことを回避します。Avoid performing large write operations more frequently than needed, such as index rebuilds.
  • 大規模なデータ読み込み操作の場合、クラスター化された列ストア インデックスの使用を検討し、クラスター化されていないインデックスの数を減らし、また、約 100 万の行数の一括読み込み操作を検討します。For large data load operations consider using clustered columnstore indexes, reduce number of non-clustered indexes, and also consider bulk load operations with row count around one million.
  • General Purpose サービス レベルでは、プロビジョニングされたデータ ストレージは超過のバックアップ ストレージより安価になります。そのため、超過のバックアップ ストレージにかかるコストが連続して高いお客様は、バックアップ ストレージを節約する目的でデータ ストレージを増加することを検討できます。In General Purpose service tier, the provisioned data storage is less expensive than the price of the excess backup storage due to which customers with continuously high excess backup storage costs may consider increasing the data storage in order to save on the backup storage.
  • 一時的な結果の保存には、パーマネント テーブルではなく TempDB を ETL ロジックで使用します (マネージド インスタンスのみ該当)。Use TempDB in your ETL logic for storing temporary results, instead of permanent tables (applicable to managed instance only).
  • 機密データが含まれないデータベース (開発またはテスト データベースなど) の TDE 暗号化をオフにすることを検討します。Consider turning off TDE encryption for databases that do not contain sensitive data (development or test databases, for instance). 暗号化されていないデータベースのバックアップを圧縮するときは、通常、圧縮率が高くなります。Backups for non-encrypted databases are typically compressed with a higher compression ratio.

重要

分析のデータ マート/データ ウェアハウス ワークロードの場合、クラスター化された列ストア インデックスを使用し、クラスター化されていないインデックスの数を減らし、さらに、100 万くらいの行数による一括読み込み操作を検討し、超過のバックアップ ストレージ消費量を減らすことを強くお勧めします。For analytical, data mart \ data warehouse workloads it is strongly recommended to use clustered columnstore indexes, reduce the number of non-clustered indexes, and also consider bulk load operations with row count around one million to reduce the excess backup storage consumption.

ストレージ コストStorage costs

DTU モデルDTU Model

DTU モデルを使用したデータベースおよびエラスティック プールについては、バックアップ ストレージに追加請求はありません。There is no additional charge for backup storage for databases and elastic pools using the DTU model.

仮想コア モデルvCore model

単一のデータベースの場合は、データベース サイズの 100% に等しい最小バックアップ ストレージ容量が、追加料金なしで提供されます。For single databases, a minimum backup storage amount equal to 100% of database size is provided at no extra charge. エラスティック プールとマネージド インスタンスの場合は、プールまたはインスタンス サイズにそれぞれ割り当てられたデータ ストレージの 100% に等しい最小バックアップ ストレージ容量が追加料金なしで提供されます。For elastic pools and managed instances, a minimum backup storage amount equal to 100% of the allocated data storage for the pool or instance size, respectively, is provided at no extra charge. 100% を超えるバックアップ ストレージの使用については、月あたりの GB 数で請求されます。Additional consumption of backup storage will be charged in GB/month. この追加の消費量は、個々のデータベースのワークロードとサイズによって異なります。This additional consumption will depend on the workload and size of the individual databases.

Azure SQL DB では、保持期間内のバックアップ ストレージの合計が累積値として計算されます。Azure SQL DB will compute your total in-retention backup storage as a cumulative value. 毎月末に消費量を取得する目的でこの時間あたり使用量を集計する役割を担う Azure 課金パイプラインにこの累積値が 1 時間おきに報告されます。Every hour, this value is reported to the Azure billing pipeline which is responsible for aggregating this hourly usage to get your consumption at the end of each month. データベースの削除後は、バックアップの時間経過と共に消費量を減少させます。After the database is dropped, we decrease the consumption as the backups age. 保持期間を過ぎると、課金が停止します。Once they become older than the retention period, the billing stops. ログ バックアップと差分バックアップはすべて、保持期間全体にわたり保持されるため、大幅に変更されたデータベースのバックアップ料金が高くなります。Because all the log backups and differential backups are retained for the full retention period, databases that are heavily modified will have higher backup charges.

データベースのバックアップ ストレージが累積で 744 GB になったとします。この量はまる 1 か月にわたり変化しません。Let's assume the database has accumulated 744 GB of backup storage and this amount stays constant throughout an entire month. この累積ストレージ消費量を 1 時間あたりの使用量に変換するには、それを 744.0 (1 か月 31 日 * 1 日 24 時間) で割ります。To convert this cumulative storage consumption to an hourly usage, we divide it by 744.0 (31 days per month * 24 hours per day). したがって、SQL DB からは、データベースは 1 時間あたり 1 GB の PITR バックアップを消費したと報告されます。Thus, SQL DB will report the database consumed 1 GB of PITR backup each hour. Azure の課金機能によりこれが集計され、まる 1 か月間の使用量として 744 GB が表示され、ご利用のリージョンでの $/GB/月レートに基づいてコストが表示されます。Azure billing will aggregate this and show a usage of 744 GB for the entire month and the cost based on the $/GB/mo rate in your region.

次の例はもっと複雑になります。Now, a more complex example. 月の真ん中にデータベースの保持期間を 14 日間に増やしたとします。その結果、(仮説上) バックアップ ストレージの合計が 2 倍の 1,488 GB になります。Suppose the database has its retention increased to 14 days in the middle of the month and this (hypothetically) results in the total backup storage doubling to 1488 GB. SQL DB により 1 から 372 時間に対して 1 GB の使用量が、373 から 744 時間に対して 2 GB の使用量が報告されます。SQL DB would report 1 GB of usage for hours 1-372, and then report the usage as 2 GB for hours 373-744. これが集計されると最終的な請求は 1,116 GB/月になります。This would be aggregated to be a final bill of 1116 GB/mo.

Azure サブスクリプションのコスト分析では、バックアップ ストレージに現在お使いの支出を確認することができます。You can use Azure subscription cost analysis to determine your current spending on backup storage.

バックアップ ストレージのコスト分析

たとえば、マネージド インスタンスのバックアップ ストレージ コストを理解するには、Azure portal で自分のサブスクリプションに移動し、[コスト分析] ブレードを開きます。For example, to understand the backup storage costs for managed instance, please go to your subscription in Azure portal and open the Cost Analysis blade. 測定サブカテゴリ mi pitr backup storage を選択し、現在のバックアップ コストと請求予測を表示します。Select the meter subcategory mi pitr backup storage to see your current backup cost and charge forecast. バックアップ ストレージのコストを他のコスト カテゴリと比較する、 [managed instance general purpose ‐ storage] (マネージド インスタンス汎用目的 ‐ ストレージ) や [managed instance general purpose - compute gen5] (マネージド インスタンス汎用目的 ‐ コンピューティング gen5) などの他の測定サブカテゴリを含めることもできます。You can also include other meter subcategories such as managed instance general purpose - storage or managed instance general purpose - compute gen5 to compare backup storage cost with other cost categories.

バックアップ保有期間Backup retention

すべての Azure SQL データベース (単一、プール、マネージド インスタンス データベース) には、7 日間という既定のバックアップ保持期間が設定されています。All Azure SQL databases (single, pooled, and managed instance databases) have a default backup retention period of seven days. バックアップのリテンション期間を最大 35 日間まで変更できます。You can change backup retention period up to 35 days.

データベースを削除した場合、SQL Database はオンライン データベースの場合と同じようにバックアップを保持します。If you delete a database, SQL Database will keep the backups in the same way it would for an online database. たとえば、7 日間のリテンション期間のある基本的なデータベースを削除すると、4 日間保存されているバックアップはさらに 3 日間保存されます。For example, if you delete a Basic database that has a retention period of seven days, a backup that is four days old is saved for three more days.

最大の保有期間より長くバックアップを保持する必要がある場合は、データベースに 1 つまたは複数のより長い保有期間を追加するようにバックアップのプロパティを変更できます。If you need to keep the backups for longer than the maximum retention period, you can modify the backup properties to add one or more long-term retention periods to your database. 詳細については、「長期保存」をご覧ください。For more information, see Long-term retention.

重要

SQL Database をホストする Azure SQL サーバーを削除すると、サーバーに属するすべてのエラスティック プールとデータベースも削除され、復元できなくなります。If you delete the Azure SQL server that hosts SQL databases, all elastic pools and databases that belong to the server are also deleted and cannot be recovered. 削除されたサーバーを復元することはできません。You cannot restore a deleted server. 長期保有を構成した場合、LTR を使用したデータベースのバックアップは削除されず、これらのデータベースを復元することができます。But if you configured long-term retention, the backups for the databases with LTR will not be deleted and these databases can be restored.

暗号化バックアップEncrypted backups

データベースが TDE で暗号化されている場合、LTR バックアップを含むバックアップは保存中に自動的に暗号化されます。If your database is encrypted with TDE, the backups are automatically encrypted at rest, including LTR backups. Azure SQL データベースに対して TDE が有効になっているとき、バックアップも暗号化されます。When TDE is enabled for an Azure SQL database, backups are also encrypted. 新しい Azure SQL データベースはすべて、既定で TDE が有効になった状態で構成されます。All new Azure SQL databases are configured with TDE enabled by default. TDE に関する詳細については、「Azure SQL Database での Transparent Data Encryption」をご覧ください。For more information on TDE, see Transparent Data Encryption with Azure SQL Database.

バックアップの整合性Backup integrity

Azure SQL Database のエンジニアリング チームは、論理サーバーとエラスティック プールに置かれているデータベースの自動データベース バックアップの復元の自動テストを継続的に行っています (これはマネージド インスタンスでは利用できません)。On an ongoing basis, the Azure SQL Database engineering team automatically tests the restore of automated database backups of databases placed in Logical servers and Elastic pools (this is not available in Managed Instance). 特定時点への復元時に、データベースは DBCC CHECKDB を使用した整合性チェックも受けます。Upon point-in-time restore, databases also receive integrity checks using DBCC CHECKDB.

マネージド インスタンスでは、以降の完了後、ネイティブ CHECKSUM コマンドまたはデータ移行サービスを利用して復元されたデータベースの RESTORE を含む自動初回バックアップが受け取られます。Managed Instance takes automatic initial backup with CHECKSUM of the databases restored using native RESTORE command or Data Migration Service once the migration is completed.

整合性チェック中に問題が見つかると、エンジニアリング チームにアラートが送信されます。Any issues found during the integrity check will result in an alert to the engineering team. Azure SQL Database におけるデータ整合性の詳細については、「Data Integrity in Azure SQL Database」 (Azure SQL Database でのデータ整合性) を参照してください。For more information about data integrity in Azure SQL Database, see Data Integrity in Azure SQL Database.

コンプライアンスCompliance

DTU ベースのサービス レベルから仮想コア ベースのサービス レベルにデータベースを移行した場合、アプリケーションのデータ リカバリ ポリシーに違反しないように、PITR リテンション期間が保持されます。When you migrate your database from a DTU-based service tier to a vCore-based service tier, the PITR retention is preserved to ensure that your application's data recovery policy is not compromised. 既定のリテンション期間では、お客様のコンプライアンス要件を満たしていない場合は、PowerShell または REST API を使用して PITR リテンション期間を変更できます。If the default retention doesn't meet your compliance requirements, you can change the PITR retention period using PowerShell or REST API. 詳細については、バックアップのリテンション期間の変更に関するセクションを参照してください。For more information, see Change Backup Retention Period.

注意

この記事は、デバイスまたはサービスから個人用データを削除する手順について説明しており、GDPR での義務を果たすために使用できます。This article provides steps for how to delete personal data from the device or service and can be used to support your obligations under the GDPR. GDPR に関する一般的な情報をお探しの場合は、Service Trust portal の GDPR に関するセクションを参照してください。If you’re looking for general info about GDPR, see the GDPR section of the Service Trust portal.

PITR バックアップ保持期間の変更Change PITR backup retention period

既定の PITR バックアップ保持期間は、Azure portal、PowerShell、または REST API を使用して変更できます。You can change the default PITR backup retention period using the Azure portal, PowerShell, or the REST API. 次の例では、PITR リテンション期間を 28 日間に変更する方法を示します。The following examples illustrate how to change PITR retention to 28 days.

警告

現在の保持期間を短縮した場合、新しい保持期間より古いすべての既存のバックアップは使用できなくなります。If you reduce the current retention period, all existing backups older than the new retention period are no longer available. 現在のリテンション期間を延長した場合、SQL Database は、より長いリテンション期間に達するまでに、既存のバックアップを保持します。If you increase the current retention period, SQL Database will keep the existing backups until the longer retention period is reached.

注意

これらの API は PITR リテンション期間にのみ影響を与えます。These APIs will only impact the PITR retention period. データベースの LTR を構成した場合、それには影響ありません。If you configured LTR for your database, it will not be impacted. LTR の保持期間を変更する方法については、長期保有に関するページを参照してください。For more information about how to change the LTR retention period(s), see Long-term retention.

Azure portal を使用して PITR のバックアップ保有期間を変更するChange PITR backup retention period using Azure portal

Azure portal を使用して PITR バックアップ保有期間を変更するには、portal 内で保持期間を変更するサーバー オブジェクトに移動し、変更するサーバー オブジェクトに基づいて適切なオプションを選択します。To change the PITR backup retention period using the Azure portal, navigate to the server object whose retention period you wish to change within the portal and then select the appropriate option based on which server object you're modifying.

単一の Azure SQL Database に対する PITR バックアップ保有期間の変更は、サーバー レベルで実行されます。Change of PITR backup retention for single Azure SQL Databases is performed at the server level. サーバー レベルで行われた変更は、そのサーバー上のデータベースに適用されます。Change made at the server level applies to databases on that server. Azure SQL Database サーバーの PITR を Azure portal から変更するには、サーバーの概要ブレードに移動し、ナビゲーション メニューの [バックアップの管理] をクリックして、ナビゲーション バーの [保有期間の構成] をクリックします。To change PITR for Azure SQL Database server from Azure portal, navigate to the server overview blade, click on Manage Backups on the navigation menu, and then click on Configure retention at the navigation bar.

Azure portal の PITR の変更

PowerShell を使用して PITR バックアップ リテンション期間を変更するChange PITR backup retention period using PowerShell

注意

この記事は、新しい Azure PowerShell Az モジュールを使用するために更新されました。This article has been updated to use the new Azure PowerShell Az module. AzureRM モジュールはまだ使用でき、少なくとも 2020 年 12 月までは引き続きバグ修正が行われます。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Az モジュールと AzureRM の互換性の詳細については、「Introducing the new Azure PowerShell Az module (新しい Azure PowerShell Az モジュールの概要)」を参照してください。To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Az モジュールのインストール手順については、Azure PowerShell のインストールを参照してください。For Az module installation instructions, see Install Azure PowerShell.

重要

PowerShell Azure Resource Manager モジュールは Azure SQL Database で引き続きサポートされますが、今後の開発はすべて Az.Sql モジュールを対象に行われます。The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. これらのコマンドレットについては、「AzureRM.Sql」を参照してください。For these cmdlets, see AzureRM.Sql. Az モジュールと AzureRm モジュールのコマンドの引数は実質的に同じです。The arguments for the commands in the Az module and in the AzureRm modules are substantially identical.

Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

REST API を使用して PITR リテンション期間を変更するChange PITR retention period using REST API

要求のサンプルSample Request

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

要求本文Request Body

{
  "properties":{
    "retentionDays":28
  }
}

応答のサンプルSample Response

状態コード:200Status code: 200

{
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
  }
}

詳細については、バックアップの保有期間の REST APIに関するページを参照してください。For more information, see Backup Retention REST API.

次のステップNext steps