Automatiserade säkerhetskopieringar i Azure SQL Database

gäller för:Azure SQL Database

• Azure SQL Database
• Azure SQL Managed Instance

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

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 en databassäkerhetskopia?

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. 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 Hyperscale 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:

• Fullständiga säkerhetskopieringar varje vecka.
• Differentiella säkerhetskopior var 12:e eller 24:e timme.
• säkerhetskopieringar av transaktionsloggar ungefär var 10:e minut.

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äkerhetskopieringar, differentiella säkerhetskopieringar och transaktionsloggar som måste återställas.

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

Redundans för säkerhetskopieringslagring

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.

Som standard lagrar nya databaser i Azure SQL Database säkerhetskopior i geo-redundanta lagringsblobar som replikeras till en parkopplad region. 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 dina databaser i en annan region i händelse av ett regionalt avbrott.

Azure-portalen innehåller en arbetsbelastningsmiljö alternativ som hjälper till att förinställa vissa konfigurationsinställningar. De här inställningarna kan åsidosättas. Det här alternativet gäller endast portalen Skapa SQL-databas.

• Om du väljer utvecklingsmiljö arbetsbelastning, ställs alternativet för redundans för säkerhetskopieringslagring in på att använda lokalt redundant lagring. Lokalt redundant lagring medför mindre kostnad och är lämplig för förproduktionsmiljöer som inte kräver redundans för zon- eller geo-replikerad lagring.
• Om du väljer Produktionsmiljö arbetsbelastning anger du Redundans för säkerhetskopieringslagring till geo-redundant lagring, standard.
• Alternativet arbetsbelastningsmiljö ändrar även den inledande inställningen för beräkning, även om detta kan åsidosättas. I annat fall påverkar arbetsbelastningsmiljöalternativet inte licensering eller andra inställningar för databaskonfiguration.

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. Den konfigurerade redundansen för lagring av säkerhetskopior tillämpas på både kortsiktiga kvarhållningssäkerhetskopior (STR) och LTR-säkerhetskopior. Mer information om lagringsredundans finns i Dataredundans.

Du kan konfigurera redundans för säkerhetskopieringslagring 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 säkerhetskopiering av 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ä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 lagringsalternativet, men vi rekommenderar det inte för program som kräver återhämtning till regionala avbrott eller en garanti för hög datahållbarhet.

  

• 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.

  

• 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.
  • Tre synkrona kopior i den kopplade regionen kopierades över asynkront från den primära regionen till den sekundära regionen.

  

• Geo-Zone redundant lagring (GZRS): Geo-zone-redundant lagring (GZRS) kombinerar den höga tillgänglighet som tillhandahålls av redundans mellan tillgänglighetszoner (ZRS) med skydd mot regionala avbrott som tillhandahålls av geo-replikering (GRS). Kopierar dina säkerhetskopior synkront över tre Azure-tillgänglighetszoner i den primära regionen och asynkront tre gånger till en enda fysisk plats i den kopplade sekundära regionen.

  Microsoft rekommenderar att du använder GZRS för program som kräver maximal konsekvens, hållbarhet och tillgänglighet, utmärkta prestanda och motståndskraft för haveriberedskap.

  Resultatet är:

  • Tre synkrona kopior över tillgänglighetszoner i den primära regionen.

  • Tre synkrona kopior i den kopplade regionen, asynkront kopierade från den primära regionen till den sekundära regionen.

    Följande diagram visar hur dina data replikeras med GZRS eller RA-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.
• 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 säkerhetskopiering av lagring för en befintlig Hyperskala-databas med minsta stilleståndstid använder du aktiv geo-replikering. Alternativt kan du använda databaskopia . Läs mer i Hyperskala-säkerhetskopieringar och lagringsredundans.

Säkerhetskopieringsanvändning

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-portalen, 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 också 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 borttagningstiden. 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ä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 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.

  Viktig

  Geo-återställning är endast tillgängligt för databaser som har konfigurerats med geo-redundant säkerhetskopieringslagring. 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älla en databas från en specifik långsiktig säkerhetskopia av en enskild 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-portalen, 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 Långsiktig kvarhållning.

Varning

När du återställer en databas och lagringsredundansen för källsäkerhetskopior konfigureras som Geo-Zone Redundant Storage (GZRS) ärvs lagringskonfigurationen för källsäkerhetskopiering av den nya databasen om redundanskonfigurationen för säkerhetskopiering av lagring för måldatabasen inte uttryckligen anges. Detta omfattar alla återställningsåtgärder, till exempel återställning till en specifik tidpunkt, databaskopiering, geoåterställning, återställning från en långsiktig backup. Om azure-målregionen inte stöder den specifika redundansen för lagring av säkerhetskopior under den här åtgärden misslyckas återställningsåtgärden med lämpligt felmeddelande. Detta kan minimeras genom att uttryckligen ange tillgängliga lagringsalternativ för regionen.

Automatiska säkerhetskopieringar på sekundära repliker

Automatiska säkerhetskopior hämtas nu från en sekundär replik på tjänstnivån Affärskritisk. Eftersom data replikeras mellan SQL Server-processer på varje nod, tar säkerhetskopieringstjänsten säkerhetskopieringen från de icke läsbara sekundära replikerna. Den här designen säkerställer att den primära repliken förblir dedikerad till din huvudsakliga arbetsbelastning och att den läsbara sekundära repliken är dedikerad till läsintensiva arbetsbelastningar. Automatiska säkerhetskopieringar på tjänstenivån Affärskritisk tas från den sekundära replikan för det mesta. Om en automatisk säkerhetskopiering misslyckas på en sekundär replik tar säkerhetskopieringstjänsten säkerhetskopian från den primära repliken.

Automatiska säkerhetskopieringar på sekundära repliker:

• Är aktiverade som standard.
• Ingår utan extra kostnad utöver priset på tjänstnivån.
• Ge bättre prestanda och förutsägbarhet till tjänstnivån Affärskritisk.

Observera

• Skapa ett Microsoft-supportärende för att inaktivera funktionen för din instans.

Återställa förmågor och funktioner

Den här tabellen sammanfattar kapaciteter och funktioner för återställning till tidpunkt (PITR), geo-återställningoch långsiktig kvarhållning.

Information om återställningstider finns i RTO och RPO.

Säkerhetskopieringsattribut	PITR	Geo-återställning	LTR
typer av SQL-säkerhetskopiering	Full, differentiell, logg.	De senaste geo-replikerade kopiorna av PITR-säkerhetskopior.	Endast de fullständiga säkerhetskopiorna.
kvarhållning	7 dagar som standard kan konfigureras mellan 1 och 35 dagar (förutom Grundläggande databaser, som kan konfigureras mellan 1 och 7 dagar).	Aktiverad som standard, samma som källan.2	Inte aktiverat som standard. Kvarhållningen är upp till 10 år.
Azure Storage	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 standardinstä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
Återställa en ny databas i samma region	Stödd	Understödd	Stöttad
Å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 inte3	Stöds inte3
Återställning via Azure-portalen	Ja	Ja	Ja
återställning via PowerShell	Ja	Ja	Ja
återställning 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 redundansgrupper.
² Alla PITR-säkerhetskopior lagras som standard på geo-redundant lagring, 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 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-databas SQL Managed Instance	SQL Database SQL Managed Instance	SQL Database SQL Managed Instance
Ändra långsiktig kvarhållning av säkerhetskopior	SQL Database SQL Managed Instance	SQL Database SQL Hanterad Instans	SQL Database SQL Managed Instance
Å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-databas SQL Managed Instance

Exportera en databas

Automatiska säkerhetskopieringar som görs av Azure-tjänsten är inte tillgängliga för nedladdning eller åtkomst direkt. De kan bara användas för återställningsåtgärder via Azure.

Det finns alternativ för att exportera en Azure SQL Database. När du behöver exportera en databas för arkivering eller för att flytta till en annan plattform kan du exportera databasschemat och data till en BACPAC- fil. En BACPAC-fil är en ZIP-fil med ett tillägg av BACPAC som innehåller metadata och data från databasen. En BACPAC-fil kan lagras i Azure Blob Storage eller i lokal lagring på en lokal plats och senare importeras tillbaka till Azure SQL Database, Azure SQL Managed Instanceeller en SQL Server-instans.

Du kan också importera eller exportera en Azure SQL Database med hjälp av en privat länk eller importera eller exportera en Azure SQL Database utan att tillåta att Azure-tjänster får åtkomst till servern.

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. Den här säkerhetskopieringen avslutas vanligtvis inom 30 minuter, men det kan ta längre tid när databasen är stor. Till exempel kan den första säkerhetskopieringen 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 tidpunkten för alla databassäkerhetskopior bestäms av SQL Database-tjänsten eftersom den balanserar den övergripande systemarbetsbelastningen. Du kan inte ändra schemat för säkerhetskopieringsjobb eller inaktivera dem.

Viktig

