BACKUP (Transact-SQL)

Maakt een back-up van een SQL-database.

Een product selecteren

Selecteer in de volgende rij de productnaam waarin u geïnteresseerd bent en alleen de informatie van dat product wordt weergegeven.

Zie Transact-SQL syntaxisconventiesvoor meer informatie over de syntaxisconventies.

* SQL Server *  

sql Managed Instance-

Analytics Platform
Systeem (PDW)

 

SQL Server

Hiermee maakt u een back-up van een volledige SQL Server-database om een databaseback-up te maken, of een of meer bestanden of bestandsgroepen van de database om een back-up van een bestand (BACKUP DATABASE) te maken. Maakt onder het volledige herstelmodel of bulksgewijs vastgelegde herstelmodel een back-up van het transactielogboek van de database om een logboekback-up (BACKUP LOG) te maken.

Syntaxis

--Back up a whole database
BACKUP DATABASE { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up specific files or filegroups
BACKUP DATABASE { database_name | @database_name_var }
 <file_or_filegroup> [ ,...n ]
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

--Create a partial backup
BACKUP DATABASE { database_name | @database_name_var }
 READ_WRITE_FILEGROUPS [ , <read_only_filegroup> [ ,...n ] ]
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up the transaction log (full and bulk-logged recovery models)
BACKUP LOG
  { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { <general_WITH_options> | <log_specific_options> } [ ,...n ] ]
[;]

--Back up all the databases on an instance of SQL Server (a server)

ALTER SERVER CONFIGURATION
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
[;]

BACKUP SERVER
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up a group of databases
ALTER DATABASE <database>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON

ALTER DATABASE <...>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
...

BACKUP GROUP {<database> [,... ]}
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

<backup_device>::=
 {
  { logical_device_name | @logical_device_name_var }
 | {   DISK
     | TAPE
     | URL } =
     { 'physical_device_name' | @physical_device_name_var | 'NUL' }
 }

<MIRROR TO clause>::=
 MIRROR TO <backup_device> [ ,...n ]

<file_or_filegroup>::=
 {
   FILE = { logical_file_name | @logical_file_name_var }
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
 }

<read_only_filegroup>::=
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

<general_WITH_options> [ ,...n ]::=
--Backup Set Options
   COPY_ONLY
 | [ COMPRESSION [ ALGORITHM = { MS_XPRESS | accelerator_algorithm } ] | NO_COMPRESSION ]
 | DESCRIPTION = { 'text' | @text_variable }
 | NAME = { backup_set_name | @backup_set_name_var }
 | CREDENTIAL
 | ENCRYPTION
 | FILE_SNAPSHOT
 | { EXPIREDATE = { 'date' | @date_var }
        | RETAINDAYS = { days | @days_var } }
 | { METADATA_ONLY | SNAPSHOT }

--Media Set Options
   { NOINIT | INIT }
 | { NOSKIP | SKIP }
 | { NOFORMAT | FORMAT }
 | MEDIADESCRIPTION = { 'text' | @text_variable }
 | MEDIANAME = { media_name | @media_name_variable }
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options
   BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options
   { NO_CHECKSUM | CHECKSUM }
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Compatibility Options
   RESTART

--Monitoring Options
   STATS [ = percentage ]

--Tape Options
   { REWIND | NOREWIND }
 | { UNLOAD | NOUNLOAD }

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

<log_specific_options> [ ,...n ]::=
--Log-specific Options
   { NORECOVERY | STANDBY = undo_file_name }
 | NO_TRUNCATE

Argumenten

DATABANK

Hiermee geeft u een volledige databaseback-up. Als er een lijst met bestanden en bestandsgroepen is opgegeven, wordt alleen een back-up gemaakt van die bestanden en bestandsgroepen. Tijdens een volledige of differentiële databaseback-up maakt SQL Server voldoende back-ups van het transactielogboek om een consistente database te produceren wanneer de back-up wordt hersteld.

Wanneer u een back-up herstelt die is gemaakt door BACKUP DATABASE (een gegevensback-up), wordt de volledige back-up hersteld. Alleen een logboekback-up kan worden hersteld naar een bepaalde tijd of transactie binnen de back-up.

Notitie

Alleen een volledige databaseback-up kan worden uitgevoerd op de master-database.

LOG

Hiermee geeft u alleen een back-up van het transactielogboek. Er wordt een back-up van het logboek gemaakt vanaf de laatste geslaagde back-up van het logboek naar het huidige einde van het logboek. Voordat u de eerste logboekback-up kunt maken, moet u een volledige back-up maken.

U kunt een logboekback-up herstellen naar een bepaald tijdstip of een specifieke transactie binnen de back-up door WITH STOPAT, STOPATMARKof STOPBEFOREMARK op te geven in uw INSTRUCTIE RESTORE LOG.

Notitie

Na een typische logboekback-up worden sommige transactielogboekrecords inactief, tenzij u WITH NO_TRUNCATE of COPY_ONLYopgeeft. Het logboek wordt afgekapt nadat alle records in een of meer virtuele logboekbestanden inactief zijn geworden. Als het logboek niet wordt afgekapt na routinelogboekback-ups, kan er een vertraging optreden bij het afkappen van logboeken. Zie Factoren die het afkappen van logboeken kunnen vertragenvoor meer informatie.

GROUP (<database>,... n)

Geïntroduceerd in SQL Server 2022 (16.x).

Een back-up maken van een groep databases. Maakt gebruik van back-up van momentopnamen. Vereist WITH METADATA_ONLY. Zie Een back-up van een Transact-SQL momentopname maken.

SERVER

Geïntroduceerd in SQL Server 2022 (16.x).

Maak een back-up van alle databases op een exemplaar van SQL Server. Maakt gebruik van back-up van momentopnamen. Vereist WITH METADATA_ONLY. Zie Een back-up van een Transact-SQL momentopname maken.

METADATA_ONLY

Geïntroduceerd in SQL Server 2022 (16.x).

Vereist voor back-up van momentopnamen. BACKUP SERVERof BACKUP GROUP... Zie Een back-up van een Transact-SQL momentopname maken.

METADATA_ONLY staat voor SNAPSHOT. VDI (Virtual Device Interface) maakt gebruik van SNAPSHOT. Zie VDI-verwijzing (Virtual Device Interface)voor meer informatie over VDI.

{ database_name | @database_name_var }

Is de database waaruit een back-up wordt gemaakt van het transactielogboek, de gedeeltelijke database of de volledige database. Als deze wordt opgegeven als een variabele (@database_name_var), kan deze naam worden opgegeven als een tekenreeksconstante (@database_name_var=databasenaam) of als een variabele van het gegevenstype tekenreeks, met uitzondering van de ntext of tekst gegevenstypen.

Notitie

Er kan geen back-up worden gemaakt van de gespiegelde database in een databasespiegelingsrelatie.

<file_or_filegroup> [ ,...n ]

Wordt alleen gebruikt met BACKUP DATABASE, geeft een databasebestand of bestandsgroep op die moet worden opgenomen in een bestandsback-up of geeft een alleen-lezen bestand of bestandsgroep op die moet worden opgenomen in een gedeeltelijke back-up.

FILE = { logical_file_name | @logical_file_name_var }

Is de logische naam van een bestand of een variabele waarvan de waarde gelijk is aan de logische naam van een bestand dat moet worden opgenomen in de back-up.

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Is de logische naam van een bestandsgroep of een variabele waarvan de waarde gelijk is aan de logische naam van een bestandsgroep die in de back-up moet worden opgenomen. Onder het eenvoudige herstelmodel is een back-up van een bestandsgroep alleen toegestaan voor een alleen-lezen bestandsgroep.

Notitie

Overweeg het gebruik van bestandsback-ups wanneer de databasegrootte en prestatievereisten een databaseback-up onpraktisch maken. Het NUL-apparaat kan worden gebruikt om de prestaties van back-ups te testen, maar mag niet worden gebruikt in productieomgevingen.

n
Is een tijdelijke aanduiding die aangeeft dat meerdere bestanden en bestandsgroepen kunnen worden opgegeven in een door komma's gescheiden lijst. Het getal is onbeperkt.

Zie volledige back-ups van bestanden en back-ups maken van bestanden en bestandsgroepenvoor meer informatie.

READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } [ ,...n ] ]

Hiermee geeft u een gedeeltelijke back-up. Een gedeeltelijke back-up bevat alle lees-/schrijfbestanden in een database: de primaire bestandsgroep en eventuele secundaire bestandsgroepen voor lezen/schrijven, en ook opgegeven alleen-lezenbestanden of bestandsgroepen.

