BACKUP (Transact-SQL)

* SQL Server *  

sql Managed Instance-

Analyseplatform
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 te maken (BACKUP DATABASE). Maak 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 | ZSTD | accelerator_algorithm } [ , LEVEL = { LOW | MEDIUM | HIGH } ] ) ] | 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.

logboek

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.

GROEP (<database>, ... n)

Van toepassing op: SQL Server 2022 (16.x) en latere versies.

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

Van toepassing op: SQL Server 2022 (16.x) en latere versies.

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

Van toepassing op: SQL Server 2022 (16.x) en latere versies.

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

METADATA_ONLY is synoniem 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 }

Er wordt een back-up gemaakt van de database van waaruit het transactielogboek, de gedeeltelijke database of de volledige database wordt gemaakt. Als deze naam 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 gegevenstypen ntekst of tekst .

< > 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 }

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

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

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.

• n

  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 bestandsback-ups (SQL Server) en back-ups maken van bestanden en bestandsgroepen voor 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.

• FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

  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

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

  Zie Gedeeltelijke back-ups (SQL Server) voor meer informatie over gedeeltelijke back-ups.

TO <backup_device> [ , ... n ]

Hiermee wordt aangegeven dat de bijbehorende set back-upapparaten een niet-bewonderde mediaset of de eerste van de spiegels binnen een gespiegelde mediaset is (waarvoor een of meer MIRROR TO componenten zijn 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.

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 het logische back-upapparaat) of als een variabele van een gegevenstype tekenreeks, met uitzondering van de gegevenstypen ntekst of tekst .

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

Van toepassing op: SQL Server.

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 Azure Blob Storage en quickstart: SQL-back-up en herstel naar Azure Blob Storage.
• Back-up en herstel naar S3-compatibele opslag is geïntroduceerd in SQL Server 2022 (16.x). Controleer back-up en herstel SQL Server met S3-compatibele objectopslag. Bekijk ook de optie voor back-ups van SQL Server naar URL voor S3-compatibele objectopslag.

U kunt vanaf het volgende een back-up maken naar Microsoft Azure Blob Storage met behulp van een beheerde identiteit:

• SQL Server 2025 (17.x) Preview: Back-up maken van URL met beheerde identiteit (preview) - SQL Server ingeschakeld door Azure Arc
• SQL Server 2022 (16.x) CU 17 voor SQL Server op Virtuele Azure-machines: back-up maken en herstellen naar URL met beheerde identiteiten

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 BACKUP instructie, wordt de back-up toegevoegd aan het apparaat.

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

Zie Back-upapparaten (SQL Server) voor meer informatie.

• n

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

SPIEGELEN AAN <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 MIRROR TO component 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.

<backup_device>

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

• n

  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 MIRROR TO component moet gelijk zijn aan het aantal apparaten in de TO component.

  Zie Mediafamilies in gespiegelde mediasets verderop in dit artikel voor meer informatie.

• [ volgende spiegeling naar ]

  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.

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

FILE_SNAPSHOT

Van toepassing op: SQL Server 2016 (13.x) en latere versies.

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 Azure voor 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

Wordt alleen gebruikt met BACKUP DATABASE, geeft aan dat de database of bestandsback-up alleen uit de delen van de database of het bestand moet bestaan 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.

Zie Differentiële back-ups (SQL Server) voor 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 and CREATE ASYMMETRIC KEY (CREATE CERTIFICATE and CREATE ASYMMETRIC KEY ) voor meer informatie.

Opties voor back-upset

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

ALLEEN_KOPIËREN

Hiermee geeft u op dat de back-up een alleen-kopiëren back-up is, die 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 alleen-kopiëren back-up 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.

• Wanneer deze wordt gebruikt BACKUP DATABASE, maakt 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, BACKUP LOGmaakt de COPY_ONLY optie een back-up van het logboek 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 Alleen-kopiëren back-ups voor meer informatie.

[ COMPRESSION [ ( ALGORITME = { MS_XPRESS | ZSTD | accelerator_algorithm } [ , NIVEAU = { LAAG | GEMIDDELD | HIGH } ] ) ] | 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 (SQL Server) weergeven of wijzigen voor 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-databases (Transparent Data Encryption).

Het ZSTD-compressie-algoritme is beschikbaar vanaf SQL Server 2025 (17.x) Preview.

• COMPRESSIE

  Hiermee schakelt u expliciet back-upcompressie in.

• NO_COMPRESSION

  Schakelt back-upcompressie expliciet uit.

• NIVEAU

  Van toepassing op: SQL Server 2022 (16.x) en latere versies.

  Dit is een optionele parameter waarmee het compressieniveau wordt opgegeven. Beïnvloedt ALGORITHM = MS_EXPRESS, en, beginnend met SQL Server 2025 (17.x) Preview, ALGORITHM = ZSTD.

  Acceptabele waarden zijn:

  • LOW (standaard)
  • MEDIUM
  • HIGH

• ALGORITME

  Van toepassing op: SQL Server 2022 (16.x) en latere versies.

  ZSTD en MS_EXPRESS zijn algoritmen op softwareniveau. QAT_DEFLATE is een op hardware gebaseerd algoritme waarvoor Intel® QuickAssist Technology (QAT) is vereist voor SQL Server. De standaardwaarde is MS_XPRESS.

  Het ZSTD-compressie-algoritme gebruiken dat is geïntroduceerd in SQL Server 2025 (17.x) Preview:

  BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = ZSTD, LEVEL = MEDIUM)
  

  Als u geïntegreerde versnelling en offloadinghebt geconfigureerd, kunt u een accelerator van de oplossing gebruiken. Als u bijvoorbeeld geïntegreerde versnelling en offloading hebt geconfigureerd, wordt in het volgende voorbeeld de back-up voltooid met de acceleratoroplossing, met de QATzip-bibliotheek met behulp van QZ_DEFLATE het compressieniveau 1.

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

  Voorbeeldgedrag:

  Back-upinstructie	Outcome
  BACK-UPDATABASE DATABASE_NAME NAAR {DISK | TAPE | URL} MET NO_COMPRESSION	Back-up zonder compressie
  BACK-UPDATABASE DATABASE_NAME NAAR {DISK | TAPE | URL} MET COMPRESSIE	Back-up met compressie met behulp van het algoritme dat is opgegeven door de serveroptie backup compression algorithm (standaard MS_XPRESS)
  BACK-UPDATABASE DATABASE_NAME NAAR {DISK | TAPE | URL} MET COMPRESSIE (ALGORITME = MS_XPRESS)	Back-up maken met compressie met behulp van MS_XPRESS algoritme
  BACK-UPDATABASE DATABASE_NAME NAAR {DISK | TAPE | URL} MET COMPRESSIE (ALGORITME = ZSTD)	Back-up met compressie met behulp van ZSTD-algoritme.
  BACK-UPDATABASE DATABASE_NAME NAAR {DISK | TAPE | URL} MET COMPRESSIE (ALGORITME = ZSTD, NIVEAU = HOOG)	Back-up met compressie met behulp van ZSTD-algoritme met compressieniveau HIGH.

DESCRIPTION = { 'text' | @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 NAME dit niet is opgegeven, is deze leeg.

{ EXPIREDATE = 'date' | RETAINDAYS = dagen }

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

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

• 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 de geconfigureerde datum/tijd-notatie van het systeem volgen en worden opgegeven als een van de volgende opties:

  • 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 tijdtypen voor 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) en latere versies.

METADATA_ONLY synoniemen SNAPSHOT zijn.

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 standaardwaarde is om toe te voegen aan de meest recente back-upset op de media (NOINIT).

• 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-upsets (SQL Server) voor meer informatie.

• INIT

  Hiermee geeft u op dat alle back-upsets moeten worden overschreven, maar de mediaheader behouden blijft. Als INIT dit is opgegeven, wordt een bestaande back-upset op dat apparaat overschreven als voorwaarden zijn toe te staan. Controleert standaard BACKUP op de volgende voorwaarden en overschrijft de back-upmedia niet als er een van de 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 BACKUP instructie, indien opgegeven, komt niet overeen met de naam op de back-upmedia. Zie de NAME optie eerder in deze sectie voor meer informatie.

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

  Zie Mediasets, mediafamilies en back-upsets (SQL Server) voor 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.

• NOSKIP

  Hiermee wordt de BACKUP instructie geïnstrueerd 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 door de BACKUP instructie wordt uitgevoerd om te voorkomen dat back-upsets worden overschreven. Zie INIT verderop in dit artikel voor informatie over de interacties tussen { | NOINITNOSKIP } en { | SKIP }.

  Als u de vervaldatums van back-upsets wilt weergeven, voert u een query uit op de expiration_date kolom van de geschiedenistabel van de back-upset .

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

  Het opgeven van FORMAT 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 SKIP optie 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 wordt geselecteerd 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 = 2048op.

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.

Verhogen BUFFERCOUNT kan de back-uptijd aanzienlijk verminderen tegen de kosten van een hoger geheugengebruik.

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) van maximaal 4.194.304 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 (SQL Server) heeft geconfigureerd of geoptimaliseerde bestandsgroepen voor geheugen bevat, moet het MAXTRANSFERSIZE tijdstip waarop een herstelbewerking is uitgevoerd groter zijn dan of gelijk is aan de MAXTRANSFERSIZE database die is gebruikt toen de back-up werd gemaakt.

Voor TDE-databases (Transparent Data Encryption) met één gegevensbestand is de standaardwaarde MAXTRANSFERSIZE 65536 (64 kB). Voor niet-TDE versleutelde databases is de standaardwaarde MAXTRANSFERSIZE 1048576 (1 MB) bij het gebruik van back-ups naar DISKen 65536 (64 kB) bij het 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 herstel (SQL Server) voor 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 de opdracht BACKUP om te mislukken als een paginacontroleom niet controleert. Dit is het standaardgedrag.

• CONTINUE_AFTER_ERROR

  Geeft aan BACKUP 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 NO_TRUNCATE optie wanneer de database is beschadigd, kunt u een back-up van het tail-loglogboek proberen door op te geven CONTINUE_AFTER_ERROR in plaats van NO_TRUNCATE.

Zie Mogelijke mediafouten tijdens back-up en herstel (SQL Server) voor meer informatie.

Compatibiliteitsopties

HERSTARTEN

Heeft geen effect. Deze optie wordt geaccepteerd door de versie voor compatibiliteit met SQL Server 2005 Analysis Services (SSAS).

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 STATS optie rapporteert het percentage voltooid vanaf de drempelwaarde voor het rapporteren van het volgende interval. Dit is ongeveer het opgegeven percentage; Als het voltooide bedrag bijvoorbeeld STATS = 1040 procent is, kan de optie 43 procent weergeven. Voor grote back-upsets is dit geen probleem, omdat het percentage voltooid heel 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 standaardwaarde.

• 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 gebruikt NOREWIND, behoudt het exemplaar van SQL Server het eigendom van het tapestation totdat een BACKUP of-instructie RESTORE die in hetzelfde proces wordt uitgevoerd, gebruikmaakt van de REWIND of UNLOAD optie of het serverexemplaren wordt afgesloten. Door de tape open te houden, hebben andere processen geen toegang tot de tape. Zie Back-upapparaten (SQL Server) voor informatie over het weergeven van een lijst met geopende tapes en het sluiten van een open tape.

{ UNLOAD | NOUNLOAD }

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

Logboekspecifieke opties

Deze opties worden alleen gebruikt met BACKUP LOG.

{ 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 alleen-lezen en STANDBY de status behouden. De STANDBY component schrijft stand-bygegevens (terugdraaien, maar met de optie voor verdere herstelbewerkingen). Het gebruik van de STANDBY optie is gelijk aan BACKUP LOG WITH 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 RESTORE LOG bewerkingen 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. Een back-up met NO_TRUNCATE kan dus onvolledige metagegevens bevatten. Met deze optie kunt u een back-up maken van het transactielogboek in situaties waarin de database is beschadigd.

De NO_TRUNCATE optie is gelijk aan het opgeven van BACKUP LOG beide COPY_ONLY en CONTINUE_AFTER_ERROR.

Zonder de NO_TRUNCATE optie moet de database de ONLINE status 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 of de OFFLINE status heeft, is dit niet toegestaan, EMERGENCY zelfs niet met BACKUP.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

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 op in uw COPY_ONLYBACKUP instructie. Zie Alleen-kopiëren back-ups voor 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 transactielogboek voor informatie over factoren die het afkappen van logboeken kunnen vertragen.

Back-upmedia opmaken

Back-upmedia worden opgemaakt door 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 met niet-gestreepte back-ups niet worden gebruikt in een stripeset, tenzij FORMAT is opgegeven. Als u een gestreepte back-upset wilt splitsen, gebruikt u FORMAT.

Als beide MEDIANAME of MEDIADESCRIPTION niet zijn 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 BACKUP instructies 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

Mediafamilies in gespiegelde mediasets

Elk back-upapparaat dat is opgegeven in de TO component van een BACKUP instructie komt overeen met een mediafamilie. Als de TO component bijvoorbeeld drie apparaten bevat, BACKUP schrijft u 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 vorige 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-upmediasets (SQL Server) voor meer informatie over gespiegelde mediasets. Zie Mediasets, mediafamilies en back-upsets (SQL Server) voor 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 herstellen en herstellen (SQL Server) voor meer informatie.

Aanvullende overwegingen over BACK-UPopties

Interactie van SKIP, NOSKIP, INIT en NOINIT

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

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 dit 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 het opgegeven MEDIANAME gebruik en MEDIADESCRIPTION, indien van toepassing.
SKIP	Als het volume een geldige mediaheader bevat, voegt u de back-upset toe, waarbij alle bestaande back-upsets behouden blijven.	Als het volume een geldige 2 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

BACKUP ondersteunt de optie RESTART om compatibiliteit met eerdere versies van SQL Server te bieden. Maar RESTART 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 MAXTRANSFERSIZEvan meer dan 65536 (64 kB) een geoptimaliseerd compressie-algoritme mogelijk voor met TDE versleutelde databases die eerst een pagina ontsleutelen, comprimeren en opnieuw versleutelen. Als MAXTRANSFERSIZE dit niet is opgegeven of 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 standaardserverconfiguratie voor back-upcompressie is ingesteld op 1, MAXTRANSFERSIZE wordt 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.

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 Traceringsvlagmen instellen met DBCC TRACEON voor 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; Bijvoorbeeld, INSERTof UPDATEDELETE instructies zijn 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, kunnen de back-upgeschiedenistabellen worden gewijzigd als de back-upset nog niet is vastgelegd in de msdb database.

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 een vermelding voor een back-upapparaat in de systeemtabellen wordt toegevoegd, controleert echter geen rechten voor bestandstoegang. 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

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

EXECUTE sp_addumpdevice 'disk', 'AdvWorksData', 'Z:\SQLServerBackups\AdvWorksData.bak';
GO

EXECUTE 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

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';

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-back-up en herstel met Azure Blob Storage enSQL Server-back-up naar URL voor Azure Blob Storage voor Azure Blob Storage voor informatie over BACK-ups van SQL Server 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) en latere versies.

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 komt overeen met het exacte URL-pad, maar voert een zoekopdracht uit voor de juiste referentie op de opgegeven URL. Zie Back-up maken en herstellen van SQL Server met S3-compatibele objectopslag voor 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 a.text AS query,
       start_time,
       percent_complete,
       dateadd(second, estimated_completion_time / 1000, getdate()) AS eta
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS a
WHERE r.command LIKE 'BACKUP%';

