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

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.

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.

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.

• 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.

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.

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.

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.

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.

Overwegingen voor geo-herstel

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

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.

Volgende stappen

• Automatische back-ups van SQL Database
• Langetermijnretentie
• Zie Actieve geo-replicatie of failovergroepen voor meer informatie over snellere herstelopties.