Otomatik yedeklemeler-SQL yönetilen örnek & Azure SQL veritabanıAutomated backups - Azure SQL Database & SQL Managed Instance

Uygulama hedefi: Azure SQL veritabanı Azure SQL yönetilen örneği

Not

Bu makale, cihaz veya hizmetten kişisel verileri silme hakkında adımlar sağlar ve GDPR kapsamındaki yükümlülüklerinizi desteklemek için kullanılabilir.This article provides steps about how to delete personal data from the device or service and can be used to support your obligations under the GDPR. GDPR hakkında genel bilgi için, Microsoft Güven Merkezi 'Nin GDPR bölümüne ve hizmet güven portalının GDPR bölümünebakın.For general information about GDPR, see the GDPR section of the Microsoft Trust Center and the GDPR section of the Service Trust portal.

Veritabanı yedeklemesi nedir?What is a database backup?

Veritabanı yedeklemeleri, iş sürekliliği ve olağanüstü durum kurtarma stratejilerinin önemli bir parçasıdır çünkü verilerinizi bozulma veya silme işleminden korur.Database backups are an essential part of any business continuity and disaster recovery strategy, because they protect your data from corruption or deletion. Bu yedeklemeler, yapılandırılan saklama süresi içinde bir zaman noktasına veritabanı geri yüklemeyi etkinleştirir.These backups enable database restore to a point in time within the configured retention period. Veri koruma kurallarınız, yedeklemelerinizin uzun süre (10 yıla kadar) kullanılabilmesini gerektiriyorsa, hem tek hem de havuza alınmış veritabanları için uzun süreli saklama yapılandırabilirsiniz.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.

Yedekleme sıklığıBackup frequency

Hem SQL veritabanı hem de SQL yönetilen örneği, her hafta tam yedeklemeler oluşturmak için SQL Server teknolojisini kullanır, fark yedeklemeleri her 12-24 saatte bir ve işlem günlüğü yedeklemeleri 5 ila 10 dakika sürer.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. İşlem günlüğü yedeklemelerinin sıklığı, işlem boyutuna ve veritabanı etkinliğinin miktarına göre belirlenir.The frequency of transaction log backups is based on the compute size and the amount of database activity.

Bir veritabanını geri yüklediğinizde, hizmet hangi tam, fark ve işlem günlüğü yedeklemelerinin geri yüklenmesi gerektiğini belirler.When you restore a database, the service determines which full, differential, and transaction log backups need to be restored.

Yedekleme depolama yedekliliğiBackup storage redundancy

Varsayılan olarak, SQL veritabanı ve SQL yönetilen örneği, eşleştirilmiş bir bölgeyeçoğaltılan coğrafi olarak yedekli depolama Bloblarında verileri depolar.By default, SQL Database and SQL Managed Instance store data in geo-redundant storage blobs that are replicated to a paired region. Bu, birincil bölgedeki yedekleme depolama alanını etkileyen kesintilere karşı korunmaya yardımcı olur ve bir olağanüstü durum durumunda sunucunuzu farklı bir bölgeye geri yüklemenize olanak tanır.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.

Yedekleme depolama yedekliliği yapılandırma seçeneği, bir SQL yönetilen örneği veya bir SQL veritabanı için yerel olarak yedekli, bölgesel olarak yedekli veya coğrafi olarak yedekli depolama Blobları arasında seçim yapmak için esneklik sağlar.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. Verilerinizin yönetilen örneğinizin veya SQL veritabanınızın dağıtıldığı bölge içinde kalmasını sağlamak için, varsayılan coğrafi olarak yedekli yedekleme depolama yedekliliği değiştirebilir ve yedeklemeler için yerel olarak yedekli ya da bölgesel olarak yedekli depolama bloblarını yapılandırabilirsiniz.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 or zone-redundant storage blobs for backups. Depolama artıklığı mekanizmaları, geçici donanım arızası, ağ veya güç kesintileri ya da büyük doğal felaketler dahil, planlı ve plansız olaylardan korunmak üzere verilerinizin birden çok kopyasını depolar.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. Yapılandırılan yedekleme depolama yedekliliği, uzun vadeli yedeklemeler (LTR) için kullanılan zaman içinde nokta geri yükleme (ıNR) ve uzun süreli bekletme yedeklemeleri için kullanılan kısa süreli yedekleme bekletme ayarlarına uygulanır.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 veritabanı için yedekleme depolama yedekliliği, veritabanı oluşturma sırasında yapılandırılabilir veya var olan bir veritabanı için güncelleştirilemeyebilir; var olan bir veritabanında yapılan değişiklikler yalnızca gelecekteki yedeklemeler için geçerlidir.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. Mevcut bir veritabanının yedek depolama yedekliliği güncelleştirildikten sonra, değişikliklerin uygulanması 48 saate kadar sürebilir.After the backup storage redundancy of an existing database is updated, it may take up to 48 hours for the changes to be applied. Coğrafi geri yükleme, bir veritabanı yerel veya bölgesel olarak yedekli depolama kullanmak üzere güncelleştirildikten hemen devre dışı bırakıldığını unutmayın.Note that, geo restore is disabled as soon as a database is updated to use local or zone redundant storage.

Önemli

Yönetilen örnek oluşturma işlemi sırasında yedekleme depolama yedekliliği yapılandırma kaynak sağlandığında, artık depolama yedekliği değiştirilemez.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.

Önemli

Bölgesel olarak yedekli depolama Şu anda yalnızca belirli bölgelerdekullanılabilir.Zone-redundant storage is currently only available in certain regions.

Not

Azure SQL veritabanı için yapılandırılabilir yedekleme depolama yedekliği Şu anda Brezilya Güney ' de genel önizlemeye sunuldu ve genel olarak Güneydoğu Asya Azure bölgesinde kullanıma sunuldu.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. Bu özellik henüz hiper ölçek katmanı için kullanılabilir değil.This feature is not yet available for Hyperscale tier.

Yedekleme kullanımıBackup usage

