Langetermijnretentieback-ups - Azure SQL Database en Azure SQL Managed Instance

Van toepassing op:Azure SQL DatabaseAzure SQL Managed Instance

Dit artikel bevat een conceptueel overzicht van langetermijnretentieback-ups (LTR) voor Azure SQL Database en Azure SQL Managed Instance. Langetermijnretentie kan worden geconfigureerd voor maximaal 10 jaar op back-ups voor Azure SQL Database (inclusief in de Hyperscale-servicelaag) en Azure SQL Managed Instance.

Als u aan de slag wilt gaan met de functie voor langetermijnretentieback-ups, raadpleegt u:

Belangrijk

Sommige oudere API's die worden gebruikt voor back-upbewerkingen voor langetermijnretentie (LTR) worden afgeschaft en worden niet meer ondersteund. Vermijd het gebruik van verouderde PowerShell-cmdlets, zoals Copy-AzSqlDatabaseLongTermRetentionBackup. Gebruik in plaats daarvan de ondersteunde herstelmethoden die in dit artikel worden beschreven.

Hoe langetermijnretentie werkt

Veel toepassingen hebben wettelijke, nalevings- of andere zakelijke redenen waarvoor u databaseback-ups langer moet bewaren dan de 1-35 dagen die worden geboden door de kortetermijnretentieperiode van automatische back-ups. Langetermijnretentie van back-ups (LTR) is afhankelijk van de volledige databaseback-ups die automatisch worden gemaakt door de Azure SQL-service. Zie Automated backups in Azure SQL Database of Automated backups in Azure SQL Managed Instance voor meer informatie.

Met behulp van de LTR-functie kunt u opgegeven volledige SQL Database en SQL Managed Instance back-ups opslaan in redundante Azure Blob-opslag met een configureerbaar bewaarbeleid van maximaal 10 jaar. LTR-back-ups kunnen vervolgens worden hersteld als een nieuwe database. Als een LTR-beleid is geconfigureerd, worden geautomatiseerde back-ups gekopieerd naar verschillende blobs voor langetermijnopslag die u vervolgens kunt gebruiken om uw database te herstellen naar een bepaald tijdstip. Het kopieerproces is een achtergrondtaak die geen invloed heeft op de prestaties van de databaseworkload. Het LTR-beleid voor elke database kan ook opgeven hoe vaak de LTR-back-ups worden gemaakt.

Opmerking

  • In Azure SQL Database kunt u back-ups voor langetermijnretentie configureren als onveranderbaar.
  • In Azure SQL Managed Instance is het momenteel niet mogelijk om back-ups te configureren als immuteerbaar. LTR-back-ups kunnen niet worden gewijzigd, maar u kunt ze verwijderen via Azure portal, Azure CLI, PowerShell of REST API. Als noodoplossing in Azure SQL Managed Instance kunt u copy-only database-back-ups maken en deze bewaren in uw eigen Azure Storage-account als een onveranderbaar bestand.

Als u LTR wilt inschakelen, kunt u een beleid definiëren met behulp van een combinatie van vier parameters: wekelijkse back-upretentie (W), maandelijkse back-upretentie (M), jaarlijkse back-upretentie (Y) en week van het jaar (WeekOfYear). Als u W opgeeft, wordt elke week één back-up gekopieerd naar langetermijnopslag. Als u M opgeeft, wordt de eerste back-up van elke maand gekopieerd naar de langetermijnopslag. Als u Y opgeeft, wordt één back-up tijdens de week die is opgegeven door WeekOfYear gekopieerd naar de langetermijnopslag. Als de opgegeven WeekOfYear in het verleden is wanneer het beleid is geconfigureerd, wordt de eerste LTR-back-up het volgende jaar gemaakt. Elke back-up wordt bewaard in langetermijnopslag volgens de beleidsparameters die zijn geconfigureerd wanneer de LTR-back-up wordt gemaakt.

