Dela via

Automatiserade säkerhetskopieringar i Azure SQL Managed Instance

  • Artikel

gäller för:Azure SQL Managed Instance

I den här artikeln beskrivs funktionen för automatisk säkerhetskopiering för Azure SQL Managed Instance.

Information om hur du ändrar säkerhetskopieringsinställningar finns i Ändra inställningar. Information om hur du återställer en säkerhetskopia finns i Återställa med hjälp av automatiserade databassäkerhetskopior.

Vad är automatiserade databassäkerhetskopior?

Databassäkerhetskopior är en viktig del av alla strategier för affärskontinuitet och haveriberedskap eftersom de skyddar dina data från skador eller borttagning. Med Azure SQL Managed Instance hanteras säkerhetskopieringar av SQL Server-databasmotorn automatiskt av Microsoft och lagras på Microsoft-hanterade Azure-lagringskonton.

Använd dessa säkerhetskopior för att återställa databasen till en viss tidpunkt inom den konfigurerade kvarhållningsperioden, upp till 35 dagar. Men 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 (LTR) principer per varje databas.

Säkerhetskopieringsfrekvens

Azure SQL Managed Instance skapar:

Frekvensen för säkerhetskopieringar av transaktionsloggar beror på beräkningsstorleken och mängden databasaktivitet. Transaktionsloggar tas ungefär var 10:e minut, men kan variera. När du återställer en databas avgör tjänsten vilka fullständiga säkerhetskopieringar, differentiella säkerhetskopieringar och transaktionsloggar som måste återställas i respektive ordning.

Försiktighet

Automatiska fullständiga säkerhetskopior initieras en gång i veckan baserat på ett schema som bestäms av Microsoft. användarinitierade säkerhetskopior ha prioritet framför automatiska fullständiga säkerhetskopior, så en långvarig säkerhetskopiering med endast kopiering kan påverka tidpunkten för nästa automatiska fullständiga säkerhetskopiering.

Redundans för säkerhetskopieringslagring

Som standard lagrar Azure SQL Managed Instance säkerhetskopior i geo-redundanta lagringsblobar som replikeras till en parat område. Geo-redundans hjälper till att skydda mot avbrott som påverkar lagring av säkerhetskopior i den primära regionen. Du kan också återställa din instans till en annan region i händelse av en katastrof.

Mekanismen för lagringsredundans lagrar flera kopior av dina data så att de skyddas från planerade och oplanerade händelser. Dessa händelser kan omfatta tillfälliga maskinvarufel, nätverks- eller strömavbrott eller massiva naturkatastrofer.

För att säkerställa att dina säkerhetskopior finns kvar i samma region där databasen distribueras kan du ändra redundans för säkerhetskopieringslagring från standard geo-redundant lagring till andra typer av lagring som håller dina data inom regionen. Mer information om lagringsredundans finns i Dataredundans.

Du kan konfigurera redundans för säkerhetskopieringslagring när du skapar instansen och du kan uppdatera den vid ett senare tillfälle på instansnivå. De ändringar som du gör i en befintlig instans gäller endast för framtida säkerhetskopior. När du har uppdaterat redundansen för säkerhetskopiering av en befintlig instans kan det ta upp till 24 timmar innan ändringarna tillämpas. Ändringar som görs i redundans för lagring av säkerhetskopior gäller endast för kortsiktiga säkerhetskopieringar. Långsiktiga kvarhållningspolicyer ärver redundansalternativet för kortsiktiga säkerhetskopieringar när policyn skapas. Redundansalternativet kvarstår för långsiktiga säkerhetskopieringar även om redundansalternativet för kortsiktiga säkerhetskopieringar senare ändras.

Not

Att ändra redundans för säkerhetskopiering är en uppdateringshanteringsåtgärd som initierar en redundansväxling.

Du kan välja någon av följande lagringsredundanser för säkerhetskopior:

  • Lokalt redundant lagring (LRS): Kopierar dina säkerhetskopior synkront tre gånger på en enda fysisk plats i den primära regionen. LRS är det billigaste replikeringsalternativet, men vi rekommenderar det inte för program som kräver hög tillgänglighet eller hållbarhet.

    diagram som visar alternativet lokalt redundant lagring (LRS).

  • Zonredundant lagring (ZRS): Kopierar dina säkerhetskopior synkront över tre Azure-tillgänglighetszoner i den primära regionen. Den är för närvarande tillgänglig i vissa regioner.

    diagram som visar alternativet zonredundant lagring (ZRS).

  • Geo-redundant lagring (GRS): Kopierar dina säkerhetskopior synkront tre gånger på en enda fysisk plats i den primära regionen med hjälp av LRS. Sedan kopieras dina data asynkront tre gånger till en enda fysisk plats i parat sekundär region.

    Resultatet är:

    • Tre synkrona kopior i den primära regionen inom en enda tillgänglighetszon.
    • Tre synkrona kopior i den kopplade regionen i en enda tillgänglighetszon som kopierades över från den primära regionen till den sekundära regionen asynkront.

    diagram som visar alternativet geo-redundant lagring (GRS).

  • Geo-zonredundant lagring (GZRS): Kombinerar hög tillgänglighet genom redundans över tillgänglighetszoner med skydd mot regionala avbrott genom geo-replikering. Data i ett GZRS-konto kopieras mellan tre Azure-tillgänglighetszoner i den primära regionen. Data replikeras också till en sekundär geografisk region för skydd mot regionala katastrofer. I den regionen har du också tre synkrona kopior i en enda tillgänglighetszon som kopierades över från den primära regionen till den sekundära regionen asynkront.

    diagram som visar alternativet geo-zonredundant lagring (GZRS).

Varning

  • Geo-återställning inaktiveras så snart en databas har uppdaterats för att använda lokalt redundant eller zonredundant lagring.
  • Diagram över lagringsredundans visar alla regioner med flera tillgänglighetszoner (multi-az). Det finns dock vissa regioner som endast tillhandahåller en enda tillgänglighetszon och inte stöder ZRS eller GZRS.

Säkerhetskopieringsanvändning

Du kan använda dessa säkerhetskopior för att:

  • Återställ en befintlig databas till en tidpunkt tidigare inom kvarhållningsperioden med hjälp av Azure-portalen, Azure PowerShell, Azure CLI eller REST-API:et. Den här åtgärden skapar en ny databas på antingen samma instans som den ursprungliga databasen eller en annan instans i samma prenumeration och region. Den använder ett annat namn för att undvika att skriva över den ursprungliga databasen. Du kan också använda Azure-portalen för att återställa säkerhetskopieringen av din tidpunktsdatabas till en instans i en annan prenumeration än källinstansen.

    När återställningen är klar kan du ta bort den ursprungliga databasen. Du kan också både byta namn på den ursprungliga databasen och byta namn på den återställda databasen till det ursprungliga databasnamnet.

  • Återställ en borttagen databas till en tidpunkt inom kvarhållningsperioden, inklusive borttagningstiden. Du kan återställa den borttagna databasen till samma hanterade instans där säkerhetskopieringen gjordes, eller en annan instans i samma eller en annan prenumeration på källinstansen. Innan du tar bort en databas tar tjänsten en slutlig säkerhetskopiering av transaktionsloggen för att förhindra dataförlust.

  • Återställ en databas till en annan geografisk region. Med geo-återställning kan du återställa från en geografisk katastrof när du inte kan komma åt databasen eller säkerhetskopiorna i den primära regionen. Den skapar en ny databas på alla befintliga hanterade instanser i valfri Azure-region.

    Viktig

    Geo-återställning är endast tillgängligt för databaser som har konfigurerats med geo-redundant säkerhetskopiering. Om du för närvarande inte använder geo-replikerade säkerhetskopior för en databas kan du ändra detta genom att konfigurera redundans för säkerhetskopieringslagring.

  • Återställ en databas från en långsiktig säkerhetskopia av en databas, om databasen har en konfigurerad LTR-princip. Med LTR kan du återställa en äldre version av databasen med hjälp av Azure-portalen, Azure CLI eller Azure PowerShell för att uppfylla en efterlevnadsbegäran eller för att köra en gammal version av programmet. För mer information, se översiktssidan över långsiktig kvarhållning.

Återställa kapacitet och funktioner

Den här tabellen sammanfattar egenskaperna och funktionerna i ögonblicksåterställning (PITR), geoåterställningoch långsiktig kvarhållning.

Egenskaper för säkerhetskopiering PITR Geo-återställning LTR
typer av SQL-säkerhetskopiering Fullständiga säkerhetskopieringar, differentiella säkerhetskopieringar och transaktionsloggar. Replikerade kopior av PITR-säkerhetskopior. Fullständiga säkerhetskopior endast.
Mål för återställningspunkt (RPO) Cirka 10 minuter, baserat på beräkningsstorlek och mängden databasaktivitet. Upp till en timme, beroende på geo-replikering. 1 En vecka (eller användarens policy).
Mål för återställningstid (RTO) Återställningen tar vanligtvis mindre än 12 timmar men kan ta längre tid, beroende på storlek och aktivitet. Se Återhämtning. Återställningen tar vanligtvis mindre än 12 timmar men kan ta längre tid, beroende på storlek och aktivitet. Se Återhämtning. Återställningen tar vanligtvis mindre än 12 timmar men kan ta längre tid, beroende på storlek och aktivitet. Se Återställning.
kvarhållning 1 till 35 dagar. Aktiverad som standard, samma som källan. 2 Inte aktiverat som standard. Bevaringstiden är upp till 10 år.
Azure-lagring Geo-redundant som standardinställning. Du kan också konfigurera zonredundant eller lokalt redundant lagring. Tillgänglig när PITR-lagringsredundans för säkerhetskopiering är inställd på geo-redundant. Inte tillgängligt när PITR-säkerhetskopieringslagring är zonredundant eller lokalt redundant. Geo-redundant som förvald inställning. Du kan konfigurera zonredundant eller lokalt redundant lagring.
Konfigurera säkerhetskopieringar som oföränderliga Stöds inte Stöds inte Stöds inte
Uppdatera princip3 Måste matcha eller uppgradera Måste matcha eller uppgradera Måste matcha eller uppgradera
Återställa en ny databas i samma region Stödd Stödd Understödd
Återställa en ny databas i en annan region Stöds inte Stöds i alla Azure-regioner Stöds i alla Azure-regioner
Återställa en ny databas i en annan prenumeration Stödd Stöds inte 4 Stöds inte 4
Återställ via Azure-portalen Ja Ja Ja
att återställa via PowerShell Ja Ja Ja
återställning via Azure CLI Ja Ja Ja

1 För affärskritiska program som kräver stora databaser och som måste säkerställa affärskontinuitet kan du läsa redundansgrupper.
2 Alla PITR-säkerhetskopior lagras som standard på geo-redundant lagring, vilket innebär att geo-återställning är aktiverat som standard.
3 Databassäkerhetskopior som hämtats från instanser som konfigurerats med SQL Server 2022 uppdateringsprincip kan återställas till instanser som konfigurerats med antingen SQL Server 2022- eller Always-up-to-date update-principen. Databassäkerhetskopior som hämtats från instanser som konfigurerats med uppdateringsprincipen Always-up-to-date kan bara återställas till instanser som också har konfigurerats med uppdateringsprincipen Always-up-to-date.
4 Lösningen är att återställa till en ny server och använda Resursflytt för att flytta servern till en annan prenumeration.

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

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

Operation Azure-portalen Azure CLI Azure PowerShell
Ändra kvarhållning av säkerhetskopior SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance
Ändra långsiktig kvarhållning av säkerhetskopior SQL-databas / SQL-hanterad instans SQL Database / SQL Managed Instance SQL-databas / Hanterad SQL-instans
Återställa en databas från en tidpunkt SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance
Återställ en borttagen databas SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance SQL Database / SQL Managed Instance
Återställa en databas från Azure Blob Storage SQL Managed Instance

Schema för automatiska säkerhetskopieringar

Azure SQL Managed Instance hanterar automatiskt säkerhetskopieringar genom att skapa fullständiga säkerhetskopieringar, differentiella säkerhetskopieringar och transaktionsloggar. Den här processen styrs av ett internt schema.

Inledande säkerhetskopiering

Omedelbart efter att en databas har skapats, återställts eller genomgått ändringar i säkerhetskopieringsredundans initieras den första fullständiga säkerhetskopieringen. Den här säkerhetskopieringen slutförs vanligtvis inom 30 minuter, men det kan ta längre tid. Varaktigheten för den första säkerhetskopieringen för återställde databaser varierar och beror på databasens storlek. Större återställde databaser eller databaskopior kan kräva mer tid för den första säkerhetskopieringen.

Viktig

Den första fullständiga säkerhetskopieringen för en ny databas prioriteras framför andra databassäkerhetskopior, så det är den första säkerhetskopieringen som görs under det första fullständiga säkerhetskopieringsfönstret. Om det fullständiga säkerhetskopieringsfönstret redan är aktivt och andra databaser säkerhetskopieras tas den första fullständiga säkerhetskopieringen för den nya databasen direkt efter att den fullständiga säkerhetskopieringen av en annan databas har slutförts.