Bu yedeklemeleri kullanarak şunları yapabilirsiniz:You can use these backups to:

  • Mevcut veritabanının - zaman içindeki bir noktaya geri yüklemesi Mevcut bir veritabanını, Azure portal, Azure PowerShell, Azure CLı veya REST API kullanarak saklama süresi içinde geçmiş bir noktaya geri yükleyin .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. Bu işlem, SQL veritabanı için özgün veritabanıyla aynı sunucuda yeni bir veritabanı oluşturur, ancak özgün veritabanının üzerine yazılmasını önlemek için farklı bir ad kullanır.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. Geri yükleme tamamlandıktan sonra özgün veritabanını silebilirsiniz.After restore completes, you can delete the original database. Alternatif olarak, özgün veritabanını yeniden adlandırabilir ve sonra geri yüklenen veritabanını özgün veritabanı adıyla yeniden adlandırabilirsiniz.Alternatively, you can rename both the original database, and then rename the restored database to the original database name. Benzer şekilde, SQL yönetilen örneği için bu işlem, aynı abonelikte ve aynı bölgede bulunan aynı veya farklı yönetilen örnekteki veritabanının bir kopyasını oluşturur.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.
  • Silinen veritabanının - zaman içindeki bir noktaya geri yüklemesi Silinen bir veritabanını silme zamanına veya Bekletme dönemi içinde herhangi bir zaman noktasına geri yükleyin.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. Silinen veritabanı yalnızca özgün veritabanının oluşturulduğu sunucuya veya yönetilen örneğe geri yüklenebilir.The deleted database can be restored only on the same server or managed instance where the original database was created. Bir veritabanı silinirken, veri kaybını engellemek için, silme işleminden önce hizmet son işlem günlüğü yedeklemesini alır.When deleting a database, the service takes a final transaction log backup before deletion, to prevent any data loss.
  • Coğrafi geri yükleme - Veritabanını başka bir coğrafi bölgeye geri yükleyin.Geo-restore - Restore a database to another geographic region. Coğrafi geri yükleme, birincil bölgedeki veritabanınıza veya yedeklemelerinize erişene zaman coğrafi bir olağanüstü durumdan kurtulmanızı sağlar.Geo-restore allows you to recover from a geographic disaster when you cannot access your database or backups in the primary region. Herhangi bir Azure bölgesindeki var olan herhangi bir sunucuda veya yönetilen örnekte yeni bir veritabanı oluşturur.It creates a new database on any existing server or managed instance, in any Azure region.

    Önemli

    Coğrafi geri yükleme yalnızca SQL veritabanları veya coğrafi olarak yedekli yedekleme depolama ile yapılandırılmış yönetilen örnekler için kullanılabilir.Geo-restore is available only for SQL databases or managed instances configured with geo-redundant backup storage.

  • Uzun vadeli yedeklemeden - geri yükleme Veritabanı uzun süreli bir bekletme ilkesiyle yapılandırılmışsa (LTR), tek bir veritabanı veya havuza alınmış bir veritabanının belirli bir uzun süreli yedeklemesinden veritabanını geri yükleyin .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, bir uyumluluk isteğini karşılamak veya uygulamanın eski bir sürümünü çalıştırmak için Azure Portal veya Azure PowerShell kullanarak veritabanının eski bir sürümünü geri yüklemenize olanak tanır.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. Daha fazla bilgi için bkz. Uzun süreli saklama.For more information, see Long-term retention.

Geri yükleme gerçekleştirmek için bkz. veritabanlarını yedeklerden geri yükleme.To perform a restore, see Restore database from backups.

Not

Azure depolama 'da, çoğaltma terimi bir konumdan diğerine blob kopyalamak anlamına gelir.In Azure Storage, the term replication refers to copying blobs from one location to another. Veritabanı çoğaltması , SQL 'de birden çok ikincil veritabanını birincil veritabanıyla eşitlenmiş halde tutmak için kullanılan çeşitli teknolojiler anlamına gelir.In SQL, database replication refers to various technologies used to keep multiple secondary databases synchronized with a primary database.

Aşağıdaki örnekleri kullanarak yedekleme yapılandırma ve geri yükleme işlemlerini deneyebilirsiniz:You can try backup configuration and restore operations using the following examples:

İşlemOperation Azure portalıAzure portal Azure PowerShellAzure PowerShell
Yedekleme bekletmesini değiştirmeChange backup retention SQL VeritabanıSQL Database
SQL Yönetilen ÖrnekSQL Managed Instance
SQL VeritabanıSQL Database
SQL Yönetilen ÖrnekSQL Managed Instance
Uzun süreli yedekleme bekletmesini değiştirmeChange long-term backup retention SQL VeritabanıSQL Database
SQL yönetilen örneği-yokSQL Managed Instance - N/A
SQL VeritabanıSQL Database
SQL Yönetilen ÖrnekSQL Managed Instance
Bir veritabanından bir zaman noktasından geri yüklemeRestore a database from a point in time SQL VeritabanıSQL Database
SQL Yönetilen ÖrnekSQL Managed Instance
SQL VeritabanıSQL Database
SQL Yönetilen ÖrnekSQL Managed Instance
Silinen veritabanını geri yüklemeRestore a deleted database SQL VeritabanıSQL Database
SQL Yönetilen ÖrnekSQL Managed Instance
SQL VeritabanıSQL Database
SQL Yönetilen ÖrnekSQL Managed Instance
Azure Blob depolamadan bir veritabanını geri yüklemeRestore a database from Azure Blob storage SQL veritabanı-yokSQL Database - N/A
SQL yönetilen örneği-yokSQL Managed Instance - N/A
SQL veritabanı-yokSQL Database - N/A
SQL Yönetilen ÖrnekSQL Managed Instance

Yedekleme zamanlamasıBackup scheduling

İlk tam yedekleme yeni bir veritabanı oluşturulduktan veya geri yüklendikten hemen sonra zamanlanır.The first full backup is scheduled immediately after a new database is created or restored. Bu yedekleme genellikle 30 dakika içinde tamamlanır, ancak veritabanı büyükse daha uzun sürebilir.This backup usually completes within 30 minutes, but it can take longer when the database is large. Örneğin, ilk yedekleme geri yüklenen bir veritabanında veya bir veritabanı kopyasında daha uzun sürebilir, bu da genellikle yeni bir veritabanından daha büyük olur.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. İlk tam yedeklemeden sonra, diğer tüm yedeklemeler otomatik olarak zamanlanır ve yönetilir.After the first full backup, all further backups are scheduled and managed automatically. Tüm veritabanı yedeklerinin tam zamanlaması, genel sistem iş yükünü dengeleyerek SQL veritabanı veya SQL yönetilen örnek hizmeti tarafından belirlenir.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. Yedekleme işlerinin zamanlamasını değiştiremez veya devre dışı bırakabilirsiniz.You cannot change the schedule of backup jobs or disable them.

Önemli

Yeni, geri yüklenen veya kopyalanmış bir veritabanı için, ilk tam yedeklemeyi izleyen ilk işlem günlüğü yedeklemesi oluşturulduğu zamandan itibaren bir noktadan sonraki geri yükleme özelliği kullanılabilir hale gelir.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.

Yedekleme depolama alanı tüketimiBackup storage consumption

SQL Server Yedekleme ve geri yükleme teknolojisine sahip bir veritabanını bir zaman noktasına geri yüklemek, bir tam yedeklemeden, isteğe bağlı olarak bir değişiklik yedeklemesinden ve bir veya daha fazla işlem günlüğü yedeğinden oluşan kesintisiz bir yedekleme zinciri gerektirir.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 veritabanı ve SQL yönetilen örnek yedekleme zamanlaması, her hafta bir tam yedekleme içerir.SQL Database and SQL Managed Instance backup schedule includes one full backup every week. Bu nedenle, tüm Bekletme dönemi içinde ara 'yı etkinleştirmek için sistem, yapılandırılan saklama süresinden daha uzun bir haftaya kadar ek tam, fark ve işlem günlüğü yedeklemeleri depolaması gerekir.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.

Diğer bir deyişle, bekletme süresi boyunca herhangi bir zaman için, bekletme döneminin en eski zamanından daha eski olan bir tam yedekleme ve bir sonraki tam yedeklemeye kadar bu tam yedeklemeden kesintisiz bir fark ve işlem günlüğü yedeklemeleri zinciri olmalıdır.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.

Not

Ara ' yı etkinleştirmek için, ek yedeklemeler yapılandırılmış saklama süresinden daha uzun bir haftaya kadar saklanır.To enable PITR, additional backups are stored for up to a week longer than the configured retention period. Yedekleme depolaması tüm yedeklemeler için aynı hızda ücretlendirilir.Backup storage is charged at the same rate for all backups.

Artık gerekli olmayan yedeklemeler otomatik olarak silinir.Backups that are no longer needed to provide PITR functionality are automatically deleted. Fark yedeklemeleri ve günlük yedeklemeleri, daha önce bir tam yedeklemenin geri yüklenebilir olmasını gerektirdiğinden, üç yedekleme türünün tümü haftalık kümeler halinde temizlenir.Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets.

Şifrelenen veritabanları da dahil olmak üzere tüm veritabanları için yedeklemeler, yedekleme depolama sıkıştırması ve maliyetlerini azaltmak için sıkıştırılır.For all databases including TDE encrypted databases, backups are compressed to reduce backup storage compression and costs. Ortalama yedekleme sıkıştırma oranı 3-4 zamandır, ancak verilerin doğasına ve veri sıkıştırmasının veritabanında kullanılıp kullanılmasından bağımsız olarak önemli ölçüde daha yüksek olabilir.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 veritabanı ve SQL yönetilen örneği toplam kullanılan yedekleme depolama alanınızı birikimli bir değer olarak hesaplama.SQL Database and SQL Managed Instance compute your total used backup storage as a cumulative value. Her saat, bu değer Azure Faturalandırma işlem hattında raporlanır ve bu saatlik kullanımı, her ayın sonunda tüketiminizi hesaplamak için sağlamaktan sorumludur.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. Veritabanı silindikten sonra, yedeklemeler yaşaşımına uğrar ve silindikçe, tüketim azalır.After the database is deleted, consumption decreases as backups age out and are deleted. Tüm yedeklemeler silindikten sonra ve artık mümkün değilse faturalandırma duraklar.Once all backups are deleted and PITR is no longer possible, billing stops.

Önemli

Veritabanı silinse bile, bir veritabanının yedeklemeleri, gızlı bir veritabanı sağlamak için tutulur.Backups of a database are retained to enable PITR even if the database has been deleted. Bir veritabanını silmek ve yeniden oluşturmak, depolama ve işlem maliyetlerini kaydedebileceğinden, hizmet her silindiğinde silinen her veritabanı için yedekleri koruduğundan, yedekleme depolama maliyetlerini artırabilir.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.

Tüketimi izlemeMonitor consumption

VCore veritabanları için her bir yedekleme türü (tam, değişiklik ve günlük) tarafından tüketilen depolama alanı, veritabanı izleme dikey penceresinde ayrı bir ölçüm olarak raporlanır.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. Aşağıdaki diyagramda tek bir veritabanı için yedekleme depolama tüketiminin nasıl izleneceği gösterilmektedir.The following diagram shows how to monitor the backup storage consumption for a single database. Bu özellik şu anda yönetilen örnekler için kullanılamaz.This feature is currently not available for managed instances.

Azure portal veritabanı yedeklemesi kullanımını izleme

Yedekleme depolama tüketimine ince ayar yapmaFine-tune backup storage consumption

Bir veritabanı için maksimum veri boyutuna kadar yedekleme depolama tüketimi ücretlendirilmez.Backup storage consumption up to the maximum data size for a database is not charged. Fazla yedekleme depolama alanı tüketimi, bireysel veritabanlarının iş yüküne ve en büyük boyutuna bağlıdır.Excess backup storage consumption will depend on the workload and maximum size of the individual databases. Yedekleme depolama tüketiminizi azaltmak için aşağıdaki ayarlama tekniklerinden bazılarını göz önünde bulundurun:Consider some of the following tuning techniques to reduce your backup storage consumption:

  • Yedekleme saklama süresini gereksinimleriniz için mümkün olan en düşük süreye düşürün.Reduce the backup retention period to the minimum possible for your needs.
  • Dizin yeniden oluşturmanız gibi büyük yazma işlemlerini yapmaktan kaçının, ancak gerekenden daha sık.Avoid doing large write operations, like index rebuilds, more frequently than you need to.
  • Büyük veri yükleme işlemleri için, kümelenmiş columnstore dizinlerini ve ilgili en iyi uygulamalarıkullanmayı ve/veya kümelenmemiş dizinlerin sayısını azaltmayı düşünün.For large data load operations, consider using clustered columnstore indexes and following related best practices, and/or reduce the number of non-clustered indexes.
  • Genel Amaçlı hizmet katmanında, sağlanan veri depolama alanı, yedekleme depolama fiyatından daha ucuz.In the General Purpose service tier, the provisioned data storage is less expensive than the price of the backup storage. Sürekli yedekleme depolama maliyetleriniz varsa, yedekleme depolama alanı üzerinde kaydedilecek veri depolama alanını artırmayı düşünebilirsiniz.If you have continually high excess backup storage costs, you might consider increasing data storage to save on the backup storage.
  • Geçici sonuçları ve/veya geçici verileri depolamak için uygulama mantığınızdaki kalıcı tablolar yerine TempDB kullanın.Use TempDB instead of permanent tables in your application logic for storing temporary results and/or transient data.
  • Mümkün olduğunda yerel olarak yedekli yedekleme depolaması kullanın (örneğin geliştirme ve test ortamları)Use locally-redundant backup storage whenever possible (for example dev/test environments)

Yedekleme dosyası saklamaBackup retention

Tüm yeni, geri yüklenen ve kopyalanmış veritabanları için, Azure SQL veritabanı ve Azure SQL yönetilen örneği, en son 7 gün içinde varsayılan olarak veri için yeterli yedeklemeler sağlar.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. Hiper ölçek ve temel katman veritabanları hariç olmak üzere, 1-35 gün aralığında her etkin veritabanı için yedekleme saklama süresini değiştirebilirsiniz .With the exception of Hyperscale and Basic tier databases, you can change backup retention period per each active database in the 1-35 day range. Yedekleme depolama tüketimibölümünde açıklandığı gibi, ınvr 'yi etkinleştirmek için depolanan yedeklemeler saklama süresinden daha eski olabilir.As described in Backup storage consumption, backups stored to enable PITR may be older than the retention period. Yalnızca Azure SQL yönetilen örneği için, 0-35 gün aralığında bir veritabanı silindikten sonra, yedek saklama oranını ayarlamak mümkündür.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.

Bir veritabanını silerseniz, sistem yedeklemeleri, belirli bir saklama süresi ile çevrimiçi bir veritabanı için olduğu gibi korur.If you delete a database, the system keeps backups in the same way it would for an online database with its specific retention period. Silinen bir veritabanı için yedekleme saklama süresini değiştiremezsiniz.You cannot change backup retention period for a deleted database.

Önemli

Bir sunucuyu veya yönetilen örneği silerseniz, bu sunucu veya yönetilen örnekteki tüm veritabanları da silinir ve kurtarılamaz.If you delete a server or a managed instance, all databases on that server or managed instance are also deleted and cannot be recovered. Silinen bir sunucuyu veya yönetilen örneği geri yükleyemezsiniz.You cannot restore a deleted server or managed instance. Ancak, bir veritabanı veya yönetilen örnek için uzun süreli saklama (LTR) yapılandırdıysanız, uzun süreli saklama yedeklemeleri silinmez ve aynı abonelikte bulunan farklı bir sunucudaki veya yönetilen örnekteki veritabanlarını, uzun süreli bir saklama yedeğinin alındığı zaman noktasına geri yüklemek için kullanılabilir.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.

Son 1-35 gün içinde yedek bekletme amaçları için bazen kısa süreli yedekleme saklama adı verilir.Backup retention for purposes of PITR within the last 1-35 days is sometimes called short-term backup retention. Yedeklemeleri 35 günlük maksimum kısa süreli saklama süresinden daha uzun tutmanız gerekiyorsa, uzun süreli saklamasağlayabilirsiniz.If you need to keep backups for longer than the maximum short-term retention period of 35 days, you can enable Long-term retention.

Uzun vadeli bekletmeLong-term retention

Hem SQL veritabanı hem de SQL yönetilen örneği için, Azure Blob depolamada en fazla 10 yıla kadar tam yedekleme uzun süreli saklama (LTR) yapılandırabilirsiniz.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 ilkesi yapılandırıldıktan sonra, tam yedeklemeler haftalık olarak farklı bir depolama kapsayıcısına kopyalanır.After the LTR policy is configured, full backups are automatically copied to a different storage container weekly. Çeşitli uyumluluk gereksinimlerini karşılamak için haftalık, aylık ve/veya yıllık tam yedeklemeler için farklı saklama süreleri seçebilirsiniz.To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. Depolama alanı tüketimi, LTR yedeklemelerin seçili sıklık ve bekletme dönemlerine bağlıdır.Storage consumption depends on the selected frequency and retention periods of LTR backups. LTR depolama maliyetini tahmin etmek için LTR Fiyatlandırma Hesaplayıcı ' yı kullanabilirsiniz.You can use the LTR pricing calculator to estimate the cost of LTR storage.

Önemli

Mevcut bir Azure SQL veritabanı için yedek depolama yedekliliği güncelleştirme, yalnızca veritabanı için yapılan yedeklemeler için geçerlidir.Updating the backup storage redundancy for an existing Azure SQL Database, only applies to the future backups taken for the database. Veritabanı için varolan tüm LTR yedeklemeleri, mevcut Depolama Blobu 'nda bulunmaya devam eder ve yeni yedeklemeler istenen Depolama Blobu türünde saklanacak.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 hakkında daha fazla bilgi için bkz. uzun süreli yedek saklama.For more information about LTR, see Long-term backup retention.

Yedekleme depolama maliyetleriBackup storage costs

Yedekleme depolaması için fiyat değişir ve satın alma modelinize (DTU veya vCore), seçili yedekleme depolama artıklığı seçeneğine ve ayrıca bölgenizde bağlıdır.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. Yedekleme depolaması tüketilen GB/ay başına ücretlendirilir, fiyatlandırma için bkz. Azure SQL Veritabanı fiyatlandırma sayfası ve Azure SQL yönetilen örnek fiyatlandırma sayfası.The backup storage is charged per GB/month consumed, for pricing see Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

Not

Azure faturasında, tüm yedekleme depolama tüketiminin değil, yalnızca tüketilen aşırı yedekleme depolaması gösterilir.Azure invoice will show only the excess backup storage consumed, not the entire backup storage consumption. Örneğin, bir kuramsal senaryoda 4TB veri depolama alanı sağladıysanız, 4TB boş yedekleme depolama alanı alacaksınız.For example, in a hypothetical scenario, if you have provisioned 4TB of data storage, you will get 4TB of free backup storage space. Toplam 5.8 TB yedekleme depolama alanını kullandıysanız Azure faturasında yalnızca fazla yedekleme depolaması ücretlendirilildiği için, Azure faturasında yalnızca 1.8 TB görüntülenir.In case that you have used the total of 5.8TB of backup storage space, Azure invoice will show only 1.8TB, as only excess backup storage used is charged.

DTU modeliDTU model

DTU modelinde, veritabanları ve elastik havuzlar için yedekleme depolaması için ek ücret alınmaz.In the DTU model, there's no additional charge for backup storage for databases and elastic pools. Yedekleme depolama alanı fiyatı, veritabanının veya havuz fiyatının bir parçasıdır.The price of backup storage is a part of database or pool price.

Sanal çekirdek modelivCore model

SQL veritabanı 'ndaki tek veritabanları için, veritabanı için en fazla veri depolama boyutunun yüzde 100 ' una eşit bir yedekleme depolama miktarı, ek ücret ödemeden sağlanır.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. Esnek havuzlar ve yönetilen örnekler için, havuz için maksimum veri depolama alanının yüzde 100 ' una eşit bir yedekleme depolama miktarı veya sırasıyla en büyük örnek depolama boyutu, ek ücret ödemeden sunulmaktadır.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.

Tek veritabanları için bu denklem, faturalandırılabilir toplam yedekleme depolama kullanımını hesaplamak için kullanılır: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

Havuza alınmış veritabanları için, faturalandırılabilir toplam yedekleme depolama boyutu havuz düzeyinde toplanır ve şu şekilde hesaplanır: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

Yönetilen örnekler için, faturalandırılabilir toplam yedekleme depolama boyutu örnek düzeyinde toplanır ve aşağıdaki şekilde hesaplanır: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

Toplam faturalanabilir yedekleme depolaması, varsa, kullanılan yedekleme depolama yedekliliğe göre GB/ay olarak ücretlendirilir.Total billable backup storage, if any, will be charged in GB/month as per the rate of the backup storage redundancy used. Bu yedekleme depolama alanı tüketimi, bireysel veritabanlarının, elastik havuzların ve yönetilen örneklerin iş yüküne ve boyutuna bağlı olarak değişir.This backup storage consumption will depend on the workload and size of individual databases, elastic pools, and managed instances. Yoğun olarak değiştirilmiş veritabanlarının boyutu daha büyük farklar ve günlük yedeklemeleri olduğundan, bu yedeklemelerin boyutu veri değişikliği miktarıyla orantılıdır.Heavily modified databases have larger differential and log backups, because the size of these backups is proportional to the amount of data changes. Bu nedenle, bu tür veritabanları daha yüksek yedekleme ücretlerine sahip olur.Therefore, such databases will have higher backup charges.

SQL veritabanı ve SQL yönetilen örneği toplam faturalandırılabilir yedekleme depolama alanınızı tüm yedekleme dosyalarında birikimli bir değer olarak hesaplar.SQL Database and SQL Managed Instance computes your total billable backup storage as a cumulative value across all backup files. Bu değer, her saat sonunda yedekleme depolama tüketiminizi almak için bu saatlik kullanımı toplayan Azure Faturalandırma işlem hattına bildirilir.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. Bir veritabanı silinirse, eski yedeklemeler yaşaşımına uğrar ve silindikçe yedekleme depolama alanı tüketimi yavaş yavaş azalır.If a database is deleted, backup storage consumption will gradually decrease as older backups age out and are deleted. Fark yedeklemeleri ve günlük yedeklemeleri, daha önce bir tam yedeklemenin geri yüklenebilir olmasını gerektirdiğinden, üç yedekleme türünün tümü haftalık kümeler halinde temizlenir.Because differential backups and log backups require an earlier full backup to be restorable, all three backup types are purged together in weekly sets. Tüm yedeklemeler silindikten sonra faturalandırma duraklar.Once all backups are deleted, billing stops.

Basitleştirilmiş bir örnek olarak, veritabanı tamamen boşta olduğu için bir veritabanının 744 GB 'lık yedekleme depolama alanı olduğunu ve bu miktarın tüm bir ay boyunca sabit kalacağını varsayalım.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. Bu toplu depolama tüketimini saatlik kullanıma dönüştürmek için, 744,0 (ayda 31 gün * günde 24 saat) ayırın.To convert this cumulative storage consumption to hourly usage, divide it by 744.0 (31 days per month * 24 hours per day). SQL veritabanı, veritabanının her saat 1 GB 'lık yedekleme ve sabit bir hızda tükettiği Azure Faturalandırma işlem hattına rapor eder.SQL Database will report to Azure billing pipeline that the database consumed 1 GB of PITR backup each hour, at a constant rate. Azure Faturalandırma, bu tüketimi toplar ve tüm ay için 744 GB kullanımını gösterir.Azure billing will aggregate this consumption and show a usage of 744 GB for the entire month. Maliyet, bölgenizdeki tutara/GB/ay oranına göre yapılır.The cost will be based on the amount/GB/month rate in your region.

Şimdi daha karmaşık bir örnek.Now, a more complex example. Aynı boştaki veritabanının bekletmenin, Ayın ortasında 7 günden 14 güne kadar arttığını varsayalım.Suppose the same idle database has its retention increased from 7 days to 14 days in the middle of the month. Bu artış, toplam yedekleme depolama alanının 1.488 GB 'a katmasına neden olur.This increase results in the total backup storage doubling to 1,488 GB. SQL veritabanı 1 ila 372 (ayın ilk yarısında) boyunca 1 GB kullanım rapor verebilir.SQL Database would report 1 GB of usage for hours 1 through 372 (the first half of the month). Kullanım süresi 373 ile 744 arasında (ayın ikinci yarısında), kullanımı 2 GB olarak raporlayabilir.It would report the usage as 2 GB for hours 373 through 744 (the second half of the month). Bu kullanım, son 1.116 GB/ay faturalandırılmakta toplanacak.This usage would be aggregated to a final bill of 1,116 GB/month.

Gerçek yedekleme faturalandırma senaryoları daha karmaşıktır.Actual backup billing scenarios are more complex. Veritabanındaki değişiklik hızı iş yüküne ve zaman içinde değişken olmasına bağlı olduğundan, her bir değişiklik ve günlük yedeklemesinin boyutu da farklılık gösterir ve saatlik yedekleme depolama tüketiminin buna uygun şekilde dalgalanmasına neden olur.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. Ayrıca, her fark yedeklemesi, son tam yedeklemeden bu yana veritabanında yapılan tüm değişiklikleri içerir, bu nedenle tüm fark yedeklemelerinin toplam boyutu bir hafta boyunca kademeli olarak artar ve daha eski bir tam, değişiklik ve günlük yedekleri kümesi bir kez daha belirginleşerek keskin hale getirilir. Örneğin, tam bir yedekleme tamamlandıktan sonra, dizin yeniden oluşturma gibi ağır bir yazma etkinliği çalıştırıldıysa, dizin yeniden oluşturma işlemi tarafından yapılan değişiklikler yeniden oluşturma süresince alınan işlem günlüğü yedeklemelerine, sonraki değişiklik yedeklemesine ve sonraki tam yedekleme gerçekleşene kadar her değişiklik yedeklemesine dahil edilir.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. Daha büyük veritabanlarındaki İkinci senaryo için, değişiklik yedeklemesi çok büyük değilse, hizmette en iyi duruma getirme değişiklik yedeklemesi yerine tam yedekleme oluşturur.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. Bu, aşağıdaki tam yedekleme yapılıncaya kadar tüm değişiklik yedeklemelerinin boyutunu azaltır.This reduces the size of all differential backups until the following full backup.

Her yedekleme türü (tam, fark, işlem günlüğü) için toplam yedekleme depolama tüketimini, tüketimi izlemebölümünde açıklandığı gibi zaman içinde izleyebilirsiniz.You can monitor total backup storage consumption for each backup type (full, differential, transaction log) over time as described in Monitor consumption.

Yedekleme depolama yedekliliğiBackup storage redundancy

Yedekleme depolama artıklığı, yedekleme maliyetlerini aşağıdaki şekilde etkiler:Backup storage redundancy impacts backup costs in the following way:

  • Yerel olarak yedekli fiyat = xlocally-redundant price = x
  • bölge-yedekli fiyat = 1,25 xzone-redundant price = 1.25x
  • coğrafi olarak yedekli fiyat = 2xgeo-redundant price = 2x

Yedekleme Depolama fiyatlandırması hakkında daha fazla bilgi için Azure SQL Veritabanı fiyatlandırma sayfasını ve Azure SQL yönetilen örnek fiyatlandırma sayfasınıziyaret edin.For more details about backup storage pricing visit Azure SQL Database pricing page and Azure SQL Managed Instance pricing page.

Önemli

SQL yönetilen örneği için yapılandırılabilir yedekleme depolama artıklığı tüm Azure bölgelerinde kullanılabilir ve şu anda Güneydoğu Asya Azure bölgesinde yalnızca SQL veritabanı için kullanılabilir.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. Yönetilen örnek için, yalnızca yönetilen örnek oluşturma işlemi sırasında belirtilebilir.For Managed Instance it can only be specified during the create managed instance process. Kaynak sağlandıktan sonra yedek depolama artıklığı seçeneğini değiştiremezsiniz.Once the resource is provisioned, you cannot change the backup storage redundancy option.

Maliyetleri izlemeMonitor costs

Yedekleme depolama maliyetlerini anlamak için Azure portal maliyet yönetimi + faturalandırma ' e gidin, maliyet yönetimi' ni seçin ve ardından Maliyet Analizi' ni seçin.To understand backup storage costs, go to Cost Management + Billing in the Azure portal, select Cost Management, and then select Cost analysis. Kapsam olarak istenen aboneliği seçin ve ilgilendiğiniz zaman aralığı ve hizmet için filtre uygulayın.Select the desired subscription as the Scope, and then filter for the time period and service that you're interested in.

Hizmet adı için bir filtre ekleyin ve ardından açılan listede SQL veritabanı ' nı seçin.Add a filter for Service name, and then select sql database in the drop-down list. Hizmetiniz için faturalandırma sayacını seçmek üzere ölçüm alt kategori filtresini kullanın.Use the meter subcategory filter to choose the billing counter for your service. Tek bir veritabanı veya elastik veritabanı havuzu için, tek/elastik havuz yedek depolama' yı seçin.For a single database or an elastic database pool, select single/elastic pool PITR backup storage. Yönetilen bir örnek için mı. yedekleme depolama alanı' nı seçin.For a managed instance, select mi PITR backup storage. Depolama ve işlem alt kategorileri sizi ilgilendirir, ancak yedekleme depolama maliyetleriyle ilişkili değildir.The Storage and compute subcategories might interest you as well, but they're not associated with backup storage costs.

Yedekleme depolama maliyeti Analizi

Not

Ölçümler yalnızca şu anda kullanımda olan sayaçlar için görülebilir.Meters are only visible for counters that are currently in use. Bir sayaç yoksa, kategori Şu anda kullanılmıyor olabilir.If a counter is not available, it is likely that the category is not currently being used. Örneğin, yönetilen bir örnek dağıtılan müşteriler için yönetilen örnek sayaçları mevcut olmayacaktır.For example, managed instance counters will not be present for customers who do not have a managed instance deployed. Benzer şekilde, depolama sayaçları, depolamayı tüketmeyen kaynaklar için görünür olmayacaktır.Likewise, storage counters will not be visible for resources that are not consuming storage.

Şifrelenmiş yedeklemelerEncrypted backups

Veritabanınız TDE ile şifrelenirse, yedeklemeler, LTR yedeklemeler de dahil olmak üzere Rest 'de otomatik olarak şifrelenir.If your database is encrypted with TDE, backups are automatically encrypted at rest, including LTR backups. Azure SQL 'deki tüm yeni veritabanları, TDE varsayılan olarak etkin ile yapılandırılır.All new databases in Azure SQL are configured with TDE enabled by default. TDE hakkında daha fazla bilgi için bkz. SQL veritabanı & SQL yönetilen örneği saydam veri şifrelemesi.For more information on TDE, see Transparent Data Encryption with SQL Database & SQL Managed Instance.

Yedekleme bütünlüğüBackup integrity

