自動バックアップ - Azure SQL Database および SQL Managed InstanceAutomated backups - Azure SQL Database & SQL Managed Instance

適用対象: Azure SQL Database Azure SQL Managed Instance

注意

この記事では、デバイスまたはサービスから個人データを削除する手順について説明します。また、これは 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.

データベースのバックアップとはWhat is a database backup?

データの破損または削除から保護するデータベース バックアップは、ビジネス継続性およびディザスター リカバリー戦略の最も重要な部分です。Database backups are an essential part of any business continuity and disaster recovery strategy, because they protect your data from corruption or deletion. これらのバックアップにより、構成された保有期間内の特定の時点にデータベースを復元できます。These backups enable database restore to a point in time within the configured retention period. データ保護規則で、バックアップを長期間 (最長 10 年間) 利用できるようにする必要がある場合は、単一データベースとプールされたデータベースの両方で長期保有を構成できます。If your data protection rules require that your backups are available for an extended time (up to 10 years), you can configure long-term retention for both single and pooled databases.

バックアップ頻度Backup frequency

SQL Database と SQL Managed Instance は SQL Server 技術を利用して、完全バックアップを毎週、差分バックアップを 12 から 24 時間ごと、そしてトランザクション ログ バックアップを 5 から 10 分ごとに作成します。Both SQL Database and SQL Managed Instance use SQL Server technology to create full backups every week, differential backups every 12-24 hours, and transaction log backups every 5 to 10 minutes. トランザクション ログ バックアップの頻度は、コンピューティング サイズとデータベース アクティビティの量に基づいて決まります。The frequency of transaction log backups is based on the compute size and the amount of database activity.

データベースを復元するとき、復元する必要がある完全バックアップ、差分バックアップ、トランザクション ログ バックアップはどれであるかがサービスによって判定されます。When you restore a database, the service determines which full, differential, and transaction log backups need to be restored.

バックアップ ストレージの冗長性Backup storage redundancy

SQL Database と SQL Managed Instance では既定で、ペアになっているリージョンにレプリケートされる geo 冗長 (RA-GRS) ストレージ BLOB にデータが格納されます。By default, SQL Database and SQL Managed Instance store data in geo-redundant (RA-GRS) storage blobs that are replicated to a paired region. それにより、プライマリ リージョンのバックアップ ストレージに影響する障害が起きないように保護され、万一障害が発生しても別のリージョンにサーバーを復元できます。This helps to protect against outages impacting backup storage in the primary region and allow you to restore your server to a different region in the event of a disaster.

バックアップ ストレージの冗長性を構成するオプションによって、ローカル冗長、ゾーン冗長、geo 冗長のいずれかのストレージ BLOB を、SQL Managed Instance または SQL Database に対して柔軟に選択することができます。The option to configure backup storage redundancy provides the flexibility to choose between locally-redundant, zone-redundant, or geo-redundant storage blobs for a SQL Managed Instance or a SQL Database. マネージド インスタンスまたは SQL データベースがデプロイされているのと同じリージョンにデータが保持されるようにするには、既定の geo 冗長バックアップ ストレージの冗長性を変更し、バックアップに対してローカル冗長 (LRS) またはゾーン冗長 (ZRS) のストレージ BLOB を構成することができます。To ensure that your data stays within the same region where your managed instance or SQL database is deployed, you can change the default geo-redundant backup storage redundancy and configure either locally-redundant (LRS) or zone-redundant (ZRS) storage blobs for backups. ストレージの冗長性メカニズムでは、計画されたイベントや計画外のイベント (一時的なハードウェア障害、ネットワークの停止や停電、大規模な自然災害など) からデータを保護するため、データのコピーが複数格納されます。Storage redundancy mechanisms store multiple copies of your data so that it is protected from planned and unplanned events, including transient hardware failure, network or power outages, or massive natural disasters. 構成されたバックアップ ストレージの冗長性が、ポイントインタイム リストア (PITR) に使用される短期保有バックアップ設定と、長期的バックアップ (LTR) に使用される長期保有バックアップの、両方に適用されます。The configured backup storage redundancy is applied to both short-term backup retention settings that are used for point in time restore (PITR) and long-term retention backups used for long-term backups (LTR).

SQL Database の場合、バックアップ ストレージの冗長性は、データベースの作成時に構成することも、既存のデータベースに対して更新することもできます。既存のデータベースに対する変更は、それ以降のバックアップにのみ適用されます。For a SQL Database the backup storage redundancy can be configured at the time of database creation or can be updated for an existing database; the changes made to an existing database apply to future backups only. 既存のデータベースのバックアップ ストレージの冗長性を更新した後、変更が適用されるまでに最大 48 時間かかることがあります。After the backup storage redundancy of an existing database is updated, it may take up to 48 hours for the changes to be applied. ローカル冗長またはゾーン冗長のストレージを使用するようにデータベースを更新するとすぐに、geo リストアが無効になることに注意してください。Note that, geo restore is disabled as soon as a database is updated to use local or zone redundant storage.

重要

リソースがプロビジョニングされたら、マネージド インスタンス作成プロセス中にバックアップ ストレージ冗長性を構成します。ストレージ冗長性を変更することはできなくなりました。Configure backup storage redundancy during the managed instance creation process as once the resource is provisioned, it is no longer possible to change the storage redundancy.

重要

ゾーン冗長ストレージは現在、特定のリージョンでのみ利用できます。Zone-redundant storage is currently only available in certain regions.

注意

Azure SQL Database の [Configurable Backup Storage Redundancy](構成可能なバックアップ ストレージの冗長性) は、ブラジル南部ではパブリック プレビューとして利用でき、一般公開されているのは東南アジアの Azure リージョンのみです。Configurable Backup Storage Redundancy for Azure SQL Database is currently available in public preview in Brazil South and generally available in Southeast Asia Azure region only. この機能は、Hyperscale レベルではまだ使用できません。This feature is not yet available for Hyperscale tier.

