Condividi tramite

BACKUP (Transact-SQL)

  • Articolo

Data aggiornamento: 12 dicembre 2006

Esegue il backup di un database completo oppure di uno o più file o filegroup (BACKUP DATABASE). Se, inoltre, si utilizza il modello di recupero con registrazione completa o il modello di recupero con registrazione minima delle transazioni di massa, esegue il backup del log delle transazioni (BACKUP LOG).

Icona di collegamento a un argomentoConvenzioni della sintassi Transact-SQL

Sintassi

Backing 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 ] } ]
[;]

Backing 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 ] } ]
[;]

Creating 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 ] } ]
[;]

Backing 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_optionspec> } [ ,...n ] ]
[;]

Truncating the Transaction Log (breaks the log chain) 
BACKUP LOG { database_name | @database_name_var } 
  WITH { NO_LOG | TRUNCATE_ONLY } 
[;]

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

<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 
  | DESCRIPTION = { 'text' | @text_variable } 
 | NAME = { backup_set_name | @backup_set_name_var } 
 | PASSWORD = { password | @password_variable } 
 | [ EXPIREDATE = { date | @date_var } 
        | RETAINDAYS = { days | @days_var } ] 
 | NO_LOG 

--Media Set Options
   { NOINIT | INIT } 
 | { NOSKIP | SKIP } 
 | { NOFORMAT | FORMAT } 
 | MEDIADESCRIPTION = { 'text' | @text_variable } 
 | MEDIANAME = { media_name | @media_name_variable } 
 | MEDIAPASSWORD = { mediapassword | @mediapassword_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 } 