• För en ny, återställd eller kopierad databas blir funktionen för återställning till tidpunkt tillgänglig när den första säkerhetskopieringen av transaktionsloggen som följer på den första fullständiga säkerhetskopian skapas.
• Hyperskala-databaser skyddas omedelbart efter skapandet, 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. För att lära dig mer, granska Hyperskala automatiserade säkerhetskopieringar.

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.

Azure SQL Database schemalägger en fullständig säkerhetskopia 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 och transaktionsloggssäkerhetskopior från den fullständiga säkerhetskopian till nästa fullständiga säkerhetskopia.

Hyperskala-databaser använder en annan mekanism för schemaläggning av säkerhetskopiering. För mer information, se hyperskala-säkerhetskopieringsschemaläggning.

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 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 Database 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. Pipeline ansvarar för att samla in timvis användning för att beräkna din förbrukning vid varje månadsslut. 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 av en databas behålls 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 virtuella kärnor i Azure SQL Database rapporteras lagringen som varje typ av säkerhetskopiering (fullständig, differentiell och logg) använder i fönstret för databasövervakning som ett separat mått. Följande skärmbild visar hur du övervakar lagringsförbrukningen för säkerhetskopiering för en enskild databas.

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

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 lägsta för dina behov.
• Undvik att utfö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 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 Database 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 Database tillräckliga säkerhetskopior för att tillåta PITR under de senaste 7 dagarna som standard. Tjänsten utför regelbundna fullständiga säkerhetskopieringar, differentiella säkerhetskopieringar och loggsäkerhetskopior för att säkerställa att databaser kan återställas till valfri tidpunkt inom den kvarhållningsperiod som har definierats för databasen.

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 den tid 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 den 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äkerhetskopieringskopior som gjorts med föregående STR-redundansalternativ flyttas inte eller kopieras. De finns kvar i det ursprungliga lagringskontot tills kvarhållningsperioden går ut, vilket kan vara mellan 1 och 35 dagar.

Du kan ändra kvarhållningsperioden för säkerhetskopior för varje aktiv databas inom intervallet 1 till 35 dagar, med undantag för Grundläggande databaser, som kan konfigureras från 1 till 7 dagar. Enligt beskrivningen i Förbrukning av säkerhetskopieringslagringkan säkerhetskopieringar 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 kortsiktiga 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 för en onlinedatabas med sin specifika kvarhållningsperiod. Du kan inte ändra kvarhållningsperioden för säkerhetskopior för en borttagen databas.

Viktig

Om du tar bort en server tas även alla databaser på 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 långsiktiga kvarhållningssä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 fullständiga säkerhetskopior varje vecka, månad och/eller år. Frekvensen beror på principen. Om du till exempel anger W=0, M=1 skapar du 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å 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.

När du återställer en Hyperskala-databas från en LTR-säkerhetskopia inaktiveras lässkalningsegenskapen. För att aktivera, läs skalningen på den återställda databasen, och uppdatera sedan databasen efter att den har skapats. Du måste ange målet för servicenivå när du återställer från en LTR-säkerhetskopia.

Långsiktig kvarhållning kan aktiveras för Hyperskala-databaser som skapats eller migrerats från andra tjänstnivåer. Om du försöker aktivera LTR för en Hyperskala-databas där den ännu inte stöds får du följande fel: "Ett fel har uppstått när långsiktig kvarhållning av säkerhetskopior för den här databasen aktiveras. Kontakta Microsofts support för att aktivera långsiktig kvarhållning av säkerhetskopior." I det här fallet kontaktar du Microsofts support och skapar ett supportärende som du kan lösa.

Kostnader för lagring av säkerhetskopior

Priset för lagring av säkerhetskopior varierar och beror på din köpmodell (DTU eller virtuell kärna), valt alternativ för redundans för lagring av säkerhetskopiering och region. Lagring av säkerhetskopior debiteras baserat på gigabyte som förbrukas per månad, med samma hastighet för alla säkerhetskopior.

För prisinformation, se sidan Azure SQL Database-prissättning.

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.

DTU-modell

För databaser och elastiska pooler i DTU-modellen tillkommer ingen extra kostnad för PITR-säkerhetskopieringslagring för den standardkvarhållning som börjar vid 7 dagar och sträcker sig längre. Priset för PITR-säkerhetskopieringslagring är en del av databasen eller poolpriset.

Viktig

I DTU-modellen debiteras databaser och elastiska pooler för lagring av LTR-säkerhetskopior baserat på den faktiska lagring som förbrukas av LTR-säkerhetskopior.

