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.
Overzicht
Automatische 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 dezelfde server, hersteld naar een opgegeven tijdstip binnen de bewaarperiode met herstel naar een bepaald tijdstip.
- Maak een database op dezelfde server, hersteld tot het tijdstip van verwijdering voor een verwijderde database.
- Maak een nieuwe database op een server in dezelfde regio, hersteld naar het tijdstip van een recente back-up met langetermijnretentieherstel of geo-herstel.
- Maak een nieuwe database op een server in een andere regio, hersteld tot het punt van de meest recente gerepliceerde back-ups met geo-herstel.
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 Databasevoor prijsinformatie 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 herstellen 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 afzonderlijke databases toenemen. Zie RTO- en RPO-voor meer informatie over hersteltijden.
Voor één abonnement gelden de volgende beperkingen voor het aantal gelijktijdige herstelaanvragen. Deze beperkingen zijn van toepassing op elke combinatie van herstel naar een bepaald tijdstip, geo-herstelbewerkingen en herstelbewerkingen op basis van back-ups met langetermijnretentie.
implementatieoptie | Maximum aantal gelijktijdige aanvragen dat wordt verwerkt | maximum aantal gelijktijdige aanvragen dat wordt ingediend |
---|---|---|
Individuele database (per abonnement) | 30 | 100 |
Elastische groep (per groep) | 4 | 2.000 |
Machtigingen
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 rollenvoor meer informatie.
U kunt herstellen met behulp van Azure Portal, PowerShell of de REST API. U kunt Transact-SQL niet gebruiken.
Herstelpunt op een specifiek 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. Point-in-time herstel over meerdere servers, abonnementen en geografische locaties wordt momenteel niet ondersteund. Als u een database wilt herstellen naar een andere regio met behulp van geo-gerepliceerde back-ups, raadpleegt u Geo-herstel.
- U kunt geen herstel naar een bepaald tijdstip uitvoeren op een geo-secundaire database. U kunt dit alleen doen op een primaire database.
- De parameter
BackupFrequency
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 om de pagina SQL Database maken - Database herstellen te openen:
Geef op de pagina SQL Database maken - Database herstellen de bron voor de back-up op en selecteer vervolgens het punt-in-time back-uppunt waaruit een nieuwe database wordt gemaakt. Omdat de gekozen database moet worden hersteld naar de huidige server, worden de brondatabase en doelserver grijs weergegeven.
Back-up herstellen op de 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 herstellenvoor meer informatie.
Als u een langetermijnback-up wilt herstellen met behulp van Azure Portal, gaat u naar uw logische server. Selecteer back-ups onder Data Managementen selecteer vervolgens Beheren onder Beschikbare LTR-back-ups voor de database die u wilt herstellen.
Verwijderde database herstellen
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 voor deze databases hebt geconfigureerd, kunt u deze back-ups gebruiken om de databases te herstellen naar een andere server. Als de logische server is verwijderd, gebruikt u Azure CLI- of PowerShell-opdrachten om LTR-back-ups weer te geven en te herstellen.
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.
Fooi
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
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.
Belangrijk
- Geo-herstel is alleen beschikbaar voor databases die zijn ingesteld met geografisch redundante reservekopieopslag. Als u momenteel geen geo-gerepliceerde back-ups voor een database gebruikt, kunt u dit wijzigen door redundantie van back-upopslag te configureren.
- U kunt alleen geo-herstel uitvoeren op databases die zich 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 server in een andere regio.
Het herstellen van geografisch redundante back-ups kan in bepaalde scenario's leiden tot gegevensverlies omdat Azure Geo-Redundant Storage (GRS) gegevens asynchroon repliceert naar een secundaire regio. Er is enige latentie betrokken bij het replicatieproces, maar de exacte latentie kan variëren op basis van verschillende factoren, waaronder de afstand tussen de primaire en secundaire regio's en de huidige netwerkvoorwaarden. Normaal gesproken ligt de replicatielatentie voor GRS binnen het bereik van minuten, maar het is niet gegarandeerd binnen een bepaald tijdsbestek. Het kan veel tijd duren, afhankelijk van de grootte van elke database. Voor meer informatie, zie RTO en RPO.
In de volgende afbeelding ziet u een databaseherstel vanaf de laatste beschikbare back-up in een andere regio.
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.
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:
- Open het deelvenster Maak SQL-database in de Azure-portal. Voer op het tabblad Basisinformatie de vereiste gegevens in.
- Selecteer Aanvullende instellingen.
- Voor Bestaande gegevensgebruiken, selecteer Backup.
- Selecteer een back-up in de lijst met beschikbare geo-herstelback-ups.
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-back-up.
Overwegingen voor geo-herstel
Voor meer informatie over het gebruik van geo-herstel, zie Herstellen met geo-herstel.
Notitie
Zie richtlijnen voor herstel na noodgevallen en de controlelijst voor hoge beschikbaarheid en herstel na noodgevallenvoor gedetailleerde informatie over herstel na noodgevallen.
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. Zie RTO- en RPO-voor meer informatie over hersteltijden. 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 failovergroepenvoor bedrijfskritieke toepassingen waarvoor grote databases nodig zijn en die bedrijfscontinuïteit moeten garanderen. Deze functie biedt een veel lagere RPO en RTO en de capaciteit is altijd gegarandeerd.
Zie Overzicht van bedrijfscontinuïteitvoor 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.
Database herstellen naar een andere server
U kunt de volgende methoden gebruiken om een database te herstellen naar een andere server: