Delen via

Back-ups maken en herstellen van SQL Server-databases

Van toepassing op:SQL Server

In dit artikel worden de voordelen beschreven van het maken van back-ups van SQL Server-databases, worden basistermen voor back-up en herstel beschreven, en worden back-up- en herstelstrategieën geïntroduceerd voor SQL Server en beveiligingsoverwegingen voor back-up en herstel.

In dit artikel worden SQL Server-back-ups geïntroduceerd. Zie Back-ups maken voor specifieke stappen voor het maken van back-ups van SQL Server-databases.

Het ONDERDEEL voor back-up en herstel van SQL Server biedt een essentiële beveiliging voor het beveiligen van kritieke gegevens die zijn opgeslagen in uw SQL Server-databases. Als u het risico op onherstelbare gegevensverlies wilt minimaliseren, moet u regelmatig een back-up maken van uw databases om wijzigingen in uw gegevens te behouden. Een goed geplande back-up- en herstelstrategie helpt databases te beschermen tegen gegevensverlies veroorzaakt door diverse fouten. Test uw strategie door een set back-ups te herstellen en vervolgens uw database te herstellen om u voor te bereiden op een effectieve reactie op een noodgeval.

Naast lokale opslag voor het opslaan van de back-ups biedt SQL Server ook ondersteuning voor back-ups naar en herstel vanuit Azure Blob Storage. Zie back-up en herstel van SQL Server met Microsoft Azure Blob Storage voor meer informatie. Voor databasebestanden die zijn opgeslagen met Behulp van Azure Blob Storage, biedt SQL Server 2016 (13.x) de optie om Azure-momentopnamen te gebruiken voor bijna directe back-ups en snellere herstelbewerkingen. Zie Back-ups van bestandsmomentopnamen voor databasebestanden in Azure voor meer informatie. Azure biedt ook een bedrijfsgebaseerde back-upoplossing voor SQL Server die wordt uitgevoerd op azure-VM's. Een volledig beheerde back-upoplossing biedt ondersteuning voor AlwaysOn-beschikbaarheidsgroepen, langetermijnretentie, herstel naar een bepaald tijdstip en centraal beheer en bewaking. Zie Back-up van SQL Server op Virtuele Azure-machines voor meer informatie.

Waarom een back-up maken?

  • Als u een back-up maakt van uw SQL Server-databases, het uitvoeren van testherstelprocedures op uw back-ups en kopieën van back-ups opslaat op een veilige, externe locatie, wordt u beschermd tegen mogelijk catastrofaal gegevensverlies. Back-ups maken is de enige manier om uw gegevens te beveiligen.

    Met geldige back-ups van een database kunt u uw gegevens herstellen van veel fouten, zoals:

    • Mediafout.
    • Gebruikersfouten, bijvoorbeeld, een tabel per ongeluk verwijderen.
    • Hardwarefouten, bijvoorbeeld een beschadigd schijfstation of permanent verlies van een server.
    • Natuurrampen. Met behulp van SQL Server Backup naar Azure Blob Storage kunt u een externe back-up maken in een andere regio dan uw on-premises locatie om te gebruiken in het geval van een natuurramp die van invloed is op uw on-premises locatie.

  • Daarnaast zijn back-ups van een database handig voor routinebeheerdoeleinden, zoals het kopiëren van een database van de ene server naar de andere, het instellen van AlwaysOn-beschikbaarheidsgroepen of het spiegelen van databases en archivering.

Woordenlijst met back-uptermen

een back-up maken van [werkwoord]
Het proces voor het maken van een back-up [zelfstandig naamwoord] door gegevensrecords te kopiëren uit een SQL Server-database of logboekrecords uit het transactielogboek.

back-up [zelfstandig naamwoord]
Een kopie van gegevens die u kunt gebruiken om de gegevens te herstellen en te herstellen na een fout. Back-ups van een database kunnen ook worden gebruikt om een kopie van de database te herstellen naar een nieuwe locatie.

back-upapparaat
Een schijf- of tapeapparaat waarnaar SQL Server-back-ups worden geschreven en waaruit ze kunnen worden hersteld. SQL Server-back-ups kunnen ook worden geschreven naar een Azure Blob Storage en DE URL-indeling wordt gebruikt om de bestemming en de naam van het back-upbestand op te geven. Zie back-up en herstel van SQL Server met Microsoft Azure Blob Storage voor meer informatie.

back-upmedia
Een of meer tapes of schijfbestanden waarnaar een of meer back-ups zijn geschreven.

gegevensback-up
Een back-up van gegevens in een volledige database (een databaseback-up), een gedeeltelijke database (een gedeeltelijke back-up) of een set gegevensbestanden of bestandsgroepen (een back-up van een bestand).

back-up van database
Een back-up van een database. Volledige databaseback-ups vertegenwoordigen de hele database op het moment dat de back-up is voltooid. Differentiële databaseback-ups bevatten alleen wijzigingen die zijn aangebracht in de database sinds de meest recente volledige databaseback-up.

differentiële back-up
Een gegevensback-up die is gebaseerd op de meest recente volledige back-up van een volledige of gedeeltelijke database of een set gegevensbestanden of bestandsgroepen (de differentiële basis) en die alleen de gegevens bevat die sinds die basis zijn gewijzigd.

volledige back-up
Een gegevensback-up die alle gegevens in een specifieke database of set bestandsgroepen of bestanden bevat, en ook voldoende logboeken voor het herstellen van die gegevens.

logboekback-up
Een back-up van transactielogboeken met alle logboekrecords waarvan geen back-up is gemaakt in een vorige logboekback-up (volledig herstelmodel).

recover
Een database retourneren naar een stabiele en consistente status.

terugwinning
Een fase van het opstarten van de database of van een herstelbewerking die de database in een transactieconsistente status brengt.

herstelmodel
Een database-eigenschap waarmee het onderhoud van transactielogboeken voor een database wordt gecontroleerd. Er zijn drie herstelmodellen: eenvoudig, volledig en bulksgewijs geregistreerd. Het herstelmodel van een database bepaalt de vereisten voor back-up en herstel.

herstellen
Een proces met meerdere fasen waarmee alle gegevens en logboekpagina's van een opgegeven SQL Server-back-up naar een opgegeven database worden gekopieerd en vervolgens alle transacties die in de back-up zijn vastgelegd, worden doorgestuurd door vastgelegde wijzigingen toe te passen om de gegevens op tijd vooruit te brengen.

Strategieën voor back-up en herstel

Het maken van back-ups en het herstellen van gegevens moet worden aangepast aan een bepaalde omgeving en moet werken met de beschikbare resources. Daarom vereist een betrouwbaar gebruik van back-up en herstel voor herstel een back-up- en herstelstrategie. Een goed ontworpen back-up- en herstelstrategie zorgt voor een balans tussen de bedrijfsvereisten voor maximale beschikbaarheid van gegevens en minimale gegevensverlies, waarbij rekening wordt gehouden met de kosten voor het onderhouden en opslaan van back-ups.

Een back-up- en herstelstrategie bevat een back-upgedeelte en een herstelgedeelte. Het back-upgedeelte van de strategie definieert het type en de frequentie van back-ups, de aard en snelheid van de hardware die ze nodig hebben, hoe back-ups moeten worden getest en waar en hoe back-upmedia moeten worden opgeslagen (inclusief beveiligingsoverwegingen). Het herstelgedeelte van de strategie definieert wie verantwoordelijk is voor het uitvoeren van herstelbewerkingen, hoe herstelbewerkingen moeten worden uitgevoerd om te voldoen aan uw doelstellingen voor database-beschikbaarheid en het minimaliseren van gegevensverlies en hoe herstelbewerkingen worden getest.

Het ontwerpen van een effectieve strategie voor back-up en herstel vereist zorgvuldige planning, implementatie en testen. Testen is vereist: u hebt geen back-upstrategie totdat u back-ups hebt hersteld in alle combinaties die zijn opgenomen in uw herstelstrategie en de herstelde database hebt getest op fysieke consistentie. U moet rekening houden met verschillende factoren. Deze omvatten:

  • De doelstellingen van uw organisatie met betrekking tot uw productiedatabases, met name de vereisten voor beschikbaarheid en bescherming van gegevens tegen verlies of schade.

  • De aard van elke database: de grootte, de gebruikspatronen, de aard van de inhoud, de vereisten voor de gegevens, enzovoort.

  • Beperkingen voor resources, zoals hardware, personeel, ruimte voor het opslaan van back-upmedia, de fysieke beveiliging van de opgeslagen media, enzovoort.

Aanbevelingen voor best practices

De accounts die back-up- of herstelbewerkingen uitvoeren, mogen niet meer bevoegdheden krijgen dan nodig is. Controleer de back-up en herstel voor specifieke machtigingsgegevens. Het wordt aanbevolen om back-ups te versleutelen en, indien mogelijk, gecomprimeerd te maken.

Om beveiliging te garanderen, moeten back-upbestanden extensies hebben die voldoen aan de juiste conventies:

  • Databaseback-upbestanden moeten de .BAK extensie hebben
  • Logboekback-upbestanden moeten de .TRN extensie hebben.

Afzonderlijke opslag gebruiken

Belangrijk

Zorg ervoor dat u uw databaseback-ups op een afzonderlijke fysieke locatie of een afzonderlijk apparaat van de databasebestanden plaatst. Wanneer uw fysieke schijf waarin uw databases storingen of crashes opslaat, is herstelbaarheid afhankelijk van de mogelijkheid om toegang te krijgen tot het afzonderlijke station of externe apparaat dat de back-ups heeft opgeslagen om een herstel uit te voeren. Houd er rekening mee dat u meerdere logische volumes of partities kunt maken vanaf hetzelfde fysieke schijfstation. Bekijk zorgvuldig de indelingen van de schijfpartitie en logische volumes voordat u een opslaglocatie voor de back-ups kiest.

Het juiste herstelmodel kiezen

Back-up- en herstelbewerkingen worden uitgevoerd binnen de context van een herstelmodel. Een herstelmodel is een database-eigenschap die bepaalt hoe het transactielogboek wordt beheerd. Het herstelmodel van een database bepaalt dus welke typen back-ups en herstelscenario's worden ondersteund voor de database en welke grootte de back-ups van transactielogboeken zouden zijn. Normaal gesproken maakt een database gebruik van het eenvoudige herstelmodel of het volledige herstelmodel. U kunt het volledige herstelmodel uitbreiden door over te schakelen naar het bulksgewijs vastgelegde herstelmodel voordat bulkbewerkingen worden uitgevoerd. Zie het transactielogboek voor een inleiding tot deze herstelmodellen en hoe deze van invloed zijn op transactielogboekbeheer.

De beste keuze voor het herstelmodel voor de database is afhankelijk van uw bedrijfsvereisten. Gebruik het eenvoudige herstelmodel om het beheer van transactielogboeken te voorkomen en back-up en herstel te vereenvoudigen. Gebruik het volledige herstelmodel om de blootstelling aan werkverlies tegen administratieve overhead te minimaliseren. Als u de impact op de logboekgrootte tijdens bulksgewijs vastgelegde bewerkingen wilt minimaliseren en tegelijkertijd de herstelbaarheid van deze bewerkingen wilt toestaan, gebruikt u het bulksgewijs vastgelegde herstelmodel. Zie het overzicht van Back-up voor informatie over het effect van herstelmodellen op back-up en herstel.

Uw back-upstrategie ontwerpen

Nadat u een herstelmodel hebt geselecteerd dat voldoet aan uw bedrijfsvereisten voor een specifieke database, moet u een bijbehorende back-upstrategie plannen en implementeren. De optimale back-upstrategie is afhankelijk van verschillende factoren, waarvan de volgende met name belangrijk zijn:

  • Hoeveel uur per dag hebben toepassingen toegang tot de database?

    Als er een voorspelbare dalperiode is, raden we u aan om volledige databaseback-ups voor die periode te plannen.

  • Hoe vaak zijn wijzigingen en updates waarschijnlijk?

    Als er regelmatig wijzigingen zijn, kunt u het volgende overwegen:

    • Overweeg onder het eenvoudige herstelmodel differentiële back-ups te plannen tussen volledige databaseback-ups. Een differentiële back-up legt alleen de wijzigingen vast sinds de laatste volledige databaseback-up.

    • Onder het volledige herstelmodel moet u regelmatige back-ups van logboeken plannen. Het plannen van differentiële back-ups tussen volledige back-ups kan de hersteltijd verminderen door het aantal logboekback-ups te verminderen dat u moet herstellen nadat u de gegevens hebt hersteld.

  • Zijn er waarschijnlijk wijzigingen in slechts een klein deel van de database of in een groot deel van de database?

    Voor een grote database waarin wijzigingen zijn geconcentreerd in een deel van de bestanden of bestandsgroepen, kunnen gedeeltelijke back-ups en of volledige bestandsback-ups nuttig zijn. Zie Gedeeltelijke back-ups (SQL Server) en volledige bestandsback-ups (SQL Server) voor meer informatie.

  • Hoeveel schijfruimte is een volledige databaseback-up vereist?

  • Hoe ver in het verleden moet uw bedrijf back-ups onderhouden?

    Zorg ervoor dat u een juiste back-upplanning hebt ingesteld op basis van de behoeften van de toepassing en bedrijfsvereisten. Naarmate de back-ups oud worden, is het risico op gegevensverlies hoger, tenzij u alle gegevens opnieuw kunt genereren tot het punt van storing. Voordat u ervoor kiest om oude back-ups te verwijderen vanwege beperkingen van opslagresources, moet u overwegen of herstelbaarheid zo ver in het verleden is vereist.

De grootte van een volledige databaseback-up schatten

Voordat u een strategie voor back-up en herstel implementeert, moet u schatten hoeveel schijfruimte een volledige databaseback-up gaat gebruiken. Met de back-upbewerking worden de gegevens in de database gekopieerd naar het back-upbestand. De back-up bevat alleen de werkelijke gegevens in de database en geen ongebruikte ruimte. Daarom is de back-up meestal kleiner dan de database zelf. U kunt een schatting maken van de grootte van een volledige databaseback-up met behulp van de door het sp_spaceused systeem opgeslagen procedure. Zie sp_spaceused (Transact-SQL) voor meer informatie.

Back-ups plannen

Het uitvoeren van een back-upbewerking heeft minimaal effect op transacties die worden uitgevoerd; Daarom kunt u back-upbewerkingen uitvoeren tijdens normale bewerkingen. U kunt een SQL Server-back-up uitvoeren met minimaal effect op productieworkloads.

Zie Het overzicht van back-ups (SQL Server) voor informatie over gelijktijdigheidsbeperkingen tijdens het maken van back-ups.

Nadat u hebt bepaald welke typen back-ups u nodig hebt en hoe vaak u elk type moet uitvoeren, raden we u aan om regelmatige back-ups te plannen als onderdeel van een databaseonderhoudsplan voor de database. Zie de wizard Onderhoudsplan gebruiken voor informatie over onderhoudsplannen en het maken ervan voor databaseback-ups en logboekback-ups.

Uw back-ups testen

U hebt pas een herstelstrategie als u uw back-ups test. Het is erg belangrijk om uw back-upstrategie voor elk van uw databases grondig te testen door een kopie van de database te herstellen naar een testsysteem. U moet het herstellen van elk type back-up testen dat u wilt gebruiken. We raden u ook aan om na het herstellen van de back-up databaseconsistentiecontroles uit te voeren via DBCC CHECKDB van de database om te controleren of de back-upmedia niet zijn beschadigd.

Mediastabiliteit en consistentie controleren

Gebruik de verificatieopties van de back-uphulpprogramma's (BACKUP T-SQL-opdracht, SQL Server-onderhoudsplannen, uw back-upsoftware of -oplossing, enzovoort). Zie RESTORE-instructies - VERIFYONLY voor een voorbeeld.

Gebruik geavanceerde functies zoals BACKUP CHECKSUM het detecteren van problemen met de back-upmedia zelf. Zie Mogelijke mediafouten tijdens back-up en herstel (SQL Server) voor meer informatie

Strategie voor documentback-up/herstel

We raden u aan uw back-up- en herstelprocedures te documenteren en een kopie van de documentatie in uw runbook te bewaren. U wordt ook aangeraden een bewerkingshandleiding voor elke database te onderhouden. Deze bewerkingshandleiding moet de locatie van de back-ups, de namen van back-ups (indien aanwezig) en de hoeveelheid tijd die nodig is voor het herstellen van de testback-ups documenteren.

Voortgang bewaken met XEvent

Back-up- en herstelbewerkingen kunnen veel tijd in beslag nemen vanwege de grootte van een database en de complexiteit van de betrokken bewerkingen. Wanneer er problemen optreden met een van beide bewerkingen, kunt u de backup_restore_progress_trace uitgebreide gebeurtenis gebruiken om de voortgang live te bewaken. Zie Overzicht van uitgebreide gebeurtenissen voor meer informatie over uitgebreide gebeurtenissen.

Waarschuwing

Het gebruik van de backup_restore_progress_trace uitgebreide gebeurtenis kan een prestatieprobleem veroorzaken en een aanzienlijke hoeveelheid schijfruimte verbruiken. Gebruik gedurende korte tijd, wees voorzichtig en test grondig voordat u in productie implementeert.

-- Create the backup_restore_progress_trace extended event session
CREATE EVENT SESSION [BackupRestoreTrace] ON SERVER
ADD EVENT sqlserver.backup_restore_progress_trace
ADD TARGET package0.event_file(SET filename=N'BackupRestoreTrace')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=5 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

-- Start the event session
ALTER EVENT SESSION [BackupRestoreTrace]
ON SERVER
STATE = start;
GO

-- Stop the event session
ALTER EVENT SESSION [BackupRestoreTrace]
ON SERVER
STATE = stop;
GO

Voorbeelduitvoer van uitgebreide gebeurtenis

Schermopname van een voorbeeld van een back-up van xevent-uitvoer. Schermopname van een voorbeeld van een back-up van xevent-uitvoer, vervolg.

Meer informatie over back-uptaken

Werken met back-upapparaten en back-upmedia

Back-ups maken

Opmerking

Voor gedeeltelijke of alleen-kopiëren back-ups moet u respectievelijk de Transact-SQL BACKUP-instructie gebruiken met de PARTIAL of COPY_ONLY optie.

SSMS gebruiken

T-SQL gebruiken

Back-ups van gegevens herstellen

SSMS gebruiken

T-SQL gebruiken

Transactielogboeken herstellen (volledig herstelmodel)

SSMS gebruiken

T-SQL gebruiken

Verwante inhoud