Wijzigingen in het LTR-beleid zijn alleen van toepassing op toekomstige back-ups. Als u bijvoorbeeld de wekelijkse back-upretentie (W), maandelijkse back-upretentie (M) of jaarlijkse back-upretentie (Y) wijzigt, is de nieuwe bewaarinstelling alleen van toepassing op nieuwe back-ups. De retentie van bestaande back-ups wordt niet gewijzigd. Het LTR-beleid kan worden geconfigureerd voor elke database in Azure SQL Database en Azure SQL Managed Instance. Als u oude LTR-back-ups wilt verwijderen voordat de bewaarperiode verloopt, kunt u de back-ups handmatig verwijderen.

Opmerking

Wanneer u in zowel Azure SQL Database als Azure SQL Managed Instance een LTR-beleid voor de eerste keer inschakelt voor een database, wordt de meest recente volledige back-up van herstel naar een bepaald tijdstip (PITR) gekopieerd naar langetermijnopslag.

Voorbeelden van het LTR-beleid:

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

    De derde volledige back-up van elk jaar wordt vijf jaar bewaard.

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

    De eerste volledige back-up van elke maand wordt drie maanden bewaard.

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

    Elke wekelijkse volledige back-up wordt 12 weken bewaard.

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

    Elke wekelijkse volledige back-up wordt zes weken bewaard. Behalve de eerste volledige back-up van elke maand, die gedurende 12 maanden wordt bewaard. Behalve de volledige back-up die is gemaakt op de 20e week van het jaar, die gedurende 10 jaar wordt bewaard.

In de volgende tabel ziet u de frequentie en vervaldatum van de langetermijnback-ups voor het volgende beleid:

W=12 weeks (84 dagen), M=12 months (365 dagen), Y=10 years (3.650 dagen), WeekOfYear=20 (de week na 13 mei)

De volgende datums bevinden zich in ISO 8601 (YYYY-MM-DD).

PITR backup naar LTR Vervaldatum W Vervaldatum M Verloopdatum 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 01-08-2018
2018-05-16 13-05-2028
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
01-08-2018 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

Als u dit beleid wijzigt en instelt W=0 (geen wekelijkse back-ups), worden de wekelijkse back-ups bewaard totdat ze verlopen en behoudt de service alleen de maandelijkse en jaarlijkse back-ups. Er worden geen toekomstige wekelijkse back-ups opgeslagen onder het LTR-beleid. De opslagruimte die nodig is om deze back-ups te behouden, vermindert dienovereenkomstig.

Belangrijk

De timing van afzonderlijke LTR-back-ups wordt beheerd door Microsoft. U kunt geen LTR-back-up handmatig maken of de timing voor het maken van de back-up beheren. Nadat u een LTR-beleid hebt geconfigureerd, kan het maximaal zeven dagen duren voordat de eerste LTR-back-up wordt weergegeven in de lijst met beschikbare back-ups.

Als u een logische server of een met SQL beheerd exemplaar verwijdert, worden ook alle databases op die server of het beheerde exemplaar verwijderd. U kunt een verwijderde logische server of een met SQL beheerd exemplaar niet herstellen. Als u echter LTR voor een database hebt geconfigureerd, worden back-ups van LTR niet verwijderd en kunnen ze worden gebruikt om databases te herstellen naar een andere server of een beheerd exemplaar in hetzelfde abonnement, naar een tijdstip waarop een LTR-back-up is gemaakt.

Als u een database verwijdert, worden LTR-back-ups ook niet verwijderd en bewaard voor de geconfigureerde bewaarperiode. Deze back-ups kunnen worden hersteld naar dezelfde server of een andere server in hetzelfde abonnement.

Geo-replicatie en langetermijnretentie van back-ups

Als u actieve geo-replicatie of failovergroepen gebruikt als oplossing voor bedrijfscontinuïteit, bereid u dan voor op eventuele failovers en configureer hetzelfde LTR-beleid voor de secundaire database of het secundaire exemplaar als voor de primaire. De kosten voor LTR-opslag worden niet verhoogd, omdat er geen back-ups worden gegenereerd op basis van secundaire bestanden. Back-ups worden alleen gemaakt nadat de secundaire primaire wordt om ononderbroken LTR-back-ups te genereren wanneer een failover wordt geactiveerd en de primaire wordt verplaatst naar de secundaire regio.

Wanneer de oorspronkelijke primaire database wordt hersteld na een storing die de failover heeft veroorzaakt, wordt deze de nieuwe secundaire database. Daarom wordt het maken van de back-up niet hervat op de nieuwe secundaire server en treedt het bestaande LTR-beleid pas in werking zodra het weer de primaire server is.

Beveiligingsperimeter voor netwerken en LTR-herstel (preview-functie)

Opmerking

Een netwerkbeveiligingsperimeter (preview) is alleen van toepassing op Azure SQL Database. Azure SQL Managed Instance is geen onboarded resource, dus deze sectie is daar niet op van toepassing. Voor de huidige lijst, zie Onboarded private link-bronnen.

LTR-herstel is een door het platform beheerde operatie die een database herstelt van een langetermijnback-up naar een doellogische server. Wanneer een van de logische servers tot een perimeter behoort, valt het herstel onder de toegangsregels van die perimeter.

De dienst controleert de uitgaande toegang op de bronserver, wanneer die server nog bestaat, en de inkomende toegang op de doelserver. Als de bronlogische server is verwijderd, kan alleen de inkomende controle aan de doelzijde worden uitgevoerd.

Ondersteunde configuraties

LTR-herstel werkt zowel in overgangs- als in de geforceerde modus. In de overgangsmodus slagen herstelbewerkingen zonder toegangsregels. Configureer de regels voordat je overschakelt naar de afgedwongen modus.

In de afgedwongen modus worden deze configuraties ondersteund:

Bronserver Doelserver Vereiste toegangsregels
Binnen een perimeter In dezelfde perimeter None. Toegang tussen resources binnen dezelfde perimeter is altijd toegestaan.
Binnen een perimeter Binnen een andere perimeter Uitgaande op de bron, inkomend op het doel.
Binnen een perimeter Niet binnen een perimeter Uitgaand vanaf de bron.
Niet in een perimeter Binnen een perimeter Op weg naar het doel.
Verwijderd Binnen een perimeter Inkomend naar het doel.
Niet in een perimeter Niet in een perimeter None.

LTR-herstel vereist geen beheerde identiteit.

Toegangsregels voor een LTR-herstel configureren

  1. Koppel elke logische server aan zijn omtrek als je dat nog niet hebt gedaan. Sla deze stap over voor een server die buiten een perimeter blijft of voor een verwijderde bronserver.
  2. Als de bronserver zich in een perimeter bevindt en de doelserver niet in dezelfde perimeter, voeg dan een outbound-regel toe op het bronprofiel met het bestemmingstype ingesteld op FQDN en de volledig gekwalificeerde domeinnaam van de doelserver.
  3. Als de doelserver in een perimeter ligt en de bronserver niet in dezelfde perimeter, voeg dan een inbound rule toe aan het doelprofiel. Het herstelverzoek komt van de Azure SQL-beheerinfrastructuur, niet van de bronserver. Sta in de regel een van de volgende bronnen toe:
    • De abonnements-ID van de bronserver (aanbevolen).
    • De servicetag (aanbevolen).
    • IP-adresbereiken. Voor de publieke cloud: Azure IP-bereiken en servicetags - Public Cloud geeft elke servicetag en de IP-adresbereiken weer weer. De naam van de servicetag is SqlManagement. Microsoft publiceert deze IP-bereiken niet per regio, dus sta ze allemaal toe.
  4. Terwijl de servers nog in overgangsmodus staan, voer je een herstel uit en controleer je de netwerkbeveiligingsperimeter-diagnoselogs op onverwachte weigeringen.
  5. Schakel pas over naar de geforceerde modus nadat alle diagnostische controles zijn doorlopen.