--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, in SQL Server viene eseguito il backup di una parte del log delle transazioni sufficiente per generare un database consistente quando viene ripristinato il backup.

    [!NOTA] Per il database master è possibile eseguire solo un backup completo.

  • LOG
    Specifica solo il backup 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.

    [!NOTA] Dopo un tipico backup del log, alcuni record del log delle transazioni diventano inattivi se non si specifica 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 ulteriori informazioni, vedere Gestione del log delle transazioni.

  • { database_name| @database_name_var }
    Nome del database di cui viene eseguito il backup del log delle transazioni, il backup parziale o il backup completo. Se indicato in forma di variabile (@database_name_var), questo nome può essere specificato come costante stringa (@database_name_var    =     nome database) oppure come variabile di tipo 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 DATABASE, specifica un file o filegroup di database da includere in un backup del file oppure un file o 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 da includere 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 a dimensioni e prestazioni del database rendono poco conveniente il backup del database.

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

    Per ulteriori informazioni, vedere Backup completi di file e Procedura: Backup di file e filegroup (Transact-SQL).

  • 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 il backup di tutti i filegroup di lettura/scrittura deve essere incluso nel backup parziale. Se il database è di sola lettura, READ_WRITE_FILEGROUPS include solo il filegroup primario.

      ms186865.note(it-it,SQL.90).gifImportante:
      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 da includere nel backup parziale. Per ulteriori informazioni, vedere "<file_or_filegroup>" più indietro in questo argomento.
    • n
      Segnaposto che indica la possibilità di specificare più filegroup di sola lettura in un elenco delimitato da virgole.

    Per ulteriori informazioni sui backup parziali, vedere Backup parziali.

  • TO <backup_device> [ ,...n ]
    Indica che il set di periferiche 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 la periferica di backup logica o fisica da utilizzare per l'operazione di backup.

      • { logical_device_name | @logical_device_name_var }
        Nome logico della periferica di backup (creata tramite sp_addumpdevice) 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 della periferica di backup può essere specificato come costante stringa (@logical_device_name_var        =         nome logico periferica di backup) oppure come variabile di tipo stringa di caratteri, ad eccezione del tipo di dati ntext o text.

      • { DISK | TAPE } = { 'physical_device_name' | **@**physical_device_name_var }
        Specifica un file su disco o una periferica nastro. Non è necessario che la periferica specificata sia presente prima dell'esecuzione dell'istruzione BACKUP. Se la periferica fisica esiste e si omette l'opzione INIT nell'istruzione BACKUP, il backup viene accodato alla periferica.

        Per ulteriori informazioni, vedere Periferiche di backup.

    • n
      Segnaposto che indica la possibilità di specificare fino a 64 periferiche di backup in un elenco delimitato da virgole.

  • MIRROR TO <backup_device> [ ,...n ]
    Indica un set di una o più periferiche di backup che eseguirà il mirroring delle periferiche di backup specificate nella clausola TO. Nella clausola MIRROR TO è necessario specificare lo stesso tipo e numero di periferiche di backup indicati nella clausola TO. Il numero massimo di clausole MIRROR TO è tre.

    Questa opzione è disponibile in SQL Server 2005 Enterprise Edition e versioni successive.

    [!NOTA] Con la clausola MIRROR TO = DISK, l'istruzione BACKUP determina automaticamente le dimensioni del blocco appropriate per le periferiche disco. Per ulteriori informazioni sulle dimensioni del blocco, vedere "BLOCKSIZE" di seguito in questo argomento.

    • <backup_device>
      Vedere "<backup_device>" più indietro in questa sezione.
    • n
      Segnaposto che indica la possibilità di specificare fino a 64 periferiche di backup in un elenco delimitato da virgole. Il numero di periferiche specificato nella clausola MIRROR TO deve essere uguale al numero di periferiche indicato nella clausola TO.
  • [ 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.

  • DIFFERENTIAL
    Utilizzata solo con BACKUP DATABASE, 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 ulteriori informazioni, vedere Utilizzo dei backup differenziali.

Opzioni relative al set di backup

Queste opzioni sono attive nel set di backup creato dall'operazione di backup.

[!NOTA] Per specificare un set di backup per un'operazione di ripristino, utilizzare l'opzione FILE =<backup_set_file_number>. Per ulteriori informazioni su come specificare un set di backup, vedere Argomenti dell'istruzione RESTORE (Transact-SQL).

  • 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 sono stati introdotti in SQL Server 2005 per i casi in cui è necessario eseguire un backup per uno scopo speciale, ad esempio un backup del log prima di un ripristino di file in linea. In genere, un backup di sola copia viene utilizzato una sola volta e quindi eliminato.

    • Se utilizzata con BACKUP DATABASE, l'opzione COPY_ONLY crea un backup completo che non può essere utilizzato 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.
      ms186865.note(it-it,SQL.90).gifImportante:
      Se le opzioni DIFFERENTIAL e COPY_ONLY vengono utilizzate insieme, COPY_ONLY viene ignorata e viene creato un backup differenziale.
    • Se utilizzata con BACKUP LOG, l'opzione COPY_ONLY crea un backup del log di sola copia, che non comporta 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 ulteriori informazioni, vedere Backup di sola copia.

  • DESCRIPTION = { 'text' | **@**text_variable }
    Specifica il testo in formato libero che descrive il set di backup. La stringa può essere composta al massimo da 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.

  • PASSWORD = { password | **@**password_variable }
    Imposta la password per il set di backup. PASSWORD è una stringa di caratteri. Se per il set di backup viene definita una password, tale password deve essere specificata per l'esecuzione di qualsiasi operazione di ripristino di SQL Server dal set di backup. L'impostazione di una password per il set di backup, tuttavia, non consente di proteggere i file di backup dalla sovrascrittura. Per impedire la sovrascrittura di un file di backup, utilizzare invece una password per il set di supporti (vedere la descrizione dell'opzione MEDIAPASSWORD di seguito in questo argomento). Per ulteriori informazioni sull'utilizzo delle password, vedere la sezione "Autorizzazioni" di seguito in questo argomento.

    ms186865.security(it-it,SQL.90).gifNota sulla protezione:
    Il livello di protezione garantito da questa password è ridotto. Lo scopo consiste nell'impedire un ripristino non corretto da parte di utenti autorizzati o non autorizzati mediante gli strumenti di SQL Server 2005. Non viene impedita la lettura dei dati di backup eseguita con altri mezzi, né la sostituzione della password. Per ottenere un livello di protezione adeguato per i backup, è consigliabile archiviare i nastri di backup in un luogo protetto oppure eseguire il backup su file su disco protetti da elenchi di controllo di accesso appropriati. Gli elenchi di controllo di accesso devono essere impostati a livello della directory principale in cui vengono creati i backup.

    [!NOTA] L'opzione PASSWORD verrà rimossa in una versione futura di SQL Server.

  • [ EXPIREDATE = date | RETAINDAYS = date ]
    Indica la data in cui è possibile sovrascrivere il set di backup per il backup specifico. Se si utilizzano entrambe le opzioni, RETAINDAYS ha la precedenza rispetto a EXPIREDATE.

    Se nessuna delle due opzioni viene specificata, la data di scadenza è determinata dall'impostazione di configurazione mediaretention. Per ulteriori informazioni, vedere Impostazione delle opzioni di configurazione del server.

    ms186865.note(it-it,SQL.90).gifImportante:
    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 la data di scadenza del set di backup, data in cui può essere sovrascritto. Se specificata in forma di variabile (@date_var), la data deve essere indicata nel formato datetime di sistema configurato e specificata in uno dei modi seguenti:

      • Come costante stringa (@date_var = data)
      • Come variabile di tipo stringa di caratteri, con l'eccezione dei tipi 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 i valori di datetime, vedere Formato di data alfabetico e Formato di data numerico.

      [!NOTA] Per ignorare la data di scadenza, utilizzare 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 tale numero viene indicato in forma di variabile (      @**days_var), è necessario specificarlo come valore integer.

  • NO_LOG
    Nel contesto di un'istruzione BACKUP DATABASE, specifica che un backup non conterrà alcun log. Questo comportamento equivale ai metodi di creazione dei backup disponibili nelle versioni precedenti rispetto a SQL Server 2005. Un backup del database creato con l'opzione NO_LOG equivale a un set completo di backup di file che non contiene alcun record di log.

    Quando si utilizza il modello di recupero con registrazione completa, l'opzione NO_LOG è utile se è necessario eseguire rapidamente un backup dei dati e si dispone di una sequenza completa di backup del log di tali dati.

Opzioni relative ai set di supporti

Queste opzioni vengono applicate all'intero set di supporti.

  • { NOINIT | INIT }
    Determina se l'operazione di backup accoda o sovrascrive i set di backup esistenti nei supporti di backup. L'impostazione predefinita consiste nell'accodare i set 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" di seguito in questo argomento.

    • NOINIT
      Indica che il set di backup viene accodato nel 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 ulteriori informazioni, vedere Accodamento a set di backup esistenti.

    • INIT
      Specifica che tutti i set di backup devono essere sovrascritti, mantenendo però l'intestazione dei supporti. Se si specifica INIT, vengono sovrascritti tutti i set di backup presenti nella periferica, se le condizioni lo consentono. Per impostazione predefinita, l'istruzione BACKUP verifica se esistono le condizioni seguenti e non sovrascrive i supporti di backup in presenza di una di tali condizioni:

      • Qualsiasi set di backup non ancora scaduto. Per ulteriori 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 più indietro in questa sezione.

      Per ignorare queste verifiche, utilizzare l'opzione SKIP.

      [!NOTA] Se i supporti di backup sono protetti da password, in SQL Server non vi viene eseguita alcuna operazione di scrittura, a meno che non venga specificata la password corretta per i supporti. Questo controllo viene eseguito anche quando si specifica l'opzione SKIP. I supporti protetti da password possono essere sovrascritti solo tramite la riformattazione, che provoca l'eliminazione dei backup dai supporti. Per informazioni sulla password per i supporti, vedere "MEDIAPASSWORD" più indietro in questo argomento. Per informazioni sulla riformattazione dei supporti, vedere "FORMAT" più indietro in questo argomento.

      Per ulteriori informazioni, vedere Sovrascrittura di set di backup.

  • { NOSKIP | SKIP }
    Determina se un'operazione di backup deve verificare 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" di seguito in questo argomento.

    • NOSKIP
      Imposta il controllo della data di scadenza di tutti i set di backup nei supporti da eseguire durante l'operazione BACKUP prima di consentire la sovrascrittura dei set. Ciò corrisponde al funzionamento predefinito.

    • SKIP
      Disattiva il controllo del nome e della scadenza dei set di backup, eseguito in genere dall'istruzione BACKUP per impedire la sovrascrittura dei set di backup. Per informazioni sulle interazioni tra { INIT | NOINIT } e { NOSKIP | SKIP }, vedere la sezione "Osservazioni" più indietro in questo argomento.

      Per visualizzare le date di scadenza dei set di backup, eseguire una query sulla colonna expiration_date della tabella di cronologia backupset.

  • { NOFORMAT | FORMAT }
    Specifica se l'intestazione del supporto deve essere scritta nei volumi utilizzati per l'operazione di backup, sovrascrivendo eventuali intestazioni di supporti e set di backup esistenti.

    • NOFORMAT
      Indica che l'operazione di backup deve mantenere l'intestazione del supporto e i set di backup esistenti nei volumi del supporto utilizzati per l'operazione di backup stessa. Si tratta del comportamento predefinito.

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

      ms186865.note(it-it,SQL.90).gifImportante:
      Utilizzare FORMAT con cautela. La formattazione di un volume di un set di supporti rende inutilizzabile l'intero set di supporti. Ad esempio, se 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'utilizzo di SKIP. Non è quindi necessario specificare SKIP in modo esplicito.

  • MEDIADESCRIPTION = { text | **@**text_variable }
    Specifica la descrizione di testo in formato libero del set di supporti, composta da un massimo di 255 caratteri.
  • MEDIANAME = { media_name | **@**media_name_variable }
    Specifica il nome dei supporti per l'intero set di supporti di backup. Il nome dei supporti deve essere composto al massimo da 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 eseguito alcun controllo del nome dei supporti.

  • MEDIAPASSWORD = { mediapassword | **@**mediapassword_variable }
    Imposta la password per il set di supporti. MEDIAPASSWORD è una stringa di caratteri.

    Se per il set di supporti è stata definita una password, per poter creare un set di backup nel set di supporti è necessario specificare la password corretta. È inoltre necessario specificarla per l'esecuzione di qualsiasi operazione di ripristino dal set di supporti. I supporti protetti con password possono essere sovrascritti solo tramite riformattazione. Per ulteriori informazioni, vedere l'opzione FORMAT. (Per ulteriori informazioni sull'utilizzo delle password, vedere la sezione Autorizzazioni di seguito in questo argomento.)

    ms186865.security(it-it,SQL.90).gifNota sulla protezione:
    Il livello di protezione garantito da questa password è ridotto. Lo scopo consiste nell'impedire un ripristino non corretto da parte di utenti autorizzati o non autorizzati mediante gli strumenti di SQL Server 2005. Non viene impedita la lettura dei dati di backup eseguita con altri mezzi, né la sostituzione della password. Per ottenere un livello di protezione adeguato per i backup, è consigliabile archiviare i nastri di backup in un luogo protetto oppure eseguire il backup su file su disco protetti da elenchi di controllo di accesso appropriati. Gli elenchi di controllo di accesso devono essere impostati a livello della directory principale in cui vengono creati i backup.

    [!NOTA] L'opzione MEDIAPASSWORD verrà rimossa in una versione futura di SQL Server.

  • BLOCKSIZE = { blocksize | **@**blocksize_variable }
    Specifica le dimensioni del blocco fisico in byte. Le dimensioni supportate sono 512, 1024, 2048, 4096, 8192, 16384, 32768 e 65536 (64 KB) byte. Il valore predefinito è 65536 per le periferiche nastro e 512 negli altri casi. Questa opzione non è in genere necessaria, in quanto vengono selezionate automaticamente le dimensioni del blocco più appropriate per la periferica. L'impostazione esplicita delle dimensioni del blocco ha priorità sulla selezione automatica.

    Se si esegue un backup che si desidera copiare e ripristinare da un CD-ROM, impostare BLOCKSIZE su 2048.

    [!NOTA] In genere, questa opzione influisce sulle prestazioni solo durante la scrittura nelle periferiche nastro.

Opzioni di trasferimento dei dati

  • BUFFERCOUNT = { buffercount | **@**buffercount_variable }
    Specifica il numero totale di buffer di I/O da utilizzare per l'operazione di backup. È possibile specificare qualsiasi 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 utilizzato dai buffer viene determinato da buffercount*****maxtransfersize.

  • MAXTRANSFERSIZE = { maxtransfersize | **@**maxtransfersize_variable }
    Specifica le dimensioni massime, in byte, per il trasferimento tra SQL Server e il supporto di backup. I possibili valori sono i multipli di 65536 byte (64 KB) fino a 4194304 byte (4 MB).

Opzioni di gestione degli errori

Queste opzioni consentono di specificare se i checksum del backup sono attivati per l'operazione di backup e se l'operazione verrà interrotta in caso di errore.

  • { NO_CHECKSUM | CHECKSUM }
    Determina se i checksum del backup sono attivati.

    • NO_CHECKSUM
      Disattiva in modo esplicito la generazione di valori di checksum per il backup e la convalida dei valori di checksum delle pagine. Ciò corrisponde al funzionamento predefinito.

    • CHECKSUM
      Attiva i checksum del backup, affinché l'istruzione BACKUP esegua le operazioni seguenti:

      1. Prima di scrivere un pagina nel supporto di backup, BACKUP verifica la pagina (checksum della pagina o pagina incompleta), se queste informazioni sono disponibili nella pagina.
      2. Indipendentemente dalla presenza di valori checksum per la pagina, viene generato un checksum di backup separato per i flussi di backup. Le operazioni di ripristino possono utilizzare facoltativamente il checksum del backup per verificare che il backup non sia danneggiato. Il checksum del backup viene archiviato nei supporti di backup e non nelle pagine del database. È possibile utilizzare facoltativamente il checksum del backup in fase di ripristino.

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

  • { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
    Determina se un'operazione di backup viene interrotta o prosegue in seguito a un errore checksum della pagina.

    • STOP_ON_ERROR
      Imposta l'interruzione dell'istruzione BACKUP in presenza di errori checksum della pagina. Si tratta del comportamento predefinito.

    • CONTINUE_AFTER_ERROR
      Imposta BACKUP per il proseguimento delle operazioni nonostante la presenza di errori, ad esempio checksum non validi o pagine incomplete.

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

Opzioni di compatibilità

  • RESTART
    Nessun effetto. L'opzione è accettata in questa versione per compatibilità con le versioni precedenti di SQL Server.

Opzioni di monitoraggio

  • STATS [ **=**percentage ]
    Visualizza un messaggio ogni volta che viene completata la percentuale specificata in percentage. Consente di tenere traccia dello stato di avanzamento dell'operazione. Se percentage viene omesso, SQL Server visualizza un messaggio dopo ogni completamento del 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, viene visualizzato un messaggio in corrispondenza di tale intervallo e l'opzione potrebbe visualizzare il 43% anziché il 40% esatto. 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 alle periferiche nastro

Queste opzioni vengono utilizzate solo per le periferiche nastro. Se non si utilizza una periferica 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 durante l'esecuzione di 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 utilizza 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 utilizza l'opzione REWIND o UNLOAD oppure fino alla chiusura dell'istanza del server. Ciò impedisce ad altri processi di accedere al nastro. Per informazioni sulla visualizzazione dell'elenco dei nastri aperti e sulla chiusura di un nastro aperto, vedere Periferiche di backup.

  • { UNLOAD | NOUNLOAD }

    [!NOTA] UNLOAD/NOUNLOAD è un'impostazione di sessione che rimane valida per l'intera durata della sessione o finché non viene reimpostata 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 una periferica di backup a nastro, l'opzione BLOCKSIZE influisce sulle prestazioni dell'operazione di backup. In genere, questa opzione influisce sulle prestazioni solo durante la scrittura nelle periferiche nastro.

Opzioni specifiche dei log

Queste opzioni vengono utilizzate solo con BACKUP LOG.

[!NOTA] Se non si desidera eseguire un backup del log, utilizzare il modello di recupero con registrazione minima. Per ulteriori informazioni, vedere Backup in base al modello di recupero con registrazione minima.

  • { 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 su un database secondario o per salvare la parte finale del log prima di un'operazione RESTORE.

      Utilizzare insieme le opzioni NO_TRUNCATE e NORECOVERY per eseguire un backup del log senza troncamento del log, in presenza di un database danneggiato, 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 utilizzare la modalità standby è necessario un file standby, specificato con il parametro 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 ripristinate 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 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 quando il database è danneggiato.

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

    Se non si utilizza l'opzione NO_TRUNCATE, il database deve essere in linea.

    Con il database in stato OFFLINE o EMERGENCY, l'esecuzione di BACKUP non è consentita neanche con NO_TRUNCATE.

  • [ NO_LOG | TRUNCATE_ONLY ]

    [!NOTA] Questa opzione verrà rimossa a partire da una delle prossime versioni di SQL Server. Evitarne l'utilizzo in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata.

    Utilizzata solo nelle istruzioni BACKUP LOG, esegue un checkpoint per forzare manualmente il troncamento del log delle transazioni. NO_LOG e TRUNCATE_ONLY sono sinonimi. Non è necessario specificare una periferica di backup, in quanto il backup del log non viene eseguito.

    Se si utilizza il modello di recupero con registrazione minima, l'esecuzione di un checkpoint rimuove la parte inattiva del log senza creare una copia di backup. In questo modo, il log viene troncato eliminandone tutte le parti inattive. Questa opzione consente di liberare spazio, ma presenta il rischio di una possibile perdita di dati. Dopo il troncamento del log tramite NO_LOG o TRUNCATE_ONLY, non è possibile recuperare le modifiche registrate nella parte troncata del log fino al successivo backup del database. Ai fini del recupero, dopo avere utilizzato una di queste opzioni, è pertanto necessario eseguire immediatamente BACKUP DATABASE per creare un backup completo o differenziale del database.

    ms186865.Caution(it-it,SQL.90).gifAttenzione:
    È consigliabile non utilizzare mai NO_LOG o TRUNCATE_ONLY per troncare manualmente il log delle transazioni, perché in questo modo viene interrotta la catena di log. Il database rimane infatti non protetto da errori dei supporti fino al successivo backup completo o differenziale del database. Utilizzare il troncamento manuale del log solo in situazioni molto particolari e creare immediatamente backup dei dati.

Osservazioni

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

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

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

Per informazioni sulla terminologia relativa al backup, sulle periferiche di backup e sulla gestione dei backup, vedere Utilizzo di supporti di backup in SQL Server.

Concorrenza

In SQL Server viene eseguito un processo di backup in linea 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, come l'istruzione ALTER DATABASE con l'opzione ADD FILE o REMOVE FILE.
  • Compattazione di database o file, incluse operazioni di compattazione automatica.

Se un'operazione di backup si sovrappone a un'operazione di gestione file o compattazione, viene generato un conflitto. Indipendentemente dall'operazione iniziata per prima, 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.

Formattazione dei supporti di backup

I supporti di backup vengono formattati tramite l'istruzione BACKUP ed esclusivamente nei casi seguenti:

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

Per ulteriori informazioni, vedere Creazione di un nuovo set di supporti.

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

    Intero database

    I backup del database vengono eseguiti sull'intero database.

    Backup parziale del database

    I backup parziali vengono eseguiti sui filegroup di lettura/scrittura e, facoltativamente, su uno o più file o filegroup di sola lettura.

    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 lettura/scrittura secondari.

  • Se si utilizza il modello di recupero con registrazione completa o con registrazione minima delle transazioni di massa, i backup convenzionali includono inoltre 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 precedenti backup del log.

    [!NOTA] Prima che sia possibile creare il primo backup del log, è necessario creare un backup completo.

    Per ulteriori informazioni, vedere Utilizzo dei backup del log delle transazioni.

  • 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 ulteriori informazioni, vedere Backup di sola copia.

Backup di dati full-text

Quando si esegue un backup completo del database in SQL Server 2005, i dati full-text vengono inclusi nel backup con gli altri dati del database. Nelle operazioni di backup, i cataloghi full-text vengono gestiti come file. Ad esempio, è possibile eseguire separatamente il backup dei cataloghi utilizzando la clausola FILE= per selezionare i cataloghi desiderati. (Il formato del nome di file logico dei cataloghi full-text è sysft_<catalog name>.)

Durante il backup, per il catalogo viene impostata la modalità di sola lettura, in modo che le attività di ricerca per indicizzazione, ovvero il processo di creazione e manutenzione di un indice full-text, vengano sospese fino al completamento del backup.

Interazioni tra le clausole SKIP, NOSKIP, INIT e NOINIT

In questa tabella vengono descritte le interazioni tra le opzioni { NOINIT | INIT } e { NOSKIP | SKIP }.

[!NOTA] In tutte le interazioni descritte, se il nastro è vuoto oppure il file di backup su disco non esiste, viene scritta un'intestazione dei supporti e l'operazione procede. Se il supporto non è vuoto e non contiene un'intestazione valida, queste operazioni segnalano la presenza di supporti MTF non validi e interrompono l'operazione di backup.

  NOINIT INIT

NOSKIP

Se il volume contiene un'intestazione dei supporti valida, controlla la password dei supporti e verifica che il nome dei supporti corrisponda al valore MEDIANAME, se specificato. Se il nome corrisponde, accoda il set di backup mantenendo tutti i set di backup esistenti.

Se il volume non contiene un'intestazione dei supporti valida, viene generato un errore.

Se il volume contiene un'intestazione dei supporti valida, esegue le verifiche seguenti:

  • Verifica la password dei supporti2.
  • Se è stato specificato MEDIANAME, verifica che il nome dei supporti indicato corrisponda al nome dei supporti nell'intestazione.
  • Verifica che i supporti non contengano set di backup non scaduti.
    In caso contrario, interrompe il backup.

Se le verifiche hanno esito positivo, sovrascrive gli eventuali set di backup presenti nei supporti, mantenendo solo l'intestazione.

Se il volume non contiene un'intestazione dei supporti valida, ne genera automaticamente una con i valori specificati per MEDIANAME, MEDIAPASSWORD e MEDIADESCRIPTION, se disponibili.

SKIP

Se il volume contiene un'intestazione dei supporti valida, verifica la password dei supporti e accoda il set di backup, mantenendo tutti i set di backup esistenti.

Se il volume contiene un'intestazione dei supporti valida1, verifica la password dei supporti e sovrascrive gli eventuali set di backup presenti nei supporti, mantenendo solo l'intestazione.

Se i supporti sono vuoti, genera un'intestazione utilizzando i valori specificati per MEDIANAME, MEDIAPASSWORD e MEDIADESCRIPTION, se disponibili.

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

2 Per eseguire un'operazione di backup, l'utente deve appartenere al ruolo predefinito del database o del server appropriato e specificare la password dei supporti corretta.

Tabelle di cronologia di backup

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

Quando si esegue un ripristino e se il set di backup non è già stato registrato nel database msdb, è possibile che le tabelle di cronologia di backup vengano modificate.

Informazioni sulla compatibilità

ms186865.Caution(it-it,SQL.90).gifAttenzione:
I backup creati nella versione più recente di SQL Server non possono essere ripristinati nelle versioni precedenti di SQL Server.

L'istruzione BACKUP supporta le parole chiave seguenti per rispondere alle esigenze di compatibilità con le versioni precedenti di SQL Server:

  • L'opzione RESTART è accettata per compatibilità con le versioni precedenti, ma non ha alcun effetto in SQL Server 2005.
  • Per garantire la compatibilità con le versioni precedenti, nelle istruzioni BACKUP è possibile utilizzare la parola chiave DUMP anziché la parola chiave BACKUP. È inoltre possibile utilizzare la parola chiave TRANSACTION anziché la parola chiave LOG. Motore di database di SQL Server interpreta DUMP DATABASE o DUMP TRANSACTION allo stesso modo rispettivamente di BACKUP DATABASE o BACKUP LOG.
    ms186865.note(it-it,SQL.90).gifImportante:
    L'istruzione DUMP è disponibile per compatibilità con le versioni precedenti. Questa funzionalità verrà rimossa in una delle prossime versioni di Microsoft SQL Server. Evitare di utilizzare questa funzionalità in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata. Utilizzare invece BACKUP.

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

Un set di striping rappresenta un insieme di file su disco in cui i dati sono divisi in blocchi e distribuiti in base a un ordine prestabilito. Il numero delle periferiche di backup utilizzate in uno striping deve rimanere invariato, a meno che i supporti non vengano reinizializzati con FORMAT.

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

BACKUP DATABASE AdventureWorks
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 AdventureWorks database;
GO

Dopo avere definito una periferica di backup come parte di un set di striping, non è possibile utilizzarla per il backup su una singola periferica, a meno che non si specifichi FORMAT. In modo analogo, non è possibile utilizzare una periferica 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 dei supporti si omette sia MEDIANAME che MEDIADESCRIPTION, il campo dell'intestazione dei supporti corrispondente alla voce non specificata risulta vuoto.

Utilizzo di un set di supporti con mirroring

In genere, i backup sono 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 periferiche di backup. Ogni gruppo di periferiche 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 periferiche di backup fisiche, configurate 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 la 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 periferiche indicati nella clausola TO. Nell'esempio seguente viene eseguita la scrittura in un set di supporti con mirroring contenente due mirror, utilizzando tre periferiche per ogni mirror:

BACKUP DATABASE AdventureWorks
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
ms186865.note(it-it,SQL.90).gifImportante:
Questo esempio è progettato in modo da consentirne il testing nel sistema locale. In pratica, l'esecuzione di un backup su più periferiche 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 periferica di backup specificata nella clausola TO di un'istruzione BACKUP corrisponde a un gruppo di supporti. Se, ad esempio, nella clausola TO sono indicate tre periferiche, 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 che il numero di periferiche deve essere identico in ogni mirror.

Se per ogni mirror vengono specificate più periferiche, l'ordine delle periferiche nell'elenco determina il gruppo di supporti scritto in ogni periferica specifica. In ognuno degli elenchi di periferiche, ad esempio, la seconda periferica corrisponde al secondo gruppo di supporti. Nella tabella seguente viene illustrata la corrispondenza tra le periferiche e i gruppi di supporti inclusi nell'esempio precedente.

Mirror Gruppo di supporti 1 Gruppo di supporti 2 Gruppo di supporti 3

0

C:\AdventureWorks1a.bak

C:\AdventureWorks2a.bak

C:\AdventureWorks3a.bak

1

C:\AdventureWorks1b.bak

C:\AdventureWorks2b.bak

C:\AdventureWorks3b.bak

Di ogni gruppo di supporti è necessario eseguire il backup sempre nella stessa periferica all'interno di un mirror specifico. Per questo motivo, ogni volta che si utilizza un set di supporti esistente, è necessario elencare le periferiche di ogni mirror in base allo stesso ordine in cui sono state specificate al momento della creazione del set di supporti.

Per ulteriori informazioni sui set di supporti con mirroring, vedere Utilizzo di set di supporti di backup con mirroring. Per ulteriori informazioni sui set di supporti e i gruppi di supporti in generale, vedere Set di supporti, gruppi di supporti e set di backup.

Autorizzazioni

Le autorizzazioni per le istruzioni 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.

È inoltre possibile specificare una password per un set di supporti o un set di backup oppure per entrambi. Se si imposta una password per un set di supporti, sarà necessario specificare tale password per eseguire queste operazioni. In modo analogo, l'operazione di ripristino è consentita solo se nel comando di ripristino vengono specificate le password corrette per i supporti e il set di backup.

Per l'istruzione BACKUP l'impostazione della password per i set di backup e di supporti è facoltativa. Il livello di protezione garantito da questa password è ridotto. Lo scopo è impedire un ripristino non corretto da parte di utenti autorizzati o non autorizzati mediante gli strumenti di SQL Server 2005. Non impedisce la lettura dei dati di backup eseguita con altri mezzi o la sostituzione della password. Le password, inoltre, non impediscono la sovrascrittura dei supporti mediante l'opzione FORMAT. È consigliabile utilizzare password complesse. Per informazioni sulle password complesse, vedere Password complesse.

L'utilizzo di password, pertanto, consente di proteggere il contenuto dei supporti da accessi non autorizzati effettuati tramite gli strumenti di SQL Server, ma non impedisce l'eliminazione del contenuto. Le password non impediscono completamente l'accesso non autorizzato al contenuto dei supporti, in quanto i dati dei set di backup non sono crittografati e sono pertanto accessibili tramite programmi creati specificatamente a tale scopo. Se la protezione è un fattore di importanza cruciale, è fondamentale impedire l'accesso fisico ai supporti da parte di utenti non autorizzati.

Non è corretto impostare una password per oggetti ai quali non è stata associata una password in fase di creazione.

L'istruzione BACKUP crea il set di backup con la password specificata tramite l'opzione PASSWORD. Questa istruzione inoltre, prima di eseguire scritture nei supporti, verifica la password dei supporti specificata nell'opzione MEDIAPASSWORD. La password non viene verificata solo durante la formattazione dei supporti, operazione che comporta la sovrascrittura dell'intestazione dei supporti. Se l'istruzione BACKUP scrive l'intestazione dei supporti, la password del set di supporti verrà impostata automaticamente sul valore specificato nell'opzione MEDIAPASSWORD.

Per informazioni sull'effetto delle password sulle opzioni SKIP, NOSKIP, INIT e NOINIT, vedere la sezione "Osservazioni" di seguito in questo argomento.

Eventuali problemi di appartenenza o autorizzazioni per il file fisico della periferica di backup possono interferire con le operazioni di backup. SQL Server deve essere in grado di leggere e scrivere nella periferica. L'account utilizzato per l'esecuzione del servizio SQL Server deve disporre di autorizzazioni di scrittura. Le autorizzazioni di accesso ai file, tuttavia, non vengono verificate dalla stored procedure sp_addumpdevice, che aggiunge una voce per una periferica nelle tabelle di sistema. Di conseguenza, i problemi relativi all'accesso e alla proprietà del file fisico della periferica di backup potrebbero emergere solo in fase di accesso alla risorsa fisica durante un tentativo di backup o ripristino.

Esempi

[!NOTA] Il database AdventureWorks viene utilizzato esclusivamente a scopo illustrativo. AdventureWorks è uno dei database di esempio disponibili in SQL Server 2005. Adventure Works Cycles è un'azienda manifatturiera fittizia utilizzata per esemplificare concetti e scenari relativi ai database. Per ulteriori informazioni su questo database, vedere Esempi e database di esempio.

In questa sezione sono disponibili gli esempi seguenti:

  • A. Backup di un database completo
  • B. Backup del database e del log
  • C. Creazione di un backup completo dei filegroup secondari
  • D. Creazione di un backup differenziale dei filegroup secondari
  • E. Creazione di un set di supporti con mirroring con un singolo gruppo di supporti ed esecuzione di un backup in tale set
  • F. Creazione di un set di supporti con mirroring con più gruppi di supporti ed esecuzione di un backup in tale set
  • G. Backup in un set di supporti con mirroring esistente

[!NOTA] Ulteriori esempi sono inclusi negli argomenti contenenti le procedure di backup. Per ulteriori informazioni, vedere Procedure per il backup e il ripristino (Transact-SQL).

A. Backup di un database completo

Nell'esempio seguente viene eseguito il backup del database AdventureWorks in un file su disco.

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

B. Backup del database e del log

Nell'esempio seguente viene eseguito il backup del database di esempio AdventureWorks, per cui, per impostazione predefinita, viene utilizzato il modello di recupero con registrazione minima. Affinché sia possibile eseguire i backup del log, il database AdventureWorks viene modificato per l'utilizzo del modello di recupero con registrazione completa.

Nell'esempio viene quindi utilizzata la stored procedure sp_addumpdevice per creare una periferica di backup logica per il backup dei dati, AdvWorksData, e un'altra periferica di backup logica 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 AdventureWorks
   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', 
'Z:\SQLServerBackups\AdvWorksLog.bak';
GO

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

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

C. Creazione di 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. Creazione di 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. Creazione di un set di supporti con mirroring con un singolo gruppo di supporti ed esecuzione di un backup in tale set

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 AdventureWorks in tali supporti.

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

F. Creazione di un set di supporti con mirroring con più gruppi di supporti ed esecuzione di un backup in tale set

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

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

G. 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 AdventureWorks
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH 
   NOINIT,
   MEDIANAME = 'AdventureWorksSet1'

[!NOTA] NOINIT, ovvero l'opzione predefinita, è specificata in modo esplicito nell'istruzione per maggiore chiarezza.

[Torna all'inizio degli esempi]

Vedere anche

Riferimento

ALTER DATABASE (Transact-SQL)
DBCC SQLPERF (Transact-SQL)
RESTORE (Transact-SQL)
RESTORE FILELISTONLY (Transact-SQL)
RESTORE HEADERONLY (Transact-SQL)
RESTORE LABELONLY (Transact-SQL)
RESTORE VERIFYONLY (Transact-SQL)
sp_addumpdevice (Transact-SQL)
sp_configure (Transact-SQL)
sp_helpfile (Transact-SQL)
sp_helpfilegroup (Transact-SQL)

Altre risorse

Creazione di backup completi e differenziali per un database di SQL Server
Utilizzo di supporti di backup in SQL Server
Set di supporti, gruppi di supporti e set di backup
Utilizzo dei backup del log delle transazioni

Guida in linea e informazioni

Assistenza su SQL Server 2005

Cronologia modifiche

Versione Cronologia

17 luglio 2006
Contenuto modificato:
  • Riorganizzazione delle sezioni "Sintassi" e "Argomenti" per raggruppare le opzioni correlate.
  • Ampliamento della descrizione dell'opzione MIRROR TO.
  • Revisione della sezione "Tipi di backup".
  • Aggiunta della sezione "Informazioni sulla compatibilità".
  • Revisione della sezione "Utilizzo di un set di supporti con mirroring".
  • Aggiunta di esempi relativi a un backup completo di file e a un backup differenziale di file.

14 aprile 2006
Nuovo contenuto:
  • Aggiunta delle opzioni BUFFERCOUNT e MAXTRANSFERSIZE alle sezioni Sintassi e Argomenti.
Contenuto modificato:
  • Elenco delle dimensioni del blocco supportate e aggiornamento della nota sulle prestazioni nella descrizione di BLOCKSIZE.
  • Aggiornamento delle descrizioni delle opzioni {REWIND | NOREWIND} e {UNLOAD | NOUNLOAD}.

5 dicembre 2005
Contenuto modificato:
  • Chiarimento della descrizione delle opzioni NO_LOG e TRUNCATE_ONLY.