Automatiserade säkerhetskopieringar – Azure SQL Database & Azure SQL Managed Instance

GÄLLER FÖR: Azure SQL Database Azure SQL Managed Instance

Vad är en databassäkerhetskopia?

Säkerhetskopiering av databaser är en viktig del i strategin för affärskontinuitet och haveriberedskap, eftersom det skyddar dina data från skada eller borttagning. Med dessa säkerhetskopior kan databasen återställas till en tidpunkt inom den konfigurerade kvarhållningsperioden. Om dina dataskyddsregler kräver att dina säkerhetskopior är tillgängliga under en längre tid (upp till 10 år) kan du konfigurera långsiktig kvarhållning för både enkla databaser och pooldatabaser.

Säkerhetskopieringsfrekvens

Både SQL Database och SQL Managed Instance använder SQL Server-teknik för att skapa fullständiga säkerhetskopior varje vecka, differentiella säkerhetskopior var 12:e till 24:e timme och säkerhetskopieringar av transaktionsloggar var femte till var 10:e minut. Frekvensen för säkerhetskopieringar av transaktionsloggar baseras på beräkningsstorleken och mängden databasaktivitet.

När du återställer en databas avgör tjänsten vilka fullständiga säkerhetskopior, differentiella säkerhetskopior och säkerhetskopior av transaktionsloggar som behöver återställas.

Redundans för lagring av säkerhetskopior

Som standard SQL Database och SQL Managed Instance data i geo-redundanta lagringsblobar som replikeras till en länkad region. Georedundans hjälper till att skydda mot avbrott som påverkar säkerhetskopieringslagring i den primära regionen och gör att du kan återställa servern till en annan region i händelse av ett haveri.

Alternativet för att konfigurera redundans för lagring av säkerhetskopior ger flexibiliteten att välja mellan lokalt redundanta, zonredundant eller geo-redundanta lagringsblobar. För att säkerställa att dina data ligger inom samma region där din hanterade instans eller SQL-databas distribueras, kan du ändra standardredundansen för lagring av geo-redundant säkerhetskopiering och konfigurera antingen lokalt redundanta eller zonredundant lagringsblobar för säkerhetskopieringar. Storage mekanismer för redundans lagrar flera kopior av dina data så att de skyddas från planerade och oplanerade händelser, inklusive tillfälliga maskinvarufel, nätverks- eller strömavbrott eller enorma naturkatastrofer. Den konfigurerade redundansen för lagring av säkerhetskopior tillämpas på både inställningar för kortsiktig kvarhållning av säkerhetskopior som används för återställning till tidpunkt (PITR) och säkerhetskopior för långsiktig kvarhållning som används för långsiktiga säkerhetskopieringar (LTR).

För SQL Database kan redundansen för lagring av säkerhetskopior konfigureras när databasen skapas eller uppdateras för en befintlig databas. Ändringarna som görs i en befintlig databas gäller endast för framtida säkerhetskopieringar. När redundansen för lagring av säkerhetskopior för en befintlig databas har uppdaterats kan det ta upp till 48 timmar innan ändringarna tillämpas. Geo-återställning inaktiveras så snart en databas har uppdaterats för att använda lokal lagring eller zonredundant lagring.

Användning av säkerhetskopiering

Du kan använda de här säkerhetskopiorna för att:

• Återställning till tidpunkt av befintlig databas - Återställ en befintlig databas till en tidigare tidpunkt inom kvarhållningsperioden med hjälp av Azure Portal, Azure PowerShell, Azure CLI eller REST API. För SQL Database den här åtgärden en ny databas på samma server som den ursprungliga databasen, men använder ett annat namn för att undvika att skriva över den ursprungliga databasen. När återställningen är klar kan du ta bort den ursprungliga databasen. Du kan också byta namn på både den ursprungliga databasen och sedan byta namn på den återställda databasen till det ursprungliga databasnamnet. För den SQL instansen skapar den här åtgärden en kopia av databasen på samma eller en annan hanterad instans i samma prenumeration och samma region.
• Återställning till tidpunkt för borttagna databaser - Återställ en borttagen databas till tidpunkten för borttagningen eller till valfri tidpunkt inom kvarhållningsperioden. Den borttagna databasen kan bara återställas på samma server eller hanterade instans där den ursprungliga databasen skapades. När du tar bort en databas tar tjänsten en slutlig säkerhetskopia av transaktionsloggen före borttagningen för att förhindra dataförlust.
• Geo-återställning - Återställ en databas till en annan geografisk region. Med geo-återställning kan du återställa efter en geografisk katastrof när du inte kan komma åt din databas eller dina säkerhetskopior i den primära regionen. Den skapar en ny databas på en befintlig server eller hanterad instans i valfri Azure-region.

  Viktigt

  Geo-återställning är endast tillgängligt för SQL eller hanterade instanser som konfigurerats med geo-redundant säkerhetskopieringslagring.