バックアップの用途Backup usage

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

  • 既存データベースのポイントインタイム リストア - Azure portal、Azure PowerShell、Azure CLI、または REST API を使用して、保持期間内の 過去の特定の時点に既存のデータベースを復元しますPoint-in-time restore of existing database - Restore an existing database to a point in time in the past within the retention period by using Azure portal, Azure PowerShell, Azure CLI, or REST API. SQL Database では、この操作により、元のデータベースと同じサーバーに新しいデータベースが作成されますが、元のデータベースが上書きされるのを防ぐため、別の名前が使用されます。For SQL Database, this operation creates a new database on the same server as the original database, but uses a different name to avoid overwriting the original database. 復元が完了したら、元のデータベースを削除することができます。After restore completes, you can delete the original database. または、元のデータベースの名前を変更したうえで、復元されたデータベースの名前を元のデータベース名に変更してもかまいません。Alternatively, you can rename both the original database, and then rename the restored database to the original database name. SQL Managed Instance でも同様に、この操作により、同じリージョン、同じサブスクリプションの同じ、または異なるマネージド インスタンスに、データベースのコピーが作成されます。Similarly, for SQL Managed Instance, this operation creates a copy of the database on the same or different managed instance in the same subscription and same region.
  • 削除されたデータベースのポイントインタイム リストア - 削除されたデータベースを削除の時点に復元します。または、保持期間内の特定の時点に復元します。Point-in-time restore of deleted database - Restore a deleted database to the time of deletion or to any point in time within the retention period. 削除されたデータベースは、元のデータベースが作成されていたのと同じサーバーまたはマネージド インスタンスにのみ復元できます。The deleted database can be restored only on the same server or managed instance where the original database was created. データベースを削除すると、データが失われないように、削除前にサービスによって最後のトランザクション ログ バックアップが取得されます。When deleting a database, the service takes a final transaction log backup before deletion, to prevent any data loss.
  • geo リストア - 別の地理的リージョンにデータベースを復元しますGeo-restore - Restore a database to another geographic region. geo リストアを使用すると、プライマリ リージョンのデータベースまたはバックアップにアクセスできないときでも、地理的な災害から復旧できます。Geo-restore allows you to recover from a geographic disaster when you cannot access your database or backups in the primary region. 任意の Azure リージョンの既存のサーバーまたはマネージド インスタンスに、新しいデータベースが作成されます。It creates a new database on any existing server or managed instance, in any Azure region.

    重要

    geo リストアは、geo 冗長バックアップ ストレージを使用して構成された SQL データベースまたはマネージド インスタンスでのみ利用できます。Geo-restore is available only for SQL databases or managed instances configured with geo-redundant backup storage.

  • 長期的バックアップからの復元 - データベースの長期保有ポリシー (LTR) が構成されている場合、単一データベースまたはプールされたデータベースの 特定の長期バックアップからデータベースを復元しますRestore from long-term backup - Restore a database from a specific long-term backup of a single database or pooled database, 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 by 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 では、" レプリケーション " とは、ある場所から別の場所に BLOB をコピーすることを表します。In Azure Storage, the term replication refers to copying blobs from one location to another. SQL では、" データベース レプリケーション " とは、複数のセカンダリ データベースをプライマリ データベースと同期しておくために使用されるさまざまなテクノロジのことです。In SQL, database replication refers to various technologies used to keep multiple secondary databases synchronized with a primary database.

次の例を使用して、バックアップの構成と復元の操作を試すことができます。You can try backup configuration and restore operations using the following examples:

操作Operation Azure portalAzure portal Azure PowerShellAzure PowerShell
バックアップ保有期間を変更するChange backup retention SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
長期的なバックアップ保有期間を変更するChange long-term backup retention SQL DatabaseSQL Database
SQL Managed Instance - N/ASQL Managed Instance - N/A
SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
特定の時点からデータベースを復元するRestore a database from a point in time SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
削除されたデータベースの復元Restore a deleted database SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
SQL DatabaseSQL Database
SQL Managed InstanceSQL Managed Instance
Azure Blob Storage からデータベースを復元するRestore a database from Azure Blob storage SQL Database - N/ASQL Database - N/A
SQL Managed Instance - N/ASQL Managed Instance - N/A
SQL Database - N/ASQL Database - N/A
SQL Managed InstanceSQL Managed Instance

バックアップのスケジュール設定Backup scheduling

初回の完全バックアップは、新しいデータベースの作成または復元の直後にスケジュールされます。The first full backup is scheduled immediately after a new database is created or restored. 通常このバックアップは 30 分以内に終了しますが、データベースが大きい場合はそれ以上かかることがあります。This backup usually completes within 30 minutes, but it can take longer when the database is large. たとえば、復元されたデータベースまたはデータベースのコピーでは、初期バックアップに時間がかかる場合があり、通常は新しいデータベースより大きくなります。For example, the initial backup can take longer on a restored database or a database copy, which would typically be larger than a new database. 初回の完全バックアップ以降のすべてのバックアップは、自動的にスケジュールおよび管理されます。After the first full backup, all further backups are scheduled and managed automatically. すべてのデータベースのバックアップの正確なタイミングは、システム全体のワークロードのバランスを取りながら、SQL Database サービスまたは SQL Managed Instance サービスによって決定されます。The exact timing of all database backups is determined by the SQL Database or SQL Managed Instance service as it balances the overall system workload. バックアップ ジョブのスケジュールを変更したり、スケジュールを無効にしたりすることはできません。You cannot change the schedule of backup jobs or disable them.

重要

新しいデータベース、復元されたデータベース、またはコピーされたデータベースの場合、特定の時点への復元機能は、最初の完全バックアップの後で最初のトランザクション ログ バックアップが作成された時点から、使用できるようになります。For a new, restored, or copied database, point-in-time restore capability becomes available from the time when the initial transaction log backup that follows the initial full backup is created.

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

SQL Server のバックアップと復元のテクノロジでは、特定の時点にデータベースを復元するには、1 回の完全バックアップ、必要に応じて 1 回の差分バックアップ、1 回以上のトランザクション ログ バックアップで構成される、中断のないバックアップ チェーンが必要です。With SQL Server backup and restore technology, restoring a database to a point in time requires an uninterrupted backup chain consisting of one full backup, optionally one differential backup, and one or more transaction log backups. SQL Database および SQL Managed Instance のバックアップ スケジュールには、毎週、1 回の完全バックアップが含まれます。SQL Database and SQL Managed Instance backup schedule includes one full backup every week. したがって、保有期間全体で PITR を有効にするには、構成されている保有期間より最大で 1 週間長い期間の、完全バックアップ、差分バックアップ、トランザクション ログ バックアップが追加で保存されている必要があります。Therefore, to enable PITR within the entire retention period, the system must store additional full, differential, and transaction log backups for up to a week longer than the configured retention period.

つまり、保有期間中の任意の時点において、保有期間の最も古い時点より古い完全バックアップと、その完全バックアップから次の完全バックアップまでの差分バックアップとトランザクション ログ バックアップの中断されていないチェーンが、存在する必要があります。In other words, for any point in time during the retention period, there must be a full backup that is older than the oldest time of the retention period, as well as an uninterrupted chain of differential and transaction log backups from that full backup until the next full backup.

注意

PITR を有効にするため、追加のバックアップは、構成されている保有期間より最大 1 週間長く格納されます。To enable PITR, additional backups are stored for up to a week longer than the configured retention period. バックアップ ストレージは、すべてのバックアップと同じ料金で課金されます。Backup storage is charged at the same rate for all backups.

PITR 機能を提供するために必要なくなったバックアップは、自動的に削除されます。Backups that are no longer needed to provide PITR functionality are automatically deleted. 差分バックアップとログ バックアップでは先行する完全バックアップが復元可能である必要なため、3 つのバックアップの種類すべてが毎週まとめて消去されます。Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets.

TDE で暗号化されたデータベースを含むすべてのデータベースでは、バックアップ ストレージの大きさとコストを削減するためバックアップが圧縮されます。For all databases including TDE encrypted databases, backups are compressed to reduce backup storage compression and costs. 平均のバックアップ圧縮率は 3 から 4 倍ですが、データの性質や、データベースでデータ圧縮が使用されているかどうかにより、大幅に低くなったり高くなったりする可能性があります。Average backup compression ratio is 3-4 times, however it can be significantly lower or higher depending on the nature of the data and whether data compression is used in the database.

SQL Database と SQL Managed Instance では、使用されたバックアップ ストレージの合計が累積値として計算されます。SQL Database and SQL Managed Instance compute your total used backup storage as a cumulative value. この累積値が 1 時間おきに Azure 課金パイプラインに報告されます。この時間あたり使用量がパイプラインによって集計されて、毎月末に消費量が計算されます。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 deleted, consumption decreases as backups age out and are deleted. すべてのバックアップが削除されて、PITR が不可能になると、課金は停止します。Once all backups are deleted and PITR is no longer possible, billing stops.

重要

データベースが削除された場合でも、データベースのバックアップは PITR を有効にするために保持されます。Backups of a database are retained to enable PITR even if the database has been deleted. データベースを削除して再作成すると、ストレージとコンピューティングのコストが削減される場合がありますが、削除されるたびに、削除された各データベースのバックアップがサービスによって保持されるため、バックアップ ストレージのコストが増加する可能性があります。While deleting and re-creating a database may save storage and compute costs, it may increase backup storage costs, because the service retains backups for each deleted database, every time it is deleted.

消費量の監視Monitor consumption

仮想コア データベースの場合、各種バックアップ (完全、差分、ログ) によって使用されるストレージは、データベース監視ブレード上で別個のメトリックとして報告されます。For vCore databases, the storage consumed by 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 backup storage consumption for a single database. この機能は、マネージド インスタンスでは現在使用できません。This feature is currently not available for managed instances.

Azure portal でのデータベース バックアップ消費量の監視

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

データベースの最大データ サイズまでのバックアップ ストレージの使用量については、課金されません。Backup storage consumption up to the maximum data size for a database is not charged. 超過のバックアップ ストレージ消費量は、個々のデータベースのワークロードと最大サイズに依存します。Excess backup storage consumption will depend on the workload and maximum size of the individual databases. バックアップ ストレージ消費量を減らすには、次の調整手法のいくつかを検討してください。Consider some of the following tuning techniques to reduce your backup storage consumption:

  • 必要最小限までバックアップの保持期間を短縮します。Reduce the backup retention period to the minimum possible for your needs.
  • インデックスの再構築などの大規模な書き込み操作を、必要以上に頻繁に行わないようにします。Avoid doing large write operations, like index rebuilds, more frequently than you need to.
  • 大規模なデータ読み込み操作の場合、クラスター化された列ストア インデックスを使用して、関連するベスト プラクティスに従うことを検討し、クラスター化されていないインデックスの数を減らします。For large data load operations, consider using clustered columnstore indexes and following related best practices, and/or reduce the number of non-clustered indexes.
  • 汎用サービス レベルでは、プロビジョニングされたデータ ストレージの方が、バックアップ ストレージの価格よりも安価です。In the General Purpose service tier, the provisioned data storage is less expensive than the price of the backup storage. 超過のバックアップ ストレージのコストが継続的に増加している場合は、データ ストレージを増やしてバックアップ ストレージを節約することを検討してください。If you have continually high excess backup storage costs, you might consider increasing data storage to save on the backup storage.
  • 一時的な結果やデータの保存には、アプリケーションのロジックでの永続的テーブルではなく TempDB を使用します。Use TempDB instead of permanent tables in your application logic for storing temporary results and/or transient data.
  • 可能な限り (Dev/Test 環境など) ローカル冗長バックアップ ストレージを使用します。Use locally-redundant backup storage whenever possible (for example dev/test environments)

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

新しいデータベース、復元されたデータベース、コピーされたデータベースのすべてについて、Azure SQL Database と Azure SQL Managed Instance では、既定で、過去 7 日間の PITR が可能な十分なバックアップが保持されます。For all new, restored, and copied databases, Azure SQL Database and Azure SQL Managed Instance retain sufficient backups to allow PITR within the last 7 days by default. Hyperscale データベースを除き、1 から 35 日の範囲で、アクティブなデータベースごとにバックアップの保持期間を変更することができます。With the exception of Hyperscale databases, you can change backup retention period per each active database in the 1-35 day range. バックアップ ストレージ消費量」で説明されているように、PITR を有効にするために保存されているバックアップは、保有期間より古い場合があります。As described in Backup storage consumption, backups stored to enable PITR may be older than the retention period. Azure SQL Managed Instance のみの場合、データベースを削除した後で、PITR バックアップ保持率を 0 から 35 日の範囲で設定できます。For Azure SQL Managed Instance only, it is possible to set the PITR backup retention rate once a database has been deleted in the 0-35 days range.

データベースを削除した場合、システムでは、オンライン データベースと同じ方法で、特定の保有期間のバックアップが保持されます。If you delete a database, the system keeps backups in the same way it would for an online database with its specific retention period. 削除されたデータベースのバックアップ保有期間を変更することはできません。You cannot change backup retention period for a deleted database.

重要

サーバーまたはマネージド インスタンスを削除すると、そのサーバーまたはマネージド インスタンス上のすべてのデータベースも削除され、復旧できなくなります。If you delete a server or a managed instance, all databases on that server or managed instance are also deleted and cannot be recovered. 削除されたサーバーまたはマネージド インスタンスは復元できません。You cannot restore a deleted server or managed instance. ただし、データベースまたはマネージド インスタンスに対して長期保有 (LTR) を構成していた場合、長期保有バックアップは削除されず、同じサブスクリプション内の異なるサーバーまたはマネージド インスタンスのデータベースを、長期保有バックアップが作成された特定の時点まで復元するために使用できます。But if you had configured long-term retention (LTR) for a database or managed instance, long-term retention backups are not deleted, and can be used to restore databases on a different server or managed instance in the same subscription, to a point in time when a long-term retention backup was taken.

過去 1 から 35 日以内の PITR のためのバックアップ保有は、短期バックアップ保有とも呼ばれます。Backup retention for purposes of PITR within the last 1-35 days is sometimes called short-term backup retention. 短期保有期間の最大値である 35 日より長くバックアップを保持する必要がある場合は、長期保有を有効にすることができます。If you need to keep backups for longer than the maximum short-term retention period of 35 days, you can enable Long-term retention.

長期保存Long-term retention

SQL Database と SQL Managed Instance ではどちらも、最大 10 年間の完全バックアップの長期保有 (LTR) を Azure Blob Storage で構成できます。For both SQL Database and SQL Managed Instance, you can configure full backup long-term retention (LTR) for up to 10 years in Azure Blob storage. LTR ポリシーを構成すると、週に 1 回、完全バックアップが自動的に別のストレージ コンテナーにコピーされます。After the LTR policy is configured, full backups are automatically copied to a different storage container weekly. 各種のコンプライアンス要件を満たすために、毎週、毎月、毎年の完全バックアップに対してさまざまな保有期間を選択できます。To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. ストレージの使用量は、LTR バックアップについて選択した頻度と保持期間によって異なります。Storage consumption depends on the selected frequency and retention periods of LTR backups. LTR ストレージのコストは、LTR 料金計算ツールを使用して見積もることができます。You can use the LTR pricing calculator to estimate the cost of LTR storage.

重要

既存の Azure SQL Database に対するバックアップ ストレージの冗長性の更新は、そのデータベースでそれ以降に作成されるバックアップについてのみ適用されます。Updating the backup storage redundancy for an existing Azure SQL Database, only applies to the future backups taken for the database. データベースのすべての既存の LTR バックアップは、既存のストレージ BLOB に引き続き存在し、新しいバックアップは要求されたストレージ BLOB の種類に格納されます。All existing LTR backups for the database will continue to reside in the existing storage blob and new backups will be stored on the requested storage blob type.

LTR の詳細については、バックアップの長期保有に関するページを参照してください。For more information about LTR, see Long-term backup retention.

ストレージ コストStorage costs

バックアップ ストレージの価格は、購入モデル (DTU または仮想コア) と選択したバックアップ ストレージ冗長性オプション、さらにリージョンによっても異なります。The price for backup storage varies and depends on your purchasing model (DTU or vCore), chosen backup storage redundancy option, and also on your region. バックアップ ストレージは、使用量 (GB/月) に応じて課金されます。価格については、「Azure SQL Database の価格」と「Azure SQL Managed Instance の価格」のページを参照してください。The backup storage is charged per GB/month consumed, for pricing see Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

DTU モデルDTU model

DTU モデルでは、データベースおよびエラスティック プール用のバックアップ ストレージに対する追加請求はありません。In the DTU model, there's no additional charge for backup storage for databases and elastic pools. バックアップ ストレージの料金は、データベースまたはプールの価格の一部です。The price of backup storage is a part of database or pool price.

仮想コア モデルvCore model

SQL Database の単一データベースの場合は、データベースの最大データ ストレージ サイズの 100% に等しいバックアップ ストレージ容量が、追加料金なしで提供されます。For single databases in SQL Database, a backup storage amount equal to 100 percent of the maximum data storage size for the database is provided at no extra charge. エラスティック プールとマネージド インスタンスの場合は、それぞれ、プールに対する最大データ ストレージまたは最大インスタンス ストレージ サイズの 100% に等しいバックアップ ストレージ容量が、追加料金なしで提供されます。For elastic pools and managed instances, a backup storage amount equal to 100 percent of the maximum data storage for the pool or the maximum instance storage size, respectively, is provided at no extra charge.

単一データベースの場合、課金対象のバックアップ ストレージ合計使用量の計算には次の式が使用されます。For single databases, this equation is used to calculate the total billable backup storage usage:

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

プールされたデータベースの場合、課金対象のバックアップ ストレージの合計サイズはプール レベルで集計され、次のように計算されます。For pooled databases, the total billable backup storage size is aggregated at the pool level and is calculated as follows:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

マネージド インスタンスの場合、課金対象のバックアップ ストレージの合計サイズはインスタンス レベルで集計され、次のように計算されます。For managed instances, the total billable backup storage size is aggregated at the instance level and is calculated as follows:

Total billable backup storage size = (total size of full backups + total size of differential backups + total size of log backups) – maximum instance data storage

すべての課金対象のバックアップ ストレージ (存在する場合) は、使用されているバックアップ ストレージの冗長性の割合に従って、GB/月単位で課金されます。Total billable backup storage, if any, will be charged in GB/month as per the rate of the backup storage redundancy used. このバックアップ ストレージ消費量は、個々のデータベース、エラスティック プール、マネージド インスタンスのワークロードとサイズに依存します。This backup storage consumption will depend on the workload and size of individual databases, elastic pools, and managed instances. 差分バックアップとログ バックアップのサイズはデータの変更量に比例するため、大幅に変更されたデータベースでは、これらのバックアップが大きくなります。Heavily modified databases have larger differential and log backups, because the size of these backups is proportional to the amount of data changes. したがって、そのようなデータベースではバックアップ料金が高くなります。Therefore, such databases will have higher backup charges.

SQL Database と SQL Managed Instance では、課金対象の合計バックアップ ストレージは、すべてのバックアップ ファイルの累積値として計算されます。SQL Database and SQL Managed Instance computes your total billable backup storage as a cumulative value across all backup files. この累積値が 1 時間ごとに Azure 課金パイプラインに報告され、そこで、この時間あたり使用量が集計されて、毎月末にバックアップ ストレージの消費量が算出されます。Every hour, this value is reported to the Azure billing pipeline, which aggregates this hourly usage to get your backup storage consumption at the end of each month. データベースが削除されると、古いバックアップが期限切れになって削除されるに従い、バックアップ ストレージの使用量は徐々に減少します。If a database is deleted, backup storage consumption will gradually decrease as older backups age out and are deleted. 差分バックアップとログ バックアップでは先行する完全バックアップが復元可能である必要なため、3 つのバックアップの種類すべてが毎週まとめて消去されます。Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets. すべてのバックアップが削除されると、課金は停止します。Once all backups are deleted, billing stops.

簡単な例として、データベースのバックアップ ストレージが累積で 744 GB になり、データベースは完全にアイドル状態であるため、この量は 1 か月を通して変わらないものとします。As a simplified example, assume a database has accumulated 744 GB of backup storage and that this amount stays constant throughout an entire month because the database is completely idle. この累積ストレージ消費量を 1 時間あたりの使用量に変換するには、744.0 (1 か月 31 日 * 1 日 24 時間) で割ります。To convert this cumulative storage consumption to hourly usage, divide it by 744.0 (31 days per month * 24 hours per day). SQL Database では、データベースで 1 時間あたり 1 GB の PITR バックアップが一定の割合で消費されたことが、Azure 課金パイプラインに報告されます。SQL Database will report to Azure billing pipeline that the database consumed 1 GB of PITR backup each hour, at a constant rate. Azure の課金では、この消費量を集計し、1 か月全体で 744 GB という使用量が示されます。Azure billing will aggregate this consumption and show a usage of 744 GB for the entire month. コストは、使っているリージョンでの GB 単位の月額料金に基づいて算出されます。The cost will be based on the amount/GB/month rate in your region.

次の例はもっと複雑になります。Now, a more complex example. 同じアイドル状態のデータベースで、保有期間が月の途中で 7 日から 14 日間に増やされたとします。Suppose the same idle database has its retention increased from 7 days to 14 days in the middle of the month. この増加により、バックアップ ストレージの合計は 1,488 GB に倍増します。This increase results in the total backup storage doubling to 1,488 GB. SQL Database では、1 時間から 372 時間まで (月の前半) の使用量が 1 GB と報告されます。SQL Database would report 1 GB of usage for hours 1 through 372 (the first half of the month). 373 時間から 744 時間まで (月の後半) の使用量は 2 GB と報告されます。It would report the usage as 2 GB for hours 373 through 744 (the second half of the month). この使用量が集計されて最終的な請求は 1,116 GB/月になります。This usage would be aggregated to a final bill of 1,116 GB/month.

実際のバックアップの課金シナリオはさらに複雑です。Actual backup billing scenarios are more complex. データベース内の変更の割合はワークロードに依存し、時間の経過と共に変化するので、各差分バックアップとログ バックアップのサイズも変化するため、時間単位のバックアップ ストレージの消費量はそれに応じて変動します。Because the rate of changes in the database depends on the workload and is variable over time, the size of each differential and log backup will vary as well, causing the hourly backup storage consumption to fluctuate accordingly. さらに、各差分バックアップには、前回の完全バックアップ以降にデータベースで行われたすべての変更が含まれるため、すべての差分バックアップの合計サイズは 1 週間の間に徐々に増加した後、完全バックアップ、差分バックアップ、ログ バックアップの古いセットが削除されると、大幅に低下します。たとえば、完全バックアップが完了した直後にインデックスの再構築などの大量の書き込み操作が実行された場合、インデックスの再構築によって行われた変更は、再構築の間に作成されたトランザクション ログ バックアップ、次の差分バックアップ、および次回の完全バックアップが実行されるまでのすべての差分バックアップに含まれます。Furthermore, each differential backup contains all changes made in the database since the last full backup, thus the total size of all differential backups gradually increases over the course of a week, and then drops sharply once an older set of full, differential, and log backups ages out. For example, if a heavy write activity such as index rebuild has been run just after a full backup completed, then the modifications made by the index rebuild will be included in the transaction log backups taken over the duration of rebuild, in the next differential backup, and in every differential backup taken until the next full backup occurs. 大規模なデータベースにおける後者のシナリオでは、そうしないと差分バックアップが過剰に大きくなる場合は、サービスの最適化によって差分バックアップではなく完全バックアップが作成されます。For the latter scenario in larger databases, an optimization in the service creates a full backup instead of a differential backup if a differential backup would be excessively large otherwise. これにより、次の完全バックアップまで、すべての差分バックアップのサイズが小さくなります。This reduces the size of all differential backups until the following full backup.

消費量の監視」で説明されているように、各バックアップの種類 (完全、差分、トランザクション ログ) の合計バックアップ ストレージ使用量を、時間を追って監視できます。You can monitor total backup storage consumption for each backup type (full, differential, transaction log) over time as described in Monitor consumption.

バックアップ ストレージの冗長性Backup storage redundancy

バックアップ ストレージの冗長性は、バックアップ コストに次のように影響します。Backup storage redundancy impacts backup costs in the following way:

  • LRS 価格 = xLRS price = x
  • ZRS 価格 = 1.25xZRS price = 1.25x
  • RA-GRS 価格 = 2xRA-GRS price = 2x

バックアップ ストレージの価格の詳細については、「Azure SQL Database の価格」と「Azure SQL Managed Instance の価格」を参照してください。For more details about backup storage pricing visit Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

重要

構成可能なバックアップ ストレージの冗長性は、SQL Managed Instance についてはすべての Azure リージョンで利用でき、SQL Database については、現在は、東南アジア Azure リージョンでのみ利用できます。Configurable backup storage redundancy for SQL Managed instance is available in all Azure regions and currently available in Southeast Asia Azure region only for SQL Database. Managed Instance については、マネージド インスタンス作成プロセスの間にのみ指定できます。For Managed Instance it can only be specified during the create managed instance process. リソースがプロビジョニングされた後に、バックアップ ストレージ冗長性オプションを変更することはできません。Once the resource is provisioned, you cannot change the backup storage redundancy option.

コストを監視するMonitor costs

バックアップ ストレージのコストを把握するには、Azure portal の [コストの管理と請求] にアクセスし、 [コスト管理] を選択してから、 [コスト分析] を選択します。To understand backup storage costs, go to Cost Management + Billing in the Azure portal, select Cost Management , and then select Cost analysis. [スコープ] として目的のサブスクリプションを選択し、目的の期間とサービスが得られるようにフィルター処理します。Select the desired subscription as the Scope , and then filter for the time period and service that you're interested in.

[サービス名] のフィルターを追加し、ドロップダウン リストで [sql database] を選択します。Add a filter for Service name , and then select sql database in the drop-down list. [測定サブカテゴリ] フィルターを使用して、サービスの課金カウンターを選択します。Use the meter subcategory filter to choose the billing counter for your service. 単一データベースまたはエラスティック データベース プールの場合は、 [single/elastic pool PITR backup storage](単一/エラスティック プール PITR バックアップ ストレージ) を選択します。For a single database or an elastic database pool, select single/elastic pool PITR backup storage. マネージド インスタンスの場合は、 [mi PITR backup storage](MI PITR バックアップ ストレージ) を選択します。For a managed instance, select mi PITR backup storage. [ストレージ][コンピューティング] のサブカテゴリも必要に応じて使用できますが、これらはバックアップ ストレージのコストに関連付けられていません。The Storage and compute subcategories might interest you as well, but they're not associated with backup storage costs.

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

注意

測定値は、現在使用中のカウンターについてのみ表示されます。Meters are only visible for counters that are currently in use. カウンターが利用できない場合、そのカテゴリが現在使用されていないと考えられます。If a counter is not available, it is likely that the category is not currently being used. たとえば、マネージド インスタンスをデプロイしていないユーザーには、マネージド インスタンス カウンターが存在しません。For example, managed instance counters will not be present for customers who do not have a managed instance deployed. 同様に、ストレージを使用していないリソースについては、ストレージ カウンターは表示されません。Likewise, storage counters will not be visible for resources that are not consuming storage.

暗号化バックアップEncrypted backups

データベースが TDE で暗号化されている場合、LTR バックアップを含むバックアップは保存中に自動的に暗号化されます。If your database is encrypted with TDE, backups are automatically encrypted at rest, including LTR backups. Azure SQL のすべての新しいデータベースでは、既定で TDE が有効に構成されます。All new databases in Azure SQL are configured with TDE enabled by default. TDE の詳細については、SQL Database および SQL Managed Instance での Transparent Data Encryption に関するページを参照してください。For more information on TDE, see Transparent Data Encryption with SQL Database & SQL Managed Instance.

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

