BACKUP (Transact-SQL)

Articolo
12/28/2023

Esegue il backup di un database SQL.

Selezionare un prodotto

Nella riga seguente selezionare il nome del prodotto a cui si è interessati. Verranno visualizzate solo le informazioni per tale prodotto.

Per altre informazioni sulle convenzioni della sintassi, vedere Convenzioni della sintassi Transact-SQL.

* SQL Server *

Istanza gestita di SQL

Piattaforma di strumenti
(PDW)

SQL Server

Esegue il backup di un database completo di SQL Server per creare un backup di database oppure di uno o più file o gruppi di file del database per creare un backup di file (BACKUP DATABASE). Se, inoltre, si utilizza il modello di recupero con registrazione completa o il modello di recupero con registrazione minima delle operazioni bulk, esegue il backup del log delle transazioni del database per creare un backup del log (BACKUP LOG).

Sintassi

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

Argomenti

DATABASE

Specifica un backup completo del database. Se viene specificato un elenco di file e di filegroup, il backup viene eseguito solo per tali file e filegroup. Durante un backup completo o differenziale del database, SQL Server esegue il backup di una parte del log delle transazioni sufficiente per generare un database consistente quando viene ripristinato il backup.

Quando si ripristina un backup creato da BACKUP DATABASE (backup dei dati), viene ripristinato l'intero backup. Solo un backup del log può essere ripristinato fino a un'ora o fino a una transazione specifica all'interno del backup.

Nota

È possibile eseguire solo un backup completo del database nel master database.

LOG

Specifica il backup solo del log delle transazioni. Il backup del log viene eseguito dal punto dell'ultimo backup del log completato correttamente fino alla fine corrente del log. Prima che sia possibile creare il primo backup del log, è necessario creare un backup completo.

È possibile ripristinare un backup del log fino a un'ora o fino a una transazione specifica all'interno del backup specificando WITH STOPAT, STOPATMARK o STOPBEFOREMARK nell'istruzione RESTORE LOG.

Nota

Dopo un tipico backup del log, alcuni record del log delle transazioni diventano inattivi, a meno che non si specifichi WITH NO_TRUNCATE o COPY_ONLY. Il log viene troncato dopo che tutti i record in uno o più file di log virtuali diventano inattivi. Se il log non viene troncato dopo i backup del log di routine, è possibile che una causa imprevista provochi un ritardo nel troncamento del log. Per altre informazioni, vedere Fattori che possono posticipare il troncamento del log.

GROUP (<database>,... n)

Introdotto in SQL Server 2022 (16.x).

Eseguire il backup di un gruppo di database. Usa il backup di snapshot. Richiede WITH METADATA_ONLY. Vedere Creare un backup di snapshot Transact-SQL.

SERVER

Introdotto in SQL Server 2022 (16.x).

Eseguire il backup di tutti i database in un'istanza di SQL Server. Usa il backup di snapshot. Richiede WITH METADATA_ONLY. Vedere Creare un backup di snapshot Transact-SQL.

METADATA_ONLY

Introdotto in SQL Server 2022 (16.x).

Obbligatorio per il backup dello snapshot. BACKUP SERVERoppure BACKUP GROUP... Vedere Creare un backup di snapshot Transact-SQL.

METADATA_ONLY è sinonimo di SN piattaforma di strumenti analitici HOT. L'interfaccia VDI (Virtual Device Interface) usa SN piattaforma di strumenti analitici HOT. Per informazioni su VDI, vedere Informazioni di riferimento su VDI (Virtual Device Interface).

{ database_name | @database_name_var }

Nome del database di cui viene eseguito il backup del log delle transazioni oppure il backup parziale o completo del database. Se indicato in forma di variabile (@database_name_var), questo nome può essere specificato come costante di stringa (@database_name_var=database name) oppure come variabile di tipo di dati stringa di caratteri, ad eccezione del tipo di dati ntext o text.

Nota

Non è possibile eseguire il backup del database mirror in una relazione di mirroring di database.

<> file_or_filegroup [ ,...n ]

Utilizzato solo con BACKUP DATABA edizione Standard, specifica un file di database o un filegroup da includere in un backup di file o specifica un file o un filegroup di sola lettura da includere in un backup parziale.

FILE = { logical_file_name | @logical_file_name_var }

Nome logico di un file o di una variabile il cui valore equivale al nome logico di un file che deve essere incluso nel backup.

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Nome logico di un filegroup o di una variabile il cui valore equivale al nome logico di un filegroup da includere nel backup. Con il modello di recupero con registrazione minima, il backup dei filegroup è consentito solo per i filegroup di sola lettura.

Nota

Prendere in considerazione l'utilizzo di backup dei file quando i requisiti relativi alle prestazioni e le dimensioni del database rendono poco conveniente il backup del database. Il dispositivo NUL può essere usato per testare le prestazioni dei backup, ma non deve essere usato negli ambienti di produzione.

n
Segnaposto che indica che è possibile specificare più file e filegroup in un elenco delimitato da virgole. Il numero di file e filegroup che è possibile specificare è illimitato.

Per altre informazioni, vedere Backup completi del file e Backup di file e filegroup.

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

Specifica un backup parziale. Un backup parziale include tutti i file di lettura/scrittura contenuti in un database, ovvero il filegroup primario, qualsiasi filegroup di lettura/scrittura secondario e tutti i file o filegroup di sola lettura specificati.

READ_WRITE_FILEGROUPS

Specifica che viene eseguito il backup di tutti i filegroup di lettura/scrittura nel backup parziale. Se il database è di sola lettura, READ_WRITE_FILEGROUPS include solo il filegroup primario.

Importante

Se i filegroup di lettura/scrittura vengono indicati in modo esplicito utilizzando FILEGROUP anziché READ_WRITE_FILEGROUPS, viene creato un backup del file.

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Nome logico di un filegroup di sola lettura o di una variabile il cui valore equivale al nome logico di un filegroup di sola lettura che deve essere incluso nel backup parziale. Per altre informazioni, vedere "<file_or_filegroup>>" in precedenza in questo articolo.

n
Segnaposto che indica che è possibile specificare più filegroup di sola lettura in un elenco delimitato da virgole.

Per altre informazioni sui backup parziali, vedere Backup parziali.

TO <backup_device> [ ,...n ]

Indica che il set di dispositivi di backup associato è un set di supporti senza mirroring oppure il primo mirror in un set di supporti con mirroring, per cui vengono dichiarate una o più clausole MIRROR TO.

<backup_device>
Specifica un dispositivo di backup logico o fisico da utilizzare per l'operazione di backup.

{ logical_device_name | @logical_device_name_var }

Si applica a: SQL Server
Nome logico del dispositivo di backup in cui viene eseguito il backup del database. Il nome logico deve essere conforme alle regole per gli identificatori. Se indicato in forma di variabile (@logical_device_name_var), il nome del dispositivo di backup può essere specificato come costante di stringa (@logical_device_name_var*= nome del dispositivo di backup logico) oppure come variabile di un tipo di dati stringa di caratteri qualsiasi, ad eccezione dei tipi di dati ntext o text.

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

Si applica a: SQL Server, URL a partire da SQL Server 2012 (11.x) SP1 CU2

Specifica un file su disco, un dispositivo nastro o un URL.

Il formato dell'URL viene usato per la creazione di backup in Archiviazione BLOB di Azure o nell'archiviazione di oggetti compatibile con S3. Per altre informazioni ed esempi, vedere:

Backup e ripristino di SQL Server con Archiviazione BLOB di Azure. Per un'esercitazione, vedere Esercitazione: Backup e ripristino di SQL Server in Archiviazione BLOB di Azure.
Il backup e il ripristino nell'archiviazione compatibile con S3 è stato introdotto in SQL Server 2022 (16.x), vedere Backup e ripristino di SQL Server con archiviazione oggetti compatibile con S3. Esaminare anche l'opzione per il backup di SQL Server nell'URL per l'archiviazione di oggetti compatibile con S3.

Nota

Il dispositivo del disco NUL elimina tutte le informazioni inviate al dispositivo e deve essere usato solo per i test. Non è progettato per l'uso in produzione.

Importante

A partire da SQL Server 2012 (11.x) SP1 CU2 tramite SQL Server 2014 (12.x), è possibile eseguire il backup in un solo dispositivo quando si esegue il backup nell'URL per Archiviazione BLOB di Azure. Per eseguire il backup in più dispositivi durante il backup nell'URL, è necessario usare SQL Server 2016 (13.x) e versioni successive ed è necessario usare i token di firma di accesso condiviso (SAS). Per esempi di creazione di una firma di accesso condiviso, vedere Backup di SQL Server nell'URL e Simplifying creation of SQL Credentials with Shared Access Signature (SAS) tokens on Azure Storage with Powershell (Semplificazione della creazione di credenziali SQL con token di firma di accesso condiviso (SAS) in Archiviazione di Azure con Powershell).

Non è necessario che un dispositivo disco sia presente prima che venga specificato in un'istruzione BACKUP. Se il dispositivo fisico è presente e si omette l'opzione INIT nell'istruzione BACKUP, il backup viene accodato al dispositivo.

Nota

Sebbene il dispositivo NUL elimini tutti gli input inviati a questo file, il backup contrassegna tutte le pagine come pagine di cui è stato eseguito il backup.

Per altre informazioni, vedere Dispositivi di backup.

Nota

L'opzione NASTRO verrà rimossa in una versione futura di SQL Server. Evitare di usare questa funzionalità in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata.

n
Segnaposto che indica che è possibile specificare fino a 64 dispositivi di backup in un elenco delimitato da virgole.

MIRROR TO <backup_device> [ ,...n ]

Indica un set di un massimo di tre dispositivi di backup secondari, ognuno dei quali esegue il mirroring dei dispositivi di backup specificati nella clausola TO. La clausola MIRROR TO deve specificare lo stesso tipo e numero di dispositivi di backup indicati nella clausola TO. Il numero massimo di clausole MIRROR TO è tre.

Questa opzione è disponibile solo nell'edizione Enterprise di SQL Server.

Nota

Per MIRROR TO = DISK, l'istruzione BACKUP determina automaticamente le dimensioni appropriate del blocco per i dispositivi disco in base alle dimensioni di settore del disco. Se MIRROR TO DISK è formattata con dimensioni di settore diverse rispetto al disco specificato come dispositivo di backup primario, il comando di backup avrà esito negativo. Per eseguire il mirroring dei backup nei dispositivi con dimensioni di settore diverse, è necessario specificare il parametro BLOCKSIZE e impostare le dimensioni del settore più elevate tra tutti i dispositivi di destinazione. Per ulteriori informazioni sulle dimensioni del blocco, vedere "BLOCKSIZE" più avanti in questo argomento.

<backup_device>
Vedere "<backup_device>" sopra in questa sezione.

n
Segnaposto che indica che è possibile specificare fino a 64 dispositivi di backup in un elenco delimitato da virgole. Il numero di dispositivi specificato nella clausola MIRROR TO deve essere uguale al numero di dispositivi indicato nella clausola TO.

Per altre informazioni, vedere "Gruppi di supporti in set di supporti con mirroring" nella sezione Commenti più avanti in questo articolo.

[ next-mirror-to ]
Segnaposto che indica che una singola istruzione BACKUP può contenere fino a tre clausole MIRROR TO, oltre alla singola clausola TO.

Opzioni WITH

Opzioni da utilizzare con un'operazione di backup.

CREDENTIAL

Si applica a: SQL Server, a partire da SQL Server 2012 (11.x) SP1 CU2.

Utilizzato solo quando si crea un backup per Archiviazione BLOB di Azure.

FILE_SNAPSHOT

Si applica a: SQL Server, a partire da SQL Server 2016 (13.x).

Usato per creare uno snapshot di Azure dei file di database quando tutti i file di database di SQL Server vengono archiviati usando Archiviazione BLOB di Azure. Per altre informazioni, vedere File di dati di SQL Server in Microsoft Azure. Il backup di snapshot di SQL Server acquisisce snapshot di Azure dei file di database (file di dati e file di log) in uno stato coerente. Un set coerente di snapshot di Azure costituisce un backup e viene registrato nel file di backup. L'unica differenza tra BACKUP DATABASE TO URL WITH FILE_SNAPSHOT e BACKUP LOG TO URL WITH FILE_SNAPSHOT è che quest'ultimo esegue anche il troncamento del log delle transazioni mentre il primo non esegue alcun troncamento. Con il backup di snapshot di SQL Server, dopo il backup completo iniziale richiesto da SQL Server per stabilire la catena di backup, è necessario un solo backup del log delle transazioni per ripristinare un database nel punto nel tempo del backup del log delle transazioni. Inoltre, sono necessari solo due backup del log delle transazioni per ripristinare un database in un punto nel tempo compreso tra i due backup del log delle transazioni.

DIFFERENTIAL

Opzione utilizzata solo con BACKUP DATABASE, che indica che il backup del database o del file deve includere solo le parti del database o del file modificate dopo l'ultimo backup completo. Un backup differenziale occupa in genere meno spazio rispetto a un backup completo. Utilizzare questa opzione per evitare di applicare tutti i singoli backup del log eseguiti dopo l'ultimo backup completo.

Nota

Per impostazione predefinita, BACKUP DATABASE crea un backup completo.

Per altre informazioni, vedere Backup differenziali.

ENCRYPTION

Consente di specificare la crittografia per un backup. È possibile specificare un algoritmo di crittografia con cui crittografare il backup oppure specificare NO_ENCRYPTION per non eseguire alcuna crittografia del backup. La crittografia è consigliabile per la sicurezza dei file di backup. Gli algoritmi che si possono specificare sono:

AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION

Se si sceglie di crittografare è necessario specificare il componente di crittografia utilizzando le relative opzioni:

SERVER CERTIFICATE = Encryptor_Name
SERVER ASYMMETRIC KEY = Encryptor_Name

SERVER CERTIFICATE e SERVER ASYMMETRIC KEY rappresentano un certificato e una chiave asimmetrica creati nel database master. Per altre informazioni, vedere CREATE CERTIFICATE e CREATE ASYMMETRIC KEY, rispettivamente.

Avviso

Quando la crittografia viene usata con l'argomento FILE_SNAPSHOT, il file di metadati viene crittografato usando l'algoritmo di crittografia specificato e il sistema verifica che il processo di Transparent Data Encryption (TDE) sia stato completato per il database. Non viene eseguita alcuna crittografia aggiuntiva per i dati. Il backup non viene eseguito se il database non è stato crittografato o se la crittografia non è stata completata prima dell'istruzione di backup.

Opzioni relative al set di backup

Queste opzioni riguardano il set di backup creato dall'operazione di backup.

Nota

Per specificare un set di backup per un'operazione di ripristino, usare l'opzione FILE = <backup_set_file_number>. Per altre informazioni su come specificare un set di backup, vedere "Specifica di un set di backup" in Argomenti dell'istruzione RESTORE.

COPY_ONLY

Specifica che il backup è un backup di sola copia che non influisce sulla normale sequenza di backup. Un backup di sola copia viene creato indipendentemente dai normali backup pianificati regolarmente. Un backup di sola copia non ha alcun impatto sulle procedure generali di backup e ripristino per il database.

I backup di sola copia devono essere utilizzati nelle situazioni in cui un backup è necessario per uno scopo specifico, ad esempio un backup del log prima di un ripristino di file online. In genere, un backup del log di sola copia viene utilizzato una sola volta e quindi eliminato.

Se usata con BACKUP DATABASE, l'opzione COPY_ONLY crea un backup completo che non può essere usato come base differenziale. La mappa di bit differenziale non viene aggiornata e i backup differenziali ignorano il backup di sola copia. I backup differenziali successivi utilizzano come base il backup completo convenzionale più recente.

Importante

Se DIFFERENTIAL e COPY_ONLY vengono usate insieme, COPY_ONLY viene ignorata e viene creato un backup differenziale.
Se usata con BACKUP LOG, l'opzione COPY_ONLY crea un backup del log di sola copia che non esegue il troncamento del log delle transazioni. Il backup del log di sola copia non ha alcun effetto sulla catena di log e viene ignorato dagli altri backup del log.

Per altre informazioni, vedere Backup di sola copia.

[ COMPRESSION [ ALGORITHM = ( { MS_XPRESS | accelerator_algorithm } ) ] | NO_COMPRESSION ]

Specifica se la compressione dei backup viene eseguita su questo backup, ignorando l'impostazione predefinita a livello di server.

In fase di installazione, la compressione backup è disattivata per impostazione predefinita. Questa impostazione predefinita può essere modificata impostando l'opzione di configurazione del server backup compression default. Per informazioni sulla visualizzazione del valore corrente di questa opzione, vedere Visualizzare o modificare le proprietà del server.

Per informazioni sull'uso della compressione dei backup con i database con Transparent Data Encryption (TDE), vedere la sezione Osservazioni.

COMPRESSION
Abilita in modo esplicito la compressione dei backup.

NO_COMPRESSION
Disabilita in modo esplicito la compressione dei backup.

SQL Server 2022 (16.x) introduce ALGORITHM, che identifica un algoritmo di compressione per l'operazione. Il valore predefinito è MS_XPRESS. Se è stata configurata l'accelerazione integrata e l'offload, è possibile usare un acceleratore fornito dalla soluzione. Ad esempio, se è stata configurata la tecnologia Intel® QuickAssist (QAT) per SQL Server, l'esempio seguente completa il backup con la soluzione di acceleratore, con la libreria QATzip usando QZ_DEFLATE con il livello di compressione 1.

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

DESCRIPTION = { 'text' | @text_variable }

Specifica il testo in formato libero che descrive il set di backup. La stringa può essere composta da un massimo di 255 caratteri.

NAME = { backup_set_name | @backup_set_var }

Specifica il nome del set di backup. I nomi possono essere composti da un massimo di 128 caratteri. Se si omette NAME, al set di backup non viene assegnato alcun nome specifico.

{ EXPIREDATE ='date' | RETAINDAYS = days }

Indica quando è possibile sovrascrivere il set di backup per il backup specifico. Se si utilizzano entrambe le opzioni, RETAINDAYS ha la precedenza rispetto a EXPIREDATE.

Se non viene specificata alcuna opzione, la data di scadenza viene determinata dall'impostazione di media retention configurazione. Per altre informazioni, vedere Opzioni di configurazione del server.

Importante

Queste opzioni impediscono esclusivamente la sovrascrittura di file da parte di SQL Server. È possibile cancellare i nastri con altri metodi e i file su disco possono essere eliminati tramite il sistema operativo. Per ulteriori informazioni sulla verifica della scadenza, vedere le opzioni SKIP e FORMAT in questo argomento.

EXPIREDATE = { 'date' | @date_var }
Specifica quando il set di backup scade e può essere sovrascritto. Se specificata in forma di variabile (@date_var), la data deve essere indicata nel formato datetime del sistema configurato e specificata in uno dei modi seguenti:

Come costante di stringa (@date_var= date)
Come variabile di tipo stringa di caratteri, ad eccezione del tipo di dati ntext o text
Come smalldatetime
Come variabile datetime

Ad esempio:

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

Per informazioni su come specificare valori datetime, vedere Tipi data e ora.

Nota

Per ignorare la data di scadenza, usare l'opzione SKIP.

RETAINDAYS = { days | @days_var }
Specifica il numero di giorni che devono trascorrere prima che il set di supporti di backup possa essere sovrascritto. Se indicato in forma di variabile (@days_var), è necessario specificarlo come valore intero.

{ METADATA_ONLY | SN piattaforma di strumenti analitici HOT }

Si applica a: SQL Server 2022 (16.x)

METADATA_ONLY e SN piattaforma di strumenti analitici HOT sono sinonimi.

Opzioni relative ai set di supporti

Queste opzioni vengono applicate all'intero set di supporti.

{ NOINIT | INIT }

Controlla se l'operazione di backup aggiunge o sovrascrive i set di backup esistenti nel supporto di backup. L'impostazione predefinita consiste nell'accodare i dati al set di backup più recente presente nel supporto (NOINIT).

Nota

Per informazioni sulle interazioni tra { NOINIT | INIT } e { NOSKIP | SKIP }, vedere la sezione Osservazioni più avanti in questo argomento.

NOINIT
Indica che il set di backup viene aggiunto al set di supporti specificato, mantenendo i set di backup esistenti. Se per il set di supporti è stata definita una password, è necessario specificare la password corretta. NOINIT è l'opzione predefinita.

Per altre informazioni, vedere Set di supporti, gruppi di supporti e set di backup.

INIT
Specifica che tutti i set di backup devono essere sovrascritti, ma conservano l'intestazione del supporto. Se si specifica INIT, vengono sovrascritti tutti i set di backup presenti nel dispositivo, se le condizioni lo consentono. Per impostazione predefinita, l'istruzione BACKUP controlla se esistono le condizioni seguenti e non sovrascrive i supporti di backup in presenza di una di tali condizioni:

Vi sono set di backup non ancora scaduti. Per altre informazioni, vedere le opzioni EXPIREDATE e RETAINDAYS.
Il nome del set di backup specificato nell'istruzione BACKUP, se indicato, non corrisponde al nome nei supporti di backup. Per ulteriori informazioni, vedere l'opzione NAME in precedenza in questa sezione.

Per ignorare questi controlli, usare l'opzione SKIP.

Per altre informazioni, vedere Set di supporti, gruppi di supporti e set di backup.

{ NOSKIP | SKIP }

Controlla se un'operazione di backup controlla la data e l'ora di scadenza dei set di backup nel supporto prima di sovrascriverli.

Nota

Per informazioni sulle interazioni tra { NOINIT | INIT } e { NOSKIP | SKIP }, vedere la sezione "Osservazioni" più avanti in questo argomento.

NOSKIP
Indica all'istruzione BACKUP di controllare la data di scadenza di tutti i set di backup nel supporto prima di consentirgli di sovrascriverli. Si tratta del comportamento predefinito.

SKIP
Disabilita il controllo della scadenza e del nome del set di backup in genere eseguito dall'istruzione BACKUP per evitare sovrascrizioni di set di backup. Per informazioni sulle interazioni tra { INIT | NOINIT } e { NOSKIP | SKIP }, vedere la sezione "Commenti" più avanti in questo articolo. Per visualizzare le date di scadenza dei set di backup, eseguire una query nella colonna expiration_date della tabella della cronologia backupset.

{ NOFORMAT | FORMAT }

Specifica se l'intestazione del supporto deve essere scritta nei volumi utilizzati per questa operazione di backup, sovrascrivendo eventuali intestazioni multimediali e set di backup esistenti.

NOFORMAT
Specifica che l'operazione di backup mantiene l'intestazione del supporto esistente e i set di backup nei volumi multimediali utilizzati per questa operazione di backup. Si tratta del comportamento predefinito.

FORMAT
Specifica che deve essere creato un nuovo set di supporti. FORMAT comporta la scrittura di una nuova intestazione supporto in tutti i volumi dei supporti utilizzati per l'operazione di backup. Il contenuto esistente del volume non è più valido, in quanto tutte le intestazioni supporti e i set di backup esistenti vengono sovrascritti.

Importante

Usare FORMAT con attenzione. La formattazione di un volume di un set di supporti rende inutilizzabile l'intero set di supporti. Se, ad esempio, si inizializza un singolo nastro appartenente a un set di supporti con striping esistente, l'intero set di supporti diventa inutilizzabile.

L'utilizzo dell'opzione FORMAT implica l'uso di SKIP. Non è quindi necessario specificare SKIP in modo esplicito.

MEDIADESCRIPTION = { text | @text_variable }

Specifica la descrizione di testo in formato libero, massimo 255 caratteri, del set di supporti.

MEDIANAME = { media_name | @media_name_variable }

Specifica il nome del supporto per l'intero set di supporti di backup. Il nome del supporto non deve contenere più di 128 caratteri. Se MEDIANAME viene specificato, deve corrispondere al nome del supporto specificato in precedenza già esistente nei volumi di backup. Se si omette MEDIANAME oppure si specifica l'opzione SKIP, non viene eseguita alcuna verifica del nome dei supporti.

BLOCKSIZE = { blocksize | @blocksize_variable }

Specifica le dimensioni fisiche del blocco, in byte. Le dimensioni supportate sono 512, 1024, 2048, 4096, 8192, 16384, 32768 e 65536 (64 KB) byte. Il valore predefinito è 65536 per i dispositivi nastro e 512 negli altri casi. Questa opzione non è in genere necessaria, in quanto vengono selezionate automaticamente le dimensioni del blocco più appropriate per il dispositivo. L'impostazione esplicita delle dimensioni del blocco ha la priorità sulla selezione automatica.

Se si esegue un backup che si desidera copiare in e ripristinare da un CD-ROM, specificare BLOCKSIZE=2048.

Nota

In genere, questa opzione influisce sulle prestazioni solo durante la scrittura nei dispositivi nastro.

Opzioni di trasferimento dei dati

BUFFERCOUNT = { buffercount | @buffercount_variable }

Specifica il numero totale di buffer di I/O da usare per l'operazione di backup. È possibile specificare qualsiasi numero intero positivo. Un numero elevato di buffer può tuttavia causare errori di memoria insufficiente dovuti a spazio degli indirizzi virtuali non adeguato nel processo Sqlservr.exe.

Lo spazio totale usato dai buffer viene determinato da BUFFERCOUNT * MAXTRANSFERSIZE.

Nota

