Långsiktiga kvarhållningssäkerhetskopior – Azure SQL Database och Azure SQL Managed Instance

gäller för:Azure SQL DatabaseAzure SQL Managed Instance

Den här artikeln innehåller en konceptuell översikt över säkerhetskopior för långtidsbevarande (LTR) för Azure SQL Database och Azure SQL Managed Instance. Långsiktig kvarhållning kan konfigureras i upp till 10 år på säkerhetskopior för Azure SQL Database (även på tjänstnivån Hyperskala) och Azure SQL Managed Instance.

Så här kommer du igång med funktionen för säkerhetskopiering med långsiktig lagring:

Viktigt!

Vissa äldre API som används för LTR-backuper (långsiktig kvarhållning) är föråldrade och stöds inte längre. Undvik att använda äldre PowerShell-cmdletar som Copy-AzSqlDatabaseLongTermRetentionBackup. Använd de återställningsmetoder som stöds som beskrivs i den här artikeln i stället.

Så här fungerar långsiktig kvarhållning

Många program har regel-, efterlevnads- eller andra affärsskäl som kräver att du behåller databassäkerhetskopior utöver de 1–35 dagar som tillhandahålls av den kortsiktiga kvarhållningsperioden för automatiska säkerhetskopieringar. Långsiktig kvarhållning av säkerhetskopior (LTR) förlitar sig på de fullständiga databassäkerhetskopieringar som skapas automatiskt av Azure SQL-tjänsten. Mer information finns i Automaterade säkerhetskopior i Azure SQL Database eller Automaterade säkerhetskopior i Azure SQL Managed Instance.

Med hjälp av LTR-funktionen kan du lagra angivna fullständiga SQL Database- och SQL Managed Instance säkerhetskopior i redundant Azure Blob Storage med en konfigurerbar kvarhållningsprincip på upp till 10 år. LTR-säkerhetskopior kan sedan återställas som en ny databas. Om en LTR-princip har konfigurerats kopieras automatiserade säkerhetskopieringar till olika blobar för långsiktig lagring som du sedan kan använda för att återställa databasen till en viss tidpunkt. Kopieringsprocessen är ett bakgrundsjobb som inte har någon prestandapåverkan på databasarbetsbelastningen. LTR-principen för varje databas kan också ange hur ofta LTR-säkerhetskopiorna skapas.

Anmärkning

Om du vill aktivera LTR kan du definiera en princip med hjälp av en kombination av fyra parametrar: kvarhållning av veckovisa säkerhetskopior (W), månatlig kvarhållning av säkerhetskopior (M), årlig kvarhållning av säkerhetskopior (Y) och veckan på året (WeekOfYear). Om du anger W kopieras en säkerhetskopia varje vecka till långsiktig lagring. Om du anger M kopieras den första säkerhetskopian för varje månad till den långsiktiga lagringen. Om du anger Y kopieras en säkerhetskopia under veckan som anges av WeekOfYear till den långsiktiga lagringen. Om den angivna WeekOfYear är tidigare när principen har konfigurerats skapas den första LTR-säkerhetskopieringen följande år. Varje säkerhetskopia sparas i långsiktig lagring enligt de principparametrar som konfigureras när LTR-säkerhetskopieringen skapas.

Ändringar av LTR-principen gäller endast för framtida säkerhetskopior. Om du till exempel ändrar kvarhållningen av veckovisa säkerhetskopior (W), månatlig kvarhållning av säkerhetskopior (M) eller årlig kvarhållning av säkerhetskopior (Y) gäller den nya kvarhållningsinställningen endast för nya säkerhetskopior. Kvarhållningen av befintliga säkerhetskopior ändras inte. LTR-principen kan konfigureras för varje databas i Azure SQL Database och Azure SQL Managed Instance. Om du tänker ta bort gamla LTR-säkerhetskopior innan deras kvarhållningsperiod går ut kan du ta bort säkerhetskopiorna manuellt.

Anmärkning

I både Azure SQL Database och Azure SQL Managed Instance kopieras den senaste fullständiga säkerhetskopieringen från tidpunktsåterställning (PITR) till långsiktig lagring när du aktiverar en LTR-princip för första gången för en databas.

Exempel på LTR-principen:

  • W=0, M=0, Y=5, WeekOfYear=3

    Den tredje fullständiga säkerhetskopian för varje år behålls i fem år.

  • W=0, M=3, Y=0

    Den första fullständiga säkerhetskopian för varje månad sparas i tre månader.

  • W=12, M=0, Y=0

    Varje veckovis fullständig säkerhetskopiering sparas i 12 veckor.

  • W=6, M=12, Y=10, WeekOfYear=20

    Varje veckovis fullständig säkerhetskopiering sparas i sex veckor. Förutom den första fullständiga säkerhetskopian av varje månad, som sparas i 12 månader. Förutom den fullständiga säkerhetskopieringen den 20:e veckan på året, som hålls i 10 år.

I följande tabell visas kadensen och förfallotiden för de långsiktiga säkerhetskopiorna för följande princip:

W=12 weeks (84 dagar), M=12 months (365 dagar), Y=10 years (3 650 dagar) WeekOfYear=20 (veckan efter den 13 maj)

Följande datum finns i ISO 8601 (YYYY-MM-DD).

PITR-säkerhetskopiering till LTR Förfallodatum W Förfallotid M Förfallodatum Y
2018-03-07 2019-03-02
2018-03-14 2018-06-06
2018-03-21 2018-06-13
2018-03-28 2018-06-20
2018-04-04 2019-03-30
2018-04-11 2018-07-04
2018-04-18 2018-07-11
2018-04-25 2018-07-18
2018-05-02 2019-04-27
2018-05-09 2018-08-01
2018-05-16 2028-05-13
2018-05-23 2018-08-15
2018-05-30 2018-08-22
2018-06-06 2019-06-01
2018-06-13 2018-09-05
2018-06-20 2018-09-12
2018-06-27 2018-09-19
2018-07-04 2019-06-29
2018-07-11 2018-10-03
2018-07-18 2018-10-10
2018-07-25 2018-10-17
2018-08-01 2019-07-27
2018-08-08 2018-10-31
2018-08-15 2018-11-07
2018-08-22 2018-11-14
2018-08-29 2018-11-21

Om du ändrar den här principen och anger W=0 (inga veckosäkerhetskopior) behålls de veckovisa säkerhetskopiorna tills de upphör att gälla och sedan behåller tjänsten endast de månatliga och årliga säkerhetskopiorna. Inga framtida veckosäkerhetskopior lagras under LTR-principen. Mängden lagringsutrymme som krävs för att behålla dessa säkerhetskopior minskar i enlighet med detta.

Viktigt!

Tidpunkten för enskilda LTR-säkerhetskopior styrs av Microsoft. Du kan inte skapa en LTR-säkerhetskopia manuellt eller styra tidpunkten då säkerhetskopian skapas. När du har konfigurerat en LTR-princip kan det ta upp till sju dagar innan den första LTR-säkerhetskopieringen visas i listan över tillgängliga säkerhetskopior.

Om du tar bort en logisk server eller en SQL-hanterad instans tas även alla databaser på servern eller den hanterade instansen bort. Du kan inte återställa en borttagen logisk server eller SQL-hanterad instans. Men om du hade konfigurerat LTR för en databas tas inte LTR-säkerhetskopior bort och kan användas för att återställa databaser till en annan server eller hanterad instans i samma prenumeration, till en tidpunkt då en LTR-säkerhetskopiering gjordes.

Om du tar bort en databas tas inte LTR-säkerhetskopior bort och behålls inte under den konfigurerade kvarhållningsperioden. Dessa säkerhetskopior kan återställas till samma server eller en annan server i samma prenumeration.

Geo-replikering och långsiktig kvarhållning av säkerhetskopior

Om du använder aktiv geo-replikering eller överlämningsgrupper som affärskontinuitetslösning, förbereder du dig för eventuella överlämningar och konfigurerar samma LTR-policy på den sekundära databasen eller instans som du har på den primära. Din LTR-lagringskostnad ökar inte eftersom säkerhetskopieringar inte genereras från sekundärfiler. Säkerhetskopior skapas först efter att den sekundära blir primär för att säkerställa oavbruten generering av LTR-säkerhetskopior när en redundans utlöses och den primära flyttas till den sekundära regionen.

När den ursprungliga primära databasen återställs från ett avbrott som orsakade felövergången blir den nya sekundära databasen. Därför återupptas inte säkerhetskopieringen på den nya sekundära och den befintliga LTR-principen börjar inte gälla förrän den blir den primära igen.

Nätverkssäkerhetsperimeter och LTR-återställning (förhandsvisning)

Anmärkning

En nätverkssäkerhetsperimeter (förhandsgranskning) gäller endast för Azure SQL Database. Azure SQL Managed Instance är inte en onboardad resurs, så detta avsnitt gäller inte för den. För den aktuella listan, se Onboarded private link-resurser.

LTR-återställning är en plattformshanterad operation som återställer en databas från en långsiktig backup till en mål-logisk server. När någon av de logiska servrarna tillhör ett perimeternätverk är återställningen föremål för perimeternätverkets åtkomstregler.

Tjänsten kontrollerar utgående åtkomst på källservern, när den servern fortfarande finns, och inkommande åtkomst på målservern. Om den logiska källservern raderades kan endast den inkommande kontrollen på målsidan köras.

Konfigurationer som stöds

LTR-återställning fungerar både i övergångs- och framtvingat läge. I övergångsläge lyckas återställningar utan åtkomstregler. Konfigurera reglerna innan du byter till enforced-läge.

I framtvingat läge stöds dessa konfigurationer:

Källserver Målserver Åtkomstregler krävs
Inom en perimeter I samma perimeter None. Åtkomst mellan resurser inom samma perimeter är alltid tillåten.
Inom en omkrets I en annan avgränsning Utgående på källan, inkommande på målsystemet.
inom en omkrets Inte inom en perimeter Utgående från källan.
Inte inom en perimeter inom en omkrets Inkommande till målet.
Borttagen inom en omkrets Inkommande på målet.
Inte inom en perimeter Inte inom en perimeter None.

LTR-återställning kräver ingen hanterad identitet.

Konfigurera åtkomstregler för en LTR-återställning

  1. Koppla varje logisk server till dess gränsområde om du inte redan gjort det. Hoppa över detta steg för en server som håller sig utanför en perimeter eller för en raderad källserver.
  2. Om källservern är i en perimeter och målservern inte är i samma perimeter, lägg till en utgående regel på källprofilen med destinationstyp satt till FQDN och målserverns fullt kvalificerade domännamn.
  3. Om målservern är i en perimeter och källservern inte är i samma perimeter, lägg till en inkommande regel på målserverns profil. Återställningsbegäran kommer från Azure SQL-hanteringsinfrastrukturen, inte från källservern. I regeln, tillåt en av dessa källor:
    • Prenumerations-ID för källservern (rekommenderas).
    • service tag (rekommenderas).
    • IP-adressintervall. För det publika molnet, Azure IP Ranges och Service Tags – Public Cloud listar varje servicetag och dess IP-adressintervall. Namnet på service tag är SqlManagement. Microsoft publicerar inte dessa intervall per region, så tillåt samtliga.
  4. Med servrarna fortfarande i övergångsläge, kör en återställning och kontrollera diagnostikloggarna för nätverkssäkerhetsperimetern för oväntade avslag.
  5. Byt till tvångsläge först efter att alla diagnostiska kontroller har godkänts.

Begränsningar och beteendeskillnader

  • Du kan inte radera en logisk server som har LTR-backuper medan dess perimeterassociation är i tvingat läge. Immutabla LTR-backuper blockerar också radering, oavsett om servern befinner sig i en perimeter eller inte. För mer information, se Oföränderliga långsiktiga säkerhetskopior och borttagning av logiska servrar.
  • Om du tar bort en källserver medan dess association är i övergångsläge kan tjänsten inte längre läsa serverns perimetermetadata, så den kan bara validera målsidan av en återställning. Ta hänsyn till detta gap om du förlitar dig på validering på källsidan som kontroll.
  • I övergångsläge lyckas en återställning även när de nödvändiga reglerna saknas. I framtvingat läge blockeras samma återställning.

Konfigurera långsiktig kvarhållning av säkerhetskopior

Viktigt!

Vissa äldre API som används för LTR-backuper (långsiktig kvarhållning) är föråldrade och stöds inte längre. Undvik att använda äldre PowerShell-cmdletar som Copy-AzSqlDatabaseLongTermRetentionBackup. Använd de återställningsmetoder som stöds som beskrivs i den här artikeln i stället.

Du kan konfigurera långsiktig kvarhållning av säkerhetskopior med hjälp av Azure-portalen och PowerShell för Azure SQL Database och Azure SQL Managed Instance. Om du vill återställa en databas från LTR-lagringen kan du välja en specifik säkerhetskopia baserat på tidsstämpeln. Databasen kan återställas till valfri befintlig server eller hanterad instans under samma prenumeration som den ursprungliga databasen. En fullständig lista över återställningsfunktioner, begränsningar och funktioner finns i Restore-funktioner i Azure SQL Managed Instance.

När en återställningsbegäran initieras under de sista sju dagarna av LTR-kvarhållningsperioden tas LTR-säkerhetskopieringen bara bort när återställningsåtgärden har slutförts, även om kvarhållningsperioden har upphört att gälla.

Anmärkning

Återställning av databaser mellan tjänstnivån Hyperskala och de andra tjänstnivåerna i Azure SQL Database stöds för närvarande inte.

I Azure SQL Managed Instance kan du använda SQL Agent-jobb för att schemalägga endast kopiera-säkerhetskopior av databasen och flytta dem till din egen lagringsplats som ett alternativ till:

  • Behåll säkerhetskopior i mer än 10 år.
  • Behåll dagliga kopior av dina databaser i mer än 35 dagar.
  • Lagra databassäkerhetskopior på oföränderlig lagring.

Tips/Råd

Om du använder LTR-säkerhetskopior för att uppfylla efterlevnadskraven eller andra verksamhetskritiska krav bör du överväga att utföra regelbundna återställningstest för att kontrollera att LTR-säkerhetskopior kan återställas och att återställningen resulterar i det förväntade databastillståndet.

Anmärkning

Säkerhetskopior för långtidslagring kräver fullständiga säkerhetskopieringar som har slutförts. En fullständig transaktionslogg kan förhindra en schemalagd fullständig backup, vilket i sin tur kan förhindra en LTR-backup. Förändringsdatafångst (CDC) och andra funktioner som förhindrar förkortning av transaktionsloggar kan fördröja en LTR-backup, som bara lyckas efter att hela backupen har lyckats. Utvärdera funktioner som förhindrar förkortning av transaktionsloggen och överväg att tillfälligt inaktivera dem tills säkerhetskopieringsoperationerna återhämtar sig.

Nästa steg

Hantera Azure SQL Database långsiktig kvarhållning av säkerhetskopior

Hantera Azure SQL Managed Instance långsiktig kvarhållning av säkerhetskopior

Relaterat innehåll

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

  • Uppdaterades senast