Schemalagda fullständiga säkerhetskopior

  • Veckoschema: Systemet anger ett fullständigt säkerhetskopieringsfönster varje vecka för hela instansen.
  • fullständigt säkerhetskopieringsfönster: Detta är en angiven period när fullständiga säkerhetskopieringar utförs. Systemet syftar till att slutföra fullständiga säkerhetskopior i det här fönstret, men om det behövs kan säkerhetskopieringen fortsätta efter den schemalagda tiden tills den har slutförts.
  • Adaptive Scheduling: Säkerhetskopieringsalgoritmen utvärderar effekten av säkerhetskopieringsfönstret på arbetsbelastningen ungefär en gång i veckan, med cpu-användning och I/O-dataflöde som indikatorer. Beroende på föregående veckas arbetsbelastning kan det fullständiga säkerhetskopieringsfönstret justeras.
  • Användarkonfiguration: Det är viktigt att observera att användare inte kan ändra eller inaktivera säkerhetskopieringsschemat.

Viktig

För en ny, återställd eller kopierad databas blir funktionen för återställning till tidpunkt (PITR) tillgänglig när den första säkerhetskopieringen av transaktionsloggen har slutförts efter den första fullständiga säkerhetskopieringen.

Lagringsförbrukning för säkerhetskopiering

Med SQL Server-säkerhetskopiering och återställningsteknik kräver återställning av en databas till en tidpunkt en oavbruten säkerhetskopieringskedja. Den kedjan består av en fullständig säkerhetskopia, eventuellt en differentiell säkerhetskopia och en eller flera säkerhetskopior av transaktionsloggar.

Säkerhetskopieringsscheman för Azure SQL Managed Instance innehåller en fullständig säkerhetskopiering varje vecka. För att tillhandahålla PITR inom hela kvarhållningsperioden måste systemet lagra ytterligare fullständiga säkerhetskopieringar, differentiella säkerhetskopieringar och transaktionsloggar 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. Det måste också finnas en oavbruten kedja av differentiella säkerhetskopior och säkerhetskopior av transaktionsloggar från den fullständiga säkerhetskopian till nästa fullständiga säkerhetskopia.

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

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

Viktig

För TDE-krypterade databaser komprimeras inte loggsäkerhetskopior av prestandaskäl. Loggsäkerhetskopior för icke-TDE-krypterade databaser komprimeras.

Azure SQL Managed Instance beräknar din totala användning av lagring av säkerhetskopior som ett kumulativt värde. Varje timme rapporteras det här värdet till Azure-faktureringspipelinen. Pipelines ansvarar för att sammanställa timanvändningen för att beräkna din förbrukning vid slutet av varje månad. När databasen har tagits bort minskar förbrukningen när säkerhetskopiorna åldras och tas bort. När alla säkerhetskopior har tagits bort och PITR inte längre är möjligt stoppas faktureringen.

Viktig

Säkerhetskopior för en borttagen databas sparas för återställning till en specifik tidpunkt (PITR), vilket kan leda till ökade lagringskostnader eftersom säkerhetskopiorna behålls även om databasen är borttagen. För att minska kostnaderna kan du ange kvarhållningsperioden för säkerhetskopior till 0 dagar, men bara för borttagna databaser. För vanliga databaser är den minsta kvarhållningsperioden 1 dag.

Finjustera lagringsförbrukningen för säkerhetskopiering

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

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

Kvarhållning av säkerhetskopior

Azure SQL Managed Instance ger både kortsiktig och långsiktig kvarhållning av säkerhetskopior. Kortsiktig kvarhållning tillåter PITR inom kvarhållningsperioden för databasen. Långsiktig kvarhållning tillhandahåller säkerhetskopior för olika efterlevnadskrav.

Kortsiktig kvarhållning

För alla nya, återställde och kopierade databaser behåller Azure SQL Managed Instance tillräckliga säkerhetskopior för att tillåta PITR under de senaste 7 dagarna som standard. Den här konfigurationen kan ändras inom intervallet 1 till 35 dagar. Tjänsten tar regelbundna fullständiga, differentiella och loggsäkerhetskopior för att säkerställa att databaser kan återställas till valfri tidpunkt inom kvarhållningsperioden som har definierats för databasen eller den hanterade instansen.

Du kan ange redundansalternativet för säkerhetskopieringslagring för STR när du skapar instansen och sedan ändra den senare. Om du ändrar redundansalternativet för säkerhetskopiering när instansen har skapats använder nya säkerhetskopior det nya redundansalternativet. Säkerhetskopieringskopior som gjorts med föregående STR-redundansalternativ flyttas inte eller kopieras. De finns kvar i det ursprungliga lagringskontot tills kvarhållningsperioden upphör att gälla. Enligt beskrivningen i Förbrukning av säkerhetskopieringslagringkan säkerhetskopieringar som lagras för att aktivera PITR vara äldre än kvarhållningsperioden för att säkerställa exakt dataåterställning.

Om du tar bort en databas behåller systemet säkerhetskopior på samma sätt som för en onlinedatabas med sin specifika kvarhållningsperiod. För en borttagen databas uppdateras dock kvarhållningsperioden från 1–35 dagar till 0–35 dagar, vilket gör det möjligt att ta bort säkerhetskopior manuellt. Om du behöver behålla säkerhetskopior längre än den maximala kortsiktiga kvarhållningsperioden på 35 dagar kan du aktivera långsiktig kvarhållning.

Viktig

Om du tar bort en hanterad instans tas även alla databaser på den hanterade instansen bort och kan inte återställas. Du kan inte återställa en borttagen hanterad instans. Men om du har konfigurerat långsiktig kvarhållning för en hanterad instans tas INTE LTR-säkerhetskopieringar bort. Du kan sedan använda dessa säkerhetskopior för att återställa databaser till en annan hanterad instans i samma prenumeration, till en tidpunkt då en LTR-säkerhetskopiering gjordes. Mer information finns i Återställa långsiktig säkerhetskopiering.

Långsiktig kvarhållning (LTR)

Med SQL Managed Instance kan du konfigurera lagring av fullständiga LTR-säkerhetskopior 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.

För att uppfylla olika efterlevnadskrav kan du välja olika kvarhållningsperioder för fullständiga säkerhetskopior varje vecka, månad och/eller år. Frekvensen beror på principen. Om du till exempel anger W=0, M=1, Y=0 skapar du en månatlig LTR-kopia. Mer information om LTR finns i Långsiktig kvarhållning.

Redundans för lagring av LTR-säkerhetskopiering i Azure SQL Managed Instance ärvs från redundansen för lagring av säkerhetskopior som används av STR när LTR-principen definieras. Du kan inte ändra detta, även om redundansen för STR-säkerhetskopior skulle ändras i framtiden.

Lagringsförbrukningen beror på de valda frekvens- och kvarhållningsperioderna för LTR-säkerhetskopior. Du kan använda priskalkylatorn LTR för att beräkna kostnaden för LTR-lagring.

Kostnader för lagring av säkerhetskopior

Azure SQL Managed Instance beräknar ditt totala fakturerbara lagringsutrymme för säkerhetskopiering som ett kumulativt värde för alla säkerhetskopieringsfiler. Varje timme rapporteras det här värdet till Azure-faktureringspipelinen. Pipelinen aggregerar den här timanvändningen för att få din lagringsförbrukning för säkerhetskopiering i slutet av varje månad.

Om en databas tas bort minskar lagringsförbrukningen för säkerhetskopiering gradvis när äldre säkerhetskopior åldras och tas bort. Eftersom differentiella säkerhetskopior och loggsäkerhetskopior kräver att en tidigare fullständig säkerhetskopia kan återställas rensas alla tre säkerhetskopieringstyperna tillsammans i veckouppsättningar. När alla säkerhetskopior har tagits bort stoppas faktureringen.

Priset för lagring av säkerhetskopior varierar. Det beror på ditt valda alternativ för säkerhetskopieringslagringsredundans och din region. Lagring av säkerhetskopior debiteras baserat på gigabyte som förbrukas per månad, med samma hastighet för alla säkerhetskopior.

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

  • Locally redundant price = published price
  • Zone-redundant price = published price x 1.25
  • Geo-redundant price = published price x 2
  • Geo-zone-redundant price = published price x 3.4

Gå till sidan Azure SQL Managed Instance-prissättning för information om priser.

Not

En Azure-faktura visar bara den överskjutande lagringsförbrukningen för säkerhetskopiering, inte hela lagringsförbrukningen för säkerhetskopiering. Om du till exempel har etablerat 4 TB datalagring i ett hypotetiskt scenario får du 4 TB ledigt lagringsutrymme för säkerhetskopiering. Om du använder totalt 5,8 TB lagringsutrymme för säkerhetskopiering visar Azure-fakturan endast 1,8 TB, eftersom du endast debiteras för extra lagringsutrymme för säkerhetskopiering som du har använt.

För hanterade instanser aggregeras den totala storleken på fakturerbar lagring av 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

Total fakturerbar lagring av säkerhetskopior debiteras i gigabyte per månad för varje region, enligt hastigheten för redundansen för lagring av säkerhetskopior som du har använt. Lagringsförbrukningen för säkerhetskopiering beror på arbetsbelastningen och storleken på enskilda databaser och hanterade instanser. Kraftigt ändrade databaser har större differentiella säkerhetskopieringar 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.

Som ett förenklat exempel kan du anta att en databas har ackumulerat 744 GB lagringsutrymme för säkerhetskopiering och att det här beloppet förblir konstant under en hel månad eftersom databasen är helt inaktiv. Om du vill konvertera den här kumulativa lagringsförbrukningen till användning per timme delar du upp den med 744,0 (31 dagar per månad gånger 24 timmar per dag). SQL Managed Instance rapporterar till Azure-faktureringspipelinen att databasen förbrukade 1 GB PITR-säkerhetskopiering varje timme, i konstant takt. Azure-fakturering 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 gigabyte per månad i din region.

Här är ett annat exempel. Anta att samma inaktiva databas har bevaringstiden ökats från 7 dagar till 14 dagar i mitten av månaden. Den här ökningen resulterar i en fördubbling av den totala lagringen av säkerhetskopior till 1 488 GB. SQL Managed Instance skulle rapportera 1 GB användning i timmar 1 till 372 (den första halvan av månaden). Det skulle rapportera användningen som 2 GB för timmar 373 till 744 (den andra halvan av månaden). Den här användningen aggregeras till en slutfaktura på 1 116 GB per månad. Kvarhållningskostnaderna ökar inte omedelbart. De ökar gradvis varje dag eftersom säkerhetskopiorna växer tills de når den maximala kvarhållningsperioden på 14 dagar.

Faktiska scenarier för säkerhetskopieringsfakturering är mer komplexa. Eftersom ändringshastigheten i databasen beror på arbetsbelastningen och varierar över tid varierar även storleken på varje differentiell säkerhetskopiering och loggsäkerhetskopiering. Timförbrukningen för lagring av säkerhetskopior varierar beroende på detta.

Varje differentiell säkerhetskopia innehåller också alla ändringar som gjorts i databasen sedan den senaste fullständiga säkerhetskopieringen. Så ökar den totala storleken på alla differentiella säkerhetskopior gradvis under en vecka. Sedan sjunker den kraftigt efter att en äldre uppsättning fullständiga, differentiella säkerhetskopieringar och loggsäkerhetskopieringar har åldrats.

Anta till exempel att en tung skrivaktivitet, till exempel återskapande av index, körs strax efter att en fullständig säkerhetskopia har slutförts. De ändringar som indexet återskapar kommer sedan att inkluderas:

  • Säkerhetskopior av transaktionsloggen som togs under ombyggnationen.
  • I nästa differentiella säkerhetskopia.
  • I varje differentiell säkerhetskopia som tas fram till dess nästa fullständiga säkerhetskopiering sker.

För att minska storleken på alla differentiella säkerhetskopior höjs alltför stora differentiella säkerhetskopior som överskrider 750 GB och blir lika med 75% av databasstorleken till fullständiga säkerhetskopior, om den senaste fullständiga säkerhetskopieringen gjordes för mer än 24 timmar sedan.

Övervaka kostnader

Om du vill förstå kostnaderna för lagring av säkerhetskopior går du till Cost Management + Fakturering i Azure-portalen. Välj Cost Managementoch välj sedan Kostnadsanalys. Välj önskad prenumeration för Omfångoch filtrera sedan efter den tidsperiod och tjänst som du är intresserad av enligt följande:

  1. Lägg till ett filter för Tjänstnamn.

  2. I listrutan väljer du sql managed instance för en hanterad instans.

  3. Lägg till ytterligare ett filter för underkategorin Meter.

  4. Om du vill övervaka kostnader för PITR-säkerhetskopiering, välj i listrutan säkerhetskopieringslagring för hanterade instanser för PITR. Mätare visas endast om det förekommer förbrukning av lagringsutrymme för säkerhetskopiering.

    Om du vill övervaka kostnaderna för LTR-säkerhetskopiering går du till listrutan och väljer sql managed instance – ltr backup storage. Mätare visas endast om lagringsförbrukningen för säkerhetskopiering finns.

Storage och beräkning underkategorier kan också intressera dig, men de är inte associerade med kostnader för lagring av säkerhetskopior.

Skärmbild som visar en analys av kostnaderna för lagring av säkerhetskopior.

Viktig

Mätare är endast synliga för räknare som används för närvarande. Om en räknare inte är tillgänglig är det troligt att kategorin inte används för närvarande. Till exempel kommer hanterade instansräknare inte att finnas för kunder som inte har någon hanterad instans installerad. På samma sätt visas inte lagringsräknare för resurser som inte förbrukar lagring. Om det inte finns någon förbrukning av PITR- eller LTR-säkerhetskopieringslagring visas inte dessa mätare.

Krypterade säkerhetskopior

Om databasen krypteras med TDE krypteras säkerhetskopior 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 Managed Instance.

Microsoft ansvarar fullt ut för att behålla och rotera nycklar för databaser med tjänsthanterade nycklar (SMK). Säkerhetskopior, antingen PITR eller LTR, som hämtas från instanser som har TDE med SMK aktiverat kan återställas av Microsoft.

Automatiska säkerhetskopieringar som lagras i Azure-hanterade lagringskonton krypteras automatiskt av Azure Storage. Läs mer om Azure Storage-kryptering för vilande data.

Säkerhetskopieringsintegritet

Alla databassäkerhetskopior tas med alternativet CHECKSUM för att ge ytterligare integritet. Automatisk testning av automatiserade databassäkerhetskopior av Azure SQL-teknikteamet är för närvarande inte tillgängligt för Azure SQL Managed Instance. Schemalägg återställning av testsäkerhetskopior och kör DBCC CHECKDB på dina databaser i SQL Managed Instance med hänsyn till din arbetsbelastning.

Även om systemet inte verifierar säkerhetskopiornas integritet finns det fortfarande ett inbyggt skydd för dina säkerhetskopior som varnar Microsoft om det finns ett problem med säkerhetskopieringstjänsten. Dessutom stöder Microsoft dig om ett problem uppstår med en säkerhetskopia, till exempel om en fullständig säkerhetskopia inte tas, säkerhetskopieringstjänsten har fastnat, en loggsäkerhetskopia är slut på serviceavtalet eller om säkerhetskopieringens maskinvara eller programvara är skadad.

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

Om du har krav på datahemvist som kräver att du behåller alla dina data i en enda Azure-region kanske du vill framtvinga zonredundanta eller lokalt redundanta säkerhetskopieringar för din SQL-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 för 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.

Inbyggd redundanspolicy för säkerhetskopieringslagring

Om du vill tillämpa krav på datahemvist på organisationsnivå kan du använda Azure-portalen eller Azure PowerShellför att tilldela policyer till en prenumeration. Om du till exempel tilldelar följande inbyggda princip på prenumerations- eller resursgruppsnivå kan användare i prenumerationen inte skapa en hanterad instans med geo-redundant lagring av säkerhetskopiering via Azure-portalen eller Azure PowerShell: 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 Managed Instance finns i principreferensen.

Viktig

Azure-principer tillämpas inte när du skapar en databas via T-SQL. Om du vill framtvinga datahemvist när du skapar en databas med hjälp av T-SQL använda LOCAL eller ZONE som indata till parametern BACKUP_STORAGE_REDUNDANCY i instruktionen CREATE DATABASE.

Efterlevnad

Om standardkvarhållningen inte uppfyller dina efterlevnadskrav kan du ändra PITR-kvarhållningsperioden. Mer information finns i Ändra kvarhållningsperioden för PITR-säkerhetskopia.

Not

Artikeln Ändra inställningar för automatisk säkerhetskopiering innehåller anvisningar om hur du tar bort personliga data från enheten eller tjänsten och kan användas för att stödja dina skyldigheter enligt GDPR. Allmän information om GDPR finns i avsnittet GDPR i Microsoft Trust Center och avsnittet GDPR i Service Trust-portalen.

Nästa steg