Per informazioni importanti sull'uso dell'opzione BUFFERCOUNT, vedere la pagina del blog Incorrect BufferCount data transfer option can lead to OOM condition (Un'opzione di trasferimento dei dati BufferCount errata può causare una condizione di memoria insufficiente).

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Specifica le dimensioni massime, in byte, per il trasferimento tra SQL Server e i supporti di backup. I valori possibili sono i multipli di 65536 byte (64 KB) fino a 4194304 byte (4 MB).

Durante la creazione di backup tramite il servizio writer SQL, se il database include l'opzione FILESTREAM configurata o filegroup ottimizzati per la memoria, MAXTRANSFERSIZE al momento del ripristino deve essere maggiore o uguale a MAXTRANSFERSIZE usato durante la creazione del backup.

Per i database con Transparent Data Encryption (TDE) con un singolo file di dati, MAXTRANSFERSIZE predefinito è 65536 (64 KB). Per i database non crittografati TDE, il valore predefinito MAXTRANSFERSIZE è 1048576 (1 MB) quando si usa il backup su DISCO e 65536 (64 KB) quando si usa VDI o TAPE. Per informazioni sull'uso della compressione dei backup con i database con crittografia TDE, vedere la sezione Osservazioni.

Opzioni relative alla gestione degli errori

Queste opzioni consentono di specificare se i checksum del backup sono abilitati per l'operazione di backup e se l'operazione deve essere arrestata in caso di errore.

{ NO_CHECKSUM | CHECKSUM }

Controlla se i checksum di backup sono abilitati.

NO_CHECKSUM
Disabilita in modo esplicito la generazione di checksum di backup (e la convalida dei checksum di pagina). Si tratta del comportamento predefinito.

CHECKSUM
Specifica che l'operazione di backup verifica in ogni pagina la presenza di checksum e pagine incomplete, se abilitati e disponibili, e genera un checksum per l'intero backup.

L'uso dei checksum di backup può influire sulla velocità effettiva del carico di lavoro e del backup.

Per altre informazioni, vedere Possibili errori relativi ai supporti durante il backup e il ripristino.

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Controlla se un'operazione di backup si arresta o continua dopo aver rilevato un errore di checksum della pagina.

STOP_ON_ERROR
Indica a BACKUP di non riuscire se non viene verificato un checksum di pagina. Si tratta del comportamento predefinito.

CONTINUE_AFTER_ERROR
Imposta il proseguimento dell'istruzione BACKUP anche in caso di errori, ad esempio checksum non validi o pagine incomplete.

Se non è possibile eseguire il backup della parte finale del log usando l'opzione NO_TRUNCATE quando il database è danneggiato, è possibile tentare un backup della parte finale del log specificando CONTINUE_AFTER_ERROR anziché NO_TRUNCATE.

Per altre informazioni, vedere Possibili errori relativi ai supporti durante il backup e il ripristino.

Opzioni di compatibilità

RESTART

A partire da SQL Server 2008 (10.0.x), non ha alcun effetto. L'opzione è accettata in questa versione per compatibilità con le versioni precedenti di SQL Server.

Opzioni di monitoraggio

STATS [ = percentage ]

Visualizza un messaggio ad ogni completamento di percentage e consente di tenere traccia dello stato di avanzamento dell'operazione. Se si omette percentage, SQL Server visualizza un messaggio dopo il completamento di ogni 10% dell'operazione.

L'opzione STATS segnala la percentuale di completamento in base alla soglia specificata per l'intervallo successivo. Si tratta approssimativamente della percentuale specificata. Con l'impostazione STATS=10, ad esempio, se la percentuale di completamento corrisponde al 40%, potrebbe venire indicata una percentuale uguale al 43%. Per i set di backup di grandi dimensioni ciò non rappresenta un problema, perché la percentuale di completamento aumenta molto lentamente tra le varie chiamate di I/O completate.

Opzioni relative al nastro

Queste opzioni vengono utilizzate solo per i dispositivi nastro. Se non si utilizza un dispositivo nastro, queste opzioni vengono ignorate.

{ REWIND | NOREWIND }

REWIND
Specifica che SQL Server deve rilasciare e riavvolgere il nastro. REWIND è l'opzione predefinita.

NOREWIND
Specifica che SQL Server deve mantenere il nastro aperto dopo l'operazione di backup. È possibile utilizzare questa opzione per migliorare le prestazioni quando si eseguono più operazioni di backup sullo stesso nastro.

L'opzione NOREWIND implica l'utilizzo di NOUNLOAD e queste opzioni non sono compatibili all'interno di una singola istruzione BACKUP.

Nota

Se si usa l'opzione NOREWIND, l'istanza di SQL Server mantiene la proprietà dell'unità nastro fino a quando un'istruzione BACKUP o RESTORE eseguita nello stesso processo non usa l'opzione REWIND o UNLOAD oppure l'istanza del server viene chiusa. Ciò impedisce ad altri processi di accedere al nastro. Per informazioni su come visualizzare un elenco di nastri aperti e come chiudere un nastro aperto, vedere Dispositivi di backup.

{ UNLOAD | NOUNLOAD }

Nota

UNLOAD e NOUNLOAD sono impostazioni di sessione che rimangono valide per l'intera durata della sessione o finché non vengono reimpostate tramite la specifica di un'impostazione alternativa.

UNLOAD
Specifica che il nastro viene riavvolto e scaricato automaticamente al termine del backup. L'opzione UNLOAD è l'impostazione predefinita all'avvio di una sessione.

NOUNLOAD
Specifica che dopo l'operazione BACKUP il nastro rimane caricato sull'unità nastro.

Nota

Per un backup in un dispositivo di backup su nastro, l'opzione BLOCKSIZE influisce sulle prestazioni dell'operazione di backup. In genere, questa opzione influisce sulle prestazioni solo durante la scrittura nei dispositivi nastro.

Opzioni specifiche dei log

Queste opzioni vengono usate solo con BACKUP LOG.

Nota

Se non si desidera eseguire un backup del log, utilizzare il modello di recupero con registrazione minima. Per altre informazioni, vedere Modelli di recupero.

{ NORECOVERY | STANDBY = undo_file_name }

NORECOVERY
Consente di eseguire il backup della parte finale del log lasciando il database nello stato RESTORING. L'opzione NORECOVERY risulta utile quando si esegue il failover in un database secondario o per salvare la parte finale del log prima di un'operazione RESTORE.

Usare insieme le opzioni NO_TRUNCATE e NORECOVERY per eseguire un backup del log senza troncamento del log e quindi portare il database nello stato RESTORING in modo atomico.

STANDBY =standby_file_name
Consente di eseguire il backup della parte finale del log lasciando il database nello stato STANDBY e di sola lettura. La clausola STANDBY scrive i dati di standby (esecuzione del rollback ma con la possibilità di ulteriori ripristini). L'utilizzo dell'opzione STANDBY equivale all'esecuzione di BACKUP LOG WITH NORECOVERY seguita da RESTORE WITH STANDBY.

Per usare la modalità standby è necessario un file standby, specificato con standby_file_name, il cui percorso viene archiviato nel log del database. Se il file specificato esiste già, il motore di database lo sovrascrive. Se il file non esiste, viene creato dal motore di database. Il file standby diventa un elemento integrante del database.

In questo file vengono memorizzate le modifiche di cui è stato eseguito il rollback, che devono essere annullate se è necessario eseguire successivamente operazioni RESTORE LOG. Lo spazio su disco a disposizione deve essere sufficiente per contenere il file standby, le cui dimensioni aumenteranno in quanto dovrà includere tutte le pagine distinte del database modificate dal rollback delle transazioni per le quali non è stato eseguito il commit.

NO_TRUNCATE

Specifica che il log delle transazioni non deve essere troncato e determina quindi un tentativo di backup da parte del motore di database indipendentemente dallo stato del database. È pertanto possibile che un backup creato con NO_TRUNCATE contenga metadati incompleti. Questa opzione consente l'esecuzione del backup del log delle transazioni quando il database è danneggiato.

L'opzione NO_TRUNCATE per BACKUP LOG equivale a specificare sia COPY_ONLY che CONTINUE_AFTER_ERROR.

Se non si usa l'opzione NO_TRUNCATE, il database deve essere ONLINE. Se lo stato del database corrisponde a SUSPENDED, è possibile creare un backup specificando NO_TRUNCATE. Se tuttavia lo stato del database è OFFLINE o EMERGENCY, l'esecuzione dell'istruzione BACKUP non è consentita nemmeno con NO_TRUNCATE. Per informazioni sugli stati del database, vedere Stati del database.

Informazioni sull'uso dei backup di SQL Server

In questa sezione vengono presentati i seguenti concetti di backup fondamentali:

Tipi di backup Troncamento del log delle transazioni Formattazione dei supporti di backup Uso di dispositivi di backup e set di supporti Ripristino di backup di SQL Server

Nota

Per un'introduzione al backup in SQL Server, vedere Panoramica del backup.

Tipi di backup

I tipi di backup supportati dipendono dal modello di recupero del database utilizzato, in base a quanto indicato di seguito.

Tutti i modelli di recupero supportano backup completi e differenziali dei dati.

Ambito del backup	Tipi di backup
Database intero	I backup del database vengono eseguiti sull'intero database. Facoltativamente, ogni backup del database può essere usato come base di una serie di uno o più backup differenziali del database.
Database parziale	I backup parziali vengono eseguiti sui filegroup di lettura/scrittura e, facoltativamente, su uno o più file o filegroup di sola lettura. Facoltativamente, ogni backup parziale può essere usato come base di una serie di uno o più backup parziali differenziali.
File o filegroup	I backup dei file vengono eseguiti su uno o più file o filegroup e sono rilevanti solo per i database contenenti più filegroup. Se si utilizza il modello di recupero con registrazione minima, i backup dei file sono in genere limitati ai filegroup di sola lettura secondari. Facoltativamente, ogni backup dei file può essere usato come base di una serie di uno o più backup differenziali dei file.

Se si usa il modello di recupero con registrazione completa o con registrazione minima delle operazioni bulk, i backup convenzionali includono anche backup del log delle transazioni (o backup del log) sequenziali, che sono obbligatori. Ogni backup del log viene eseguito sulla parte del log delle transazioni attiva al momento della creazione del backup e include tutti i record del log di cui non è stato eseguito il backup nei backup del log precedenti.

Per ridurre al minimo il rischio di perdita di dati, aumentando tuttavia il numero di operazioni amministrative, è consigliabile pianificare backup del log frequenti. La pianificazione di backup differenziali nei periodi intermedi tra i backup completi consente di ridurre i tempi di ripristino limitando il numero di backup del log da ripristinare in seguito al ripristino dei dati.

È consigliabile archiviare i backup dei log in un volume distinto rispetto ai backup dei database.

Nota

Prima che sia possibile creare il primo backup del log, è necessario creare un backup completo.
Un backup di sola copia è un backup completo o un backup del log per scopi speciali indipendente dalla normale sequenza di backup convenzionali. Per creare un backup di sola copia, specificare l'opzione COPY_ONLY nell'istruzione BACKUP. Per altre informazioni, vedere Backup di sola copia.

Troncamento del log delle transazioni

Per evitare di esaurire lo spazio nel log delle transazioni di un database, è essenziale eseguire backup di routine. Con il modello di recupero con registrazione minima il troncamento del log si verifica automaticamente dopo il backup del database, mentre con il modello di recupero con registrazione completa si verifica dopo il backup del log delle transazioni. A volte, tuttavia, il processo di troncamento può essere ritardato. Per informazioni sui fattori che possono ritardare il troncamento del log, vedere Log delle transazioni.

Nota

Le opzioni BACKUP LOG WITH NO_LOG e WITH TRUNCATE_ONLY non sono più disponibili. Se si utilizza il modello di recupero con registrazione completa o con registrazione minima delle operazioni bulk ed è necessario rimuovere la catena dei backup del log da un database, passare al modello di recupero con registrazione minima. Per altre informazioni, vedere Visualizzazione o modifica del modello di recupero di un database.

Formattazione dei supporti di backup

I supporti di backup vengono formattati tramite l'istruzione BACKUP esclusivamente quando si verifica una delle condizioni seguenti:

L'opzione FORMAT è specificata.
I supporti sono vuoti.
Viene eseguita un'operazione di scrittura in un nastro di continuità.

Usare dispositivi di backup e set di supporti

Dispositivi di backup in un set di supporti con striping (set di striping)

Un set di striping è un set di file su disco in cui i dati sono divisi in blocchi e distribuiti in base a un ordine prestabilito. Il numero di dispositivi di backup usati in un set di striping deve rimanere invariato, a meno che i supporti non vengano reinizializzati tramite FORMAT.

Nell'esempio seguente un backup del database AdventureWorks2022 viene scritto in un nuovo set di supporti con striping che utilizza tre file su disco.

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

Dopo avere definito un dispositivo di backup come parte di un set di striping, non è possibile utilizzarlo per il backup su un singolo dispositivo, a meno che non si specifichi FORMAT. In modo analogo, non è possibile utilizzare un dispositivo di backup contenente backup senza striping in un set di striping, a meno che non si specifichi l'opzione FORMAT. Utilizzare l'opzione FORMAT per dividere un set di backup di striping.

Se per la scrittura di un'intestazione supporto non si specifica né MEDIANAME né MEDIADESCRIPTION, il campo dell'intestazione supporto corrispondente alla voce non specificata risulta vuoto.

Usare un set di supporti con mirroring

In genere, i backup vengono eseguiti senza mirroring e le istruzioni BACKUP includono solo una clausola TO. Ogni set di supporti, tuttavia, può contenere uno totale di quattro mirror. Per un set di supporti con mirroring, l'operazione di backup scrive in più gruppi di dispositivi di backup. Ogni gruppo di dispositivi di backup comprende un solo mirror all'interno del set di supporti con mirroring. Ogni mirror deve utilizzare la stessa quantità e lo stesso tipo di dispositivi di backup fisici, configurati con le stesse proprietà.

Per eseguire il backup in un set di supporti con mirroring, è necessario che siano presenti tutti i mirror. Per eseguire il backup in un set di backup con mirroring, specificare la clausola TO per indicare il primo mirror e quindi una clausola MIRROR TO per ogni mirror aggiuntivo.

Per un set di supporti con mirroring, ogni clausola MIRROR TO deve includere lo stesso numero e lo stesso tipo di dispositivi indicati nella clausola TO. Nell'esempio seguente viene eseguita la scrittura in un set di supporti con mirroring contenente due mirror, utilizzando tre dispositivi per ogni mirror:

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

Importante

Questo esempio è progettato in modo da poter essere testato nel sistema locale. In pratica, l'esecuzione di un backup su più dispositivi nella stessa unità influirebbe negativamente sulle prestazioni ed eliminerebbe la ridondanza per cui sono progettati i set di supporti con mirroring.

Gruppi di supporti in set di supporti con mirroring

Ogni dispositivo di backup specificato nella clausola TO di un'istruzione BACKUP corrisponde a un gruppo di supporti. Se, ad esempio, nella clausola TO sono indicati tre dispositivi, l'istruzione BACKUP scrive i dati in tre gruppi di supporti. In un set di supporti con mirroring ogni mirror deve contenere una copia di ogni gruppo di supporti. Per questo motivo, il numero di dispositivi deve essere identico in ogni mirror.

Se per ogni mirror vengono specificati più dispositivi, l'ordine dei dispositivi nell'elenco determina il gruppo di supporti scritto in ogni dispositivo specifico. In ognuno degli elenchi di dispositivi, ad esempio, il secondo dispositivo corrisponde al secondo gruppo di supporti. Nella tabella seguente viene illustrata la corrispondenza tra i dispositivi e i gruppi di supporti inclusi nell'esempio precedente.

Mirror	Gruppo di supporti 1	Gruppo di supporti 2	Gruppo di supporti 3
0	`Z:\AdventureWorks1a.bak`	`Z:\AdventureWorks2a.bak`	`Z:\AdventureWorks3a.bak`
1	`Z:\AdventureWorks1b.bak`	`Z:\AdventureWorks2b.bak`	`Z:\AdventureWorks3b.bak`

Di ogni gruppo di supporti è necessario eseguire il backup sempre nello stesso dispositivo all'interno di un mirror specifico. Per questo motivo, ogni volta che si utilizza un set di supporti esistente, è necessario elencare i dispositivi di ogni mirror in base allo stesso ordine in cui sono stati specificati al momento della creazione del set di supporti.

Per altre informazioni sui set di supporti con mirroring, vedere Set di supporti di backup con mirroring. Per altre informazioni sui set di supporti e sulle famiglie di supporti in generale, vedere Set di supporti, gruppi di supporti e set di backup.

Ripristinare i backup di SQL Server

Per ripristinare un database e, facoltativamente, recuperarlo per portarlo online, oppure per ripristinare un file o un gruppo di file, usare l'istruzione RESTORE di Transact-SQL o le attività di ripristino di SQL Server Management Studio. Per altre informazioni, vedere Panoramica del ripristino e del recupero.

Considerazioni aggiuntive sulle opzioni DI BACKUP

Interazione di SKIP, NOSKIP, INIT e NOINIT

Questa tabella descrive le interazioni tra le opzioni { NOINIT | INIT } e { NOSKIP | SKIP }.

Nota

Se il nastro è vuoto oppure il file di backup su disco non esiste, tutte le interazioni comportano la scrittura di un'intestazione supporto prima di continuare l'operazione. Se i supporti non sono vuoti e non è presente un'intestazione supporto valida, viene segnalata la presenza di supporti MTF non validi e l'operazione di backup viene interrotta.

Opzione skip	NOINIT	INIT
NOSKIP	Se il volume contiene un'intestazione supporto valida, verifica che il nome del supporto corrisponda al valore di `MEDIANAME`, se specificato. Se il nome corrisponde, il set di backup viene accodato, mantenendo tutti i set di backup esistenti. Se il volume non contiene un'intestazione supporto valida, viene generato un errore.	Se il volume contiene un'intestazione supporto valida, vengono effettuati i controlli seguenti: Se è stato specificato `MEDIANAME`, viene verificata la corrispondenza tra il nome del supporto indicato e il nome del supporto nell'intestazione.¹ Verifica dell'assenza di set di backup non scaduti nel supporto. In caso contrario, il backup viene interrotto. Se i controlli hanno esito positivo, gli eventuali set di backup presenti nel supporto vengono sovrascritti, mantenendo solo l'intestazione. Se il volume non contiene un'intestazione supporto valida, ne viene generata automaticamente una con i valori specificati per `MEDIANAME` e `MEDIADESCRIPTION`, se disponibili.
SKIP	Se il volume contiene un'intestazione supporto valida, il set di backup viene accodato, mantenendo tutti i set di backup esistenti.	Se il volume contiene un'intestazione supporto valida², gli eventuali set di backup presenti nel supporto vengono sovrascritti, mantenendo solo l'intestazione. Se il supporto è vuoto, viene generata un'intestazione usando i valori specificati per `MEDIANAME` e `MEDIADESCRIPTION`, se disponibili.

¹ Per eseguire un'operazione di backup, l'utente deve appartenere al ruolo predefinito del database o del server appropriato.

² Per il controllo di validità vengono verificati il numero di versione MTF e altre informazioni dell'intestazione. Se la versione specificata non è supportata o ha un valore imprevisto, viene generato un errore.

Compatibilità

Attenzione

I backup creati nella versione più recente di SQL Server non possono essere ripristinati nelle versioni precedenti di SQL Server.

BACKUP supporta l'opzione per garantire la RESTART compatibilità con le versioni precedenti di SQL Server. L'opzione RESTART non ha tuttavia alcun effetto.

Osservazioni:

È possibile accodare i backup di database o log in qualsiasi disco o dispositivo nastro, in modo che il database e i relativi log delle transazioni possano essere mantenuti nella stessa posizione fisica.

Non è possibile usare l'istruzione BACKUP in una transazione esplicita o implicita .

Non è possibile eseguire il backup di un database negli stati seguenti:

Restoring
Standby
Sola lettura

È possibile eseguire operazioni di backup tra piattaforme diverse e anche tra tipi di processore diversi, a condizione che le regole di confronto del database siano supportate dal sistema operativo.

A partire da SQL Server 2016 (13.x), impostando MAXTRANSFERSIZE su un valore maggiore di 65536 (64 KB) si abilita un algoritmo di compressione ottimizzato per i database con crittografia Transparent Data Encryption (TDE) che esegue innanzitutto la decrittografia di una pagina, la comprime e quindi ne esegue nuovamente la crittografia. Se il parametro MAXTRANSFERSIZE non viene specificato o se viene usato il valore MAXTRANSFERSIZE = 65536 (64 KB), la compressione di backup con i database con crittografia TDE comprime direttamente le pagine crittografate e potrebbe non produrre rapporti di compressione validi. Per altre informazioni, vedere Backup Compression for TDE-enabled Databases (Compressione dei backup per i database con TDE).

A partire da SQL Server 2019 (15.x) CU5, non è più necessario impostare MAXTRANSFERSIZE per abilitare questo algoritmo di compressione ottimizzato con TDE. Se il comando di backup viene specificato con WITH COMPRESSION o la configurazione del server del valore predefinito di compressione backup è impostata su 1, il valore di MAXTRANSFERSIZE verrà automaticamente aumentato a 128 KB per abilitare l'algoritmo ottimizzato. Se MAXTRANSFERSIZE viene specificato nel comando di backup con un valore > 64 K, il valore specificato viene rispettato. In altre parole, SQL Server non riduce mai automaticamente il valore, ma lo aumenta solo. Se è necessario eseguire il backup di un database con crittografia TDE con MAXTRANSFERSIZE = 65536, è necessario specificare WITH NO_COMPRESSION o assicurarsi che la configurazione server Valore predefinito di compressione backup sia impostata su 0.

Nota

Esistono casi in cui il valore predefinito MAXTRANSFERSIZE è maggiore di 64 KB:

Quando nel database sono stati creati più file di dati, viene usato il valore MAXTRANSFERSIZE> 64 K.
Quando si esegue il backup nell'URL in Archiviazione BLOB di Azure, il valore predefinito è MAXTRANSFERSIZE = 1048576 (1 MB).
Quando si esegue il backup nell'URL di un'archiviazione oggetti compatibile con S3, il valore predefinito è MAXTRANSFERSIZE = 10485760 (10 MB).

Anche se sussiste una di queste condizioni, è necessario impostare esplicitamente MAXTRANSFERSIZE su un valore maggiore di 64K nel comando di backup per ottenere l'algoritmo di compressione di backup ottimizzato, a meno che non si usi SQL Server 2019 (15.x) CU5 o una versione successiva.

Per impostazione predefinita, per ogni operazione di backup eseguita in modo corretto viene aggiunta una voce al log degli errori di SQL Server e al registro eventi di sistema. Se il backup del log viene eseguito di frequente, questi messaggi di corretta esecuzione possono aumentare rapidamente, provocando la creazione di log degli errori di dimensioni elevate e rendendo difficile l'individuazione di altri messaggi. In questo caso è possibile eliminare tali voci di log usando il flag di traccia 3226 se l'automazione o il monitoraggio non dipendono da esse. Per altre informazioni, vedere Flag di traccia.

Interoperabilità

In SQL Server viene usato un processo di backup online per consentire l'esecuzione del backup di un database mentre il database è ancora in uso. Durante un backup, è possibile eseguire la maggior parte delle operazioni, ad esempio istruzioni INSERT, UPDATE o DELETE.

Le operazioni di cui non è consentita l'esecuzione durante un backup del database o del log delle transazioni sono le seguenti:

Operazioni di gestione dei file, ad esempio l'istruzione ALTER DATABASE con le opzioni ADD FILE o REMOVE FILE.
Compattazione di database o file, Sono incluse le operazioni autoshrink.

Se un'operazione di backup si sovrappone a una gestione o DBCC SHRINK a un'operazione di file, si verifica un conflitto. Indipendentemente dall'operazione iniziata per prima tra quelle in conflitto, la seconda operazione attende il timeout del blocco impostato dalla prima operazione. Il periodo di timeout dipende da un'impostazione di timeout di sessione. Se il blocco viene rilasciato entro il periodo di timeout, la seconda operazione continua. Se il periodo di timeout scade, la seconda operazione non viene eseguita.

Metadati UFX

In SQL Server sono incluse le tabelle di cronologia dei backup seguenti, usate per tenere traccia delle attività di backup:

Quando viene eseguito un ripristino, se il set di backup non è già stato registrato nel msdb database, è possibile modificare le tabelle della cronologia di backup.

Sicurezza

A partire da SQL Server 2012 (11.x), le opzioni PASSWORD e MEDIAPASSWORD vengono sospese per la creazione di backup. È comunque possibile ripristinare backup creati con password.

Autorizzazioni

Le autorizzazioni BACKUP DATABASE e BACKUP LOG vengono assegnate per impostazione predefinita ai membri del ruolo predefinito del server sysadmin e dei ruoli predefiniti del database db_owner e db_backupoperator.

Eventuali problemi correlati alla proprietà e alle autorizzazioni sul file fisico del dispositivo di backup possono interferire con l'operazione di backup. Assicurarsi che l'account di avvio di SQL Server debba disporre delle autorizzazioni di lettura e scrittura per il dispositivo di backup e la cartella in cui vengono scritti i file di backup. Le autorizzazioni di accesso ai file, tuttavia, non vengono controllate dalla stored procedure sp_addumpdeviceche aggiunge una voce per un dispositivo di backup nelle tabelle di sistema. Tali problemi nel file fisico del dispositivo di backup potrebbero non essere visualizzati fino a quando non viene eseguito l'accesso alla risorsa fisica quando si tenta di eseguire il backup o il ripristino.

Esempi

Questa sezione contiene gli esempi seguenti:

R. Eseguire il backup di un database completo
B. Eseguire il backup del database e del log
C. Creare un backup completo dei filegroup secondari
D. Creare un backup differenziale dei filegroup secondari
E. Creare e eseguire il backup in un set di supporti con mirroring a famiglia singola
F. Creare e eseguire il backup in un set di supporti con mirroring multifamily
G. Eseguire il backup in un set di supporti con mirroring esistente
H. Creare un backup compresso in un nuovo set di supporti
I. Eseguire il backup in Archiviazione BLOB di Azure
J. [Eseguire il backup nell'archivio oggetti compatibile con S3] ((#j-backup-to-s3-compatible-object-storage)
K. Monitorare lo stato dell'istruzione di backup

Nota

Ulteriori esempi sono inclusi negli argomenti relativi alle procedure di backup. Per altre informazioni, vedere Panoramica del backup.

R. Eseguire il backup di un database completo

L'esempio seguente esegue il backup del database AdventureWorks2022 in un file su disco.

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

B. Eseguire il backup del database e del log

Nell'esempio seguente viene eseguito il backup del database di esempio AdventureWorks2022, per il quale viene utilizzato per impostazione predefinita il modello di recupero con registrazione minima. Per consentire il backup del log, il database AdventureWorks2022 viene modificato per l'utilizzo del modello di recupero con registrazione completa.

Nell'esempio viene quindi usata la stored procedure sp_addumpdevice per creare un dispositivo di backup logico per il backup dei dati, AdvWorksData, e un altro dispositivo di backup logico per il backup del log, AdvWorksLog.

Nell'esempio viene infine creato un backup completo del database in AdvWorksData e, dopo un periodo dedicato alle attività di aggiornamento, viene eseguito il backup del log in 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

Nota

Per i database di produzione, eseguire il backup del log regolarmente. La frequenza dei backup del log dovrà essere tale da consentire una protezione sufficiente per evitare perdite di dati.

C. Creare un backup completo dei filegroup secondari

Nell'esempio seguente viene creato un backup completo di ogni file presente in entrambi i filegroup secondari.

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

D. Creare un backup differenziale dei filegroup secondari

Nell'esempio seguente viene creato un backup differenziale di ogni file presente in entrambi i filegroup secondari.

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

E. Creare e eseguire il backup in un set di supporti con mirroring a famiglia singola

Nell'esempio seguente viene creato un set di supporti con mirroring contenente un singolo gruppo di supporti e quattro mirror, quindi viene eseguito il backup del database AdventureWorks2022 in tali supporti.

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

F. Creare e eseguire il backup in un set di supporti con mirroring multifamily

Nell'esempio seguente viene creato un set di supporti con mirroring in cui ogni mirror è composto da due gruppi di supporti. Viene quindi eseguito il backup del database AdventureWorks2022 in entrambi i mirror.

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

G. Eseguire il backup in un set di supporti con mirroring esistente

Nell'esempio seguente un set di backup viene accodato al set di supporti creato nell'esempio precedente.

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

Nota

L'opzione predefinita NOINIT viene specificata in modo esplicito nell'istruzione per maggiore chiarezza.

H. Creare un backup compresso in un nuovo set di supporti

L'esempio seguente formatta il supporto, crea un nuovo set di supporti ed esegue un backup completo compresso del AdventureWorks2022 database.

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

I. Eseguire il backup in Microsoft Archiviazione BLOB di Azure

In questo esempio viene eseguito un backup completo del database di Sales in Archiviazione BLOB di Azure. Il nome dell'account di archiviazione è mystorageaccount, mentre il nome del contenitore è myfirstcontainer. I criteri di accesso archiviati sono già stati creati con diritti di lettura, scrittura, eliminazione ed elenco. Le credenziali di SQL Server, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, sono stati creati usando una firma di accesso condiviso associata a criteri di accesso archiviati. Per informazioni sul backup di SQL Server in Archiviazione BLOB di Azure, vedere Backup e ripristino di SQL Server con Archiviazione BLOB di Azure e backup di SQL Server nell'URL.

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

È anche possibile eseguire il backup del database in più striping e sarà simile al seguente:

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. Eseguire il backup nell'archiviazione di oggetti compatibile con S3

Si applica a: SQL Server 2022 (16.x)

In questo esempio viene eseguito un database di backup completo del Sales database nella piattaforma di archiviazione oggetti compatibile con S3. Il nome delle credenziali non è obbligatorio nell'istruzione né deve corrispondere al percorso esatto dell'URL, ma consentirà di eseguire una ricerca delle credenziali appropriate nell'URL specificato. Per altre informazioni, vedere Backup e ripristino di SQL Server con l'archiviazione di oggetti compatibile con S3.

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. Monitorare lo stato dell'istruzione di backup

La query seguente restituisce informazioni sulle istruzioni di backup attualmente in esecuzione:

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

SQL Server

* Istanza gestita di SQL *

Piattaforma di strumenti
(PDW)

Istanza gestita di SQL di Azure

Esegue il backup di un database SQL in Istanza gestita di SQL di Azure. Istanza gestita di SQL di Azure dispone di backup automatici. È possibile creare backup COPY_ONLY del database completi. I backup differenziali, del log e di snapshot di file non sono supportati.

Si applica anche alle Istanza gestita di SQL abilitate da Azure Arc.

Sintassi

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

Argomenti

DATABASE

Specifica un backup completo del database. Durante un backup del database, Istanza gestita di SQL di Azure esegue il backup di una parte del log delle transazioni sufficiente per generare un database consistente quando viene ripristinato il backup.

Importante

Un backup del database creato in un'istanza gestita può essere ripristinato solo in un altro Istanza gestita di SQL di Azure o in un'istanza di SQL Server 2022. Ciò è dovuto al fatto che Istanza gestita di SQL ha una versione del database interna superiore rispetto ad altre versioni di SQL Server. Per altre informazioni, vedere Ripristinare un backup del database Istanza gestita di SQL in SQL Server 2022.

Quando si ripristina un backup creato da BACKUP DATABASE (backup dei dati), viene ripristinato l'intero backup. Per eseguire il ripristino dai backup automatici di Istanza gestita di SQL, vedere Ripristinare un database in Istanza gestita di SQL di Azure.

{ database_name | @database_name_var }

Nome del database da cui viene eseguito il backup completo del database. Se indicato in forma di variabile (@database_name_var), questo nome può essere specificato come costante di stringa (@database_name_var=database name) oppure come variabile di tipo di dati stringa di caratteri, ad eccezione del tipo di dati ntext o text.

Per altre informazioni, vedere Backup completi del file e Backup di file e filegroup.

TO URL

Specifica l'URL da usare per l'operazione di backup. Il formato URL viene usato per la creazione di backup nel servizio di archiviazione di Microsoft Azure.

Importante

Per eseguire il backup in più dispositivi durante il backup nell'URL, è necessario usare i token di firma di accesso condiviso (SAS). Per esempi di creazione di una firma di accesso condiviso, vedere Backup di SQL Server nell'URL e Simplifying creation of SQL Credentials with Shared Access Signature (SAS) tokens on Azure Storage with Powershell (Semplificazione della creazione di credenziali SQL con token di firma di accesso condiviso (SAS) in Archiviazione di Azure con Powershell).

n
Segnaposto che indica che è possibile specificare fino a 64 dispositivi di backup in un elenco delimitato da virgole.

Opzioni WITH

Opzioni da utilizzare con un'operazione di backup.

ENCRYPTION

AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION

Se si sceglie di crittografare è necessario specificare il componente di crittografia utilizzando le relative opzioni:

SERVER CERTIFICATE = <Encryptor_Name>
SERVER ASYMMETRIC KEY = <Encryptor_Name>

Opzioni relative al set di backup

COPY_ONLY

Specifica che il backup è un backup di sola copia che non influisce sulla normale sequenza di backup. Un backup di sola copia viene creato indipendentemente dai backup automatici del database SQL di Azure. Per altre informazioni, vedere Backup di sola copia.

{ COMPRESSION | NO_COMPRESSION }

Specifica se la compressione dei backup viene eseguita su questo backup, ignorando l'impostazione predefinita a livello di server.

Il comportamento predefinito prevede che la compressione dei backup non venga applicata. Questa impostazione predefinita può essere modificata impostando l'opzione di configurazione del server backup compression default. Per informazioni sulla visualizzazione del valore corrente di questa opzione, vedere Visualizzare o modificare le proprietà del server.

COMPRESSION
Abilita in modo esplicito la compressione dei backup.

NO_COMPRESSION
Disabilita in modo esplicito la compressione dei backup.

DESCRIPTION = { 'text' | @text_variable }

Specifica il testo in formato libero che descrive il set di backup. La stringa può essere composta da un massimo di 255 caratteri.

NAME = { backup_set_name | @_backup| set_var }

Specifica il nome del set di backup. I nomi possono essere composti da un massimo di 128 caratteri. Se si omette NAME, al set di backup non viene assegnato alcun nome specifico.

MEDIADESCRIPTION = { text | @text_variable }

Specifica la descrizione di testo in formato libero, massimo 255 caratteri, del set di supporti.

MEDIANAME = { media_name | @media_name_variable }

Specifica il nome del supporto per l'intero set di supporti di backup. Il nome dei supporti deve essere composto da un massimo di 128 caratteri. Se si specifica MEDIANAME, il nome deve corrispondere al nome dei supporti precedentemente specificato già esistente nei volumi di backup. Se si omette MEDIANAME oppure si specifica l'opzione SKIP, non viene eseguita alcuna verifica del nome dei supporti.

BLOCKSIZE = { blocksize | @blocksize_variable }

Opzioni di trasferimento dei dati

BUFFERCOUNT = { buffercount | @buffercount_variable }

Lo spazio totale usato dai buffer viene determinato da BUFFERCOUNT * MAXTRANSFERSIZE.

Nota

Per informazioni importanti sull'uso dell'opzione BUFFERCOUNT , vedere il post di blog L'opzione di trasferimento dei dati BufferCount non corretto può causare la condizione OOM.

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Specifica le dimensioni massime, in byte, per il trasferimento tra SQL Server e i supporti di backup. I valori possibili sono i multipli di 65536 byte (64 KB) fino a 4194304 byte (4 MB).

Per i database con Transparent Data Encryption (TDE) con un singolo file di dati, MAXTRANSFERSIZE predefinito è 65536 (64 KB). Per i database senza crittografia TDE, MAXTRANSFERSIZE predefinito è 1048576 (1 MB) quando viene usato il backup su disco e 65536 (64 KB) quando viene usata una VDI o un nastro.

Nota

MAXTRANSFERSIZE specifica l'unità di trasferimento più grande e non garantisce che ogni operazione di scrittura trasferisca le dimensioni massime specificate. MAXTRANSFERSIZE per le operazioni di scrittura dei backup del log delle transazioni con striping è impostato su 64 KB.

Opzioni relative alla gestione degli errori

Queste opzioni consentono di specificare se i checksum del backup sono abilitati per l'operazione di backup e se l'operazione deve essere arrestata in caso di errore.

{ NO_CHECKSUM | CHECKSUM }

Controlla se i checksum di backup sono abilitati.

NO_CHECKSUM
Disabilita in modo esplicito la generazione di checksum di backup (e la convalida dei checksum di pagina). Si tratta del comportamento predefinito.

CHECKSUM
Specifica che l'operazione di backup verifica in ogni pagina la presenza di checksum e pagine incomplete, se abilitati e disponibili, e genera un checksum per l'intero backup.

L'uso dei checksum di backup può influire sulla velocità effettiva del carico di lavoro e del backup.

Per altre informazioni, vedere Possibili errori relativi ai supporti durante il backup e il ripristino.

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Controlla se un'operazione di backup si arresta o continua dopo aver rilevato un errore di checksum della pagina.

STOP_ON_ERROR
Indica a BACKUP di non riuscire se non viene verificato un checksum di pagina. Si tratta del comportamento predefinito.

CONTINUE_AFTER_ERROR
Imposta il proseguimento dell'istruzione BACKUP anche in caso di errori, ad esempio checksum non validi o pagine incomplete.

Per altre informazioni, vedere Possibili errori relativi ai supporti durante il backup e il ripristino.

Opzioni di compatibilità

RESTART

Non ha alcun effetto. L'opzione è accettata in questa versione per compatibilità con le versioni precedenti di SQL Server.

Opzioni di monitoraggio

STATS [ = percentage ]

Limitazioni per Istanza gestita di SQL

La dimensione massima della striscia di backup corrisponde a 195 GB (dimensione massima di un oggetto BLOB). Aumentare il numero di strisce nel comando di backup per ridurre la dimensione delle singole strisce e rimanere entro questo limite.

Sicurezza

Autorizzazioni

Le autorizzazioni BACKUP DATABASE vengono assegnate per impostazione predefinita ai membri del ruolo predefinito del server sysadmin e dei ruoli predefiniti del database db_owner e db_backupoperator.

Eventuali problemi correlati alla proprietà e alle autorizzazioni per l'URL possono interferire con l'operazione di backup. SQL Server deve essere in grado di leggere e scrivere nel dispositivo; l'account con il quale viene eseguito il servizio SQL Server deve avere autorizzazioni di scrittura.

Esempi

Nell'esempio viene eseguito un backup COPY_ONLY di in Sales Microsoft Archiviazione BLOB di Azure. Il nome dell'account di archiviazione è mystorageaccount, mentre il nome del contenitore è myfirstcontainer. Sono stati creati criteri di accesso archiviati con diritti di lettura, scrittura ed elenco. Le credenziali di SQL Server, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, sono stati creati usando una firma di accesso condiviso associata a criteri di accesso archiviati. Per informazioni sul backup di SQL Server in Archiviazione BLOB di Azure, vedere Backup e ripristino di SQL Server con Microsoft Archiviazione BLOB di Azure e backup di SQL Server nell'URL.

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

È anche possibile eseguire il backup del database in più striping e sarà simile al seguente:

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;

RESTORE DATABASE

SQL Server

Istanza gestita di SQL

* Piattaforma di strumenti
analitici (PDW) *

Sistema della piattaforma di analisi

Crea un backup di un database di piattaforma di strumenti analitici (PDW) e archivia il backup all'esterno dell'appliance in un percorso di rete specificato dall'utente. Usare questa istruzione con RESTORE DATABASE - Piattaforma di strumenti analitici per il ripristino di emergenza o per copiare un database da un'appliance all'altra.

Prima di iniziare, vedere "Acquisire e configurare un server di backup" nella documentazione del prodotto piattaforma di strumenti analitici (PDW).

Esistono due tipi di backup nella piattaforma di strumenti analitici (PDW). Un backup completo del database è un backup di un intero database della piattaforma di strumenti analitici (PDW). Un backup di database differenziale include solo le modifiche apportate dall'ultimo backup completo. Il backup di un database utente include gli utenti del database e i ruoli del database. Il backup del database master include gli account di accesso.

Per altre informazioni sui backup del database della piattaforma di strumenti analitici (PDW), vedere "Backup and ripristino" nella documentazione del prodotto piattaforma di strumenti analitici (PDW).

Sintassi

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

Argomenti

database_name

Nome del database in cui creare un backup. Il database può essere il database master o un database utente.

TO DISK = '\\UNC_path\backup_directory'

Il percorso di rete e la directory in cui la piattaforma di strumenti analitici (PWD) scrive i file di backup. Ad esempio: \\\xxx.xxx.xxx.xxx\backups\2012\Monthly\08.2012.Mybackup.

Il percorso del nome della directory di backup deve esistere già e deve essere specificato come percorso UNC completo.
La directory di backup, backup_directory, non deve essere presente prima di eseguire il comando di backup. La piattaforma di strumenti analitici (PDW) creerà la directory di backup.
Il percorso della directory di backup non può essere un percorso locale e non può essere il percorso di uno dei nodi dell'appliance della piattaforma di strumenti analitici (PDW).
La lunghezza massima del percorso UNC e del nome della directory di backup è di 200 caratteri.
Il server o l'host deve essere specificato come indirizzo IP. Non è possibile specificarlo come nome host o nome server.

DESCRIPTION = 'text'

Specifica una descrizione testuale del backup. La lunghezza massima del testo è di 255 caratteri.

La descrizione viene archiviata nei metadati e verrà visualizzata quando l'intestazione del backup viene ripristinata con RESTORE HEADERONLY.

NAME = 'backup _name'

Specifica il nome del backup. Il nome del backup può essere diverso dal nome del database.

I nomi possono essere composti da un massimo di 128 caratteri.
Non è possibile includere un percorso.
Deve iniziare con una lettera o un numero oppure con un carattere di sottolineatura (_). I caratteri speciali consentiti sono il carattere di sottolineatura (_), il trattino (-) o lo spazio ( ). I nomi di backup non possono terminare con uno spazio.
L'istruzione avrà esito negativo se backup_name esiste già nel percorso specificato.

Questo nome viene archiviato nei metadati e verrà visualizzato quando l'intestazione del backup viene ripristinata con RESTORE HEADERONLY.

DIFFERENTIAL

Specifica di eseguire un backup differenziale di un database utente. Se omesso, il valore predefinito è un backup completo del database. Il nome del backup differenziale non deve necessariamente corrispondere al nome del backup completo. Per tenere traccia del backup differenziale e del backup completo corrispondente, può essere utile usare lo stesso nome con l'aggiunta di 'compl' o 'diff'.

Ad esempio:

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

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

Autorizzazioni

Richiede l'autorizzazione o l'appartenenza BACKUP DATABASE al ruolo predefinito del database db_backupoperator . Il backup del database master può essere eseguito solo da un utente standard aggiunto al ruolo predefinito del database db_backupoperator. Il backup del database master può essere eseguito solo da sa, l'amministratore dell'infrastruttura, o dai membri del ruolo predefinito del server sysadmin.

Richiede un account di Windows con l'autorizzazione per accedere, creare e scrivere nella directory di backup. È anche necessario archiviare il nome e la password dell'account di Windows nella piattaforma di strumenti analitici (PWD). Per aggiungere queste credenziali di rete alla piattaforma di strumenti analitici (PDW), usare la stored procedure sp_pdw_add_network_credentials - Azure Synapse Analytics.

Per altre informazioni sulla gestione delle credenziali nella piattaforma di strumenti analitici (PDW), vedere la sezione Sicurezza.

Gestione errori

Gli errori di BACKUP DATABASE si verificano nelle condizioni seguenti:

Le autorizzazioni utente non sono sufficienti per eseguire un backup.
La piattaforma di strumenti analitici (PDW) non ha le autorizzazioni corrette per il percorso di rete in cui verrà archiviato il backup.
Il database non esiste.
La directory di destinazione esiste già nella condivisione di rete.
La condivisione di rete di destinazione non è disponibile.
La condivisione di rete di destinazione non ha spazio sufficiente per il backup. Il comando BACKUP DATABASE non conferma l'esistenza di spazio su disco sufficiente prima di avviare il backup e rende possibile la generazione di un errore di spazio su disco insufficiente durante l'esecuzione di BACKUP DATABASE. Quando lo spazio su disco è insufficiente, la piattaforma di strumenti analitici (PDW) esegue il rollback del comando BACKUP DATABASE. Per ridurre le dimensioni del database, eseguire DBCC SHRINKLOG (Analytics Platform System (PDW))
Tentativo di avviare un backup in una transazione.

Osservazioni:

Prima di eseguire un backup del database, usare DBCC SHRINKLOG (Analytics Platform System (PDW) per ridurre le dimensioni del database.

Il backup della piattaforma di strumenti analitici (PDW) viene archiviato come set di file multipli all'interno della stessa directory.

Un backup differenziale richiede in genere meno tempo rispetto a un backup completo e può essere eseguito più di frequente. Quando più copie di backup differenziale si basano sullo stesso backup completo, ogni backup differenziale include tutte le modifiche del backup differenziale precedente.

Se si annulla un comando BACKUP, la piattaforma di strumenti analitici (PDW) rimuoverà la directory di destinazione e i file creati per il backup. Se la piattaforma di strumenti analitici (PDW) perde la connettività di rete alla condivisione, non è possibile completare il rollback.

I backup completi e differenziali vengono archiviati in directory distinte. Le convenzioni di denominazione non vengono applicate per specificare che un backup completo e un backup differenziale sono collegati. È possibile tenerne traccia attraverso le proprie convenzioni di denominazione. In alternativa, è possibile tenerne traccia usando l'opzione WITH DESCRIPTION per aggiungere una descrizione e quindi usando l'istruzione RESTORE HEADERONLY per recuperare la descrizione.

Limiti

Non è possibile eseguire un backup differenziale del database master. Sono supportati solo i backup completi del database master.

I backup del log delle transazioni del master database di sistema non sono supportati.

I file di backup vengono archiviati in un formato adatto esclusivamente per il ripristino del backup in un'appliance della piattaforma di strumenti analitici (PDW) tramite l'istruzione RESTORE DATABASE - Analytics Platform System.

Il backup con l'istruzione BACKUP DATABASE non può essere usato per trasferire i dati o le informazioni dell'utente nei database SMP SQL Server. Per questa funzionalità, è possibile usare la funzione di copia della tabella remota. Per altre informazioni, vedere "Copia della tabella remota" nella documentazione del prodotto piattaforma di strumenti analitici (PDW).

Analytics Platform System (PDW) usa la tecnologia di backup di SQL Server per eseguire il backup e il ripristino dei database. Le opzioni di backup di SQL Server sono preconfigurate per l'utilizzo della compressione dei backup. Non è possibile impostare opzioni di backup come la compressione, il checksum, la dimensione blocco e il conteggio buffer.

È possibile eseguire nell'appliance un solo backup o ripristino di database in qualsiasi momento. La piattaforma di strumenti analitici (PDW) metterà in coda i comandi di backup o ripristino fino a quando non viene completato il comando di backup o ripristino corrente.

L'appliance di destinazione per il ripristino del backup deve avere almeno un numero di nodi di calcolo equivalente a quello dell'appliance di origine. La destinazione può avere un numero di nodi di calcolo maggiore dell'appliance di origine, ma non può avere un numero di nodi di calcolo minore.

La piattaforma di strumenti analitici (PDW) non tiene traccia del percorso e dei nomi di backup poiché i backup sono archiviati all'esterno dell'appliance.

La piattaforma di strumenti analitici (PDW) tiene traccia dell'esito positivo o negativo dei backup del database.

È possibile eseguire un backup differenziale solo se l'ultimo backup completo è stato eseguito correttamente. Si supponga, ad esempio, che il lunedì si crei un backup completo del Sales database e che il backup venga completato correttamente. Il martedì si crea quindi un backup completo del database e l'operazione Sales ha esito negativo. Dopo questo errore, non sarà possibile creare un backup differenziale basato sul backup completo di lunedì. Prima di creare un backup differenziale è necessario aver già creato un backup completo.

Metadati UFX

Queste DMV contengono informazioni su tutte le operazioni di backup, ripristino e caricamento. Le informazioni vengono mantenute tra un riavvio di sistema e l'altro.

Prestazioni

Per eseguire un backup, la piattaforma di strumenti analitici (PDW) esegue prima il backup dei metadati e poi un backup parallelo dei dati del database archiviati nei nodi di calcolo. I dati vengono copiati direttamente da ogni nodo di calcolo nella directory di backup. Per ottenere le migliori prestazioni per lo spostamento dei dati dai nodi di calcolo alla directory di backup, la piattaforma di strumenti analitici (PDW) controlla il numero di nodi di calcolo che copiano i dati contemporaneamente.

Blocco

Acquisisce un blocco ExclusiveUpdate nell'oggetto DATABASE.

Sicurezza

I backup della piattaforma di strumenti analitici (PDW) non vengono archiviati nell'appliance. Pertanto, il team IT è responsabile della gestione di tutti gli aspetti della sicurezza dei backup. Questi aspetti includono ad esempio la gestione della sicurezza dei dati di backup, del server usato per l'archiviazione dei backup e dell'infrastruttura di rete che connette il server di backup all'appliance della piattaforma di strumenti analitici (PDW).

Gestire le credenziali di rete

L'accesso di rete alla directory di backup è basato sulla sicurezza di condivisione dei file del sistema operativo standard. Prima di eseguire un backup, è necessario creare o impostare un account di Windows che verrà usato per l'autenticazione della piattaforma di strumenti analitici (PDW) nella directory di backup. L'account di Windows deve avere le autorizzazioni per accedere, creare e scrivere nella directory di backup.

Importante

Per ridurre i rischi di sicurezza dei dati, è consigliabile impostare un account di Windows dedicato esclusivamente all'esecuzione delle operazioni di backup e ripristino. Concedere all'account le autorizzazioni solo per il percorso di backup.

È necessario archiviare nome utente e password nella piattaforma di strumenti analitici (PDW) eseguendo la stored procedure sp_pdw_add_network_credentials - Azure Synapse Analytics. La piattaforma di strumenti analitici (PDW) usa Gestione credenziali di Windows per archiviare e crittografare i nomi utente e le password nel nodo di controllo e nei nodi di calcolo. Con il comando BACKUP DATABASE non viene eseguito il backup delle credenziali.

Per rimuovere le credenziali di rete dalla piattaforma di strumenti analitici (PDW), vedere sp_pdw_remove_network_credentials - Azure Synapse Analytics.

Per visualizzare un elenco di tutte le credenziali di rete archiviate nella piattaforma di strumenti analitici (PDW), usare la vista DMV sys.dm_pdw_network_credentials.

Esempi

R. Aggiungere le credenziali di rete per il percorso di backup

Per creare un backup, la piattaforma di strumenti analitici (PDW) deve avere l'autorizzazione di lettura/scrittura per la directory di backup. L'esempio seguente illustra come aggiungere le credenziali per un utente. La piattaforma di strumenti analitici (PDW) memorizzerà queste credenziali che verranno usate per le operazioni di backup e ripristino.

Importante

Per motivi di sicurezza, è consigliabile creare un account di dominio dedicato esclusivamente all'esecuzione dei backup.

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

B. Rimuovere le credenziali di rete per il percorso di backup

L'esempio seguente illustra come rimuovere le credenziali per un utente di dominio dalla piattaforma di strumenti analitici (PDW).

EXEC sp_pdw_remove_network_credentials 'xxx.xxx.xxx.xxx';

C. Creare un backup completo di un database utente

L'esempio seguente crea un backup completo del database utente Invoices. La piattaforma di strumenti analitici (PDW) crea la directory Invoices2013 e salva i file di backup nella directory \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full.

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

D. Creare un backup differenziale di un database utente

L'esempio seguente crea un backup differenziale che include tutte le modifiche apportate dopo l'ultimo backup completo del database Invoices. Analytics Platform System (PDW) creerà la \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff directory per archiviare i file. La descrizione 'Invoices 2013 differential backup' viene memorizzata con la descrizione dell'intestazione del backup.

Il backup differenziale viene eseguito correttamente solo se l'ultimo backup completo di Invoices è stato completato correttamente.

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

E. Creare un backup completo di un database master

L'esempio seguente crea un backup completo del database master e lo archivia nella directory \\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master, dove IP è un indirizzo IP di rete.

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

Il database master archivia le informazioni di accesso dell'appliance. Per eseguire il backup delle informazioni di accesso dell'appliance, è necessario eseguire il backup del master database.

L'esempio seguente crea un backup completo del database master.

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

RESTORE DATABASE - Parallel Data Warehouse