Beperkingen en gedragsverschillen

  • Je kunt een logische server die LTR-back-ups heeft niet verwijderen terwijl de perimeter-associatie in de gedwongen modus staat. Onveranderlijke LTR-back-ups blokkeren ook verwijdering, ongeacht of de server zich in een perimeter bevindt of niet. Voor meer informatie, zie Immutable long-term back-ups en het verwijderen van logische servers.
  • Als je een bronserver verwijdert terwijl de associatie in transitiemodus is, kan de service de perimetermetadata van die server niet langer lezen, dus kan hij alleen de doelzijde van een herstel valideren. Houd rekening met deze kloof als je bron-zijde validatie als controle gebruikt.
  • In overgangsmodus slaagt een herstel, zelfs als de vereiste regels ontbreken. In de gedwongen modus wordt hetzelfde herstel geblokkeerd.

Langetermijnretentie van back-ups configureren

Belangrijk

Sommige oudere API's die worden gebruikt voor back-upbewerkingen voor langetermijnretentie (LTR) worden afgeschaft en worden niet meer ondersteund. Vermijd het gebruik van verouderde PowerShell-cmdlets, zoals Copy-AzSqlDatabaseLongTermRetentionBackup. Gebruik in plaats daarvan de ondersteunde herstelmethoden die in dit artikel worden beschreven.

U kunt langetermijnretentie van back-ups configureren met behulp van de Azure-portal en PowerShell voor Azure SQL Database en Azure SQL Managed Instance. Als u een database wilt herstellen vanuit de LTR-opslag, kunt u een specifieke back-up selecteren op basis van de tijdstempel. De database kan worden hersteld naar elke bestaande server of elk beheerd exemplaar onder hetzelfde abonnement als de oorspronkelijke database. Zie Restore-mogelijkheden en -functies in Azure SQL Managed Instance voor een volledige lijst met herstelmogelijkheden, beperkingen en functies.

Wanneer een herstelaanvraag wordt gestart in de laatste zeven dagen van de LTR-bewaarperiode, wordt de LTR-back-up pas verwijderd nadat de herstelbewerking is voltooid, zelfs als de bewaarperiode is verlopen.

Opmerking

Het herstellen van databases tussen de Hyperscale-servicelaag en de andere servicelagen van Azure SQL Database wordt momenteel niet ondersteund.

In Azure SQL Managed Instance kunt u SQL Agent-taken gebruiken om copy-only databaseback-ups te plannen en deze als alternatief te verplaatsen naar uw eigen opslagaccount:

  • Bewaar back-ups langer dan 10 jaar.
  • Bewaar dagelijkse kopieën van uw databases langer dan 35 dagen.
  • Sla databaseback-ups op onveranderbare opslag op.

Aanbeveling

Als u LTR-back-ups gebruikt om te voldoen aan naleving of andere bedrijfskritieke vereisten, kunt u periodieke herstelanalyses uitvoeren om te controleren of LTR-back-ups kunnen worden hersteld en dat de herstelbewerking resulteert in de verwachte databasestatus.

Opmerking

Langdurige back-ups zijn afhankelijk van succesvolle volledige back-ups. Een volledig transactielogboek kan een geplande volledige back-up voorkomen, wat weer een LTR-back-up kan voorkomen. Change Data Capture (CDC) en andere functies die het afbreken van transactielogs voorkomen, kunnen een LTR-back-up vertragen, die pas slaagt nadat de volledige back-up is geslaagd. Evalueer functies die het afkappen van transactielogs voorkomen en overweeg deze tijdelijk uit te schakelen totdat back-upoperaties herstellen.

Volgende stap

Beheer langetermijnretentie van back-ups in Azure SQL Database

Beheer langetermijnbewaring van back-ups voor Azure SQL Managed Instance

Verwante inhoud

Omdat databaseback-ups gegevens beschermen tegen onbedoelde beschadiging of verwijdering, zijn ze een essentieel onderdeel van elke strategie voor bedrijfscontinuïteit en herstel na noodgevallen.

  • Laatst bijgewerkt om