READ_WRITE_FILEGROUPS

Hiermee geeft u op dat een back-up van alle lees-/schrijfbestandsgroepen wordt gemaakt in de gedeeltelijke back-up. Als de database het kenmerk Alleen-lezen heeft, bevat READ_WRITE_FILEGROUPS alleen de primaire bestandsgroep.

Belangrijk

Vermeld expliciet de lees-/schrijfbestandsgroepen met behulp van FILEGROUP in plaats van READ_WRITE_FILEGROUPS maakt een back-up van bestanden.

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Is de logische naam van een alleen-lezen bestandsgroep of een variabele waarvan de waarde gelijk is aan de logische naam van een alleen-lezen bestandsgroep die moet worden opgenomen in de gedeeltelijke back-up. Zie '<file_or_filegroup>' eerder in dit artikel voor meer informatie.

n
Is een tijdelijke aanduiding die aangeeft dat meerdere alleen-lezen bestandsgroepen kunnen worden opgegeven in een door komma's gescheiden lijst.

Zie Gedeeltelijke back-upsvoor meer informatie over gedeeltelijke back-ups.

TO <backup_device> [ ,...n ]

Geeft aan dat de bijbehorende set back-upapparaten een ongelezen mediaset is of de eerste van de spiegels binnen een gespiegelde mediaset (waarvoor een of meer MIRROR TO-componenten worden gedeclareerd).

<backup_device>
Hiermee geeft u een logisch of fysiek back-upapparaat op dat moet worden gebruikt voor de back-upbewerking.

{ logical_device_name | @logical_device_name_var }

van toepassing op: SQL Server
Is de logische naam van het back-upapparaat waarvan een back-up van de database wordt gemaakt. De logische naam moet de regels voor id's volgen. Als deze wordt opgegeven als een variabele (@logical_device_name_var), kan de naam van het back-upapparaat worden opgegeven als een tekenreeksconstante (@logical_device_name_var= naam van een logisch back-upapparaat) of als een variabele van een gegevenstype tekenreeks, met uitzondering van de ntext of tekst gegevenstypen.

{ DISK | TAPE | URL} = { 'physical_device_name' | @physical_device_name_var | 'NUL' }

Van toepassing op: SQL Server (URL vanaf SQL Server 2012 (11.x) SP1 CU2)

Hiermee geeft u een schijfbestand of tapeapparaat of een URL.

De URL-indeling wordt gebruikt voor het maken van back-ups naar Microsoft Azure Blob Storage of S3-compatibele objectopslag. Zie voor meer informatie en voorbeelden:

• BACK-up en herstel van SQL Server met Microsoft Azure Blob Storage. Zie zelfstudie: SQL Server Backup and Restore to Microsoft Azure Blob Storagevoor een zelfstudie.
• Back-up en herstel naar S3-compatibele opslag is geïntroduceerd in SQL Server 2022 (16.x), zie BACK-up en herstel van SQL Server met S3-compatibele objectopslag. Bekijk ook de optie voor BACK-up van SQL Server naar URL voor S3-compatibele objectopslag.

Notitie

Het NUL-schijfapparaat negeert alle informatie die naar het apparaat wordt verzonden en mag alleen worden gebruikt voor het testen. Dit is niet voor productiegebruik.

Belangrijk

Vanaf SQL Server 2012 (11.x) SP1 CU2 tot en met SQL Server 2014 (12.x) kunt u slechts een back-up maken naar één apparaat wanneer u een back-up maakt van de URL voor Azure Blob Storage. Als u een back-up wilt maken naar meerdere apparaten wanneer u een back-up maakt van een URL, moet u SQL Server 2016 (13.x) en hoger gebruiken en moet u SAS-tokens (Shared Access Signature) gebruiken. Zie voor voorbeelden van het maken van een Shared Access Signature SQL Server Backup to URL en Het maken van SQL-referenties vereenvoudigen met SAS-tokens (Shared Access Signature) in Azure Storage met PowerShell.

Een schijfapparaat hoeft niet te bestaan voordat het is opgegeven in een BACKUP-instructie. Als het fysieke apparaat bestaat en de INIT-optie niet is opgegeven in de BACK-upinstructie, wordt de back-up toegevoegd aan het apparaat.

Notitie

Het NUL-apparaat negeert alle invoer die naar dit bestand wordt verzonden, maar de back-up markeert nog steeds alle pagina's als back-up.

Zie Back-upapparatenvoor meer informatie.

Notitie

De optie TAPE wordt verwijderd in een toekomstige versie van SQL Server. Vermijd het gebruik van deze functie in nieuwe ontwikkelwerkzaamheden en plan om toepassingen te wijzigen die momenteel gebruikmaken van deze functie.

n
Is een tijdelijke aanduiding die aangeeft dat maximaal 64 back-upapparaten kunnen worden opgegeven in een door komma's gescheiden lijst.

SPIEGELEN NAAR <backup_device> [ ,...n ]

Hiermee geeft u een set van maximaal drie secundaire back-upapparaten op, die elk overeenkomen met de back-ups die zijn opgegeven in de TO-component. De component MIRROR TO moet hetzelfde type en hetzelfde nummer van de back-upapparaten opgeven als de TO-component. Het maximum aantal MIRROR TO-componenten is drie.

Deze optie is alleen beschikbaar in de Enterprise-editie van SQL Server.

Notitie

Voor MIRROR TO = DISKbepaalt BACKUP automatisch de juiste blokgrootte voor schijfapparaten op basis van de sectorgrootte van de schijf. Als de MIRROR TO-schijf is geformatteerd met een andere sectorgrootte dan de schijf die is opgegeven als het primaire back-upapparaat, mislukt de back-upopdracht. Als u back-ups wilt spiegelen naar apparaten met verschillende sectorgrootten, moet de parameter BLOCKSIZE worden opgegeven en moet deze worden ingesteld op de hoogste sectorgrootte van alle doelapparaten. Zie BLOKKENIZE verderop in dit onderwerp voor meer informatie over blokgrootte.

<backup_device>
Zie '<backup_device>', eerder in deze sectie.

n
Is een tijdelijke aanduiding die aangeeft dat maximaal 64 back-upapparaten kunnen worden opgegeven in een door komma's gescheiden lijst. Het aantal apparaten in de component MIRROR TO moet gelijk zijn aan het aantal apparaten in de TO-component.

Zie 'Mediafamilies in gespiegelde mediasets' in de sectie Opmerkingen verderop in dit artikel voor meer informatie.

[ volgende spiegeling naar ]
Is een tijdelijke aanduiding die aangeeft dat één BACKUP-instructie maximaal drie MIRROR TO-componenten kan bevatten, naast de enkele TO-component.

MET opties

Hiermee geeft u opties die moeten worden gebruikt met een back-upbewerking.

GELOOFSBRIEF

van toepassing op: SQL Server (te beginnen metSQL Server 2012 (11.x) SP1 CU2).

Wordt alleen gebruikt bij het maken van een back-up naar Azure Blob Storage.

FILE_SNAPSHOT

is van toepassing op: SQL Server (te beginnen met SQL Server 2016 (13.x)).

Wordt gebruikt voor het maken van een Azure-momentopname van de databasebestanden wanneer alle SQL Server-databasebestanden worden opgeslagen met behulp van Azure Blob Storage. Zie SQL Server-gegevensbestanden in Microsoft Azurevoor meer informatie. Sql Server Snapshot Backup maakt Azure-momentopnamen van de databasebestanden (gegevens en logboekbestanden) met een consistente status. Een consistente set Azure-momentopnamen vormen een back-up en worden vastgelegd in het back-upbestand. Het enige verschil tussen BACKUP DATABASE TO URL WITH FILE_SNAPSHOT en BACKUP LOG TO URL WITH FILE_SNAPSHOT is dat de laatste ook het transactielogboek afkapt, terwijl dat niet het geval is. Na de eerste volledige back-up van SQL Server die door SQL Server is vereist om de back-upketen tot stand te brengen, is slechts één back-up van het transactielogboek vereist om een database te herstellen naar het tijdstip van de back-up van het transactielogboek. Bovendien zijn er slechts twee back-ups van transactielogboeken vereist om een database te herstellen naar een bepaald tijdstip tussen het tijdstip van de twee back-ups van transactielogboeken.

DIFFERENTIAAL