Azure SQL mühendislik ekibi, sürekli olarak otomatik veritabanı yedeklemelerinin geri yüklemesini otomatik olarak sınar.On an ongoing basis, the Azure SQL engineering team automatically tests the restore of automated database backups. (Bu test Şu anda SQL yönetilen örneği 'nde kullanılamaz.) Bir noktadan sonra geri yükleme sonrasında veritabanları DBCC CHECKDB bütünlük denetimleri de alır.(This testing is not currently available in SQL Managed Instance.) Upon point-in-time restore, databases also receive DBCC CHECKDB integrity checks.

Bütünlük denetimi sırasında bulunan tüm sorunlar, mühendislik ekibine bir uyarıya neden olur.Any issues found during the integrity check will result in an alert to the engineering team. Daha fazla bilgi için bkz. SQL veritabanı 'Nda veri bütünlüğü.For more information, see Data Integrity in SQL Database.

Tüm veritabanı yedeklemeleri, ek yedekleme bütünlüğü sağlamak için sağlama TOPLAMı seçeneğiyle alınır.All database backups are taken with the CHECKSUM option to provide additional backup integrity.

UyumlulukCompliance

Veritabanınızı DTU tabanlı bir hizmet katmanından sanal çekirdek tabanlı bir hizmet katmanına geçirdiğinizde, uygulamanızın veri kurtarma ilkesinin tehlikeye atılmasını sağlamak için, sür saklama korunur.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. Varsayılan saklama, uyumluluk gereksinimlerinizi karşılamıyorsa, elde tutma süresini değiştirebilirsiniz.If the default retention doesn't meet your compliance requirements, you can change the PITR retention period. Daha fazla bilgi için bkz. yedek saklama süresini değiştirme.For more information, see Change the PITR backup retention period.

Not

Bu makale, cihaz veya hizmetten kişisel verileri silme hakkında adımlar sağlar ve GDPR kapsamındaki yükümlülüklerinizi desteklemek için kullanılabilir.This article provides steps about how to delete personal data from the device or service and can be used to support your obligations under the GDPR. GDPR hakkında genel bilgi için, Microsoft Güven Merkezi 'Nin GDPR bölümüne ve hizmet güven portalının GDPR bölümünebakın.For general information about GDPR, see the GDPR section of the Microsoft Trust Center and the GDPR section of the Service Trust portal.

Yedek yedekleme saklama süresini değiştirmeChange the PITR backup retention period

Varsayılan yedek saklama süresini Azure portal, PowerShell veya REST API kullanarak değiştirebilirsiniz.You can change the default PITR backup retention period by using the Azure portal, PowerShell, or the REST API. Aşağıdaki örneklerde, fr bekletmenin 28 güne nasıl değiştirileceği gösterilmektedir.The following examples illustrate how to change the PITR retention to 28 days.

Uyarı

Geçerli saklama süresini azaldıysanız, yeni saklama süresinden daha eski olan noktalara geri yükleme imkanını kaybedersiniz.If you reduce the current retention period, you lose the ability to restore to points in time older than the new retention period. Yeni saklama dönemi içinde artık gerekli olmayan yedeklemeler silinir.Backups that are no longer needed to provide PITR within the new retention period are deleted. Geçerli saklama süresini artırdıysanız, yeni saklama döneminde zaman içinde eski noktalara geri yükleme imkanını hemen elde edersiniz.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. Sistem yedeklemeleri daha uzun süre tutmaya başladığı için zaman içinde bu becerisine sahip olursunuz.You gain that ability over time, as the system starts to retain backups for longer.

Not

Bu API 'Ler yalnızca sür saklama süresini etkiler.These APIs will affect only the PITR retention period. Veritabanınız için LTR yapılandırdıysanız, bu etkilenmez.If you configured LTR for your database, it won't be affected. LTR bekletme dönemlerini değiştirme hakkında daha fazla bilgi için bkz. uzun süreli saklama.For information about how to change LTR retention periods, see Long-term retention.

Azure portal kullanarak, yedek yedekleme saklama süresini değiştirinChange the PITR backup retention period by using the Azure portal

Azure portal kullanarak etkin veritabanlarının ara yedek saklama süresini değiştirmek için, saklama süresini değiştirmek istediğiniz veritabanlarında sunucuya veya yönetilen örneğe gidin.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. Sol bölmedeki yedeklemeler ' i seçin, sonra bekletme ilkeleri sekmesini seçin. İçin yedek saklama için değişiklik yapmak istediğiniz veritabanlarını seçin.Select Backups in the left pane, then select the Retention policies tab. Select the database(s) for which you want to change the PITR backup retention. Ardından Eylem çubuğundan bekletmeyi Yapılandır ' ı seçin.Then select Configure retention from the action bar.

PowerShell kullanarak yedek saklama süresini değiştirmeChange the PITR backup retention period by using PowerShell

Not

Bu makale Azure Az PowerShell modülünü kullanacak şekilde güncelleştirilmiştir.This article has been updated to use the Azure Az PowerShell module. Az PowerShell modülü, Azure ile etkileşim kurmak için önerilen PowerShell modülüdür.The Az PowerShell module is the recommended PowerShell module for interacting with Azure. Az PowerShell modülünü kullanmaya başlamak için Azure PowerShell’i yükleyin.To get started with the Az PowerShell module, see Install Azure PowerShell. Az PowerShell modülüne nasıl geçeceğinizi öğrenmek için bkz. Azure PowerShell’i AzureRM’den Az’ye geçirme.To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.

Önemli

PowerShell Azurerd modülü, SQL veritabanı ve SQL yönetilen örneği tarafından hala desteklenmektedir, ancak gelecekteki tüm geliştirmeler az. SQL modülüne yöneliktir.The PowerShell AzureRM module is still supported by SQL Database and SQL Managed Instance, but all future development is for the Az.Sql module. Daha fazla bilgi için bkz. Azurerd. SQL.For more information, see AzureRM.Sql. Az Module içindeki komutlar için bağımsız değişkenler Azurerd modüllerindekilerle oldukça benzerdir.The arguments for the commands in the Az module are substantially identical to those in the AzureRm modules.

Etkin Azure SQL veritabanları için yedek yedekleme bekletmesini değiştirmek için aşağıdaki PowerShell örneğini kullanın.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 kullanarak, yedek yedekleme saklama süresini değiştirinChange the PITR backup retention period by using the REST API

Örnek istekSample 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

İstek gövdesiRequest body

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

Örnek yanıtSample response

Durum kodu: 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
  }
}

Daha fazla bilgi için bkz. yedekleme bekletme REST API.For more information, see Backup Retention REST API.

Örnek istekSample 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

İstek gövdesiRequest body

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

Örnek yanıtSample response

Durum kodu: 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
  }
}

Daha fazla bilgi için bkz. yedekleme bekletme REST API.For more information, see Backup Retention REST API.

Yedek depolama yedekliliği yapılandırmaConfigure backup storage redundancy

Not

SQL yönetilen örneği için yapılandırılabilir depolama yedekliliği yalnızca yönetilen örnek oluşturma işlemi sırasında belirtilebilir.Configurable storage redundancy for backups for SQL Managed Instance can only be specified during the create managed instance process. Kaynak sağlandıktan sonra yedek depolama artıklığı seçeneğini değiştiremezsiniz.Once the resource is provisioned, you can't change the backup storage redundancy option. SQL veritabanı için, bu özelliğin genel önizlemesi Şu anda Brezilya Güney sürümünde sunulmaktadır ve Güney Doğu Asya Azure bölgesinde genel kullanıma sunulmuştur.For SQL Database, public preview of this feature is currently available in Brazil South and it is generally available in Southeast Asia Azure region.

Yönetilen bir örnek için yedek depolama yedekliği yalnızca örnek oluşturma sırasında ayarlanabilir.A backup storage redundancy of a managed instance can be set during instance creation only. Bir SQL veritabanı için veritabanı oluşturulurken ayarlanabilir veya var olan bir veritabanı için güncelleştirilemeyebilir.For a SQL Database it can be set when creating the database or can be updated for an existing database. Varsayılan değer, coğrafi olarak yedekli depolama.The default value is geo-redundant storage. Yerel olarak yedekli, bölgesel olarak yedekli ve coğrafi olarak yedekli yedekleme depolaması arasındaki fiyatlandırma farkları için yönetilen örnek fiyatlandırma sayfasınıziyaret edin.For differences in pricing between locally-redundant, zone-redundant and geo-redundant backup storage visit managed instance pricing page.

Azure portal kullanarak yedek depolama yedekliliği yapılandırmaConfigure backup storage redundancy by using the Azure portal

Azure portal, SQL veritabanı oluştur dikey penceresinde yedek depolama yedekliği yapılandırabilirsiniz.In Azure portal, you can configure the backup storage redundancy on the Create SQL Database blade. Bu seçenek, yedekleme depolama artıklığı bölümünde bulunur.The option is available under the Backup Storage Redundancy section. SQL veritabanı oluştur dikey penceresini açOpen Create SQL Database blade

PowerShell kullanarak yedek depolama yedekliliği yapılandırmaConfigure backup storage redundancy by using PowerShell

Yeni bir veritabanı oluştururken yedek depolama yedekliliği yapılandırmak için-BackupStoageRedundancy parametresini belirtebilirsiniz.To configure backup storage redundancy when creating a new database you can specify the -BackupStoageRedundancy parameter. Olası değerler coğrafi, bölge ve yerel ' dir.Possible values are Geo, Zone and Local. Varsayılan olarak, tüm SQL veritabanları yedeklemeler için coğrafi olarak yedekli depolama kullanır.By default, all SQL Databases use geo-redundant storage for backups. Yerel veya bölge yedekli yedekleme depolama alanı ile bir veritabanı oluşturulduysa coğrafi geri yükleme devre dışı bırakılır.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

Ayrıntılar için New-AzSqlDatabaseadresini ziyaret edin.For details visit New-AzSqlDatabase.

Var olan bir veritabanının yedek depolama yedekliliği güncelleştirmek için-BackupStorageRedundancy parametresini kullanabilirsiniz.To update backup storage redundancy of an existing database, you can use the -BackupStorageRedundancy parameter. Olası değerler coğrafi, bölge ve yerel ' dir.Possible values are Geo, Zone and Local. Bu işlem, değişikliklerin veritabanına uygulanması 48 saat kadar sürebilir.Note that, it may take up to 48 hours for the changes to be applied on the database. Coğrafi olarak yedekli yedekleme depolama alanından yerel veya bölge yedekli depolama alanına geçiş, coğrafi geri yüklemeyi devre dışı bırakır.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

Ayrıntılar için set-AzSqlDatabase adresini ziyaret edinFor details visit Set-AzSqlDatabase

Not

Veritabanı geri yükleme ile-BackupStorageRedundancy parametresini kullanmak için veritabanı kopyalama veya ikincil işlemleri oluşturma, Azure PowerShell sürümünü az. SQL 2.11.0 kullanın.To use -BackupStorageRedundancy parameter with database restore, database copy or create secondary operations, use Azure PowerShell version Az.Sql 2.11.0.

Yedekleme depolama yedekliliği zorlamak için Azure Ilkesini kullanmaUse Azure Policy to enforce backup storage redundancy

Tüm verilerinizi tek bir Azure bölgesinde tutmanızı gerektiren veri yerleriniz varsa, Azure Ilkesi 'ni kullanarak SQL veritabanınız veya yönetilen örneğiniz için bölgesel olarak yedekli veya yerel olarak yedekli yedeklemeler zorlamak isteyebilirsiniz.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 Ilkesi, Azure kaynaklarına kurallar uygulayan ilkeler oluşturmak, atamak ve yönetmek için kullanabileceğiniz bir hizmettir.Azure Policy is a service that you can use to create, assign, and manage policies that apply rules to Azure resources. Azure Ilkesi, bu kaynakları kurumsal standartlarınızla ve hizmet düzeyi Sözleşmelerinizle uyumlu tutmanıza yardımcı olur.Azure Policy helps you to keep these resources compliant with your corporate standards and service level agreements. Daha fazla bilgi için bkz. Azure Ilkesine genel bakış.For more information, see Overview of Azure Policy.

Yerleşik yedekleme depolama artıklığı ilkeleriBuilt-in backup storage redundancy policies

Yeni veritabanları veya örnek oluşturmayı engellemek için abonelik veya kaynak grubu düzeyinde atanabilir ve coğrafi olarak yedekli yedekleme depolama ile yeni veritabanı veya örnek oluşturulmasını engellemek için aşağıdaki yeni yerleşik ilkeler eklenmiştir.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 veritabanı GRS yedek yedekliliği kullanmaktan kaçınmalıdırSQL Database should avoid using GRS backup redundancy

SQL yönetilen örnekler, GRS yedek yedekliliği kullanmaktan kaçınmalıdırSQL Managed Instances should avoid using GRS backup redundancy

SQL veritabanı ve yönetilen örnek için yerleşik ilke tanımlarının tam listesini buradabulabilirsiniz.A full list of built-in policy definitions for SQL Database and Managed Instance can be found here.

Bir kuruluş düzeyinde veri yerleşimi gereksinimlerini zorlamak için bu ilkeler bir aboneliğe atanabilir.To enforce data residency requirements at an organizational level, these policies can be assigned to a subscription. Bunlar bir abonelik düzeyinde atandıktan sonra, belirtilen abonelikteki kullanıcılar Azure portal veya Azure PowerShell aracılığıyla coğrafi olarak yedekli yedekleme depolama alanı ile bir veritabanı veya yönetilen örnek oluşturamaz.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.

Önemli

T-SQL aracılığıyla bir veritabanı oluşturulurken Azure ilkeleri zorlanmaz.Azure policies are not enforced when creating a database via T-SQL. T-SQL kullanarak bir veritabanı oluştururken veri fazlalığını zorlamak için, Create Database ifadesinde BACKUP_STORAGE_REDUNDANCY parater olarak ' Local ' veya ' Zone ' kullanın.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 veya Azure PowerShell kullanarak ilke atamayı öğreninLearn how to assign policies using the Azure portal or Azure PowerShell

Sonraki adımlarNext steps