Automatiserade säkerhetskopieringar i Azure SQL Database

Gäller för: Azure SQL-databas

Den här artikeln beskriver funktionen för automatisk säkerhetskopiering för Azure SQL Database.

Information om hur du ändrar inställningar för säkerhetskopiering 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 en säkerhetskopia av databasen?

Databassäkerhetskopior är en viktig del av en strategi för affärskontinuitet och haveriberedskap, eftersom de skyddar dina data från skador eller borttagning. Dessa säkerhetskopior aktiverar databasåterställning 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 (LTR) för både enkla databaser och pooldatabaser.

För andra tjänstnivåer än Hyperskala använder Azure SQL Database SQL Server motorteknik för att säkerhetskopiera och återställa data. Hyperskala-databaser använder säkerhetskopiering och återställning baserat på ögonblicksbilder av lagring. Med traditionell SQL Server säkerhetskopieringsteknik har större databaser långa säkerhetskopierings-/återställningstider. Med hjälp av ögonblicksbilder ger Hyperskala funktioner för omedelbar säkerhetskopiering och snabb återställning oavsett databasstorlek. Mer information finns i Hyperskala-säkerhetskopieringar.

Säkerhetskopieringsfrekvens

Azure SQL Database skapar:

Den exakta 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.

Hyperskala-arkitekturen kräver inte fullständiga säkerhetskopior, differentiella säkerhetskopior eller loggsäkerhetskopior. Mer information finns i Hyperskala-säkerhetskopieringar.

Redundans för säkerhetskopieringslagring

Som standard lagrar Azure SQL Database säkerhetskopior i geo-redundanta lagringsblobar som replikeras till en länkad region. Geo-redundans skyddar mot avbrott som påverkar lagring av säkerhetskopior i den primära regionen. Du kan också återställa dina databaser i en annan region i händelse av ett regionalt avbrott.

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 lagring av säkerhetskopior från standard geo-redundant lagring till andra typer av lagring som håller dina data inom regionen. Den konfigurerade redundansen för lagring av säkerhetskopior tillämpas på både kortsiktig kvarhållning (STR) och LTR-säkerhetskopior. Mer information om lagringsredundans finns i Dataredundans.

Du kan konfigurera redundans för lagring av säkerhetskopior när du skapar databasen och du kan uppdatera den vid ett senare tillfälle. De ändringar som du gör i en befintlig databas gäller endast för framtida säkerhetskopior. När du har uppdaterat redundansen för lagring av säkerhetskopior för en befintlig databas kan det ta upp till 48 timmar innan ändringarna tillämpas.

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

  • 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 lagringsalternativet, men vi rekommenderar det inte för program som kräver återhämtning vid regionala avbrott eller en garanti för hög datahå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 endast tillgänglig i vissa regioner.

    Diagram som visar alternativet zonredundant lagring (ZRS).

  • Geo-redundant lagring (GRS): Kopierar dina säkerhetskopior synkront tre gånger inom 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 den kopplade sekundära regionen.

    Resultatet är:

    • Tre synkrona kopior i den primära regionen.
    • Tre synkrona kopior i den parkopplade regionen som kopierades från den primära regionen till den sekundära regionen asynkront.

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

Varning

  • Geo-återställning inaktiveras så snart en databas uppdateras för att använda lokalt redundant eller zonredundant lagring.
  • Diagrammen för 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.
  • Redundans för lagring av säkerhetskopior för Hyperskala-databaser kan bara anges när de skapas. Du kan inte ändra den här inställningen när resursen har etablerats. Om du vill uppdatera redundansinställningarna för lagring av säkerhetskopior för en befintlig Hyperskala-databas med minsta stilleståndstid använder du aktiv geo-replikering. Du kan också använda databaskopiering. Läs mer i Hyperskala-säkerhetskopieringar och lagringsredundans.

Användning av säkerhetskopiering

Du kan använda automatiskt skapade säkerhetskopior i följande scenarier:

  • Återställ en befintlig databas till en tidpunkt inom kvarhållningsperioden med hjälp av Azure Portal, Azure PowerShell, Azure CLI eller REST-API:et. Den här åtgärden skapar en ny databas på samma server som den ursprungliga databasen, men den 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 och byta namn på den återställde databasen till det ursprungliga databasnamnet. I stället för att ta bort den ursprungliga databasen kan du byta namn på den och sedan byta namn på den återställde databasen till det ursprungliga databasnamnet.

  • Återställ en borttagen databas till en tidpunkt inom kvarhållningsperioden, inklusive tidpunkten för borttagningen. Den borttagna databasen kan bara återställas på samma server där du skapade den ursprungliga databasen. Innan du tar bort en databas tar tjänsten en slutlig säkerhetskopia 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 ett regionalt avbrott när du inte kan komma åt databasen eller säkerhetskopiorna i den primära regionen. Den skapar en ny databas på alla befintliga servrar i valfri Azure-region.

    Viktigt

    Geo-återställning är endast tillgängligt för databaser som har konfigurerats med geo-redundant lagring av säkerhetskopior. 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 lagring av säkerhetskopior.

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

Återställa funktioner

Den här tabellen sammanfattar funktionerna i återställning till tidpunkt (PITR),geo-återställning och långsiktig kvarhållning.

Säkerhetskopieringsegenskap  PITR Geo-återställning LTR
Typer av SQL-säkerhetskopiering Full, differential, log. Replikerade kopior av PITR-säkerhetskopior. Endast fullständiga säkerhetskopior.
Mål för återställningspunkt (RPO)  10 minuter, baserat på beräkningsstorlek och mängden databasaktivitet.   Upp till 1 timme baserat på geo-replikering.*  En vecka (eller användarens princip).
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. Läs mer i Återställning Återställningen tar vanligtvis mindre än 12 timmar men kan ta längre tid beroende på storlek och aktivitet. Läs mer i Återställning. Återställningen tar vanligtvis mindre än 12 timmar men kan ta längre tid beroende på storlek och aktivitet. Läs mer i Återställning.
Kvarhållning 7 dagar som standard kan konfigureras upp till 35 dagar.  Aktiverat som standard, samma som källa.** Inte aktiverat som standard. Kvarhållningen är upp till 10 år.
Azure Storage   Geo-redundant som standard. Du kan också konfigurera zonredundant eller lokalt redundant lagring. Tillgängligt när redundans för PITR-säkerhetskopieringslagring är inställt på geo-redundant. Inte tillgängligt när PITR-säkerhetskopieringslagring är zonredundant eller lokalt redundant.  Geo-redundant som standard. Du kan konfigurera zonredundant eller lokalt redundant lagring.
Återställa en ny databas i samma region Stöds Stöds  Stöds
Å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öds inte Stöds inte*** Stöds inte***
Återställa via Azure Portal Ja Ja Ja
Återställa via PowerShell Ja Ja Ja
Återställa via Azure CLI Ja Ja Ja

* För affärskritiska program som kräver stora databaser och måste säkerställa affärskontinuitet använder du grupper för automatisk redundans.

** Alla PITR-säkerhetskopior lagras på geo-redundant lagring som standard, så geo-återställning är aktiverat som standard.

Lösningen är att återställa till en ny server och använda Resource Move för att flytta servern till en annan prenumeration eller använda en databaskopia mellan prenumerationer.

Å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 utforska konfigurations- och återställningsåtgärder för säkerhetskopiering med hjälp av följande exempel.

Åtgärd Azure Portal Azure CLI Azure PowerShell
Ändra kvarhållning av säkerhetskopior SQL Database
SQL-hanterad instans
SQL Database
SQL-hanterad instans
SQL Database
SQL-hanterad instans
Ändra långsiktig kvarhållning av säkerhetskopior SQL Database
SQL-hanterad instans
SQL Database
SQL-hanterad instans
SQL Database
SQL-hanterad instans
Återställa en databas från en tidpunkt SQL Database
SQL-hanterad instans
SQL Database
SQL-hanterad instans
SQL Database
SQL-hanterad instans
Återställa en borttagen databas SQL Database
SQL-hanterad instans
SQL Database
SQL-hanterad instans
SQL Database
SQL-hanterad instans

Schemaläggning av säkerhetskopiering

Den första fullständiga säkerhetskopian schemaläggs omedelbart efter att en ny databas har skapats eller återställts. Den här 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, som vanligtvis är större än en ny databas.

Efter den första fullständiga säkerhetskopieringen schemaläggs och hanteras alla ytterligare säkerhetskopior automatiskt. Den exakta tiden för alla databassäkerhetskopieringar fastställs av SQL Database-tjänsten eftersom den balanserar den övergripande systemarbetsbelastningen. Du kan inte ändra schemat för säkerhetskopieringsjobb eller inaktivera dem.

Viktigt

  • För en ny, återställd eller kopierad databas blir återställningsfunktionen för tidpunkt tillgänglig när den första säkerhetskopieringen av transaktionsloggen som följer den första fullständiga säkerhetskopian skapas.
  • Hyperskala-databaser skyddas omedelbart efter att de har skapats, till skillnad från andra databaser där den första säkerhetskopieringen tar tid. Skyddet är omedelbart även om Hyperskala-databasen skapades med en stor mängd data via kopiering eller återställning. Mer information finns i Automatiserade hyperskalningssäkerhetskopior.

Lagringsförbrukning för säkerhetskopiering

Med SQL Server säkerhetskopierings- 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.

Azure SQL Database schemalägger 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äkerhetskopior, 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 under kvarhållningsperioden. Det måste också finnas en oavbruten kedja av differentiella säkerhetskopieringar och transaktionsloggsäkerhetskopior från den fullständiga säkerhetskopian fram till nästa fullständiga säkerhetskopiering.

Hyperskala-databaser använder en annan mekanism för schemaläggning av säkerhetskopiering. Mer information finns i Schemaläggning av hyperskala för säkerhetskopiering.

Säkerhetskopior som inte längre behövs för att tillhandahålla PITR-funktioner tas bort automatiskt. Eftersom differentiella säkerhetskopior och loggsäkerhetskopieringar 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 säkerhetskopior för att minska förbrukningen och kostnaderna för lagring av säkerhetskopior. Det genomsnittliga komprimeringsförhållandet 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.

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

Viktigt

Säkerhetskopior av en databas bevaras för att tillhandahålla PITR även om databasen har tagits bort. Även om borttagning och återskapande av en databas kan spara lagrings- och beräkningskostnader kan det öka kostnaderna för lagring av säkerhetskopior. Anledningen är att tjänsten behåller säkerhetskopior för varje borttagen databas varje gång den tas bort.

Övervaka förbrukning

För vCore-databaser i Azure SQL Database rapporteras lagringen som varje typ av säkerhetskopiering (fullständig, differentiell och logg) använder i databasövervakningsfönstret som ett separat mått. Följande skärmbild visar hur du övervakar lagringsförbrukningen för säkerhetskopior för en enskild databas.

Skärmbild som visar val för övervakning av förbrukningen av säkerhetskopiering av databaser i Azure Portal.

Anvisningar om hur du övervakar förbrukningen i Hyperskala finns i Övervaka förbrukning av hyperskala för säkerhetskopiering.

Finjustera förbrukningen av lagring av säkerhetskopior

Förbrukning av lagring av säkerhetskopior upp till den maximala datastorleken för en databas debiteras inte. Överförbrukning av lagringsutrymme för säkerhetskopiering 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 lagring av säkerhetskopior:

  • Minska kvarhållningsperioden för säkerhetskopior till det minsta möjliga för dina behov.
  • Undvik att utföra stora skrivåtgärder, till exempel återskapade index, oftare än du behöver.
  • Överväg att använda grupperade kolumnlagringsindex och följa relaterade metodtips för stora datainläsningsåtgärder. Överväg också att minska antalet icke-klustrade index.
  • På tjänstnivån Generell användning är den etablerade datalagringen billigare än priset för lagring av säkerhetskopior. Om du kontinuerligt har höga kostnader för extra lagring av säkerhetskopior 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 eller tillfälliga data.
  • Använd lokalt redundant lagring av säkerhetskopior när det är möjligt (till exempel utvecklings-/testmiljöer).

Kvarhållningsperiod för säkerhetskopior

Azure SQL Database tillhandahåller 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 ger säkerhetskopior för olika efterlevnadskrav.

Kortsiktig kvarhållning

För alla nya, återställde och kopierade databaser behåller Azure SQL Database tillräckliga säkerhetskopior för att tillåta PITR under de senaste 7 dagarna som standard. Tjänsten tar regelbundna fullständiga säkerhetskopior, differentiella säkerhetskopior och loggsäkerhetskopior för att säkerställa att databaser kan återställas till valfri tidpunkt inom den kvarhållningsperiod som definierats för databasen.

Kortsiktig kvarhållning av säkerhetskopior på 1 till 35 dagar för Hyperskala-databaser är nu i förhandsversion. Mer information finns i Hantera kvarhållning av säkerhetskopior i Hyperskala.

Differentiella säkerhetskopior kan konfigureras för att ske antingen en gång på 12 timmar eller en gång på 24 timmar. En differentiell säkerhetskopieringsfrekvens på 24 timmar kan öka tiden som krävs för att återställa databasen, jämfört med 12-timmarsfrekvensen. I modellen med virtuella kärnor är standardfrekvensen för differentiella säkerhetskopior en gång på 12 timmar. I DTU-modellen är standardfrekvensen en gång på 24 timmar.

Du kan ange redundansalternativet för säkerhetskopieringslagring för STR när du skapar databasen och sedan ändra det vid ett senare tillfälle. Om du ändrar redundansalternativet för säkerhetskopiering när databasen har skapats använder nya säkerhetskopior det nya redundansalternativet. Säkerhetskopior som gjorts med föregående redundansalternativ i STR flyttas eller kopieras inte. De finns kvar i det ursprungliga lagringskontot tills kvarhållningsperioden går ut, vilket kan vara 1 till 35 dagar.

Förutom basic-databaser kan du ändra kvarhållningsperioden för säkerhetskopior för varje aktiv databas inom intervallet 1 till 35 dagar. Enligt beskrivningen i förbrukning av säkerhetskopieringslagring kan säkerhetskopior som lagras för att aktivera PITR vara äldre än kvarhållningsperioden. 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.

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. Du kan inte ändra kvarhållningsperioden för säkerhetskopior för en borttagen databas.

Viktigt

Om du tar bort en server tas även alla databaser på den servern bort och kan inte återställas. Du kan inte återställa en borttagen server. Men om du har konfigurerat långsiktig kvarhållning för en databas tas inte LTR-säkerhetskopior bort. Du kan sedan använda dessa säkerhetskopior för att återställa databaser på en annan server 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

För SQL Database kan du konfigurera fullständiga LTR-säkerhetskopieringar 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 fullständiga säkerhetskopior varje vecka, månad och/eller år. Frekvensen beror på principen. Om du till exempel anger W=0, M=1 skapas en LTR-kopia varje månad. Mer information om LTR finns i Långsiktig kvarhållning.

Om du uppdaterar redundansen för lagring av säkerhetskopior för en befintlig databas tillämpas ändringen endast på efterföljande säkerhetskopior som görs i framtiden och inte för befintliga säkerhetskopior. Alla befintliga LTR-säkerhetskopior för databasen fortsätter att finnas i den befintliga lagringsbloben. Nya säkerhetskopior replikeras baserat på den konfigurerade redundansen för lagring av säkerhetskopior.

Lagringsförbrukningen beror på den valda frekvensen och kvarhållningsperioderna för LTR-säkerhetskopior. Du kan beräkna kostnaden för LTR-lagring med LTR-priskalkylatorn.

Kostnader för lagring av säkerhetskopior

Priset för lagring av säkerhetskopior varierar och beror på din inköpsmodell (DTU eller virtuell kärna), valt redundansalternativ för säkerhetskopieringslagring och region. Lagring av säkerhetskopior debiteras baserat på gigabyte som förbrukas per månad, till samma pris för alla säkerhetskopior.

Redundans för lagring av säkerhetskopior 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

Priser finns på prissättningssidan för Azure SQL Database.

Anteckning

En Azure-faktura visar bara den överskjutande lagringsförbrukningen för säkerhetskopior, inte hela förbrukningen för lagring av säkerhetskopior. 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 bara 1,8 TB, eftersom du endast debiteras för överflödig lagring av säkerhetskopior som du har använt.

DTU-modell

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

vCore-modellen

Azure SQL Database beräknar din totala fakturerbara lagring av säkerhetskopior som ett ackumulerat värde för alla säkerhetskopierade filer. Varje timme rapporteras det här värdet till Azure-faktureringspipelinen. Pipelinen aggregerar den här timanvändningen för att få din förbrukning av lagring av säkerhetskopior i slutet av varje månad.

Om en databas tas bort minskar lagringsförbrukningen för säkerhetskopior 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.

Kostnaden för lagring av säkerhetskopior beräknas på olika sätt för Hyperskala-databaser. Mer information finns i Kostnader för lagring av hyperskala för säkerhetskopiering.

För enskilda databaser tillhandahålls en lagringsmängd för säkerhetskopior som motsvarar 100 procent av databasens maximala datalagringsstorlek utan extra kostnad. Följande ekvation används för att beräkna den totala fakturerbara lagringsanvändningen för säkerhetskopiering:

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

För elastiska pooler tillhandahålls en lagringsmängd för säkerhetskopior som motsvarar 100 procent av den maximala datalagringen för poolens lagringsstorlek utan extra kostnad. För pooldatabaser aggregeras den totala storleken på fakturerbar lagring av säkerhetskopior 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