Alleen gebruikt met BACKUP DATABASE, geeft aan dat de database of bestandsback-up alleen mag bestaan uit de gedeelten van de database of het bestand die zijn gewijzigd sinds de laatste volledige back-up. Een differentiële back-up neemt meestal minder ruimte in beslag dan een volledige back-up. Gebruik deze optie zodat alle afzonderlijke logboekback-ups die zijn uitgevoerd sinds de laatste volledige back-up niet hoeven te worden toegepast.

Notitie

Standaard maakt BACKUP DATABASE een volledige back-up.

Zie Differentiële back-upsvoor meer informatie.

CODERING

Wordt gebruikt om versleuteling voor een back-up op te geven. U kunt een versleutelingsalgoritmen opgeven om de back-up te versleutelen met of NO_ENCRYPTION opgeven dat de back-up niet is versleuteld. Versleuteling wordt aanbevolen om back-upbestanden te beveiligen. De lijst met algoritmen die u kunt opgeven, zijn:

• AES_128
• AES_192
• AES_256
• TRIPLE_DES_3KEY
• NO_ENCRYPTION

Als u ervoor kiest om te versleutelen, moet u ook de versleuteler opgeven met behulp van de versleutelingsopties:

• SERVER CERTIFICATE = Encryptor_Name
• SERVER ASYMMETRIC KEY = Encryptor_Name

De SERVER CERTIFICATE en SERVER ASYMMETRIC KEY zijn een certificaat en een asymmetrische sleutel die is gemaakt in master database. Zie respectievelijk CREATE CERTIFICATE en CREATE ASYMMETRIC KEY voor meer informatie.

Waarschuwing

Wanneer versleuteling wordt gebruikt in combinatie met het argument FILE_SNAPSHOT, wordt het metagegevensbestand zelf versleuteld met behulp van het opgegeven versleutelingsalgoritme en controleert het systeem of TDE- is voltooid voor de database. Er gebeurt geen extra versleuteling voor de gegevens zelf. De back-up mislukt als de database niet is versleuteld of als de versleuteling niet is voltooid voordat de back-upinstructie werd uitgegeven.

Opties voor back-upset

Deze opties worden uitgevoerd op de back-upset die door deze back-upbewerking wordt gemaakt.

Notitie

Als u een back-upset wilt opgeven voor een herstelbewerking, gebruikt u de optie FILE = <backup_set_file_number>. Zie 'Een back-upset opgeven' in RESTORE-argumentenvoor meer informatie over het opgeven van een back-upset.

COPY_ONLY

Hiermee geeft u op dat de back-up een back-up isdie niet van invloed is op de normale volgorde van back-ups. Een back-up met alleen kopiëren wordt onafhankelijk van uw regelmatig geplande, conventionele back-ups gemaakt. Een back-up met alleen kopiëren heeft geen invloed op uw algehele back-up- en herstelprocedures voor de database.

Back-ups met alleen kopiëren moeten worden gebruikt in situaties waarin een back-up wordt gemaakt voor een speciaal doel, zoals het maken van een back-up van het logboek voordat een onlinebestand wordt hersteld. Normaal gesproken wordt er eenmaal een back-up van een logboek met alleen-kopiëren gebruikt en vervolgens verwijderd.

• Bij gebruik met BACKUP DATABASEmaakt de COPY_ONLY optie een volledige back-up die niet als differentiële basis kan fungeren. De differentiële bitmap wordt niet bijgewerkt en differentiële back-ups gedragen zich alsof de back-up alleen-kopiëren niet bestaat. Volgende differentiële back-ups maken gebruik van de meest recente conventionele volledige back-up als basis.

  Belangrijk

  Als DIFFERENTIAL en COPY_ONLY samen worden gebruikt, wordt COPY_ONLY genegeerd en wordt er een differentiële back-up gemaakt.

• Wanneer deze wordt gebruikt met BACKUP LOG, maakt de COPY_ONLY optie een back-up van logboeken met alleen-kopiëren, waardoor het transactielogboek niet wordt afgekapt. De back-up van het alleen-kopiëren-logboek heeft geen effect op de logboekketen en andere logboekback-ups gedragen zich alsof de back-up alleen-kopiëren niet bestaat.

Zie Copy-Only Back-upsvoor meer informatie.

[ COMPRESSIE [ ALGORITME = ( { MS_XPRESS | accelerator_algorithm } ) ] | NO_COMPRESSION ]

Hiermee geeft u op of back-upcompressie wordt uitgevoerd op deze back-up, waarbij de standaardwaarde op serverniveau wordt overschreven.

Tijdens de installatie is het standaardgedrag geen back-upcompressie. Maar deze standaardinstelling kan worden gewijzigd door de standaardoptie voor back-upcompressie in te stellen serverconfiguratieoptie. Zie Servereigenschappen weergeven of wijzigenvoor informatie over het weergeven van de huidige waarde van deze optie.

Zie de sectie opmerkingen voor informatie over het gebruik van back-upcompressie met TDE (Transparent Data Encryption) ingeschakelde databases.

COMPRESSIE
Hiermee schakelt u expliciet back-upcompressie in.

NO_COMPRESSION
Schakelt back-upcompressie expliciet uit.

SQL Server 2022 (16.x) introduceert ALGORITHM, waarmee een compressie-algoritme voor de bewerking wordt geïdentificeerd. De standaardwaarde is MS_XPRESS. Als u geïntegreerde versnelling en offloadinghebt geconfigureerd, kunt u een accelerator van de oplossing gebruiken. Als u bijvoorbeeld Intel® QuickAssist Technology (QAT) voor SQL Serverhebt geconfigureerd, wordt in het volgende voorbeeld de back-up voltooid met de acceleratoroplossing, met qatzip-bibliotheek met QZ_DEFLATE met het compressieniveau 1.

BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = QAT_DEFLATE) 

DESCRIPTION = { 'tekst' | @text_variable }

Hiermee geeft u de vrije tekst die de back-upset beschrijft. De tekenreeks mag maximaal 255 tekens bevatten.

NAME = { backup_set_name | @backup_set_var }

Hiermee geeft u de naam van de back-upset. Namen mogen maximaal 128 tekens bevatten. Als NAAM niet is opgegeven, is deze leeg.

{ EXPIREDATE ='datum' | RETAINDAYS = dagen }

Hiermee geeft u op wanneer de back-upset voor deze back-up kan worden overschreven. Als deze opties beide worden gebruikt, heeft RETAINDAYS voorrang op EXPIREDATE.

Als geen van beide opties is opgegeven, wordt de vervaldatum bepaald door de media retention configuratie-instelling. Zie Serverconfiguratieoptiesvoor meer informatie.

Belangrijk

Met deze opties voorkomt u dat SQL Server een bestand overschrijft. Tapes kunnen worden gewist met behulp van andere methoden en schijfbestanden kunnen worden verwijderd via het besturingssysteem. Zie SKIP en FORMAT in dit onderwerp voor meer informatie over verloopverificatie.

EXPIREDATE = { 'datum' | @date_var }
Hiermee geeft u op wanneer de back-upset verloopt en kan worden overschreven. Als deze datum wordt opgegeven als een variabele (@date_var), moet deze datum het geconfigureerde systeem volgen datum/tijd notatie en worden opgegeven als een van de volgende:

• Een tekenreeksconstante (@date_var= datum)
• Een variabele van het gegevenstype tekenreeks (met uitzondering van de ntext- of tekst gegevenstypen)
• Een smalldatetime-
• Een datum/tijd- variabele

Bijvoorbeeld:

• 'Dec 31, 2020 11:59 PM'
• '1/1/2021'

Zie datum- en tijdtypenvoor meer informatie over het opgeven van datum/tijd waarden.

Notitie

Als u de vervaldatum wilt negeren, gebruikt u de optie SKIP.

RETAINDAYS = { dagen | @days_var }
Hiermee geeft u het aantal dagen op dat moet worden verstreken voordat deze back-upmediaset kan worden overschreven. Als deze wordt opgegeven als een variabele (@days_var), moet deze worden opgegeven als een geheel getal.

{ METADATA_ONLY | MOMENTOPNAME }

van toepassing op: SQL Server 2022 (16.x)

METADATA_ONLY en SNAPSHOT zijn synoniemen.

Opties voor mediaset

Deze opties werken op de mediaset als geheel.

{ NOINIT | INIT }

Hiermee bepaalt u of de back-upbewerking wordt toegevoegd aan of overschreven door de bestaande back-upsets op de back-upmedia. De standaardinstelling is om toe te voegen aan de meest recente back-upset op de media (NOINIT).