Verwante inhoud

• Back-upapparaten
• Mediasets, mediafamilies en back-upsets
• Back-ups van tail-log
• ALTER DATABASE (Transact-SQL)
• DBCC SQLPERF (Transact-SQL)
• RESTORE-instructies (Transact-SQL)
• RESTORE FILELISTONLY (Transact-SQL)
• HEADERONLY HERSTELLEN (Transact-SQL)
• LABELONLY HERSTELLEN (Transact-SQL)
• VERIFYONLY HERSTELLEN (Transact-SQL)
• sp_addumpdevice
• sp_configure
• sp_helpfile
• sp_helpfilegroup
• Serverconfiguratieopties
• stukje terugzetten van databases met Memory-Optimized tabellen

SQL Server-

* SQL Managed Instance *  

Analyseplatform
Systeem (PDW)

 

Azure SQL Managed Instance (een beheerde database-instantie van Azure)

Maakt een back-up van een SQL-database in Azure SQL Managed Instance. Azure SQL Managed Instance automatische back-ups heeft. U kunt volledige database maken COPY_ONLY back-ups. Back-ups van differentiële, logboek- en bestandsmomentopnamen worden niet ondersteund.

Is ook van toepassing op SQL Managed Instance ingeschakeld door Azure Arc.

Syntaxis

BACKUP DATABASE { database_name | @database_name_var }
  TO URL = { 'physical_device_name' | @physical_device_name_var } [ , ...n ]
  WITH COPY_ONLY [ , { <general_WITH_options> } ]
[ ; ]

<general_WITH_options> [ , ...n ] ::=

--Media set options
   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 ]

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

Argumenten

DATABANK

Hiermee geeft u een volledige databaseback-up. Tijdens een databaseback-up maakt Azure SQL Managed Instance 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. Als u automatische back-ups van SQL Managed Instance wilt herstellen, raadpleegt u Een database herstellen naar een azure SQL Managed Instance-.

{ database_name | @database_name_var }

Er wordt een back-up gemaakt van de database waaruit een back-up van de volledige database wordt gemaakt. Als deze naam 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 gegevenstypen ntekst of tekst .

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

TO URL

Hiermee geeft u de URL op die moet worden gebruikt voor de back-upbewerking. De URL-indeling wordt gebruikt voor het maken van back-ups naar de Microsoft Azure-opslagservice.

• n

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

MET opties

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

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>

Opties voor back-upset

ALLEEN_KOPIËREN

Hiermee geeft u op dat de back-up een alleen-kopiëren back-up is, die niet van invloed is op de normale volgorde van back-ups. Er wordt onafhankelijk van de automatische back-ups van Azure SQL Database een back-up gemaakt die alleen kan worden gekopieerd. Zie Copy-Only Back-upsvoor meer informatie.

{ COMPRESSION | NO_COMPRESSION }

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