Azure SQL のエンジニアリング チームは、自動データベース バックアップに対する復元の自動テストを継続的に行っています。On an ongoing basis, the Azure SQL engineering team automatically tests the restore of automated database backups. (このテストは、現在は SQL Managed Instance では使用できません)。ポイントインタイム リストア時に、データベースは DBCC CHECKDB の整合性チェックも受けます。(This testing is not currently available in SQL Managed Instance.) Upon point-in-time restore, databases also receive DBCC CHECKDB integrity checks.

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

すべてのデータベース バックアップは、バックアップの整合性を高めるために、CHECKSUM オプションを使用して実行されます。All database backups are taken with the CHECKSUM option to provide additional backup integrity.

コンプライアンス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 isn't compromised. 既定の保有期間がコンプライアンス要件を満たしていない場合は、PITR 保有期間を変更できます。If the default retention doesn't meet your compliance requirements, you can change the PITR retention period. 詳細については、「PITR バックアップ保有期間を変更する」を参照してください。For more information, see Change the PITR 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 the PITR backup retention period

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

警告

現在の保有期間を短くすると、新しい保有期間より古い特定の時点に復元することができなくなります。If you reduce the current retention period, you lose the ability to restore to points in time older than the new retention period. 新しい保有期間内で PITR を提供するために必要がなくなったバックアップは削除されます。Backups that are no longer needed to provide PITR within the new retention period are deleted. 現在の保有期間を長くした場合、新しい保有期間内の古い特定の時点に復元する機能はすぐには利用できません。If you increase the current retention period, you do not immediately gain the ability to restore to older points in time within the new retention period. システムにより長いバックアップの保有が開始されたら、やがて使用できるようになります。You gain that ability over time, as the system starts to retain backups for longer.

注意

これらの API は PITR 保有期間にのみ影響します。These APIs will affect only the PITR retention period. データベースに LTR が構成されている場合、それには影響しません。If you configured LTR for your database, it won't be affected. LTR の保有期間を変更する方法については、長期保有に関するページを参照してください。For information about how to change LTR retention periods, see Long-term retention.

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

Azure portal を使用してアクティブなデータベースの PITR バックアップ保持期間を変更するには、保持期間を変更するデータベースのサーバーまたはマネージド インスタンスに移動します。To change the PITR backup retention period for active databases by using the Azure portal, go to the server or managed instance with the databases whose retention period you want to change.

SQL Database の PITR バックアップ保有期間に対する変更は、ポータルのサーバー ページで行われます。Changes to PITR backup retention for SQL Database are done on the server page in the portal. サーバーでデータベースの PITR 保有期間を変更するには、サーバーの概要ブレードに移動します。To change PITR retention for databases on a server, go to the server overview blade. 左側のペインで [バックアップの管理] を選択し、変更の範囲内のデータベースを選択してから、画面の上部にある [保有期間の構成] を選択します。Select Manage Backups in the left pane, select the databases in scope of your change, and then select Configure retention at the top of the screen:

PITR 保有期間の変更 (サーバー レベル)

PowerShell を使用して PITR バックアップ保有期間を変更するChange the PITR backup retention period by 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 AzureRM モジュールは SQL Database と SQL Managed Instance によって引き続きサポートされていますが、今後の開発はすべて Az.Sql モジュールを対象に行われます。The PowerShell AzureRM module is still supported by SQL Database and SQL Managed Instance, but all future development is for the Az.Sql module. 詳細については、「AzureRM.Sql」を参照してください。For more information, see AzureRM.Sql. Az モジュールのコマンドの引数は、AzureRm モジュールのものと実質的に同じです。The arguments for the commands in the Az module are substantially identical to those in the AzureRm modules.

アクティブな Azure SQL データベースの PITR バックアップ保持期間を変更するには、次の PowerShell の例を使用します。To change the PITR backup retention for active Azure SQL Databases, use the following PowerShell example.

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

REST API を使用して PITR バックアップ保有期間を変更する方法Change the PITR backup retention period by using the 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.

要求のサンプル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.

バックアップ ストレージの冗長性を構成するConfigure backup storage redundancy

注意

SQL Managed Instance のバックアップに対する構成可能なストレージの冗長性は、マネージド インスタンス作成プロセスの間にのみ指定できます。Configurable storage redundancy for backups for SQL Managed Instance can only be specified during the create managed instance process. リソースがプロビジョニングされた後に、バックアップ ストレージ冗長性オプションを変更することはできません。Once the resource is provisioned, you can't change the backup storage redundancy option. SQL Database の場合、現在、この機能のパブリック プレビューはブラジル南部で使用可能であり、東南アジアの Azure リージョンで一般提供されています。For SQL Database, public preview of this feature is currently available in Brazil South and it is generally available in Southeast Asia Azure region.

マネージド インスタンスのバックアップ ストレージに対する冗長性を設定できるのは、インスタンスの作成時のみです。A backup storage redundancy of a managed instance can be set during instance creation only. SQL Database については、データベースを作成するときに設定するか、または既存のデータベースに対して更新することができます。For a SQL Database it can be set when creating the database or can be updated for an existing database. 既定値は geo 冗長ストレージ (RA-GRS) です。The default value is geo-redundant storage (RA-GRS). ローカル冗長 (LRS)、ゾーン冗長 (ZRS)、geo 冗長 (RA-GRS) の各バックアップ ストレージ間の価格の違いについては、マネージド インスタンスの価格のページを参照してください。For differences in pricing between locally-redundant (LRS), zone-redundant (ZRS) and geo-redundant (RA-GRS) backup storage visit managed instance pricing page.

Azure portal を使用してバックアップ ストレージの冗長性を構成するConfigure backup storage redundancy by using the Azure portal