Notitie

Voor informatie over de interacties tussen { NOINIT | INIT } en { NOSKIP- | SKIP }, zie Opmerkingen verderop in dit onderwerp.

NOINIT
Geeft aan dat de back-upset wordt toegevoegd aan de opgegeven mediaset, waarbij bestaande back-upsets behouden blijven. Als er een mediawachtwoord is gedefinieerd voor de mediaset, moet het wachtwoord worden opgegeven. NOINIT is de standaardwaarde.

Zie mediasets, mediafamilies en back-upsetsvoor meer informatie.

INIT
Hiermee geeft u op dat alle back-upsets moeten worden overschreven, maar de mediaheader behouden blijft. Als INIT is opgegeven, wordt een bestaande back-upset op dat apparaat overschreven als voorwaarden zijn toe te staan. Standaard controleert BACKUP op de volgende voorwaarden en wordt de back-upmedia niet overschreven als er een van beide voorwaarden bestaat:

• Een back-upset is nog niet verlopen. Zie de opties voor EXPIREDATE en RETAINDAYS voor meer informatie.
• De naam van de back-upset die is opgegeven in de back-upinstructie, indien opgegeven, komt niet overeen met de naam op de back-upmedia. Zie de optie NAME eerder in deze sectie voor meer informatie.

Als u deze controles wilt overschrijven, gebruikt u de optie SKIP.

Zie mediasets, mediafamilies en back-upsetsvoor meer informatie.

{ NOSKIP | SKIP }

Bepaalt of een back-upbewerking de vervaldatum en tijd van de back-upsets op de media controleert voordat deze worden overschreven.

Notitie

Voor informatie over de interacties tussen { NOINIT | INIT } en { NOSKIP- | SKIP }, zie 'Opmerkingen', verderop in dit onderwerp.

NOSKIP
Geeft de INSTRUCTIE BACKUP de opdracht om de vervaldatum van alle back-upsets op de media te controleren voordat ze kunnen worden overschreven. Dit is het standaardgedrag.

OVERSLAAN
Hiermee wordt het controleren van het verlopen van de back-upset en de naam uitgeschakeld die meestal wordt uitgevoerd door de BACK-UP-instructie om te voorkomen dat back-upsets worden overschreven. Voor informatie over de interacties tussen { INIT | NOINIT } en { NOSKIP | SKIP }, zie 'Opmerkingen', verderop in dit artikel. Als u de vervaldatums van back-upsets wilt weergeven, voert u een query uit op de expiration_date kolom van de backupset geschiedenistabel.

{ NOFORMAT | FORMAT }

Hiermee geeft u op of de mediaheader moet worden geschreven op de volumes die voor deze back-upbewerking worden gebruikt, en eventuele bestaande mediaheader- en back-upsets moet worden overschreven.

NOFORMAT
Hiermee geeft u op dat de back-upbewerking de bestaande mediaheader- en back-upsets behoudt op de mediavolumes die voor deze back-upbewerking worden gebruikt. Dit is het standaardgedrag.

FORMATTEREN
Hiermee geeft u op dat er een nieuwe mediaset wordt gemaakt. FORMAT zorgt ervoor dat de back-upbewerking een nieuwe mediaheader schrijft op alle mediavolumes die worden gebruikt voor de back-upbewerking. De bestaande inhoud van het volume wordt ongeldig, omdat bestaande mediaheaders en back-upsets worden overschreven.

Belangrijk

Gebruik FORMAT zorgvuldig. Als u een volume van een mediaset opmaakt, wordt de hele mediaset onbruikbaar. Als u bijvoorbeeld één tape initialiseert die hoort bij een bestaande gestreepte mediaset, wordt de hele mediaset nutteloos weergegeven.

Format opgeven impliceert SKIP; SKIP hoeft niet expliciet te worden vermeld.

MEDIADESCRIPTION = { text | @text_variable }

Hiermee geeft u de beschrijving van vrije tekst, maximaal 255 tekens, van de mediaset.

MEDIANAME = { media_name | @media_name_variable }

Hiermee geeft u de medianaam voor de volledige back-upmediaset. De medianaam mag niet langer zijn dan 128 tekens. Als MEDIANAME is opgegeven, moet deze overeenkomen met de eerder opgegeven medianaam die al bestaat op de back-upvolumes. Als deze niet is opgegeven of als de optie SKIP is opgegeven, is er geen verificatiecontrole van de medianaam.

BLOCKSIZE = { blocksize | @blocksize_variable }

Hiermee geeft u de fysieke blokgrootte, in bytes. De ondersteunde grootten zijn 512, 1024, 2048, 4096, 8192, 16384, 32768 en 65536 (64 KB) bytes. De standaardwaarde is 65536 voor tapeapparaten en 512 anders. Deze optie is doorgaans niet nodig omdat BACKUP automatisch een blokgrootte selecteert die geschikt is voor het apparaat. Expliciet aangeven dat een blokgrootte de automatische selectie van blokgrootte overschrijft.

Als u een back-up maakt die u wilt kopiëren naar en terugzetten vanaf een cd-rom, geeft u BLOCKSIZE=2048 op.

Notitie

Deze optie is doorgaans alleen van invloed op de prestaties bij het schrijven naar tapeapparaten.

Opties voor gegevensoverdracht

BUFFERCOUNT = { buffercount | @buffercount_variable }

Hiermee geeft u het totale aantal I/O-buffers dat moet worden gebruikt voor de back-upbewerking. U kunt elk positief geheel getal opgeven; Grote aantallen buffers kunnen echter 'onvoldoende geheugen'-fouten veroorzaken vanwege onvoldoende virtuele adresruimte in het Sqlservr.exe proces.

De totale ruimte die door de buffers wordt gebruikt, wordt bepaald door: BUFFERCOUNT * MAXTRANSFERSIZE.

Notitie

Zie voor belangrijke informatie over het gebruik van de optie BUFFERCOUNT de optie Onjuiste BufferCount-gegevensoverdracht kan leiden tot een OOM-voorwaarde blog.

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Hiermee geeft u de grootste overdrachtseenheid in bytes die moet worden gebruikt tussen SQL Server en de back-upmedia. De mogelijke waarden zijn veelvouden van 65536 bytes (64 kB) tot 4194304 bytes (4 MB). In een specifiek geval van back-up naar URL naar S3-compatibele objectopslag is MAXTRANSFERSIZE 10 MB. Zie Opmerkingenvoor meer informatie.

Wanneer u back-ups maakt met behulp van de SQL Writer-service, als de database FILESTREAM-heeft geconfigureerd of voor geheugen geoptimaliseerde bestandsgroepenbevat, moet de MAXTRANSFERSIZE op het moment van een herstel groter dan of gelijk zijn aan de MAXTRANSFERSIZE die is gebruikt toen de back-up werd gemaakt.

Voor TDE (Transparent Data Encryption) ingeschakelde databases met één gegevensbestand, is de standaard MAXTRANSFERSIZE 65536 (64 KB). Voor niet-TDE-versleutelde databases is de standaard-MAXTRANSFERSIZE 1048576 (1 MB) bij het gebruik van back-up naar SCHIJF en 65536 (64 kB) bij gebruik van VDI of TAPE. Zie de sectie Opmerkingen voor meer informatie over het gebruik van back-upcompressie met met TDE versleutelde databases.

Opties voor foutbeheer

Met deze opties kunt u bepalen of back-upcontrolesommen zijn ingeschakeld voor de back-upbewerking en of de bewerking stopt bij het optreden van een fout.

{ NO_CHECKSUM | CONTROLESOM }

Hiermee bepaalt u of back-upcontrolesommen zijn ingeschakeld.

NO_CHECKSUM
Schakelt het genereren van back-upcontrolesommen (en de validatie van paginacontrolesommen) expliciet uit. Dit is het standaardgedrag.

CHECKSUM
Hiermee geeft u op dat de back-upbewerking elke pagina controleert op de controlesom en gescheurde pagina, indien ingeschakeld en beschikbaar, en een controlesom genereert voor de volledige back-up.

Het gebruik van back-upcontrolesommen kan van invloed zijn op de werkbelasting en de back-updoorvoer.

Zie Mogelijke mediafouten tijdens back-up en herstelvoor meer informatie.

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Hiermee bepaalt u of een back-upbewerking wordt gestopt of voortgezet nadat een paginacontrolefout is opgetreden.

