Een database herstellen vanuit een back-up in Azure SQL Managed Instance
Van toepassing op:
Azure SQL Managed Instance
Dit artikel bevat stappen voor het herstellen van een database vanuit een back-up in Azure SQL Managed Instance. Zie Een database herstellen vanuit een back-up in Azure SQL Database voor Meer informatie over Azure SQL Database.
Overzicht
Geautomatiseerde databaseback-ups helpen uw databases te beschermen tegen gebruikers- en toepassingsfouten, onbedoelde databaseverwijdering en langdurige storingen. Deze ingebouwde mogelijkheid is beschikbaar voor alle servicelagen en rekengrootten. De volgende opties zijn beschikbaar voor databaseherstel via geautomatiseerde back-ups:
- Maak een nieuwe database op hetzelfde beheerde exemplaar, hersteld naar een bepaald tijdstip binnen de bewaarperiode.
- Maak een nieuwe database op hetzelfde beheerde exemplaar of een ander beheerd exemplaar, hersteld naar een bepaald tijdstip binnen de bewaarperiode.
- Maak een database op hetzelfde beheerde exemplaar of een ander beheerd exemplaar, hersteld naar de verwijderingstijd voor een verwijderde database.
- Maak een nieuwe database op een beheerd exemplaar in hetzelfde abonnement of een ander abonnement in dezelfde tenant en in dezelfde regio, hersteld naar het punt van de meest recente back-ups.
Als u langetermijnretentie (LTR) hebt geconfigureerd, kunt u ook een nieuwe database maken op basis van een back-up voor langetermijnretentie op elk exemplaar.
Belangrijk
U kunt een bestaande database niet overschrijven tijdens het herstellen.
Hersteltijd
Verschillende factoren zijn van invloed op de hersteltijd voor het herstellen van een database via geautomatiseerde databaseback-ups:
- De grootte van de database
- De rekenkracht van de database
- Het aantal betrokken transactielogboeken
- De hoeveelheid activiteit die opnieuw moet worden afgespeeld om te herstellen naar het herstelpunt
- De netwerkbandbreedte als de herstelbewerking zich in een andere regio bevindt
- Het aantal gelijktijdige herstelaanvragen dat wordt verwerkt in de doelregio
Voor een grote of zeer actieve database kan het herstel enkele uren duren. Een langdurige storing in een regio kan leiden tot een groot aantal aanvragen voor geo-herstel voor herstel na noodgevallen. Wanneer er veel aanvragen zijn, kan de hersteltijd voor individuele databases toenemen. De meeste herstelbewerkingen voor databases zijn in minder dan 12 uur voltooid.
Tip
Voor Azure SQL Managed Instance hebben systeemupdates voorrang op databaseherstel die wordt uitgevoerd. Als er een systeemupdate is voor SQL Managed Instance, worden alle lopende herstelbewerkingen opgeschort en vervolgens hervat nadat de update is toegepast. Dit systeemgedrag kan de tijd van herstelbewerkingen verlengen en kan vooral van invloed zijn op langlopende herstelbewerkingen.
Om voor een voorspelbare tijd van databaseherstel te zorgen, kunt u overwegen om onderhoudsvensters te configureren waarmee systeemupdates op een specifieke dag en tijd kunnen worden gepland. Overweeg ook om databaseherstel uit te voeren buiten het geplande onderhoudsvenster.
Bevoegdheden
Als u wilt herstellen met behulp van geautomatiseerde back-ups, moet u het volgende zijn:
- Een lid van de rol INzender voor SQL Server of inzender voor SQL Managed Instance (afhankelijk van de herstelbestemming) in het abonnement
- De eigenaar van het abonnement
Zie Azure RBAC: Ingebouwde rollen voor meer informatie.
U kunt herstellen met behulp van Azure Portal, PowerShell of de REST API. U kunt Transact-SQL niet gebruiken.
Herstel naar een bepaald tijdstip
U kunt een database herstellen naar een eerder tijdstip. De aanvraag kan elke servicelaag of rekenkracht voor de herstelde database opgeven. Zorg ervoor dat u voldoende resources hebt op het exemplaar waarnaar u de database herstelt.
Wanneer het herstellen is voltooid, wordt er een nieuwe database gemaakt op het doelexemplaren, ongeacht of het hetzelfde exemplaar is of een ander exemplaar. De herstelde database wordt tegen normale tarieven in rekening gebracht op basis van de servicelaag en rekenkracht. Er worden geen kosten in rekening gebracht totdat het herstellen van de database is voltooid.
Over het algemeen herstelt u een database naar een eerder punt voor hersteldoeleinden. U kunt de herstelde database behandelen als vervanging voor de oorspronkelijke database of deze als gegevensbron gebruiken om de oorspronkelijke database bij te werken.
Belangrijk
U kunt geen herstel naar een bepaald tijdstip uitvoeren voor een geo-secundaire database. U kunt dit alleen doen voor een primaire database.
Databasevervanging
Als u wilt dat de herstelde database een vervanging is voor de oorspronkelijke database, moet u de rekenkracht en servicelaag van de oorspronkelijke database opgeven. Vervolgens kunt u de naam van de oorspronkelijke database wijzigen en de herstelde database de oorspronkelijke naam geven met behulp van de opdracht ALTER DATABASE in T-SQL.
Gegevensherstel
Als u van plan bent om gegevens op te halen uit de herstelde database om te herstellen van een fout in een gebruiker of toepassing, moet u een script voor gegevensherstel schrijven en uitvoeren waarmee gegevens uit de herstelde database worden geëxtraheerd en toegepast op de oorspronkelijke database. Hoewel het lang kan duren voordat de herstelbewerking is voltooid, is de hersteldatabase zichtbaar in de databaselijst tijdens het herstelproces.
Als u de database tijdens het herstellen verwijdert, wordt de herstelbewerking geannuleerd. Er worden geen kosten in rekening gebracht voor de database die het herstellen niet heeft voltooid.
Als u een database in SQL Managed Instance naar een bepaald tijdstip wilt herstellen met behulp van Azure Portal, gaat u naar de database in de portal en kiest u Herstellen. U kunt ook de overzichtspagina van het beheerde doelexemplaren van SQL openen en + Nieuwe database op de werkbalk selecteren om de pagina Azure SQL Managed Database maken te openen.
Geef de details van het beheerde doelexemplaren op op het tabblad Basisbeginselen en kies een type back-up op het tabblad Gegevensbron .
Raadpleeg het artikel Herstel naar een bepaald tijdstip voor meer informatie.
Verwijderde databaseherstel
U kunt een verwijderde database herstellen naar het verwijderingstijdspunt, of een eerder tijdstip, naar hetzelfde exemplaar of naar een ander exemplaar dan het bronexemplaren. Het doelexemplaren kunnen zich in hetzelfde abonnement of in een ander abonnement bevinden dan het bronexemplaren. U herstelt een verwijderde database door een nieuwe database te maken vanuit de back-up.
Belangrijk
U kunt een verwijderd beheerd exemplaar niet herstellen. Als u een beheerd exemplaar verwijdert, worden ook alle bijbehorende databases verwijderd en kunnen ze niet worden hersteld naar het verwijderingstijdspunt of een eerder tijdstip. Als u langetermijnretentie (LTR) hebt geconfigureerd, kunt u nog steeds een database herstellen van een verwijderd exemplaar naar een ander exemplaar en naar een bepaald tijdstip waarop de LTR-back-up is gemaakt.
Als u een database wilt herstellen met behulp van Azure Portal, opent u de overzichtspagina van het beheerde exemplaar en selecteert u Back-ups. Kies ervoor om verwijderde back-ups weer te geven en selecteer vervolgens Herstellen naast de verwijderde back-up die u wilt herstellen om de pagina Azure SQL Managed Database maken te openen. Geef details van het beheerde doelexemplaren op op het tabblad Basisinformatie en details van het beheerde bronexemplaren op het tabblad Gegevensbron . Configureer bewaarinstellingen op het tabblad Aanvullende instellingen .
Tip
Het kan enkele minuten duren voordat onlangs verwijderde databases worden weergegeven op de pagina Verwijderde databases in Azure Portal of wanneer u verwijderde databases wilt weergeven met behulp van de opdrachtregel.
Geo-herstel
Belangrijk
- Geo-herstel is alleen beschikbaar voor beheerde exemplaren die zijn geconfigureerd met geografisch redundante back-upopslag. Als u momenteel geen geo-gerepliceerde back-ups voor een database gebruikt, kunt u dat wijzigen door redundantie van back-upopslag te configureren.
- U kunt geo-herstel uitvoeren op beheerde exemplaren die zich alleen in hetzelfde abonnement bevinden.
Geo-herstel is de standaardhersteloptie wanneer uw database niet beschikbaar is vanwege een incident in de hostingregio. U kunt de database herstellen naar een exemplaar in een andere regio. U kunt een database herstellen op elk beheerd exemplaar in elke Azure-regio vanuit de meest recente geo-gerepliceerde back-ups. Geo-herstel maakt gebruik van een geo-gerepliceerde back-up als bron. U kunt een geo-herstel aanvragen, zelfs als een storing de database of het datacenter niet toegankelijk heeft gemaakt.
Er is een vertraging tussen het moment waarop een back-up wordt gemaakt en wanneer deze geografisch wordt gerepliceerd naar een Azure-blob in een andere regio. Als gevolg hiervan kan de herstelde database maximaal één uur achter de oorspronkelijke database zijn. In de volgende afbeelding ziet u een databaseherstel vanaf de laatste beschikbare back-up in een andere regio.
Vanuit Azure Portal kunt u een geo-gerepliceerde back-up herstellen naar een bestaand exemplaar of een nieuw beheerd exemplaar maken en een beschikbare back-up voor geo-herstel selecteren. De zojuist gemaakte database bevat de geografisch herstelde back-upgegevens.
Als u naar een bestaand exemplaar wilt herstellen, volgt u de stappen in herstel naar een bepaald tijdstip en kiest u de juiste bron- en doelexemplaren om uw database te herstellen naar uw beoogde exemplaar.
Als u geo-herstel naar een nieuw exemplaar wilt uitvoeren met behulp van Azure Portal, voert u de volgende stappen uit:
- Ga naar uw nieuwe met Azure SQL beheerde exemplaar.
- Selecteer Nieuwe database.
- Voer een databasenaam in.
- Kies onder Gegevensbron het juiste type back-up en geef vervolgens details op voor de gegevensbron.
- Selecteer een back-up in de lijst met beschikbare back-ups voor geo-herstel.
Nadat u het proces voor het maken van een exemplaardatabase hebt voltooid, bevat deze de herstelde back-up voor geo-herstel.
Overwegingen voor geo-herstel
Geo-herstel is de meest eenvoudige oplossing voor herstel na noodgevallen die beschikbaar is in Azure SQL Managed Instance. Het is afhankelijk van automatisch gemaakte geo-gerepliceerde back-ups in een secundaire (gekoppelde) regio. Hier volgen enkele overwegingen voor geo-herstel:
- RPO (Recovery Point Objective) is maximaal 1 uur.
- Herstelprocessen (beoogde hersteltijd - RTO) duren meestal minder dan 12 uur, maar kunnen variëren op basis van de grootte en activiteit van de database, zodat herstel langer kan duren dan dit tijdsbestek.
- Secundaire (gekoppelde) regio is Azure-opslaginstellingen voor de primaire regio. U kunt de secundaire regio niet wijzigen.
- Nieuw gemaakte/herstelde databases worden mogelijk niet onmiddellijk als herstelbaar weergegeven in andere regio's vanwege een vertraging bij het invullen van nieuwe gegevens. Als klanten de back-ups van nieuwe databases niet zien, moeten ze een wachttijd van maximaal 24 uur verwachten.
Het is essentieel om te erkennen dat geo-herstel dient als een geschikte oplossing voor herstel na noodgevallen voor toepassingen met relatief kleine databases die niet essentieel zijn voor het bedrijf. Gebruik failovergroepen voor bedrijfskritieke toepassingen waarvoor grote databases nodig zijn en moeten zorgen voor bedrijfscontinuïteit. Deze functie biedt een veel lagere RPO en RTO en de capaciteit is altijd gegarandeerd.
Zie Overzicht van bedrijfscontinuïteit voor meer informatie over keuzes voor bedrijfscontinuïteit.
Beperkingen
Houd rekening met de volgende beperkingen bij het werken met back-ups en Azure SQL Managed Instance:
- Geo-herstel van een database kan alleen worden uitgevoerd naar een exemplaar in hetzelfde abonnement als het beheerde bronexemplaren van SQL.
- Azure SQL Managed Instance-databases kunnen alleen worden hersteld naar SQL Server 2022 (on-premises of op een virtuele machine) als de bron-SQL Managed Instance is ingeschreven in de onderdelengolf van november 2022.
- Azure SQL Managed Instance-databases worden standaard versleuteld met TDE. Wanneer de brondatabase een door de klant beheerde sleutel (CMK) als TDE-beveiliging gebruikt, moet het doelexemplaren toegang hebben tot dezelfde sleutel die wordt gebruikt voor het versleutelen van de brondatabase in Azure Key Vault, of moet u TDE-versleuteling voor de brondatabase uitschakelen voordat u de back-up maakt.
- U kunt alleen de voortgang van het herstelproces bijhouden met behulp van de sys.dm_exec_requests en sys.dm_operation_status dynamische beheerweergaven.
- Wanneer beleidsregels voor service-eindpunten zijn ingeschakeld in Azure SQL Managed Instance, voorkomt het plaatsen van een beleid voor service-eindpunten op een subnet dat herstel naar een bepaald tijdstip (PITR) van exemplaren in verschillende subnetten voorkomt.
- RPO (Recovery Point Objective) is maximaal 1 uur.
- De beoogde hersteltijd (RTO) is ongeveer 12 uur, maar kan variëren op basis van de grootte van de database en de activiteit kan langer duren dan dit tijdsbestek.
- Secundaire (gekoppelde) regio kan niet worden gewijzigd.
- Nieuw gemaakte/herstelde databases worden mogelijk niet onmiddellijk als herstelbaar weergegeven in andere regio's vanwege een vertraging bij het invullen van nieuwe gegevens. Het kan tot 24 uur duren voordat back-ups van nieuwe databases zichtbaar zijn.
Gerelateerde inhoud
- Automatische back-ups van SQL Managed Instance
- Langetermijnretentie
- Zie Failover-groepen voor meer informatie over snellere herstelopties.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor