Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 maximaal 10 jaar worden geconfigureerd voor 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:
- Langetermijnretentie van back-ups van Azure SQL Database beheren
- Langetermijnretentie van back-ups van Azure SQL Managed Instance beheren
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 Automatische back-ups in Azure SQL Database of geautomatiseerde back-ups in Azure SQL Managed Instance voor meer informatie.
Met behulp van de LTR-functie kunt u opgegeven volledige back-ups van SQL Database en SQL Managed Instance 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
Het is momenteel niet mogelijk om back-ups van Azure SQL Database en Azure SQL Managed Instance te configureren als onveranderbaar. LTR-back-ups kunnen niet worden gewijzigd, maar u kunt ze verwijderen via Azure Portal, Azure CLI, PowerShell of REST API.
Als tijdelijke oplossing in Azure SQL Managed Instance kunt u copy-only databaseback-ups maken en bewaren in uw eigen Azure Storage-account als een onveranderbare 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 en het beleid een jaarlijkse retentie opgeeft, 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=3De derde volledige back-up van elk jaar wordt vijf jaar bewaard.
W=0, M=3, Y=0De eerste volledige back-up van elke maand wordt drie maanden bewaard.
W=12, M=0, Y=0Elke wekelijkse volledige back-up wordt 12 weken bewaard.
W=6, M=12, Y=10, WeekOfYear=20Elke 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.
Langetermijnretentie van back-ups configureren
U kunt langetermijnretentie van back-ups configureren met behulp van 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.
- Langetermijnretentie van back-ups van Azure SQL Database beheren.
- Langetermijnretentie van back-ups van Azure SQL Managed Instance beheren.
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.
In Azure SQL Managed Instance kunt u SQL Agent-taken gebruiken om back-ups van 'copy-only'-databases te plannen en naar uw eigen opslagaccount over te zetten als alternatief voor:
- 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.
Volgende stap
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.