STOP_ON_ERROR
Geeft back-up de opdracht om te mislukken als een paginacontroleom niet controleert. Dit is het standaardgedrag.

CONTINUE_AFTER_ERROR
Geeft back-up de opdracht om door te gaan ondanks fouten zoals ongeldige controlesommen of gescheurde pagina's.

Als u geen back-up kunt maken van de staart van het logboek met behulp van de optie NO_TRUNCATE wanneer de database is beschadigd, kunt u een back-up van het tail-logboeklogboek proberen door CONTINUE_AFTER_ERROR op te geven in plaats van NO_TRUNCATE.

Zie Mogelijke mediafouten tijdens back-up en herstelvoor meer informatie.

Compatibiliteitsopties

HERSTARTEN

Vanaf SQL Server 2008 (10.0.x) heeft dit geen effect. Deze optie wordt geaccepteerd door de versie voor compatibiliteit met eerdere versies van SQL Server.

Bewakingsopties

STATS [ = percentage ]

Geeft een bericht weer telkens wanneer een ander percentage is voltooid en wordt gebruikt om de voortgang te meten. Als percentage wordt weggelaten, wordt in SQL Server een bericht weergegeven nadat elke 10 procent is voltooid.

De optie STATS rapporteert het percentage voltooid vanaf de drempelwaarde voor het rapporteren van het volgende interval. Dit is ongeveer het opgegeven percentage; Als bijvoorbeeld met STATS=10 het voltooide bedrag 40 procent is, kan de optie 43 procent weergeven. Voor grote back-upsets is dit geen probleem, omdat het percentage voltooid zeer langzaam wordt verplaatst tussen voltooide I/O-aanroepen.

Tapeopties

Deze opties worden alleen gebruikt voor TAPE-apparaten. Als er een niet-tape-apparaat wordt gebruikt, worden deze opties genegeerd.

{ TERUGSPOELEN | NOREWIND }

TERUGSPOELEN
Hiermee geeft u op dat SQL Server de tape vrijgeeft en terugspoelen. REWIND is de standaardinstelling.

NOREWIND
Hiermee geeft u op dat SQL Server de tape geopend houdt na de back-upbewerking. U kunt deze optie gebruiken om de prestaties te verbeteren bij het uitvoeren van meerdere back-upbewerkingen op een tape.

NOREWIND impliceert NOUNLOAD en deze opties zijn niet compatibel binnen één BACKUP-instructie.

Notitie

Als u NOREWINDgebruikt, behoudt het exemplaar van SQL Server het eigendom van het tapestation totdat een BACK-up- of RESTORE-instructie die in hetzelfde proces wordt uitgevoerd, de optie REWIND of UNLOAD gebruikt, of het serverexemplaren wordt afgesloten. Door de tape open te houden, hebben andere processen geen toegang tot de tape. Zie Back-upapparatenvoor informatie over het weergeven van een lijst met geopende tapes en het sluiten van een open tape.

{ UNLOAD | NOUNLOAD }

Notitie

UNLOAD en NOUNLOAD zijn sessie-instellingen die blijven bestaan gedurende de levensduur van de sessie of totdat deze opnieuw is ingesteld door het alternatief op te geven.

UITLADEN
Hiermee geeft u op dat de tape automatisch opnieuw wordt opgestart en wordt verwijderd wanneer de back-up is voltooid. UNLOAD is de standaardinstelling wanneer een sessie begint.

NOUNLOAD
Hiermee geeft u op dat na de BACKUP-bewerking de tape op het tapestation geladen blijft.

Notitie

Voor een back-up naar een tapeback-upapparaat is de BLOCKSIZE optie om de prestaties van de back-upbewerking te beïnvloeden. Deze optie is doorgaans alleen van invloed op de prestaties bij het schrijven naar tapeapparaten.

Logboekspecifieke opties

Deze opties worden alleen gebruikt met BACKUP LOG.

Notitie

Als u geen logboekback-ups wilt maken, gebruikt u het eenvoudige herstelmodel. Zie Recovery Modelsvoor meer informatie.

{ NORECOVERY | STAND-BY = undo_file_name }

NORECOVERY
Hiermee wordt een back-up gemaakt van de staart van het logboek en blijft de database in de status HERSTELLEN. NORECOVERY is handig bij het uitvoeren van een failover naar een secundaire database of bij het opslaan van de staart van het logboek vóór een RESTORE-bewerking.

Als u een logboekback-up wilt uitvoeren die de afkapping van logboeken overslaat en vervolgens de database atomisch herstelt, gebruikt u de NO_TRUNCATE en NORECOVERY opties samen.

STAND-BY-=standby_file_name
Hiermee wordt een back-up gemaakt van de staart van het logboek en blijft de database in een alleen-lezen- en STAND-BY-status. De STAND-BY-component schrijft stand-bygegevens (het terugdraaien, maar met de optie voor verdere herstelbewerkingen). Het gebruik van de STAND-BY-optie is gelijk aan BACK-UPLOGBOEK MET NORECOVERY, gevolgd door een RESTORE WITH STANDBY.

Voor het gebruik van de stand-bymodus is een stand-bybestand vereist, opgegeven door standby_file_name, waarvan de locatie is opgeslagen in het logboek van de database. Als het opgegeven bestand al bestaat, overschrijft de database-engine het; als het bestand niet bestaat, maakt de database-engine het. Het stand-bybestand wordt onderdeel van de database.

Dit bestand bevat de teruggedraaide wijzigingen, die moeten worden omgekeerd als HERSTELLOGBOEKbewerkingen vervolgens moeten worden toegepast. Er moet voldoende schijfruimte zijn om het stand-bybestand te laten groeien, zodat het alle afzonderlijke pagina's uit de database kan bevatten die zijn gewijzigd door niet-doorgevoerde transacties terug te draaien.

NO_TRUNCATE

Hiermee geeft u op dat het transactielogboek niet mag worden afgekapt en ervoor zorgt dat de database-engine de back-up probeert te maken, ongeacht de status van de database. Daarom kan een back-up met NO_TRUNCATE onvolledige metagegevens hebben. Met deze optie kunt u een back-up maken van het transactielogboek in situaties waarin de database is beschadigd.

De NO_TRUNCATE optie back-uplogboek is gelijk aan het opgeven van zowel COPY_ONLY als CONTINUE_AFTER_ERROR.

Zonder de optie NO_TRUNCATE moet de database de status ONLINE hebben. Als de database de status ONDERBROKEN heeft, kunt u mogelijk een back-up maken door NO_TRUNCATEop te geven. Maar als de database de status OFFLINE of NOOD heeft, is BACKUP niet toegestaan, zelfs niet met NO_TRUNCATE. Zie databasestatussenvoor informatie over databasestatussen.

Over het werken met BACK-ups van SQL Server

In deze sectie worden de volgende essentiële back-upconcepten geïntroduceerd:

back-uptypenafkapping van transactielogboekenBack-upmedia opmakenWerken met back-upapparaten en mediasetsSQL Server-back-ups herstellen

Notitie

Zie Overzicht van back-upsvoor een inleiding tot back-up in SQL Server.

Back-uptypen

De ondersteunde back-uptypen zijn als volgt afhankelijk van het herstelmodel van de database

• Alle herstelmodellen ondersteunen volledige en differentiële back-ups van gegevens.

  Bereik van back-up	Back-uptypen
  Hele database	databaseback-ups betrekking hebben op de hele database. Optioneel kan elke databaseback-up fungeren als de basis van een reeks van een of meer differentiële databaseback-ups.
  Gedeeltelijke database	gedeeltelijke back-ups betrekking hebben op bestandsgroepen voor lezen/schrijven en, mogelijk, een of meer alleen-lezen bestanden of bestandsgroepen. Optioneel kan elke gedeeltelijke back-up fungeren als basis van een reeks van een of meer differentiële gedeeltelijke back-ups.
  Bestand of bestandsgroep	bestandsback-ups betrekking hebben op een of meer bestanden of bestandsgroepen en zijn alleen relevant voor databases die meerdere bestandsgroepen bevatten. Onder het eenvoudige herstelmodel zijn bestandsback-ups in wezen beperkt tot alleen-lezen secundaire bestandsgroepen. Optioneel kan elke bestandsback-up fungeren als de basis van een reeks van een of meer differentiële bestandsback-ups.