バックアップ ストレージの冗長性は、Azure portal の [SQL データベースの作成] ブレードで構成できます。In Azure portal, you can configure the backup storage redundancy on the Create SQL Database blade. このオプションは、[バックアップ ストレージの冗長性] セクションにあります。The option is available under the Backup Storage Redundancy section. [SQL データベースの作成] ブレードを開くOpen Create SQL Database blade

PowerShell を使用してバックアップ ストレージの冗長性を構成するConfigure backup storage redundancy by using PowerShell

新しいデータベースを作成するときにバックアップ ストレージの冗長性を構成するには、-BackupStoageRedundancy パラメーターを指定します。To configure backup storage redundancy when creating a new database you can specify the -BackupStoageRedundancy parameter. 指定できる値は、Geo、Zone、Local です。Possible values are Geo, Zone and Local. 既定では、すべての SQL データベースでバックアップに geo 冗長ストレージが使用されます。By default, all SQL Databases use geo-redundant storage for backups. ローカルまたはゾーンの冗長バックアップ ストレージを使用してデータベースを作成した場合、geo リストアは無効になります。Geo Restore is disabled if a database is created with local or zone redundant backup storage.

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Geo

詳細については、「New-AzSqlDatabase」を参照してください。For details visit New-AzSqlDatabase.

既存のデータベースのバックアップ ストレージの冗長性を更新するには、-BackupStorageRedundancy パラメーターを使用できます。To update backup storage redundancy of an existing database, you can use the -BackupStorageRedundancy parameter. 指定できる値は、Geo、Zone、Local です。Possible values are Geo, Zone and Local. 変更がデータベースに適用されるまでに、最大で 48 時間かかる場合があることに注意してください。Note that, it may take up to 48 hours for the changes to be applied on the database. geo 冗長バックアップ ストレージからローカルまたはゾーン冗長ストレージに切り替えると、geo リストアは無効になります。Switching from geo-redundant backup storage to local or zone redundant storage disables geo restore.

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Zone

詳細については、「Set-AzSqlDatabase」を参照してくださいFor details visit Set-AzSqlDatabase

注意

データベースの復元、データベースのコピー、またはセカンダリの作成の操作で -BackupStorageRedundancy パラメーターを使用するには、Azure PowerShell のバージョン Az.Sql 2.11.0 を使用します。To use -BackupStorageRedundancy parameter with database restore, database copy or create secondary operations, use Azure PowerShell version Az.Sql 2.11.0.

Azure Policy を使用してバックアップ ストレージの冗長性を適用するUse Azure Policy to enforce backup storage redundancy

すべてのデータを 1 つの Azure リージョンに保持する必要があるデータ所在地の要件がある場合は、Azure Policy を使用して、SQL Database または Managed Instance に対し、ゾーン冗長またはローカル冗長のバックアップを適用することができます。If you have data residency requirements that require you to keep all your data in a single Azure region, you may want to enforce zone-redundant or locally-redundant backups for your SQL Database or Managed Instance using Azure Policy. Azure Policy は、Azure リソースにルールを適用するポリシーの作成、割り当て、管理に使用できるサービスです。Azure Policy is a service that you can use to create, assign, and manage policies that apply rules to Azure resources. Azure Policy を使用すると、これらのリソースが会社の標準やサービス レベル アグリーメントに準拠した状態を維持するのに役立ちます。Azure Policy helps you to keep these resources compliant with your corporate standards and service level agreements. 詳細については、Azure Policy の概要に関するページを参照してください。For more information, see Overview of Azure Policy.

バックアップ ストレージの冗長性の組み込みポリシーBuilt-in backup storage redundancy policies

次の新しい組み込みポリシーが追加されました。これをサブスクリプションまたはリソース グループのレベルで割り当てて、geo 冗長バックアップ ストレージを使用した新しいデータベースまたはインスタンスの作成をブロックすることができます。Following new built-in policies are added, which can be assigned at the subscription or resource group level to block creation of new database(s) or instance(s) with geo-redundant backup storage.

SQL データベースでは GRS バックアップ冗長の使用を避けるSQL Database should avoid using GRS backup redundancy

SQL マネージド インスタンスでは GRS バックアップ冗長の使用を避けるSQL Managed Instances should avoid using GRS backup redundancy

SQL Database と Managed Instance に対する組み込みポリシーの定義の完全な一覧については、こちらを参照してください。A full list of built-in policy definitions for SQL Database and Managed Instance can be found here.

データ所在地要件を組織レベルで適用するには、これらのポリシーをサブスクリプションに割り当てることができます。To enforce data residency requirements at an organizational level, these policies can be assigned to a subscription. これらをサブスクリプション レベルで割り当てると、指定したサブスクリプションのユーザーは、Azure portal または Azure PowerShell を使用して、geo 冗長バックアップ ストレージでデータベースまたはマネージド インスタンスを作成できなくなります。After these are assigned at a subscription level, users in the given subscription will not be able to create a database or a managed instance with geo-redundant backup storage via Azure portal or Azure PowerShell.

重要

T-SQL を使用してデータベースを作成する場合は、Azure ポリシーは適用されません。Azure policies are not enforced when creating a database via T-SQL. T-SQL を使用してデータベースを作成するときにデータ所在地を適用するには、CREATE DATABASE ステートメントの BACKUP_STORAGE_REDUNDANCY パラメーターに対する入力として "LOCAL" または "ZONE" を使用しますTo enforce data residency when creating a database using T-SQL, use 'LOCAL' or 'ZONE' as input to BACKUP_STORAGE_REDUNDANCY paramater in CREATE DATABASE statement.

Azure portal または Azure PowerShell を使用してポリシーを割り当てる方法を参照してくださいLearn how to assign policies using the Azure portal or Azure PowerShell

次のステップNext steps