Delen via

Een database herstellen vanuit een back-up in Azure SQL Database

  • Artikel

Van toepassing op: Azure SQL Database

Dit artikel bevat stappen voor het herstellen van een database vanuit een back-up in Azure SQL Database, met inbegrip van Hyperscale-databases. Zie Een database herstellen vanuit een back-up in Azure SQL Managed Instance voor Azure SQL Managed Instance.

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:

  • Een nieuwe database maken op dezelfde server, hersteld naar een opgegeven tijdstip binnen de retentieperiode.
  • Een database maken op dezelfde server, hersteld naar het verwijderingstijdstip van een verwijderde database.
  • Maak een nieuwe database op elke server in dezelfde regio, hersteld naar het tijdstip van een recente back-up.
  • Maak een nieuwe database op een server in een willekeurige andere regio, die is hersteld naar het tijdstip van de meest recent gerepliceerde back-ups.

Als u langetermijnretentie (LTR) hebt geconfigureerd, kunt u ook een nieuwe database maken op basis van een back-up voor langetermijnretentie op elke server.

Belangrijk

  • U kunt een bestaande database niet overschrijven tijdens het herstellen.
  • Met databaseherstelbewerkingen worden de tags van de oorspronkelijke database niet hersteld.

Wanneer u de Standard- of Premium-servicelaag in het DTU-aankoopmodel gebruikt, kunnen er extra opslagkosten in rekening worden gebracht voor het herstellen van uw database. De extra kosten gebeuren wanneer de maximale grootte van de herstelde database groter is dan de hoeveelheid opslagruimte die is opgenomen in de servicelaag en servicedoelstelling van de doeldatabase.

Zie de pagina met prijzen voor SQL Database-prijzen voor meer informatie over extra opslag. Als de werkelijke hoeveelheid gebruikte ruimte kleiner is dan de hoeveelheid opslagruimte die is inbegrepen, kunt u deze extra kosten voorkomen door de maximale databasegrootte in te stellen op het inbegrepen bedrag.

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.

Voor één abonnement gelden de volgende beperkingen voor het aantal gelijktijdige herstelaanvragen. Deze beperkingen zijn van toepassing op elke combinatie van herstelbewerkingen naar een bepaald tijdstip, geo-herstelbewerkingen, en herstelbewerkingen vanaf back-ups met een langetermijnbewaarperiode.

Implementatieoptie Maximum aantal gelijktijdige aanvragen dat wordt verwerkt Maximum aantal gelijktijdige aanvragen dat wordt verzonden
Individuele database (per abonnement) 30 100
Elastische pool (per groep) 4 2.000

Bevoegdheden

Als u wilt herstellen met behulp van geautomatiseerde back-ups, moet u het volgende zijn:

  • Een lid van de rol Inzender of de rol SQL Server-inzender in het abonnement of de resourcegroep die de logische server bevat
  • De eigenaar van het abonnement of de resourcegroep

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 elke database herstellen naar een eerder tijdstip binnen de bewaarperiode. De herstelaanvraag kan elke servicelaag of rekengrootte voor de herstelde database opgeven. Wanneer u een database herstelt in een elastische pool, moet u ervoor zorgen dat u voldoende resources in de pool hebt om de database te kunnen gebruiken.

Wanneer het herstellen is voltooid, wordt er een nieuwe database gemaakt op dezelfde server als de oorspronkelijke database. 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 een herstel naar een bepaald tijdstip van een database uitvoeren op dezelfde server. Herstel naar meerdere servers, abonnementen en herstel naar meerdere geografische locaties wordt momenteel niet ondersteund. Als u een database wilt herstellen naar een andere regio met geo-gerepliceerde back-ups, raadpleegt u Geo-herstel.
  • U kunt geen herstel naar een bepaald tijdstip uitvoeren voor een geo-secundaire database. U kunt dit alleen doen voor een primaire database.
  • De BackupFrequency parameter wordt niet ondersteund voor Hyperscale-databases.
  • Databaseherstelbewerkingen zijn resource-intensief en vereisen mogelijk een servicelaag van S3 of hoger voor de hersteldatabase (doeldatabase). Zodra het herstellen is voltooid, kan de database of elastische pool indien nodig omlaag worden geschaald.

  • 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 naar een bepaald tijdstip wilt herstellen met behulp van Azure Portal, opent u de overzichtspagina van de database en selecteert u Herstellen op de werkbalk. Kies de back-upbron en selecteer vervolgens het punt-in-time-back-uppunt waaruit een nieuwe database wordt gemaakt.

Screenshot of database restore options for SQL Database.

Back-upherstel op lange termijn

Als u een herstelbewerking wilt uitvoeren op een back-up op lange termijn, kunt u Azure Portal, De Azure CLI, Azure PowerShell of de REST API gebruiken. Zie Een langetermijnback-up herstellen voor meer informatie. Langetermijnretentie is niet van toepassing op Hyperscale-databases.

Als u een langetermijnback-up wilt herstellen met behulp van Azure Portal, gaat u naar uw logische server. Selecteer Back-ups onder Instellingen en selecteer vervolgens Beheren onder Beschikbare LTR-back-ups voor de database die u wilt herstellen.

Screenshot of the Azure portal that shows available long-term retention backups.

Verwijderde databaseherstel

U kunt een verwijderde database herstellen naar het verwijderingstijdspunt of een eerder tijdstip op dezelfde server met behulp van Azure Portal, de Azure CLI, Azure PowerShell en de REST API.

Belangrijk

Als u een server verwijdert, worden ook alle databases en de bijbehorende PITR-back-ups verwijderd. U kunt een verwijderde server niet herstellen en u kunt de verwijderde databases niet terugzetten vanuit pitr-back-ups. Als u LTR-back-ups hebt geconfigureerd, kunt u deze back-ups gebruiken om de databases te herstellen naar een andere server.

Als u een verwijderde database wilt herstellen naar de verwijderingstijd met behulp van Azure Portal, opent u de overzichtspagina van de server en selecteert u Verwijderde databases. Selecteer een verwijderde database die u wilt herstellen en voer vervolgens de naam in voor de nieuwe database die wordt gemaakt met gegevens die worden hersteld vanuit de back-up.

Screenshot of the Azure portal that shows how to restore a deleted database.

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 programmatisch wilt weergeven.

Geo-herstel

U kunt geo-herstel gebruiken om een verwijderde database te herstellen met behulp van Azure Portal, de Azure CLI, Azure PowerShell en de REST API.

Belangrijk

  • Geo-herstel is alleen beschikbaar voor databases 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 alleen geo-herstel uitvoeren op databases die zich in hetzelfde abonnement bevinden.

Geo-herstel maakt gebruik van geo-gerepliceerde back-ups als bron. U kunt een database herstellen op elke logische server in elke Azure-regio vanuit de meest recente geo-gerepliceerde back-ups. U kunt een geo-herstel aanvragen, zelfs als een storing de database of de hele regio niet toegankelijk heeft gemaakt.

Geo-herstel is de standaardhersteloptie wanneer uw database niet beschikbaar is vanwege een incident in de hostingregio. U kunt de database herstellen naar een server in elke andere regio.

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.

Illustration of geo-restore.

Vanuit Azure Portal maakt u een nieuwe individuele database en selecteert u een beschikbare back-up voor geo-herstel. De zojuist gemaakte database bevat de geografisch herstelde back-upgegevens.

Voer de volgende stappen uit om een individuele database te herstellen vanuit Azure Portal in de regio en server van uw keuze:

  1. Selecteer In Dashboard de optie Create SQL Database toevoegen>. Voer op het tabblad Basisinformatie de vereiste gegevens in.
  2. Selecteer Aanvullende instellingen.
  3. Als u bestaande gegevens wilt gebruiken, selecteert u Back-up.
  4. Selecteer een back-up in de lijst met beschikbare back-ups voor geo-herstel.

Screenshot of the Azure portal that shows options to create a database.

Voltooi het proces voor het maken van een database vanuit de back-up. Wanneer u een database maakt in Azure SQL Database, bevat deze de herstelde geo-herstelback-up.

Overwegingen voor geo-herstel

Zie Herstel met geo-herstel met geo-herstel voor meer informatie over het gebruik van geo-herstel.

Notitie

Zie de richtlijnen voor herstel na noodgevallen van Azure SQL Database en de controlelijst voor hoge beschikbaarheid en herstel na noodgevallen in Azure SQL Database voor gedetailleerde informatie over het herstellen van een storing.

Geo-herstel is de meest eenvoudige oplossing voor herstel na noodgevallen die beschikbaar is in SQL Database. Het is afhankelijk van automatisch gemaakte geo-gerepliceerde back-ups met een RPO (Recovery Point Objective) van maximaal 1 uur en een geschatte hersteltijddoelstelling (RTO) van maximaal 12 uur. Het garandeert niet dat de doelregio de capaciteit heeft om uw databases te herstellen na een regionale storing, omdat een sterke toename van de vraag waarschijnlijk is. Als uw toepassing relatief kleine databases gebruikt en niet essentieel is voor het bedrijf, is geo-herstel een geschikte oplossing voor herstel na noodgevallen.

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.

Notitie

Als u van plan bent geo-herstel te gebruiken als noodhersteloplossing, raden we u aan periodieke analyses uit te voeren om toepassingstolerantie te controleren op verlies van recente gegevenswijzigingen, samen met alle operationele aspecten van de herstelprocedure.

Volgende stappen