• Onder het volledige herstelmodel of het bulksgewijs vastgelegde herstelmodel bevatten conventionele back-ups ook sequentiële back-ups van transactielogboekback-ups (of logboekback-ups), die vereist zijn. Elke logboekback-up dekt het gedeelte van het transactielogboek dat actief was toen de back-up werd gemaakt en bevat alle logboekrecords waarvan geen back-up is gemaakt in een vorige logboekback-up.

  Als u de blootstelling aan werkverlies wilt minimaliseren, moet u regelmatig back-ups van logboeken plannen tegen administratieve overhead. 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.

  U wordt aangeraden logboekback-ups op een afzonderlijk volume te plaatsen dan de databaseback-ups.

  Notitie

  Voordat u de eerste logboekback-up kunt maken, moet u een volledige back-up maken.

• Een alleen-kopiëren back-up is een speciale volledige back-up of logboekback-up die onafhankelijk is van de normale volgorde van conventionele back-ups. Als u een back-up met alleen kopiëren wilt maken, geeft u de optie COPY_ONLY op in uw BACKUP-instructie. Zie Copy-Only Back-upsvoor meer informatie.

Afkapping van transactielogboek

Om te voorkomen dat het transactielogboek van een database volloopt, zijn routineback-ups essentieel. Onder het eenvoudige herstelmodel vindt afkapping van logboeken automatisch plaats nadat u een back-up van de database hebt gemaakt en onder het volledige herstelmodel nadat u een back-up van het transactielogboek hebt gemaakt. Soms kan het afkappingsproces echter worden vertraagd. Zie Het transactielogboekvoor informatie over factoren die het afkappen van logboeken kunnen vertragen.

Notitie

De BACKUP LOG WITH NO_LOG en WITH TRUNCATE_ONLY opties zijn stopgezet. Als u het volledige herstelmodel of het bulksgewijs vastgelegde herstelmodel gebruikt en u de back-upketen van het logboek uit een database moet verwijderen, schakelt u over naar het eenvoudige herstelmodel. Zie Het herstelmodel van een database-weergeven of wijzigen voor meer informatie.

Back-upmedia opmaken

Back-upmedia worden opgemaakt met een BACKUP-instructie als en alleen als een van de volgende waar is:

• De optie FORMAT is opgegeven.
• De media zijn leeg.
• De bewerking schrijft een vervolgband.

Werken met back-upapparaten en mediasets

Back-ups maken van apparaten in een gestreepte mediaset (een stripe-set)

Een stripe set is een set schijfbestanden waarop gegevens worden verdeeld in blokken en gedistribueerd in een vaste volgorde. Het aantal back-upapparaten dat in een stripeset wordt gebruikt, moet hetzelfde blijven (tenzij de media opnieuw worden geïnitialiseerd met FORMAT).

In het volgende voorbeeld wordt een back-up van de AdventureWorks2022-database naar een nieuwe gestreepte mediaset geschreven die gebruikmaakt van drie schijfbestanden.

BACKUP DATABASE AdventureWorks2022
TO DISK = 'X:\SQLServerBackups\AdventureWorks1.bak',
DISK = 'Y:\SQLServerBackups\AdventureWorks2.bak',
DISK = 'Z:\SQLServerBackups\AdventureWorks3.bak'
WITH FORMAT,
  MEDIANAME = 'AdventureWorksStripedSet0',
  MEDIADESCRIPTION = 'Striped media set for AdventureWorks2022 database';
GO

Nadat een back-upapparaat is gedefinieerd als onderdeel van een stripe-set, kan het niet worden gebruikt voor een back-up van één apparaat, tenzij FORMAT is opgegeven. Op dezelfde manier kan een back-upapparaat dat niet-gestreepte back-ups bevat, niet worden gebruikt in een stripe-set, tenzij FORMAT is opgegeven. Als u een gestreepte back-upset wilt splitsen, gebruikt u FORMAT.

Als geen MEDIANAME of MEDIADESCRIPTION wordt opgegeven wanneer een mediakoptekst wordt geschreven, is het veld voor de mediakoptekst die overeenkomt met het lege item leeg.

Werken met een gespiegelde mediaset

Back-ups worden doorgaans niet gemirroerd en BACK-upinstructies bevatten gewoon een TO-component. Een totaal van vier spiegels is echter mogelijk per mediaset. Voor een gespiegelde mediaset schrijft de back-upbewerking naar meerdere groepen back-upapparaten. Elke groep back-upapparaten bestaat uit één spiegel binnen de gespiegelde mediaset. Elke spiegel moet dezelfde hoeveelheid en hetzelfde type fysieke back-upapparaten gebruiken, die allemaal dezelfde eigenschappen moeten hebben.

Als u een back-up wilt maken van een gespiegelde mediaset, moeten alle spiegels aanwezig zijn. Als u een back-up wilt maken van een gespiegelde mediaset, geeft u de TO-component op om de eerste spiegel op te geven en geeft u een MIRROR TO component op voor elke extra spiegel.

Voor een gespiegelde mediaset moet elke MIRROR TO component hetzelfde aantal en type apparaten weergeven als de TO-component. In het volgende voorbeeld wordt naar een gespiegelde mediaset geschreven die twee spiegels bevat en drie apparaten per spiegel gebruikt:

BACKUP DATABASE AdventureWorks2022
TO DISK = 'X:\SQLServerBackups\AdventureWorks1a.bak',
  DISK = 'Y:\SQLServerBackups\AdventureWorks2a.bak',
  DISK = 'Z:\SQLServerBackups\AdventureWorks3a.bak'
MIRROR TO DISK='X:\SQLServerBackups\AdventureWorks1b.bak',
  DISK = 'Y:\SQLServerBackups\AdventureWorks2b.bak',
  DISK = 'Z:\SQLServerBackups\AdventureWorks3b.bak';
GO

Belangrijk

In dit voorbeeld kunt u het testen op uw lokale systeem. In de praktijk zou het maken van back-ups naar meerdere apparaten op hetzelfde station de prestaties schaden en zou de redundantie waarvoor gespiegelde mediasets zijn ontworpen, worden geëlimineerd.

Mediafamilies in gespiegelde mediasets

Elk back-upapparaat dat is opgegeven in de TO component van een BACKUP-instructie komt overeen met een mediafamilie. Als in de TO component bijvoorbeeld drie apparaten worden vermeld, schrijft BACKUP gegevens naar drie mediafamilies. In een gespiegelde mediaset moet elke spiegel een kopie van elke mediafamilie bevatten. Daarom moet het aantal apparaten in elke spiegel identiek zijn.

Wanneer voor elke spiegel meerdere apparaten worden vermeld, bepaalt de volgorde van de apparaten welke mediafamilie naar een bepaald apparaat wordt geschreven. In elk van de lijsten met apparaten komt het tweede apparaat bijvoorbeeld overeen met de tweede mediafamilie. Voor de apparaten in het bovenstaande voorbeeld wordt de correspondentie tussen apparaten en mediafamilies weergegeven in de volgende tabel.

Spiegel	Mediafamilie 1	Mediafamilie 2	Mediafamilie 3
0	Z:\AdventureWorks1a.bak	Z:\AdventureWorks2a.bak	Z:\AdventureWorks3a.bak
1	Z:\AdventureWorks1b.bak	Z:\AdventureWorks2b.bak	Z:\AdventureWorks3b.bak

Er moet altijd een back-up van een mediafamilie worden gemaakt op hetzelfde apparaat binnen een specifieke spiegel. Elke keer dat u een bestaande mediaset gebruikt, moet u daarom de apparaten van elke spiegel in dezelfde volgorde weergeven als de apparaten die zijn opgegeven toen de mediaset werd gemaakt.

Zie Gespiegelde back-upmediasetsvoor meer informatie over gespiegelde mediasets. Zie Mediasets, mediafamilies en back-upsetsvoor meer informatie over mediasets en mediafamilies in het algemeen.

BACK-ups van SQL Server herstellen

Als u een database wilt herstellen en eventueel wilt herstellen om deze online te brengen of om een bestand of bestandsgroep te herstellen, gebruikt u de instructie Transact-SQL RESTORE of sql Server Management Studio Restore-taken. Zie Overzicht van herstellen en herstellenvoor meer informatie.

Aanvullende overwegingen over BACK-UPopties

Interactie van SKIP, NOSKIP, INIT en NOINIT

In deze tabel worden interacties beschreven tussen de {NOINIT- | INIT } en { NOSKIP- | SKIP } opties.

Notitie

Als de tapemedia leeg zijn of het back-upbestand van de schijf niet bestaat, schrijven al deze interacties een mediaheader en gaan verder. Als de media niet leeg zijn en geen geldige mediaheader hebben, geven deze bewerkingen feedback waarin wordt aangegeven dat dit geen geldige MTF-media is en de back-upbewerking wordt beëindigd.

Optie Overslaan	NOINIT	INIT
NOSKIP	Als het volume een geldige mediakop bevat, controleert u of de medianaam overeenkomt met de opgegeven MEDIANAME, indien van toepassing. Als deze overeenkomt, voegt u de back-upset toe, waarbij alle bestaande back-upsets behouden blijven. Als het volume geen geldige mediaheader bevat, treedt er een fout op.	Als het volume een geldige mediaheader bevat, voert u de volgende controles uit: Als MEDIANAME is opgegeven, controleert u of de opgegeven medianaam overeenkomt met de medianaam van de mediaheader.1 Controleert of er geen niet-verlopen back-upsets al op de media staan. Als dat zo is, wordt de back-up beëindigd. Als deze controles worden doorgegeven, overschrijft u alle back-upsets op de media, waarbij alleen de mediaheader behouden blijft. Als het volume geen geldige mediaheader bevat, genereert u er een met opgegeven MEDIANAME en MEDIADESCRIPTION, indien van toepassing.
OVERSLAAN	Als het volume een geldige mediaheader bevat, voegt u de back-upset toe, waarbij alle bestaande back-upsets behouden blijven.	Als het volume een geldige2 mediaheader bevat, overschrijft u alle back-upsets op de media, waarbij alleen de mediaheader behouden blijft. Als de media leeg zijn, genereert u een mediaheader met behulp van de opgegeven MEDIANAME en MEDIADESCRIPTION, indien van toepassing.

¹ De gebruiker moet behoren tot de juiste vaste database- of serverfuncties om een back-upbewerking uit te voeren.

² geldigheid bevat het MTF-versienummer en andere headergegevens. Als de opgegeven versie niet wordt ondersteund of een onverwachte waarde, treedt er een fout op.

Compatibiliteit

Voorzichtigheid

Back-ups die zijn gemaakt door een recentere versie van SQL Server, kunnen niet worden hersteld in eerdere versies van SQL Server.

BACKUP ondersteunt de optie RESTART om compatibiliteit met eerdere versies van SQL Server te bieden. Maar OPNIEUW OPSTARTEN heeft geen effect.

Opmerkingen

Database- of logboekback-ups kunnen worden toegevoegd aan een schijf of tapeapparaat, zodat een database en de transactielogboeken op één fysieke locatie kunnen worden bewaard.

De BACKUP-instructie is niet toegestaan in een expliciete of impliciete transactie.

U kunt geen back-ups maken van een database in de volgende statussen:

• Herstellen
• Standby
• Alleen-lezen

Back-upbewerkingen op meerdere platforms, zelfs tussen verschillende processortypen, kunnen worden uitgevoerd zolang de sortering van de database wordt ondersteund door het besturingssysteem.

Vanaf SQL Server 2016 (13.x) maakt het instellen van MAXTRANSFERSIZEgroter dan 65536 (64 kB) een geoptimaliseerd compressie-algoritme mogelijk voor Transparent Data Encryption (TDE) versleutelde databases die eerst een pagina ontsleutelen, comprimeren en vervolgens opnieuw versleutelen. Als MAXTRANSFERSIZE niet is opgegeven of als MAXTRANSFERSIZE = 65536 (64 kB) wordt gebruikt, comprimeert back-upcompressie met met TDE versleutelde databases de versleutelde pagina's rechtstreeks en levert dit mogelijk geen goede compressieverhoudingen op. Zie Back-upcompressie voor databases met TDE-functionaliteitvoor meer informatie.

Vanaf SQL Server 2019 (15.x) CU5 is het instellen van MAXTRANSFERSIZE niet meer vereist om dit geoptimaliseerde compressie-algoritme met TDE in te schakelen. Als de back-upopdracht is opgegeven WITH COMPRESSION of de standaardconfiguratie van de back-upcompressie server is ingesteld op 1, wordt MAXTRANSFERSIZE automatisch verhoogd naar 128 K om het geoptimaliseerde algoritme in te schakelen. Als MAXTRANSFERSIZE is opgegeven in de back-upopdracht met een waarde > 64 K, wordt de opgegeven waarde gehonoreerd. Met andere woorden, SQL Server verlaagt nooit automatisch de waarde, maar verhoogt deze alleen. Als u een back-up wilt maken van een met TDE versleutelde database met MAXTRANSFERSIZE = 65536, moet u WITH NO_COMPRESSION opgeven of ervoor zorgen dat de standaardconfiguratie van back-upcompressie is ingesteld serverconfiguratie is ingesteld op 0.

Notitie

Er zijn enkele gevallen waarin de standaard-MAXTRANSFERSIZE groter is dan 64.000.

• Wanneer de database meerdere gegevensbestanden heeft gemaakt, wordt MAXTRANSFERSIZE> 64K gebruikt.
• Bij het uitvoeren van back-ups naar URL naar Azure Blob Storage, de standaard-MAXTRANSFERSIZE = 1048576 (1 MB).
• Bij het uitvoeren van back-ups naar URL naar S3-compatibele objectopslag, de standaard MAXTRANSFERSIZE = 10485760 (10 MB).

Zelfs als een van deze voorwaarden van toepassing is, moet u expliciet MAXTRANSFERSIZE groter dan 64.000 in uw back-upopdracht instellen om het geoptimaliseerde algoritme voor back-upcompressie op te halen, tenzij u zich op SQL Server 2019 (15.x) CU5 of hoger bevindt.

Bij elke geslaagde back-upbewerking wordt standaard een vermelding toegevoegd aan het SQL Server-foutenlogboek en in het gebeurtenislogboek van het systeem. Als u heel vaak een back-up van het logboek maakt, worden deze succesberichten snel verzameld, wat resulteert in grote foutenlogboeken die het vinden van andere berichten moeilijk kunnen maken. In dergelijke gevallen kunt u deze logboekvermeldingen onderdrukken met behulp van traceringsvlag 3226, als geen van uw automatisering of bewaking afhankelijk is van deze vermeldingen. Zie traceringsvlagmenvoor meer informatie.

Interoperabiliteit

SQL Server maakt gebruik van een online back-upproces om een databaseback-up toe te staan terwijl de database nog steeds wordt gebruikt. Tijdens een back-up zijn de meeste bewerkingen mogelijk; De instructies INSERT, UPDATE of DELETE zijn bijvoorbeeld toegestaan tijdens een back-upbewerking.

Bewerkingen die niet kunnen worden uitgevoerd tijdens een back-up van een database of transactielogboek zijn onder andere:

• Bestandsbeheerbewerkingen zoals de ALTER DATABASE-instructie met de ADD FILE- of REMOVE FILE-opties.

• Database verkleinen of bestandsbewerkingen verkleinen. Dit omvat autoshrink-bewerkingen.

Als een back-upbewerking overlapt met een bestandsbeheer of DBCC SHRINK bewerking, ontstaat er een conflict. Ongeacht welke van de conflicterende bewerking eerst is gestart, wacht de tweede bewerking totdat de vergrendeling die door de eerste bewerking is ingesteld, een time-out optreedt (de time-outperiode wordt bepaald door een time-outinstelling voor een sessie). Als de vergrendeling tijdens de time-outperiode wordt vrijgegeven, wordt de tweede bewerking voortgezet. Als er een time-out optreedt voor de vergrendeling, mislukt de tweede bewerking.

Metagegevens

SQL Server bevat de volgende back-upgeschiedenistabellen waarmee back-upactiviteit wordt bijgehouden:

• back-upbestand
• backupfilegroup
• backupmediafamily-
• backupmediaset
• back-upset

Wanneer een herstelbewerking wordt uitgevoerd en de back-upset nog niet is vastgelegd in de msdb database, kunnen de back-upgeschiedenistabellen worden gewijzigd.

Veiligheid

Vanaf SQL Server 2012 (11.x) worden de PASSWORD- en MEDIAPASSWORD-opties stopgezet voor het maken van back-ups. Het is nog steeds mogelijk om back-ups te herstellen die zijn gemaakt met wachtwoorden.

Machtigingen

BACKUP DATABASE- en BACKUP LOG-machtigingen zijn standaard ingesteld op leden van de sysadmin vaste serverfunctie en de db_owner en db_backupoperator vaste databaserollen.