Het standaardgedrag is 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.

• COMPRESSIE

  Hiermee schakelt u expliciet back-upcompressie in.

• NO_COMPRESSION

  Schakelt back-upcompressie expliciet uit.

DESCRIPTION = { 'text' | @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 NAME dit niet is opgegeven, is deze leeg.

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 SKIP optie 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 wordt geselecteerd die geschikt is voor het apparaat. Expliciet aangeven dat een blokgrootte de automatische selectie van blokgrootte overschrijft.

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.

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) van maximaal 4.194.304 bytes (4 MB).

Voor TDE-databases (Transparent Data Encryption) met één gegevensbestand is de standaardwaarde MAXTRANSFERSIZE 65536 (64 kB). Voor niet-TDE versleutelde databases is de standaardwaarde MAXTRANSFERSIZE 1048576 (1 MB) bij het gebruik van back-up naar DISKen 65536 (64 kB) bij het gebruik van VDI of TAPE.

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 de opdracht BACKUP om te mislukken als een paginacontroleom niet controleert. Dit is het standaardgedrag.

• CONTINUE_AFTER_ERROR

  Geeft aan BACKUP 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 NO_TRUNCATE optie wanneer de database is beschadigd, kunt u een back-up van het tail-loglogboek proberen door op te geven CONTINUE_AFTER_ERROR in plaats van NO_TRUNCATE.

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

Compatibiliteitsopties

HERSTARTEN

Heeft 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 STATS optie rapporteert het percentage voltooid vanaf de drempelwaarde voor het rapporteren van het volgende interval. Dit is ongeveer het opgegeven percentage; Als het voltooide bedrag bijvoorbeeld STATS = 1040 procent is, kan de optie 43 procent weergeven. Voor grote back-upsets is dit geen probleem, omdat het percentage voltooid heel langzaam wordt verplaatst tussen voltooide I/O-aanroepen.

Beperkingen voor SQL Managed Instance

De maximale grootte van de back-upstrook is 195 GB (maximale blobgrootte). Verhoog het aantal strepen in de back-upopdracht om de grootte van afzonderlijke strepen te verkleinen en binnen deze limiet te blijven.

Veiligheid

Machtigingen

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

Eigendoms- en machtigingsproblemen op de URL kunnen een back-upbewerking verstoren. SQL Server moet kunnen lezen en schrijven naar het apparaat; het account waaronder de SQL Server-service wordt uitgevoerd, moet schrijfmachtigingen hebben.

Voorbeelden

In het voorbeeld wordt een COPY_ONLY back-up van Sales Microsoft Azure Blob Storage uitgevoerd. De naam van het opslagaccount is mystorageaccount. De container wordt myfirstcontainergenoemd. Er is 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 Microsoft Azure Blob Storage and SQL Server Backup to URLvoor informatie over back-up van SQL Server naar Azure Blob Storage.

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

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;

Verwante inhoud

• DATABASE HERSTELLEN

SQL Server-

sql Managed Instance-

* Analyse
PlatformSysteem (PDW) *  

 

Analyseplatformsysteem

Hiermee maakt u een back-up van een PDW-database (Analytics Platform System) en slaat u de back-up van het apparaat op een door de gebruiker opgegeven netwerklocatie op. Gebruik deze instructie met RESTORE DATABASE voor herstel na noodgevallen of om een database van het ene apparaat naar het andere te kopiëren.

Zie 'Een back-upserver verkrijgen en configureren' in de productdocumentatie van Analytics Platform System (PDW)voordat u begint met.

Er zijn twee soorten back-ups in Analytics Platform System (PDW). Een volledige databaseback-up is een back-up van een volledige PDW-database (Analytics Platform System). Een differentiële databaseback-up bevat alleen wijzigingen die zijn aangebracht sinds de laatste volledige back-up. Een back-up van een gebruikersdatabase bevat databasegebruikers en databaserollen. Een back-up van de master-database bevat aanmeldingen.

Zie Back-up en herstel in de productdocumentatie van Analytics Platform System (PDW)voor meer informatie over pdw-databaseback-ups (Analytics Platform System).

Syntaxis

--Create a full backup of a user database or the master database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    [ WITH [ ( ] <with_options> [ , ...n ] [ ) ] ]
[ ; ]

--Create a differential backup of a user database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    WITH [ ( ] DIFFERENTIAL
    [ , <with_options> [ , ...n ] [ ) ] ]
[ ; ]

<with_options> ::=
    DESCRIPTION = 'text'
    | NAME = 'backup_name'

Argumenten

database_name

De naam van de database waarop een back-up moet worden gemaakt. De database kan de master database of een gebruikersdatabase zijn.