Det totala fakturerbara lagringsutrymmet för säkerhetskopiering debiteras i gigabyte per månad enligt den redundansfrekvens för säkerhetskopieringslagring som du har använt. Den här lagringsförbrukningen för säkerhetskopior beror på arbetsbelastningen och storleken på enskilda databaser, elastiska pooler och hanterade instanser. Databaser som ändras kraftigt 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.

Ett förenklat exempel är att anta att en databas har ackumulerat 744 GB lagringsutrymme för säkerhetskopior 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 här kumulativa lagringsförbrukningen till användning per timme dividerar du den med 744,0 (31 dagar per månad gånger 24 timmar per dag). SQL Database rapporterar 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 gigabyte per månad i din region.

Här är ett annat exempel. Anta att kvarhållningen för samma inaktiva databas har ökat 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 Database skulle rapportera 1 GB användning för 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 skulle aggregeras till en slutfaktura på 1 116 GB per månad.

Faktureringsscenarier för faktisk säkerhetskopiering är mer komplexa. Eftersom ändringsfrekvensen i databasen beror på arbetsbelastningen och varierar över tid varierar även storleken på varje differentiell säkerhetskopiering och loggsäkerhetskopiering. Den timvisa förbrukningen av lagring av säkerhetskopior varierar i enlighet med detta.

Varje differentiell säkerhetskopia innehåller också alla ändringar som gjorts i databasen sedan den senaste fullständiga säkerhetskopieringen. Därför ö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äkerhetskopior har åldrats.

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

  • I de säkerhetskopior av transaktionsloggen som tagits under återskapandetiden.
  • I nästa differentiella säkerhetskopia.
  • I varje differentiell säkerhetskopiering som görs tills nästa fullständiga säkerhetskopiering sker.

I det sista 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 alltför stor. Detta minskar storleken på alla differentiella säkerhetskopior fram till följande fullständiga säkerhetskopiering.

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

Övervaka kostnader

Om du vill förstå kostnaderna för lagring av säkerhetskopior går du till Kostnadshantering + fakturering i Azure Portal. Välj Cost Management och sedan Kostnadsanalys. Välj önskad prenumeration för Omfång och filtrera sedan för 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 database för en enskild databas eller en elastisk databaspool.

  3. Lägg till ytterligare ett filter för mätarunderkategori.

  4. Om du vill övervaka kostnader för PITR-säkerhetskopiering går du till listrutan och väljer lagring av säkerhetskopiering med en enda/elastisk pool för en enskild databas eller en elastisk databaspool. Mätare visas endast om lagringsförbrukningen för säkerhetskopior finns.

    Om du vill övervaka kostnaderna för LTR-säkerhetskopiering väljer du i listrutan lagring av säkerhetskopior för en enskild databas eller en elastisk databaspool. Mätare visas endast om lagringsförbrukningen för säkerhetskopior finns.

Underkategorierna Lagring och beräkning kan också intressera dig, men de är inte kopplade till kostnader för lagring av säkerhetskopior.

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

Viktigt

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. Lagringsräknare visas till exempel inte för resurser som inte förbrukar lagringsutrymme. Om det inte finns någon förbrukning av PITR- eller LTR-säkerhetskopieringslagring visas inte dessa mätare.

Mer information finns i Azure SQL Database cost management (Kostnadshantering för Azure SQL Database).

Krypterade säkerhetskopior

Om databasen krypteras med transparent datakryptering (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 Database.

Säkerhetskopieringsintegritet

Azure SQL:s utvecklingsteam testar regelbundet återställningen av automatiserade säkerhetskopior av databaser. Vid återställning till tidpunkt får databaser även DBCC CHECKDB-integritetskontroller.

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

Alla säkerhetskopior av databasen görs med alternativet CHECKSUM för att ge ytterligare säkerhetskopia integritet.

Efterlevnad

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

Anteckning

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 GDPR-avsnittet i Microsoft Trust Center och GDPR-avsnittet i Service Trust Portal.

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-databas 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 redundans för lagring av säkerhetskopior

Om du vill framtvinga krav på datahemvist på organisationsnivå kan du tilldela principer till en prenumeration med hjälp av Azure Portal eller Azure PowerShell. Om du till exempel tilldelar följande inbyggda princip kan användare i prenumerationen inte skapa en databas med geo-redundant lagring av säkerhetskopior via Azure Portal eller Azure PowerShell: SQL Database bör undvika att använda GRS-säkerhetskopieringsredundans.

En fullständig lista över inbyggda principdefinitioner för SQL Database finns i principreferensen.

Viktigt

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

Nästa steg