vCore-modell

Azure SQL Database 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. 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.

Kostnaden för lagring av säkerhetskopior beräknas på olika sätt för Hyperskala-databaser. För mer information, se kostnader för säkerhetskopieringslagring i hyperskala.

För enskilda databaser tillhandahålls en lagringsmängd för säkerhetskopior som är lika med 100 procent av den maximala datalagringsstorleken för databasen 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äkerhetskopiering 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ä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

Totalt fakturerbart lagringsutrymme för säkerhetskopiering debiteras i gigabyte per månad enligt hastigheten för den redundans för säkerhetskopieringslagring som du har använt. Den här lagringsförbrukningen för säkerhetskopiering beror på arbetsbelastningen och storleken på enskilda databaser, elastiska pooler 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 har sådana databaser 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 Database 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 får sin kvarhållningstid ökad från 7 dagar till 14 dagar under 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 aggregeras till en slutfaktura på 1 116 GB per månad.

Faktiska faktureringsscenarier för säkerhetskopiering ä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äkerhetskopior och loggsäkerhetskopior har blivit för gamla.

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

• I säkerhetskopiorna av transaktionsloggen som tagits under återuppbyggnadsperioden.
• Vid nästa differentiella säkerhetskopia.
• I varje differentiell säkerhetskopia som görs fram till dess att nästa fullständiga säkerhetskopiering sker.

För 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 för stor. Detta minskar storleken på alla differentiella säkerhetskopior tills följande fullständiga säkerhetskopia.

Du kan övervaka den totala lagringsförbrukningen för säkerhetskopiering 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 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-databas för en enskild databas eller en elastisk databaspool.

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

4. För att övervaka kostnaderna för PITR-säkerhetskopieringar, välj i listrutan pitr-säkerhetskopieringslagring för en enskild databas eller en elastisk databaspool. Mätare visas endast om säkerhetskopieringslagring finns.

   Om du vill övervaka kostnaderna för LTR-säkerhetskopiering går du till listrutan och väljer ltr backup storage för en enskild databas eller en elastisk databaspool. Mätare visas endast om säkerhetskopieringslagring används.

Storage och beräkning underkategorier kan också intressera dig, men de är inte associerade med kostnader 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. Lagringsräknare visas till exempel inte för resurser som inte förbrukar lagring. Om det inte finns någon förbrukning av PITR- eller LTR-backuplagring visas inte dessa mätare.

Mer information finns i Kostnadshantering i Azure SQL Database.

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 Database.

Säkerhetskopieringsintegritet

På löpande basis testar Azure SQL-teknikteamet automatiskt återställningen av automatiserade databassäkerhetskopior. Vid återställning till en viss tidpunkt genomgår databaserna även DBCC CHECKDB-integritetskontroller.

Eventuella problem som upptäcks under en integritetskontroll 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 säkerhetskopians integritet.

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 standardkvarhållningen inte uppfyller dina efterlevnadskrav kan du ändra PITR-kvarhållningsperioden. För mer information, se Ändra kvarhållningsperioden för PITR-säkerhetskopiering.

Notis

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.

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äkerhetskopior 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 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.

Inbyggda policyer för säkerhetskopiering och lagringsredundans

Om du vill tillämpa krav på datahemvist på organisationsnivå kan du tilldela principer till en prenumeration med hjälp av Azure-portalen eller Azure PowerShell-.

Om du till exempel aktiverar principen "Azure SQL DB bör undvika att använda GRS-säkerhetskopiering" kan databaser inte skapas med standardlagringen som globalt redundant lagring, och användarna skulle hindras från att använda GRS med felmeddelandet "Konfigurera lagringskontotypen för säkerhetskopiering till "Standard_RAGRS" misslyckades när databasen skapades eller uppdaterades.

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

Viktig

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ända LOCAL eller ZONE som indata till parametern BACKUP_STORAGE_REDUNDANCY i instruktionen CREATE DATABASE.

Relaterat innehåll

• Mer information om andra lösningar för affärskontinuitet i SQL Database finns i Översikt över affärskontinuitet.
• 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 säkerhetskopior eller Återställa en databas till en tidpunkt med hjälp av PowerShell.
• Information om hur du konfigurerar, hanterar och återställer från långsiktig kvarhållning av automatiserade säkerhetskopior i Azure Blob Storage finns i Hantera långsiktig kvarhållning av säkerhetskopior.
• Information om Azure SQL Managed Instance finns i Automatiserade säkerhetskopieringar för SQL Managed Instance.