Langetermijnretentie - Azure SQL Database en Azure SQL Managed Instance
Van toepassing op: Azure SQL DatabaseAzure SQL Managed Instance
Dit artikel bevat een conceptueel overzicht van langetermijnretentie van back-ups 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.
Zie Langetermijnretentie voor back-ups configureren voor Azure SQL Database en Azure SQL Managed Instance om aan de slag te gaan.
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 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. De kopie is een achtergrondtaak die geen invloed heeft op de prestaties van de databaseworkload. Het LTR-beleid voor elke database in SQL Database kan ook opgeven hoe vaak de LTR-back-ups worden gemaakt.
Notitie
- Het is momenteel niet mogelijk om back-ups van Azure SQL Database en Azure SQL Managed Instance te configureren als onveranderbaar.
- Gebruik in Azure SQL Managed Instance SQL Agent-taken om back-ups van alleen-kopiëren database te plannen als alternatief voor LTR na 35 dagen.
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.
Elke wijziging in het LTR-beleid is alleen van toepassing op toekomstige back-ups. Als bijvoorbeeld wekelijkse back-upretentie (W), maandelijkse back-upretentie (M) of jaarlijkse back-upretentie (Y) wordt gewijzigd, is de nieuwe bewaarinstelling alleen van toepassing op nieuwe back-ups. De retentie van bestaande back-ups wordt niet gewijzigd. Als u oude LTR-back-ups wilt verwijderen voordat de bewaarperiode verloopt, moet u de back-ups handmatig verwijderen.
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
(3650 dagen), WeekOfYear=20
(de week na 13 mei)
De volgende datums bevinden zich in ISO 8601 (YYYY-MM-DD
).
Pitr back-up naar LTR | Vervaldatum W | Vervaldatum M | Verloopdatum Y |
---|---|---|---|
2018-03-07 | 2019-07-03 | ||
2018-03-14 | 2018-06-06 | ||
2018-03-21 | 2018-06-13 | ||
2018-03-28 | 2018-06-20 | ||
2018-04-04 | 25-04-2019 | ||
2018-04-11 | 2018-07-04 | ||
2018-04-18 | 2018-07-11 | ||
2018-04-25 | 2018-07-18 | ||
2018-05-02 | 2019-05-23 | ||
2018-05-09 | 01-08-2018 | ||
2018-05-16 | 2028-05-13 | ||
2018-05-23 | 2018-08-15 | ||
2018-05-30 | 2018-08-22 | ||
2018-06-06 | 2019-06-20 | ||
2018-06-13 | 2018-09-05 | ||
2018-06-20 | 2018-09-12 | ||
2018-06-27 | 2018-09-19 | ||
2018-07-04 | 2019-07-25 | ||
2018-07-11 | 2018-10-03 | ||
2018-07-18 | 2018-10-10 | ||
2018-07-25 | 2018-10-17 | ||
2018-08-01 | 2019-08-22 | ||
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 het bovenstaande beleid wijzigt en instelt W=0
(geen wekelijkse back-ups), behoudt de service alleen de maandelijkse en jaarlijkse back-ups. Er worden geen 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 Azure SQL Database. 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 tot 7 dagen duren voordat de eerste LTR-back-up wordt weergegeven in de lijst met beschikbare back-ups.
Als u een logische server of een beheerd exemplaar verwijdert, worden alle databases op die server of het beheerde exemplaar ook verwijderd en kunnen ze niet worden hersteld. U kunt een verwijderde server of een beheerd exemplaar niet herstellen. Als u echter LTR hebt geconfigureerd voor een database of beheerd exemplaar, worden LTR-back-ups niet verwijderd en kunnen ze worden gebruikt om databases op een andere server of beheerd exemplaar in hetzelfde abonnement te herstellen, naar een bepaald tijdstip waarop een LTR-back-up is gemaakt.
Als u een database verwijdert, worden LTR-back-ups 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 uw oplossing voor bedrijfscontinuïteit, moet u zich voorbereiden op uiteindelijke failovers en hetzelfde LTR-beleid configureren voor de secundaire database of het secundaire exemplaar. De kosten voor LTR-opslag worden niet verhoogd, omdat er geen back-ups worden gegenereerd op basis van de secundaire bestanden. De back-ups worden alleen gemaakt wanneer de secundaire primaire wordt. Het zorgt voor niet-onderbroken generatie van de LTR-back-ups wanneer de failover wordt geactiveerd en de primaire wordt verplaatst naar de secundaire regio.
Notitie
Wanneer de oorspronkelijke primaire database wordt hersteld na een storing die de failover heeft veroorzaakt, wordt deze een nieuwe secundaire database. Het maken van de back-up wordt daarom niet hervat en het bestaande LTR-beleid wordt pas van kracht als het opnieuw de primaire wordt.
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.
Voor meer informatie over het configureren van langetermijnretentie of het herstellen van een database vanuit een back-up voor SQL Database met behulp van Azure Portal of PowerShell, raadpleegt u Langetermijnretentie van back-ups van Azure SQL Database beheren.
Voor meer informatie over het configureren van langetermijnretentie of het herstellen van een database vanuit een back-up voor SQL Managed Instance met behulp van Azure Portal of PowerShell, raadpleegt u Langetermijnretentie van back-ups van Azure SQL Managed Instance beheren.
Wanneer een herstelaanvraag wordt gestart in de laatste 7 dagen van de LTR-bewaarperiode, wordt de vervaldatum van alle back-ups +7 dagen automatisch verlengd in Azure om te voorkomen dat een LTR-back-up verloopt tijdens het herstellen.
Notitie
Als u LTR-back-ups gebruikt om te voldoen aan de 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.
Gerelateerde 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.
- Overzicht van bedrijfscontinuïteit voor Azure SQL Database
- Overzicht van bedrijfscontinuïteit voor Azure SQL Managed Instance
- Automatische back-ups in Azure SQL Database
- Geautomatiseerde back-ups in Azure SQL Managed Instance
Ga voor een zelfstudie over het configureren en beheren van LTR-back-ups naar: