Automatiserade säkerhetskopieringar för Hyperskala-databaser

  • Artikel

Gäller för:Azure SQL Database

Den här artikeln förklarar funktionen för automatisk säkerhetskopiering med Hyperskala-databaser i Azure SQL Database.

Hyperskala-databaser använder en unik arkitektur med mycket skalbara lagrings- och beräkningsprestandanivåer. Hyperskala-säkerhetskopior är ögonblicksbildsbaserade och är nästan omedelbart. Loggsäkerhetskopior lagras i långsiktig Azure Storage under kvarhållningsperioden för säkerhetskopior.

En Hyperskala-arkitektur kräver inte fullständiga säkerhetskopieringar, differentiella säkerhetskopieringar eller loggsäkerhetskopior. Därför skiljer sig säkerhetskopieringsfrekvens, lagringskostnader, schemaläggning, lagringsredundans och återställningsfunktioner från andra databaser i Azure SQL Database.

Prestanda för säkerhetskopiering och återställning

Lagrings- och beräkningsseparation gör det möjligt för Hyperskala att push-överföra säkerhetskopierings- och återställningsåtgärder till lagringslagret för att eliminera resursförbrukningen på beräkningsrepliker. Databassäkerhetskopior påverkar inte prestandan för varken primära eller sekundära beräkningsrepliker.

Säkerhetskopierings- och återställningsåtgärder för Hyperskala-databaser är snabba oavsett datastorlek, eftersom de använder ögonblicksbilder av lagring. Säkerhetskopieringen är praktiskt taget omedelbar.

Du kan återställa en databas till valfri tidpunkt inom kvarhållningsperioden för säkerhetskopior genom att:

  1. Återgå till tillämpliga ögonblicksbilder av filer.
  2. Använda transaktionsloggar för att göra den återställde databasen transaktionsmässigt konsekvent.

Återställning är därför inte en storleksanpassad dataåtgärd som förblir densamma. Återställningen av en Hyperskala-databas inom samma Azure-region slutförs på några minuter i stället för timmar eller dagar, även för databaser med flera terabyte.

Om du ändrar lagringsredundansen när du utfärdar en återställning kan det leda till längre återställningstider eftersom återställningen är storleken på data, och därför är tiden proportionell mot databasens storlek.

När du skapar nya databaser genom att återställa en befintlig säkerhetskopia eller kopiera databasen kan du även dra nytta av beräknings- och lagringsavgränsningen i Hyperskala. Du kan skapa kopior i utvecklings- eller testsyfte, även för databaser med flera terabyte, på några minuter i samma region när du använder samma lagringstyp.

Kvarhållningsperiod för säkerhetskopior

Standardkvarhållningen på kort sikt av säkerhetskopior för Hyperskala-databaser är 7 dagar.

Kortsiktig kvarhållning av säkerhetskopior inom intervallet 1 till 35 dagar och långsiktig kvarhållning av säkerhetskopior (LTR) för Hyperskala-databaser är allmänt tillgänglig från och med september 2023. Mer information finns i Långsiktig kvarhållning – Azure SQL Database och Azure SQL Managed Instance.

Schemaläggning av säkerhetskopiering

Det finns ingen traditionell, fullständig säkerhetskopiering, differentiell säkerhetskopiering eller säkerhetskopiering för transaktionsloggar för Hyperskala-databaser. I stället tas regelbundna ögonblicksbilder av lagrade datafiler.

De genererade transaktionsloggarna behålls precis som för den konfigurerade kvarhållningsperioden. Vid återställningen tillämpas relevanta transaktionsloggposter på den återställde lagringsögonblicksbilden. Resultatet är en transaktionsmässigt konsekvent databas utan dataförlust från och med den angivna tidpunkten inom kvarhållningsperioden.

Övervaka lagringsförbrukning för säkerhetskopiering

I Hyperskala rapporterar Azure Monitor-mått följande förbrukningsinformation:

  • Lagringsstorlek för säkerhetskopiering av data (storlek på säkerhetskopiering av ögonblicksbilder)
  • Datalagringsstorlek (allokerad databasstorlek)
  • Lagringsstorlek för loggsäkerhetskopiering (storlek på säkerhetskopiering av transaktionslogg)

Följ dessa steg om du vill visa mått för säkerhetskopiering och datalagring i Azure-portalen:

  1. Gå till hyperskaladatabasen som du vill övervaka mått för säkerhetskopiering och datalagring för.
  2. I avsnittet Övervakning väljer du sidan Mått .
  3. I listrutan Mått väljer du måttet Datasäkerhetskopieringslagring, Datalagringsstorlek och Lagringsmått för loggsäkerhetskopiering med en lämplig aggregeringsregel.

Screenshot of the Azure portal that shows selections for viewing Hyperscale backup storage consumption.

Minska lagringsförbrukningen för säkerhetskopiering

Lagringsförbrukningen för säkerhetskopiering för en Hyperskala-databas beror på kvarhållningsperioden, valet av region, redundans för säkerhetskopieringslagring och arbetsbelastningstyp. Överväg några av följande justeringstekniker för att minska lagringsförbrukningen för säkerhetskopiering för en Hyperskala-databas:

  • 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 indexunderhåll, oftare än du behöver. Rekommendationer för indexunderhåll finns i Optimera indexunderhåll för att förbättra frågeprestanda och minska resursförbrukningen.
  • För stora datainläsningsåtgärder bör du överväga att använda datakomprimering när det är lämpligt.
  • Använd databasen tempdb i stället för permanenta tabeller i programlogik för att lagra tillfälliga resultat och/eller tillfälliga data.
  • Använd lokalt redundant eller zonredundant säkerhetskopieringslagring när geo-återställningsfunktionen är onödig (till exempel utvecklings-/testmiljöer).

Lagringskostnader för säkerhetskopiering

Kostnaden för lagring av Hyperskala-säkerhetskopior beror på valet av region och redundans för lagring av säkerhetskopior. Det beror också på arbetsbelastningstypen.

För skrivintensiva arbetsbelastningar är det mer troligt att datasidorna ofta ändras, vilket resulterar i större ögonblicksbilder av lagringen. Sådana arbetsbelastningar genererar också fler transaktionsloggar, vilket bidrar till de totala kostnaderna för säkerhetskopiering. Lagring av säkerhetskopior debiteras baserat på gigabyte som förbrukas per månad. Prisinformation finns på prissättningssidan för Azure SQL Database.

För Hyperskala beräknas fakturerbar lagring av säkerhetskopiering enligt följande:

Total billable backup storage size = (data backup storage size + log backup storage size)

Datalagringsstorleken ingår inte i den fakturerbara säkerhetskopieringen eftersom den redan faktureras som allokerad databaslagring.

Borttagna Hyperskala-databaser medför säkerhetskopieringskostnader för återställning till en tidpunkt innan de tas bort. För en borttagen Hyperskala-databas beräknas fakturerbar lagring av säkerhetskopiering enligt följande:

Total billable backup storage size for deleted Hyperscale database = (data storage size + data backup size + log backup storage size) * (remaining backup retention period after deletion / configured backup retention period)

Datalagringsstorleken ingår i formeln eftersom allokerad databaslagring inte faktureras separat för en borttagen databas. För en borttagen databas lagras data efter borttagning för att aktivera återställning under den konfigurerade kvarhållningsperioden för säkerhetskopiering.

Fakturerbar lagring av säkerhetskopiering för en borttagen databas minskar gradvis med tiden efter att den har tagits bort. Den blir noll när säkerhetskopior inte längre behålls och återställningen inte längre är möjlig. Om det är en permanent borttagning och du inte längre behöver säkerhetskopior kan du optimera kostnaderna genom att minska kvarhållningen innan du tar bort databasen.

Övervaka kostnader för säkerhetskopiering

Så här förstår du kostnaderna för lagring av säkerhetskopior:

  1. Gå till Kostnadshantering + fakturering i Azure-portalen.

  2. Välj Kostnadsanalys för Kostnadshantering>.

  3. För Omfång väljer du önskad prenumeration.

  4. Filtrera efter den tidsperiod och tjänst som du är intresserad av genom att följa dessa steg:

    1. Lägg till ett filter för Tjänstnamn.
    2. Välj sql-database i listrutan.
    3. Lägg till ytterligare ett filter för Meter.
    4. Om du vill övervaka säkerhetskopieringskostnader för återställning till tidpunkt väljer du Lagrade data – Säkerhetskopiering – RA i listrutan.

Följande skärmbild visar ett exempel på kostnadsanalys.

Screenshot of the Azure portal that shows Hyperscale Backup storage costs.

Redundans för data- och säkerhetskopieringslagring

Hyperskala stöder konfigurerbar lagringsredundans. När du skapar en Hyperskala-databas kan du välja önskad lagringstyp: skrivskyddad geo-zonredundant lagring (RA-GZRS), geo-redundant lagring med läsåtkomst (RA-GRS), zonredundant lagring (ZRS) eller lokalt redundant lagring (LRS).

  • Geo-zonredundant lagring: Kopierar dina säkerhetskopior synkront över tre Azure-tillgänglighetszoner i den primära regionen. liknar zonredundant lagring (ZRS). Dessutom kopieras dina data asynkront till en enda fysisk plats i den kopplade sekundära regionen. Den är för närvarande endast tillgänglig i vissa regioner.

Mer information om hur säkerhetskopiorna replikeras för andra lagringstyper finns i Redundans för säkerhetskopieringslagring.

Eftersom Hyperskala använder ögonblicksbilder av lagring för säkerhetskopior delar data och säkerhetskopior samma lagringskonto. Därför gäller den valda redundansen för lagring av säkerhetskopior för både data och säkerhetskopior.

Kommentar

Överväg säkerhetskopiering av lagringsredundans noggrant när du skapar en Hyperskala-databas, eftersom du bara kan ange den när databasen skapas. Du kan inte ändra den här inställningen när resursen har etablerats.

Använd aktiv geo-replikering för att uppdatera redundansinställningarna för säkerhetskopiering av lagring för en befintlig Hyperskala-databas med minsta stilleståndstid. Du kan också använda databaskopiering.

Varning

Återställa en Hyperskala-databas till en annan region

Du kan behöva återställa hyperskaladatabasen till en annan region än den aktuella regionen. Vanliga orsaker är en haveriberedskapsåtgärd, ett detaljtest eller en omlokalisering. Den primära metoden är att göra en geo-återställning av databasen. Du använder samma steg som du skulle använda för att återställa alla andra databaser i Azure SQL Database till en annan region:

  1. Skapa en server i målregionen om du inte redan har en lämplig server där. Den här servern ska ägas av samma prenumeration som den ursprungliga (källservern).
  2. Följ anvisningarna i avsnittet geo-återställning på sidan om hur du återställer en databas i Azure SQL Database från automatiska säkerhetskopior.

Kommentar

Eftersom källan och målet finns i separata regioner kan databasen inte dela ögonblicksbildlagring med källdatabasen som i icke-geo-återställningar. Icke-geo-återställningar slutförs snabbt oavsett databasstorlek.

En geo-återställning av en Hyperskala-databas är en datastorleksåtgärd, även om målet finns i den kopplade regionen för den geo-replikerade lagringen. Därför tar en geo-återställning betydligt längre tid jämfört med en återställning till tidpunkt i samma region.

Om målet finns i den kopplade regionen sker dataöverföringen inom en region. Överföringen kommer att vara betydligt snabbare än en dataöverföring mellan regioner. Men det kommer fortfarande att vara en datastorleksåtgärd.

Om du vill kan du kopiera databasen till en annan region. Använd den här metoden om geo-återställning inte är tillgänglig eftersom den inte stöds med den valda lagringsredundanstypen. Mer information finns i Databaskopiering för Hyperskala.

Relaterat innehåll

Databassäkerhetskopior är en viktig del av alla strategier för affärskontinuitet och haveriberedskap eftersom de skyddar dina data från oavsiktlig skada eller borttagning.