Eigendoms- en machtigingsproblemen in het fysieke bestand van het back-upapparaat kunnen een back-upbewerking verstoren. Zorg ervoor dat het opstartaccount van SQL Server lees- en schrijfmachtigingen moet hebben voor het back-upapparaat en de map waarnaar de back-upbestanden worden geschreven. sp_addumpdevice, waarmee echter een vermelding voor een back-upapparaat in de systeemtabellen wordt toegevoegd, worden geen machtigingen voor bestandstoegang gecontroleerd. Dergelijke problemen in het fysieke bestand van het back-upapparaat worden mogelijk pas weergegeven wanneer de fysieke resource wordt geopend wanneer de back-up of herstel wordt uitgevoerd.

Voorbeelden

Deze sectie bevat de volgende voorbeelden:

• Een. een back-up maken van een volledige database
• B. een back-up maken van de database en
• C. een volledige back-up van de secundaire bestandsgroepen maken
• D. een differentiële bestandsback-up maken van de secundaire bestandsgroepen
• E. Een gespiegelde mediaset met één gezin maken en er een back-up van maken en er een back-up van maken
• F. Een gespiegelde mediaset met meerdere families maken en er een back-up van maken en er een back-up van maken
• G. Back-up maken van een bestaande gespiegelde mediaset
• H. een gecomprimeerde back-up maken in een nieuwe mediaset
• Ik. back-up maken van Azure Blob Storage-
• J. [Back-up maken van S3-compatibele objectopslag]((#j-backing-up-to-s3-compatibele object-opslag)
• K. De voortgang van de back-upinstructie bijhouden

Notitie

De onderwerpen over instructies voor back-ups bevatten aanvullende voorbeelden. Zie Overzicht van back-upsvoor meer informatie.

Een. Een back-up maken van een volledige database

In het volgende voorbeeld wordt een back-up gemaakt van de AdventureWorks2022-database naar een schijfbestand.

BACKUP DATABASE AdventureWorks2022
 TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
    WITH FORMAT;
GO

B. Een back-up maken van de database en het logboek

In het volgende voorbeeld wordt een back-up gemaakt van de AdventureWorks2022 voorbeelddatabase, die standaard gebruikmaakt van het eenvoudige herstelmodel. Ter ondersteuning van logboekback-ups wordt de AdventureWorks2022-database gewijzigd om het volledige herstelmodel te gebruiken.

Vervolgens wordt in het voorbeeld sp_addumpdevice gebruikt om een logisch back-upapparaat te maken voor het maken van back-ups van gegevens, AdvWorksDataen maakt een ander logisch back-upapparaat voor het maken van een back-up van het logboek, AdvWorksLog.

In het voorbeeld wordt vervolgens een volledige databaseback-up gemaakt voor AdvWorksDataen na een periode van updateactiviteit wordt een back-up gemaakt van het logboek naar AdvWorksLog.

-- To permit log backups, before the full database backup, modify the database
-- to use the full recovery model.
USE master;
GO
ALTER DATABASE AdventureWorks2022
    SET RECOVERY FULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices.
USE master
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksData',
'Z:\SQLServerBackups\AdvWorksData.bak';
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksLog',
'X:\SQLServerBackups\AdvWorksLog.bak';
GO

-- Back up the full AdventureWorks2022 database.
BACKUP DATABASE AdventureWorks2022 TO AdvWorksData;
GO
-- Back up the AdventureWorks2022 log.
BACKUP LOG AdventureWorks2022
    TO AdvWorksLog;
GO

Notitie

Maak regelmatig een back-up van het logboek voor een productiedatabase. Logboekback-ups moeten regelmatig genoeg zijn om voldoende bescherming te bieden tegen gegevensverlies.

C. Een volledige back-up van de secundaire bestandsgroepen maken

In het volgende voorbeeld wordt een volledige bestandsback-up gemaakt van elk bestand in beide secundaire bestandsgroepen.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
    FILEGROUP = 'SalesGroup1',
    FILEGROUP = 'SalesGroup2'
    TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck';
GO

D. Een differentiële bestandsback-up maken van de secundaire bestandsgroepen

In het volgende voorbeeld wordt een differentiële bestandsback-up gemaakt van elk bestand in beide secundaire bestandsgroepen.

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
    FILEGROUP = 'SalesGroup1',
    FILEGROUP = 'SalesGroup2'
    TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
    WITH
      DIFFERENTIAL;
GO

E. Een gespiegelde mediaset met één gezin maken en er een back-up van maken

In het volgende voorbeeld wordt een gespiegelde mediaset gemaakt met één mediafamilie en vier spiegels en wordt een back-up gemaakt van de AdventureWorks2022-database.

BACKUP DATABASE AdventureWorks2022
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
    FORMAT,
    MEDIANAME = 'AdventureWorksSet0';

F. Een gespiegelde mediaset maken en er een back-up van maken

In het volgende voorbeeld wordt een gespiegelde mediaset gemaakt waarin elke spiegel bestaat uit twee mediafamilies. In het voorbeeld wordt vervolgens een back-up gemaakt van de AdventureWorks2022-database naar beide spiegels.

BACKUP DATABASE AdventureWorks2022
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
    FORMAT,
    MEDIANAME = 'AdventureWorksSet1';

G. Een back-up maken van een bestaande gespiegelde mediaset

In het volgende voorbeeld wordt een back-upset toegevoegd aan de mediaset die in het vorige voorbeeld is gemaakt.

BACKUP LOG AdventureWorks2022
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
    NOINIT,
    MEDIANAME = 'AdventureWorksSet1';

Notitie

NOINIT, de standaardinstelling, wordt hier ter duidelijkheid weergegeven.

H. Een gecomprimeerde back-up maken in een nieuwe mediaset

In het volgende voorbeeld wordt de media opgemaakt, een nieuwe mediaset gemaakt en wordt een gecomprimeerde volledige back-up van de AdventureWorks2022-database uitgevoerd.

BACKUP DATABASE AdventureWorks2022 TO DISK='Z:\SQLServerBackups\AdvWorksData.bak'
WITH
    FORMAT,
    COMPRESSION;

Ik. Een back-up maken van Microsoft Azure Blob Storage

In dit voorbeeld wordt een volledige databaseback-up van Sales naar Azure Blob Storage uitgevoerd. De naam van het opslagaccount is mystorageaccount. De container wordt myfirstcontainergenoemd. Er is al een opgeslagen toegangsbeleid gemaakt met lees-, schrijf-, verwijder- en lijstrechten. De SQL Server-referentie, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, is gemaakt met behulp van een Shared Access Signature die is gekoppeld aan het opgeslagen toegangsbeleid. Zie SQL Server Backup and Restore with Azure Blob Storage and SQL Server Backup to URLvoor meer informatie over SQL Server-back-up naar Azure Blob Storage.

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales.bak'
WITH STATS = 5;

U kunt ook een back-up van uw database maken in meerdere strepen en deze ziet er als volgt uit:

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-04.bak'
WITH COPY_ONLY;

J. Een back-up maken van S3-compatibele objectopslag

van toepassing op: SQL Server 2022 (16.x)

In dit voorbeeld wordt een volledige back-updatabase van de Sales-database uitgevoerd naar het S3-compatibele objectopslagplatform. De naam van de referentie is niet vereist in de instructie of om overeen te komen met het exacte URL-pad, maar voert een zoekopdracht uit voor de juiste referentie op de opgegeven URL. Zie back-up en herstel van SQL Server met S3-compatibele objectopslagvoor meer informatie.

BACKUP DATABASE Sales
TO      URL = 's3://10.10.10.10:8787/sqls3backups/sales_01.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_02.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_03.bak'
WITH    FORMAT
,       STATS               = 10
,       COMPRESSION;

K. De voortgang van de back-upinstructie bijhouden

De volgende query retourneert informatie over de momenteel actieve back-upinstructies:

SELECT query = a.text, start_time, percent_complete,
    eta = dateadd(second,estimated_completion_time/1000, getdate())
FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command LIKE 'BACKUP%';

Verwante inhoud

• Back-upapparaten
• mediasets, mediafamilies en back-upsets
• Tail-Log back-ups
• ALTER DATABASE
• DBCC SQLPERF-
• RESTORE-
• FILELISTONLY- HERSTELLEN
• HEADERONLY- HERSTELLEN
• LABELONLY HERSTELLEN
• VERIFYONLY- HERSTELLEN
• sp_addumpdevice
• sp_configure
• sp_helpfile
• sp_helpfilegroup
• serverconfiguratieopties
• stukje terugzetten van databases met Memory-Optimized tabellen