• Återställa från långsiktig säkerhetskopiering - Återställa en databas från en specifik långsiktig säkerhetskopia av en enkel databas eller en pooldatabas, om databasen har konfigurerats med en princip för långsiktig kvarhållning (LTR). Med LTR kan du återställa en gammal version av databasen med hjälp av Azure Portal, Azure CLI eller Azure PowerShell för att uppfylla en efterlevnadsbegäran eller köra en gammal version av programmet. Mer information finns i avsnittet om långsiktig kvarhållning.

Återställningsfunktioner och funktioner i Azure SQL Database och Azure SQL Managed Instance

I den här tabellen sammanfattas funktionerna i återställning till tidpunkt (PITR), geo-återställningoch säkerhetskopior för långsiktig kvarhållning.

* För affärskritiska program som kräver stora databaser och som måste garantera affärskontinu kontinuerlighet använder du automatiska redundansgrupper.

** Alla pitr-säkerhetskopior lagras på geo-redundant lagring som standard. Därför är geo-återställning aktiverat som standard.

*** Lösningen är att återställa till en ny server och använda Resursflyttning för att flytta servern till en annan prenumeration.

Återställa en databas från säkerhetskopior

Information om hur du utför en återställning finns i Återställa databas från säkerhetskopior. Du kan prova konfigurations- och återställningsåtgärder för säkerhetskopiering med hjälp av följande exempel:

Schemaläggning av säkerhetskopiering

Den första fullständiga säkerhetskopieringen schemaläggs omedelbart efter att en ny databas har skapats eller återställts. Säkerhetskopieringen slutförs vanligtvis inom 30 minuter, men det kan ta längre tid när databasen är stor. Den första säkerhetskopieringen kan till exempel ta längre tid på en återställd databas eller en databaskopia, vilket vanligtvis är större än en ny databas. Efter den första fullständiga säkerhetskopieringen schemaläggs och hanteras alla ytterligare säkerhetskopieringar automatiskt. Den exakta tidpunkten för alla databassäkerhetskopior bestäms av SQL Database eller SQL Managed Instance-tjänsten eftersom den balanserar den övergripande systemarbetsbelastningen. Du kan inte ändra schemat för säkerhetskopieringsjobb eller inaktivera dem.

Förbrukning av lagring av säkerhetskopior

Med SQL Server för säkerhetskopiering och återställning kräver återställning av en databas till en viss tidpunkt en oavbruten säkerhetskopieringskedja som består av en fullständig säkerhetskopia, eventuellt en differentiell säkerhetskopia och en eller flera transaktionsloggsäkerhetskopior. SQL Database och SQL för managed instance-säkerhetskopiering innehåller en fullständig säkerhetskopiering varje vecka. För att tillhandahålla PITR inom hela kvarhållningsperioden måste systemet därför lagra ytterligare fullständiga, differentiella och transaktionsloggsäkerhetskopior i upp till en vecka längre än den konfigurerade kvarhållningsperioden.

För alla tidpunkter under kvarhållningsperioden måste det med andra ord finnas en fullständig säkerhetskopia som är äldre än den äldsta tiden för kvarhållningsperioden, samt en oavbruten kedja av differentiella säkerhetskopior och transaktionsloggsäkerhetskopior från den fullständiga säkerhetskopian fram till nästa fullständiga säkerhetskopiering.

Säkerhetskopior som inte längre behövs för att tillhandahålla PITR-funktioner tas bort automatiskt. Eftersom differentiella säkerhetskopieringar och loggsäkerhetskopior kräver att en tidigare fullständig säkerhetskopia kan återställas rensas alla tre säkerhetskopieringstyperna tillsammans i veckovisa uppsättningar.

För alla databaser, inklusive TDE-krypterade databaser, komprimeras säkerhetskopior för att minska komprimering och kostnader för lagring av säkerhetskopior. Det genomsnittliga komprimeringsförhållandet för säkerhetskopiering är 3–4 gånger, men det kan vara betydligt lägre eller högre beroende på typen av data och om datakomprimering används i databasen.

SQL Database och SQL Managed Instance beräknar du din totala använda lagring av säkerhetskopior som ett kumulativt värde. Varje timme rapporteras det här värdet till Azure-faktureringspipelinen, som ansvarar för att aggregera användningen per timme för att beräkna förbrukningen i slutet av varje månad. När databasen har tagits bort minskar förbrukningen när säkerhetskopiorna blir äldre och tas bort. När alla säkerhetskopior har tagits bort och PITR inte längre är möjligt stoppas faktureringen.

Övervaka förbrukning

För vCore-databaser rapporteras den lagring som används av varje typ av säkerhetskopiering (fullständig, differentiell och logg) i databasövervakningsfönstret som ett separat mått. Följande diagram visar hur du övervakar förbrukningen av lagring av säkerhetskopior för en enskild databas. Den här funktionen är för närvarande inte tillgänglig för hanterade instanser.

Finjustera förbrukning av lagringsutrymme för säkerhetskopiering

Förbrukning av säkerhetskopieringslagring upp till den maximala datastorleken för en databas debiteras inte. Överflödig förbrukning av säkerhetskopieringslagring beror på arbetsbelastningen och den maximala storleken på de enskilda databaserna. Överväg några av följande justeringstekniker för att minska förbrukningen av lagringsutrymme för säkerhetskopiering:

• Minska kvarhållningsperioden för säkerhetskopior till minsta möjliga för dina behov.
• Undvik att göra stora skrivåtgärder, till exempel återskapa index, oftare än du behöver.
• För stora datainläsningsåtgärder bör du överväga att använda grupperade columnstore-index och följa relaterade metodtips och/eller minska antalet icke-klustrade index.
• På Generell användning-tjänstnivån är den etablerade datalagringen billigare än priset för säkerhetskopieringslagringen. Om du kontinuerligt har höga kostnader för säkerhetskopieringslagring kan du överväga att öka datalagringen för att spara på lagringen av säkerhetskopior.
• Använd TempDB i stället för permanenta tabeller i programlogiken för att lagra tillfälliga resultat och/eller tillfälliga data.
• Använd lokalt redundant lagring av säkerhetskopiering när det är möjligt (till exempel utvecklings-/testmiljöer)

Kvarhållningsperiod för säkerhetskopior

Azure SQL Database och Azure SQL Managed Instance tillhandahåller både kortsiktig och långsiktig kvarhållning av säkerhetskopior. Säkerhetskopiorna för kortsiktig kvarhållning tillåter återställning till tidpunkt (PITR) med kvarhållningsperioden för databasen, medan långsiktig kvarhållning ger säkerhetskopior för olika efterlevnadskrav.

Kortsiktig kvarhållning

För alla nya, återställda och kopierade databaser behåller Azure SQL Database och Azure SQL Managed Instance tillräckliga säkerhetskopior för att tillåta PITR under de senaste sju dagarna som standard. Regelbundna fullständiga, differentiella säkerhetskopior och loggsäkerhetskopior tas för att säkerställa att databaserna kan återställas till valfri tidpunkt inom den kvarhållningsperiod som definierats för databasen eller den hanterade instansen. För Azure SQL-databaser kan differentiella säkerhetskopior dessutom konfigureras till antingen en 12-timmars- eller 24-timmarsfrekvens.

Med undantag för databaser på Hyperskala- och Basic-nivå kan du ändra kvarhållningsperioden för säkerhetskopior för varje aktiv databas i intervallet 1–35 dagar. Enligt beskrivningen i Lagringsförbrukning för säkerhetskopieringkan säkerhetskopior som lagras för att aktivera PITR vara äldre än kvarhållningsperioden. Endast för Azure SQL Managed Instance är det möjligt att ange kvarhållningsfrekvensen för PITR-säkerhetskopiering när en databas har tagits bort i intervallet 0–35 dagar.

Om du tar bort en databas behåller systemet säkerhetskopior på samma sätt som för en onlinedatabas med dess specifika kvarhållningsperiod. Du kan inte ändra kvarhållningsperioden för säkerhetskopior för en borttagna databas.