TO DISK = '\\UNC_path backup_directory\'

Het netwerkpad en de map waarnaar PDW (Analytics Platform System) de back-upbestanden schrijft. Bijvoorbeeld \\\xxx.xxx.xxx.xxx\backups\2012\Monthly\08.2012.Mybackup.

• Het pad naar de naam van de back-upmap moet al bestaan en moet worden opgegeven als een volledig gekwalificeerde UNC-pad (Universal Naming Convention).
• De back-upmap, backup_directory, mag niet bestaan voordat u de back-upopdracht uitvoert. Met PDW (Analytics Platform System) wordt de back-upmap gemaakt.
• Het pad naar de back-upmap kan geen lokaal pad zijn en kan geen locatie zijn op een van de knooppunten van het PDW-apparaat (Analytics Platform System).
• De maximale lengte van het UNC-pad en de naam van de back-upmap is 200 tekens.
• De server of host moet worden opgegeven als EEN IP-adres. U kunt deze niet opgeven als host- of servernaam.

DESCRIPTION = 'tekst'

Hiermee geeft u een tekstuele beschrijving van de back-up. De maximale lengte van de tekst is 255 tekens.

De beschrijving wordt opgeslagen in de metagegevens en wordt weergegeven wanneer de back-upheader wordt hersteld met RESTORE HEADERONLY.

NAME = '_backup name'

Hiermee geeft u de naam van de back-up. De back-upnaam kan afwijken van de databasenaam.

• Namen mogen maximaal 128 tekens bevatten.
• Kan geen pad opnemen.
• Moet beginnen met een letter of cijfer of een onderstrepingsteken (_). De toegestane speciale tekens zijn het onderstrepingsteken (_), afbreekstreepje (-) of spatie ( ). Back-upnamen kunnen niet eindigen met een spatieteken.
• De instructie mislukt als backup_name al op de opgegeven locatie bestaat.

Deze naam wordt opgeslagen in de metagegevens en wordt weergegeven wanneer de back-upheader wordt hersteld met RESTORE HEADERONLY.

DIFFERENTIAAL

Hiermee geeft u een differentiële back-up van een gebruikersdatabase uit. Als u dit weglaat, is de standaardwaarde een volledige back-up van de database. De naam van de differentiële back-up hoeft niet overeen te komen met de naam van de volledige back-up. Voor het bijhouden van het differentieel en de bijbehorende volledige back-up kunt u overwegen dezelfde naam te gebruiken met 'full' of 'diff' toegevoegd.

Bijvoorbeeld:

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerFull';

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerDiff' WITH DIFFERENTIAL;

Machtigingen

Vereist de BACKUP DATABASE machtiging of lidmaatschap van de db_backupoperator vaste databaserol. Er master kan geen back-up van de database worden gemaakt, maar door een gewone gebruiker die is toegevoegd aan de db_backupoperator vaste databaserol. Een back-up van de master-database kan alleen worden gemaakt door sa, de infrastructuurbeheerder of leden van de sysadmin vaste serverrol.

Vereist een Windows-account met machtigingen voor toegang, maken en schrijven naar de back-upmap. U moet ook de Windows-accountnaam en het wachtwoord opslaan in Analytics Platform System (PDW). Als u deze netwerkreferenties wilt toevoegen aan Analytics Platform System (PDW), gebruikt u de sp_pdw_add_network_credentials - Azure Synapse Analytics opgeslagen procedure.

Zie de sectie Security voor meer informatie over het beheren van referenties in Analytics Platform System (PDW).

Foutafhandeling

BACKUP DATABASE fouten onder de volgende voorwaarden:

• Gebruikersmachtigingen zijn niet voldoende om een back-up uit te voeren.
• PdW (Analytics Platform System) beschikt niet over de juiste machtigingen voor de netwerklocatie waar de back-up wordt opgeslagen.
• De database bestaat niet.
• De doelmap bestaat al op de netwerkshare.
• De doelnetwerkshare is niet beschikbaar.
• De doelnetwerkshare heeft onvoldoende ruimte voor de back-up. Met BACKUP DATABASE de opdracht wordt niet bevestigd dat er voldoende schijfruimte bestaat voordat de back-up wordt gestart, waardoor het mogelijk is om tijdens het uitvoeren BACKUP DATABASEeen fout met onvoldoende schijfruimte te genereren. Wanneer er onvoldoende schijfruimte is, wordt de BACKUP DATABASE opdracht door Analytics Platform System (PDW) teruggedraaid. Als u de grootte van uw database wilt verkleinen, voert u DBCC SHRINKLOG uit
• Probeer een back-up te starten binnen een transactie.

Opmerkingen

Voordat u een databaseback-up uitvoert, gebruikt u DBCC SHRINKLOG om de grootte van uw database te verkleinen.

Een PDW-back-up (Analytics Platform System) wordt opgeslagen als een set van meerdere bestanden in dezelfde map.

Een differentiële back-up duurt meestal minder tijd dan een volledige back-up en kan vaker worden uitgevoerd. Wanneer meerdere differentiële back-ups zijn gebaseerd op dezelfde volledige back-up, bevat elke differentiële back-up alle wijzigingen in de vorige differentiële back-up.

Als u een BACKUP opdracht annuleert, verwijdert Analytics Platform System (PDW) de doelmap en alle bestanden die voor de back-up zijn gemaakt. Als PdW (Analytics Platform System) de netwerkverbinding met de share verliest, kan het terugdraaien niet worden voltooid.

Volledige back-ups en differentiële back-ups worden opgeslagen in afzonderlijke mappen. Naamconventies worden niet afgedwongen om op te geven dat een volledige back-up en differentiële back-up bij elkaar horen. U kunt dit volgen via uw eigen naamconventies. U kunt dit ook bijhouden met behulp van de WITH DESCRIPTION optie om een beschrijving toe te voegen en vervolgens de RESTORE HEADERONLY instructie te gebruiken om de beschrijving op te halen.

Beperkingen

U kunt geen differentiële back-up van de master database uitvoeren. Alleen volledige back-ups van de master-database worden ondersteund.

Back-ups van transactielogboeken van de master systeemdatabase worden niet ondersteund.

De back-upbestanden worden alleen opgeslagen in een indeling die alleen geschikt is voor het herstellen van de back-up naar een PDW-apparaat (Analytics Platform System) met behulp van de instructie RESTORE DATABASE .

De back-up met de BACKUP DATABASE instructie kan niet worden gebruikt om gegevens of gebruikersgegevens over te dragen naar SMP SQL Server-databases. Voor deze functionaliteit kunt u de functie voor het kopiëren van externe tabellen gebruiken. Zie 'Remote Table Copy' in de productdocumentatie Analytics Platform System (PDW)voor meer informatie.

Analytics Platform System (PDW) maakt gebruik van SQL Server-back-uptechnologie om back-ups te maken van databases en deze te herstellen. Back-upopties van SQL Server zijn vooraf geconfigureerd voor het gebruik van back-upcompressie. U kunt geen back-upopties instellen, zoals compressie, controlesom, blokgrootte en bufferaantal.

Op elk gewenst moment kan slechts één databaseback-up of herstel op het apparaat worden uitgevoerd. Met PDW (Analytics Platform System) worden back-up- of herstelopdrachten in de wachtrij geplaatst totdat de huidige back-up- of herstelopdracht is voltooid.

Het doelapparaat voor het herstellen van de back-up moet ten minste evenveel rekenknooppunten hebben als het bronapparaat. Het doel kan meer rekenknooppunten hebben dan het bronapparaat, maar kan niet minder rekenknooppunten hebben.

In Analytics Platform System (PDW) worden de locatie en namen van back-ups niet bijgehouden, omdat de back-ups worden opgeslagen op het apparaat.

In Analytics Platform System (PDW) wordt het slagen of mislukken van databaseback-ups bijgehouden.

Een differentiële back-up is alleen toegestaan als de laatste volledige back-up is voltooid. Stel dat u op maandag een volledige back-up van de Sales-database maakt en dat de back-up is voltooid. Vervolgens maakt u op dinsdag een volledige back-up van de Sales-database en mislukt deze. Na deze fout kunt u geen differentiële back-up maken op basis van de volledige back-up van maandag. U moet eerst een geslaagde volledige back-up maken voordat u een differentiële back-up maakt.

Metagegevens

Deze dynamische beheerweergaven bevatten informatie over alle back-up-, herstel- en laadbewerkingen. De informatie blijft behouden tijdens het opnieuw opstarten van het systeem.

• sys.pdw_loader_backup_runs
• sys.pdw_loader_backup_run_details
• sys.pdw_loader_run_stages

Voorstelling

Voor het uitvoeren van een back-up maakt Analytics Platform System (PDW) eerst een back-up van de metagegevens en voert het vervolgens een parallelle back-up uit van de databasegegevens die zijn opgeslagen op de rekenknooppunten. Gegevens worden rechtstreeks vanuit elk rekenknooppunt gekopieerd naar de back-upmap. Om de beste prestaties te bereiken voor het verplaatsen van gegevens van de rekenknooppunten naar de back-upmap, bepaalt Analytics Platform System (PDW) het aantal rekenknooppunten dat gegevens gelijktijdig kopieert.

Vergrendeling

Neemt een ExclusiveUpdate-vergrendeling op het DATABASE object.

Veiligheid

PDW-back-ups (Analytics Platform System) worden niet opgeslagen op het apparaat. Daarom is uw IT-team verantwoordelijk voor het beheren van alle aspecten van de back-upbeveiliging. Dit omvat bijvoorbeeld het beheren van de beveiliging van de back-upgegevens, de beveiliging van de server die wordt gebruikt voor het opslaan van back-ups en de beveiliging van de netwerkinfrastructuur die de back-upserver verbindt met het PDW-apparaat (Analytics Platform System).

Netwerkreferenties beheren

Netwerktoegang tot de back-upmap is gebaseerd op standaardbeveiliging voor het delen van bestanden van het besturingssysteem. Voordat u een back-up uitvoert, moet u een Windows-account maken of aanwijzen dat wordt gebruikt voor verificatie van Analytics Platform System (PDW) naar de back-upmap. Dit Windows-account moet gemachtigd zijn voor toegang tot, maken en schrijven naar de back-upmap.

U moet de gebruikersnaam en het wachtwoord opslaan in Analytics Platform System (PDW) door de sp_pdw_add_network_credentials - Azure Synapse Analytics opgeslagen procedure uit te voeren. Analytics Platform System (PDW) maakt gebruik van Windows Credential Manager voor het opslaan en versleutelen van gebruikersnamen en wachtwoorden op het beheerknooppunt en rekenknooppunten. Er wordt geen back-up van de referenties gemaakt met de BACKUP DATABASE opdracht.

Zie sp_pdw_remove_network_credentials - Azure Synapse Analyticsom netwerkreferenties te verwijderen uit Analytics Platform System (PDW).

Als u alle netwerkreferenties wilt weergeven die zijn opgeslagen in Analytics Platform System (PDW), gebruikt u de sys.dm_pdw_network_credentials dynamische beheerweergave.

Voorbeelden

Een. Netwerkreferenties toevoegen voor de back-uplocatie

Als u een back-up wilt maken, moet Analytics Platform System (PDW) beschikken over lees-/schrijfmachtigingen voor de back-upmap. In het volgende voorbeeld ziet u hoe u de referenties voor een gebruiker toevoegt. In Analytics Platform System (PDW) worden deze referenties opgeslagen en gebruikt voor back-up- en herstelbewerkingen.

EXECUTE sp_pdw_add_network_credentials 'xxx.xxx.xxx.xxx', 'domain1\backupuser', '*****';

B. Netwerkreferenties voor de back-uplocatie verwijderen

In het volgende voorbeeld ziet u hoe u de referenties voor een domeingebruiker verwijdert uit Analytics Platform System (PDW).

EXECUTE sp_pdw_remove_network_credentials 'xxx.xxx.xxx.xxx';

C. Een volledige back-up van een gebruikersdatabase maken

In het volgende voorbeeld wordt een volledige back-up gemaakt van de gebruikersdatabase Facturen. In Analytics Platform System (PDW) wordt de Invoices2013 map gemaakt en worden de back-upbestanden opgeslagen in de \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full map.

BACKUP DATABASE Invoices
    TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full';

D. Een differentiële back-up van een gebruikersdatabase maken

In het volgende voorbeeld wordt een differentiële back-up gemaakt, die alle wijzigingen bevat die zijn aangebracht sinds de laatste volledige back-up van de Invoices-database. Met PDW (Analytics Platform System) wordt de \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff map gemaakt om de bestanden op te slaan. De beschrijving 'Facturen 2013 differentiële back-up' wordt opgeslagen met de headerinformatie voor de back-up.

De differentiële back-up wordt alleen uitgevoerd als de laatste volledige back-up van facturen is voltooid.

BACKUP DATABASE Invoices
    TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff'
    WITH DIFFERENTIAL,
    DESCRIPTION = 'Invoices 2013 differential backup';

E. Een volledige back-up van de master database maken

In het volgende voorbeeld wordt een volledige back-up van de master-database gemaakt en opgeslagen in de map \\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master, waarbij IP een netwerk-IP-adres is.

BACKUP DATABASE master
    TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master';

F. Een back-up maken van aanmeldingsgegevens van het apparaat

De master-database slaat de aanmeldingsgegevens van het apparaat op. Als u een back-up wilt maken van de aanmeldingsgegevens van het apparaat, moet u een back-up van de master database maken.

In het volgende voorbeeld wordt een volledige back-up van de master-database gemaakt.

BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master'
WITH (
    DESCRIPTION = 'Master Backup 20130722',
    NAME = 'login-backup'
)
;

Verwante inhoud

• DATABASE HERSTELLEN