Kvarhållning av säkerhetskopior för PITR under de senaste 1–35 dagarna kallas ibland kortsiktig kvarhållning av säkerhetskopior. Om du behöver behålla säkerhetskopior längre än den maximala korta kvarhållningsperioden på 35 dagar kan du aktivera långsiktig kvarhållning.

Långsiktig kvarhållning

För både SQL Database och SQL Managed Instance kan du konfigurera fullständig långsiktig kvarhållning av säkerhetskopior (LTR) i upp till 10 år i Azure Blob Storage. När LTR-principen har konfigurerats kopieras fullständiga säkerhetskopior automatiskt till en annan lagringscontainer varje vecka. För att uppfylla olika efterlevnadskrav kan du välja olika kvarhållningsperioder för veckovisa, månatliga och/eller årliga fullständiga säkerhetskopior. Storage beror på den valda frekvensen och kvarhållningsperioderna för LTR-säkerhetskopior. Du kan använda priskalkylatorn för LTR för att beräkna kostnaden för LTR-lagring.

Mer information om LTR finns i Långsiktig kvarhållning av säkerhetskopior.

Kostnader för lagring av säkerhetskopior

Priset för lagring av säkerhetskopior varierar och beror på din inköpsmodell (DTU eller vCore), valt redundansalternativ för lagring av säkerhetskopior och även på din region. Säkerhetskopieringslagringen debiteras per GB/månad som förbrukas. För priser kan du Azure SQL Database sidan med priser och priser för Azure SQL Managed Instance.

Mer information om köpmodeller finns i Välja mellan köpmodellerna vCore och DTU.

DTU-modell

I DTU-modellen tillkommer ingen extra kostnad för säkerhetskopieringslagring för databaser och elastiska pooler. Priset för lagring av säkerhetskopior är en del av databas- eller poolpriset.

vCore-modellen

För enskilda databaser i SQL Database en lagringssumma för säkerhetskopiering som motsvarar 100 procent av databasens maximala datalagringsstorlek tillhandahålls utan extra kostnad. För elastiska pooler och hanterade instanser tillhandahålls en mängd lagringsutrymme för säkerhetskopiering som motsvarar 100 procent av den maximala datalagringen för poolen eller den maximala instanslagringsstorleken utan extra kostnad.

För enskilda databaser används den här ekvationen för att beräkna den totala fakturerbara lagringsanvändningen för säkerhetskopior:

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

För pooldatabaser aggregeras den totala fakturerbara lagringsstorleken för säkerhetskopiering på poolnivå och beräknas på följande sätt:

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

För hanterade instanser aggregeras den totala fakturerbara lagringsstorleken för säkerhetskopiering på instansnivå och beräknas på följande sätt:

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

Totalt fakturerbart lagringsutrymme för säkerhetskopiering, om det finns någon, debiteras i GB/månad enligt frekvensen för den redundans för säkerhetskopieringslagring som används. Förbrukningen för lagring av säkerhetskopior beror på arbetsbelastningen och storleken på enskilda databaser, elastiska pooler och hanterade instanser. Kraftigt modifierade databaser har större differentiella säkerhetskopior och loggsäkerhetskopior, eftersom storleken på dessa säkerhetskopior är proportionell mot mängden ändrade data. Därför kommer sådana databaser att ha högre avgifter för säkerhetskopiering.

SQL Database och SQL Managed Instance beräknar din totala fakturerbara lagring av säkerhetskopior som ett kumulativt värde för alla säkerhetskopieringsfiler. Varje timme rapporteras det här värdet till Azure-faktureringspipelinen, som aggregerar den här timanvändningen för att få din förbrukning av lagringsutrymme för säkerhetskopiering i slutet av varje månad. Om en databas tas bort minskar användningen av lagringsutrymme för säkerhetskopiering gradvis när äldre säkerhetskopior blir äldre och tas bort. Eftersom differentiella säkerhetskopieringar och loggsäkerhetskopior kräver att en tidigare fullständig säkerhetskopia kan återställas, rensas alla tre säkerhetskopieringstyperna tillsammans i veckovisa uppsättningar. När alla säkerhetskopior har tagits bort stoppas faktureringen.

Som ett förenklat exempel antar vi att en databas har ackumulerat 744 GB lagringsutrymme för säkerhetskopiering och att den här mängden förblir konstant under en hel månad eftersom databasen är helt inaktiv. Om du vill konvertera den kumulativa lagringsförbrukningen till användning per timme delar du den med 744,0 (31 dagar per månad * 24 timmar per dag). SQL Database till Azure-faktureringspipelinen att databasen förbrukade 1 GB PITR-säkerhetskopiering varje timme, med en konstant hastighet. Azure-faktureringen aggregerar den här förbrukningen och visar en användning på 744 GB för hela månaden. Kostnaden baseras på priset för belopp/GB/månad i din region.

Nu är det ett mer komplext exempel. Anta att samma inaktiva databas har ökat sin kvarhållning från sju dagar till 14 dagar i mitten av månaden. Den här ökningen resulterar i att den totala säkerhetskopieringslagringen fördubblas till 1 488 GB. SQL Database skulle rapportera 1 GB användning för timmarna 1 till 372 (den första halvan av månaden). Det skulle rapportera användningen som 2 GB för timmarna 373 till 744 (den andra halvan av månaden). Den här användningen skulle aggregeras till en slutlig faktura på 1 116 GB/månad.

Faktiska faktureringsscenarier för säkerhetskopiering är mer komplexa. Eftersom ändringstakten i databasen beror på arbetsbelastningen och varierar med tiden, varierar storleken på varje differentiell säkerhetskopiering och loggsäkerhetskopia också, vilket gör att förbrukningen av lagringsutrymme för säkerhetskopiering per timme varierar i enlighet med detta. Dessutom innehåller varje differentiell säkerhetskopia alla ändringar som gjorts i databasen sedan den senaste fullständiga säkerhetskopian, vilket innebär att den totala storleken på alla differentiella säkerhetskopior gradvis ökar under loppet av en vecka och sedan minskar kraftigt när en äldre uppsättning fullständiga, differentiella och loggsäkerhetskopior blir äldre. Om till exempel en tung skrivaktivitet, till exempel återskapande av index, har körts precis efter att en fullständig säkerhetskopiering har slutförts, kommer de ändringar som görs av indexet att inkluderas i de säkerhetskopieringar av transaktionsloggen som görs under återskapandetiden, i nästa differentiella säkerhetskopia och i varje differentiell säkerhetskopia som görs tills nästa fullständiga säkerhetskopiering sker. I det senare scenariot i större databaser skapar en optimering i tjänsten en fullständig säkerhetskopia i stället för en differentiell säkerhetskopia om en differentiell säkerhetskopia annars skulle vara för stor. Detta minskar storleken på alla differentiella säkerhetskopior tills följande fullständiga säkerhetskopiering.

Du kan övervaka den totala lagringsförbrukningen för säkerhetskopior för varje säkerhetskopieringstyp (fullständig, differentiell, transaktionslogg) över tid enligt beskrivningen i Övervaka förbrukning.

Redundans för lagring av säkerhetskopior

Redundans för säkerhetskopieringslagring påverkar säkerhetskopieringskostnaderna på följande sätt:

• lokalt redundant pris = x
• zonredundant pris = 1,25 x
• geo-redundant price = 2x

Mer information om priser för säkerhetskopieringslagring finns Azure SQL Database prissättningssidan och sidan med priser för Azure SQL Managed Instance.

Övervaka kostnader

Om du vill förstå kostnaderna för lagring av säkerhetskopior går Cost Management + Billing i Azure Portal väljer du Cost Management och väljer sedan Kostnadsanalys. Välj önskad prenumeration som Omfång och filtrera sedan för den tidsperiod och tjänst som du är intresserad av.

Lägg till ett filter för Tjänstnamn och välj sedan sql database i listrutan. Använd filtret för mätarunderkategori för att välja faktureringsräknare för din tjänst. För en enkel databas eller en elastisk databaspool väljer du PITR-säkerhetskopieringslagring för en enskild/elastisk pool. För en hanterad instans väljer du mi PITR Backup Storage. De Storage och beräkningsunderkategorier kan också intressera dig, men de är inte associerade med lagringskostnader för säkerhetskopior.

Mer information finns i Azure SQL Database kostnadshantering.

Krypterade säkerhetskopior

Om databasen är krypterad med TDE krypteras säkerhetskopiorna automatiskt i vila, inklusive LTR-säkerhetskopior. Alla nya databaser i Azure SQL konfigureras med TDE aktiverat som standard. Mer information om TDE finns i transparent datakryptering med SQL Database & SQL Managed Instance.

Säkerhetskopieringsintegritet

Azures teknikerteam testar regelbundet SQL automatiskt återställningen av automatiserade databassäkerhetskopior. (Det här testet är för närvarande inte tillgängligt i SQL Managed Instance. Du bör schemalägga DBCC CHECKDB på dina databaser i SQL Managed Instance, schemalagt runt arbetsbelastningen.)

Vid återställning till tidpunkt får databaserna även DBCC CHECKDB-integritetskontroller.

Eventuella problem som påträffas under integritetskontrollen resulterar i en avisering till teknikteamet. Mer information finns i Dataintegritet i SQL Database.

Alla databassäkerhetskopior tas med alternativet CHECKSUM för att ge ytterligare integritet för säkerhetskopiering.

Efterlevnad

När du migrerar databasen från en DTU-baserad tjänstnivå till en vCore-baserad tjänstnivå bevaras PITR-kvarhållningen för att säkerställa att programmets dataåterställningsprincip inte komprometteras. Om standardvärdet för kvarhållning inte uppfyller dina efterlevnadskrav kan du ändra kvarhållningsperioden för PITR. Mer information finns i Ändra kvarhållningsperioden för PITR-säkerhetskopior.

Ändra principen för kortsiktig kvarhållning

Du kan ändra standardkvarhållningsperioden för PITR-säkerhetskopior och differentiell säkerhetskopieringsfrekvens med hjälp av Azure Portal, PowerShell eller REST API. I följande exempel visas hur du ändrar kvarhållningen av PITR till 28 dagar och differentiella säkerhetskopior till ett intervall på 24 timmar.

Ändra principen för kortsiktig kvarhållning med hjälp av Azure Portal

Om du vill ändra kvarhållningsperioden för PITR-säkerhetskopiering eller differentiell säkerhetskopieringsfrekvens för aktiva databaser med hjälp av Azure Portal går du till servern eller den hanterade instansen med de databaser vars kvarhållningsperiod du vill ändra. Välj Säkerhetskopieringar i det vänstra fönstret och välj sedan fliken Kvarhållningsprinciper. Välj den eller de databaser som du vill ändra kvarhållningen av PITR-säkerhetskopior för. Välj sedan Konfigurera kvarhållning i åtgärdsfältet.

Ändra principen för kortsiktig kvarhållning med Hjälp av Azure CLI

Förbered din miljö för Azure CLI.

• Använd bash-miljön i Azure Cloud Shell.

  

• Om du vill kan du i stället installera Azure CLI för att köra CLI-referenskommandon.

  • Om du använder en lokal installation loggar du in på Azure CLI med hjälp av kommandot az login. Slutför autentiseringsprocessen genom att följa stegen som visas i terminalen. Fler inloggningsalternativ finns i Logga in med Azure CLI.

  • När du uppmanas till det installerar du Azure CLI-tillägg vid första användning. Mer information om tillägg finns i Använda tillägg med Azure CLI.

  • Kör az version om du vill hitta versionen och de beroende bibliotek som är installerade. Om du vill uppgradera till den senaste versionen kör du az upgrade.

# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --retention-days 28 \
    --diffbackup-hours 24

# Set new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --name mymanageddb \
    --retention-days 1 \

# Set new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --retention-days 1 \

Ändra principen för kortsiktig kvarhållning med PowerShell

# 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

# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24. 
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24

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

# SET new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
Get-AzSqlInstanceDatabase -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 1

# SET new PITR backup retention on an individual deleted database
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database.
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver -DatabaseName testDatabase | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

# SET new PITR backup retention for ALL deleted databases
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

Ändra principen för kortsiktig kvarhållning med hjälp av REST API

Begäran nedan uppdaterar kvarhållningsperioden till 28 dagar och anger även frekvensen för differentiell säkerhetskopiering till 24 timmar.

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

{ 
    "properties":{
        "retentionDays":28
        "diffBackupIntervalInHours":24
  }
}

{ 
  "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
    "diffBackupIntervalInHours":24
  }
}

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

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

{
  "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
  }
}

Konfigurera redundans för lagring av säkerhetskopior

Konfigurerbar lagringsredundans för SQL-databaser kan konfigureras när databasen skapas eller uppdateras för en befintlig databas. Ändringarna som görs i en befintlig databas gäller endast för framtida säkerhetskopior. För SQL redundans för lagring av säkerhetskopior i Managed Instance och HyperScale kan endast anges under processen för att skapa. När resursen har etablerats kan du inte ändra redundansalternativet för lagring av säkerhetskopior. Standardvärdet är geo-redundant lagring. Information om prisskillnaderna mellan lokalt redundant, zonredundant och geo-redundant säkerhetskopiering finns på prissättningssidan för hanterad instans.

Konfigurera redundans för lagring av säkerhetskopior med hjälp av Azure Portal

Konfigurera redundans för lagring av säkerhetskopior med hjälp av Azure CLI

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

Konfigurera redundans för lagring av säkerhetskopior med hjälp av PowerShell

# 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

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

New-AzSqlInstance -Name managedInstance2 -ResourceGroupName ResourceGroup01 -Location westcentralus -AdministratorCredential (Get-Credential) -SubnetId "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/resourcegroup01/providers/Microsoft.Network/virtualNetworks/vnet_name/subnets/subnet_name" -LicenseType LicenseIncluded -StorageSizeInGB 1024 -VCore 16 -Edition "GeneralPurpose" -ComputeGeneration Gen4 -BackupStorageRedundancy Geo

Använda Azure Policy för att framtvinga redundans för lagring av säkerhetskopior

Om du har krav på datahemhemlighet som kräver att du behåller alla dina data i en enda Azure-region kanske du vill framtvinga zonredundant eller lokalt redundant säkerhetskopiering för din SQL Database eller hanterade instans med hjälp av Azure Policy. Azure Policy är en tjänst som du kan använda för att skapa, tilldela och hantera principer som tillämpar regler på Azure-resurser. Azure Policy hjälper dig att hålla dessa resurser kompatibla med företagets standarder och serviceavtal. Mer information finns i Översikt över Azure Policy.

Inbyggda principer för lagringsredundans för säkerhetskopior

Följande nya inbyggda principer läggs till, som kan tilldelas på prenumerations- eller resursgruppsnivå för att blockera skapandet av nya databaser eller instanser med geo-redundant säkerhetskopieringslagring.

SQL Database bör undvika att använda GRS-redundans för säkerhetskopiering

SQL Managed Instances bör undvika att använda GRS-redundans för säkerhetskopiering

En fullständig lista över inbyggda principdefinitioner för SQL Database och Managed Instance finns här.

För att framtvinga krav på datahemhemlighet på organisationsnivå kan dessa principer tilldelas till en prenumeration. När dessa principer har tilldelats på prenumerationsnivå kan användare i den angivna prenumerationen inte skapa en databas eller en hanterad instans med geo-redundant säkerhetskopieringslagring via Azure Portal eller Azure PowerShell.

Lär dig hur du tilldelar principer med hjälp Azure Portal eller Azure PowerShell

Nästa steg

• Databassäkerhetskopior är en viktig del av en strategi för affärskontinuering och haveriberedskap eftersom de skyddar dina data mot oavsiktlig skada eller borttagning. Information om de andra SQL Database för affärskontinuhet finns i Översikt över affärskontinuhet.
• Information om hur du konfigurerar, hanterar och återställer från långsiktig kvarhållning av automatiska säkerhetskopior i Azure Blob Storage med hjälp av Azure Portal finns i Hantera långsiktig kvarhållning av säkerhetskopior med hjälp av Azure Portal.
• Information om hur du konfigurerar, hanterar och återställer från långsiktig kvarhållning av automatiska säkerhetskopior i Azure Blob Storage med hjälp av PowerShell finns i Hantera långsiktig kvarhållning av säkerhetskopior med hjälp av PowerShell.
• Få mer information om hur du återställer en databas till en tidpunkt med hjälp av Azure Portal.
• Få mer information om hur du återställer en databas till en tidpunkt med hjälp av PowerShell.
• Om du vill veta mer om förbrukningen av lagringsutrymme för säkerhetskopiering i Azure SQL Managed Instance kan du läsa mer i Förklaring av lagringsförbrukning för säkerhetskopiering på hanterad instans.
• Information om hur du finjusterar kvarhållning av säkerhetskopior och kostnader för Azure SQL Managed Instance finns i Finjustera kostnader för lagring av säkerhetskopior i Managed Instance.