BACKUP (Transact-SQL)

Opzioni da utilizzare con un'operazione di backup.

• 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 ulteriori informazioni, vedere Utilizzo dei backup differenziali.

Opzioni relative al set di backup

Queste opzioni riguardano il set di backup creato dall'operazione 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 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 del log 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.

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

• { COMPRESSION | NO_COMPRESSION }
  Solo in SQL Server 2008 Enterprise Edition e versioni successive, specifica se la compressione viene applicata a questo backup, ignorando l'impostazione predefinita a livello di server.

  In fase di installazione, la compressione dei 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 Procedura: Visualizzazione delle proprietà di un server (SQL Server Management Studio).

  • COMPRESSION
    Abilita in modo esplicito la compressione dei backup.

    [!NOTA]

    Per impostazione predefinita, quando un backup è compresso vengono eseguiti checksum per rilevare eventuali danni ai supporti.

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

• PASSWORD = { password | **@**password_variable }
  Imposta la password per il set di backup. PASSWORD è una stringa di caratteri.

  Importante
  Questa caratteristica verrà rimossa a partire dalla prossima versione 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.

  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 più avanti in questa tabella). Per ulteriori informazioni sull'utilizzo delle password, vedere la sezione "Autorizzazioni" più avanti in questo argomento.

  Nota 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. 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 dei 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 (ACL) appropriati. Gli elenchi di controllo di accesso devono essere impostati a livello della directory radice in cui vengono creati i backup.

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

  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 di sistema configurato e specificata in uno dei modi seguenti:

    • Come costante stringa (@date_var = data)

    • 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 i valori datetime, vedere Utilizzo di dati relativi a data e ora.

    [!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.

Opzioni relative ai set di supporti

Queste opzioni vengono applicate all'intero set di supporti.

• { NOINIT | INIT }
  Determina se l'operazione di backup accoda i dati ai set di backup esistenti nei supporti di backup o sovrascrive tali set. 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 accodato 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 ulteriori informazioni, vedere Accodamento a set di backup esistenti.

  • INIT
    Specifica che tutti i set di backup devono essere sovrascritti, mantenendo però 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 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 questi controlli, utilizzare l'opzione SKIP.

    [!NOTA]

    Se i supporti di backup sono protetti da password, in SQL Server non 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 controlla la data e l'ora di scadenza dei set di backup nei supporti prima di sovrascriverli.

  [!NOTA]

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

  • NOSKIP
    Imposta il controllo della data di scadenza di tutti i set di backup nei supporti da eseguire durante l'istruzione BACKUP prima di consentire la sovrascrittura dei set. Questo comportamento è quello predefinito.

  • SKIP
    Disabilita 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ù avanti in questo argomento.

    Per visualizzare le date di scadenza dei set di backup, eseguire una query sulla colonna expiration_date della tabella della 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 dei supporti utilizzati per l'operazione di backup stessa. Questo comportamento è quello 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 dei supporti utilizzati per l'operazione di backup. Il contenuto esistente del volume non è più valido, in quanto tutte le intestazioni dei supporti e i set di backup esistenti vengono sovrascritti.

    Importante
    Utilizzare FORMAT con cautela. 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'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 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.

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

  Importante
  Questa caratteristica verrà rimossa a partire dalla prossima versione 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.

  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 specificare tale password 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 più avanti in questo argomento.

  Nota 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. 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 dei 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 (ACL) appropriati. Gli elenchi di controllo di accesso devono essere impostati a livello della directory radice in cui vengono creati i backup.

• 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 in genere non è necessaria, in quanto BACKUP seleziona 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 utilizzare 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 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 i supporti di backup. I valori possibili sono i multipli di 65536 byte (64 KB) fino a 4194304 byte (4 MB).

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 interrotta in caso di errore.

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

  • NO_CHECKSUM
    Disabilita in modo esplicito la generazione di valori di checksum del backup e la convalida dei valori di checksum delle pagine. Si tratta del comportamento predefinito, tranne nel caso di un backup compresso.

  • CHECKSUM
    Abilita i checksum del backup, affinché tramite l'istruzione BACKUP vengano eseguite le operazioni seguenti:

    1. Prima di scrivere una pagina nel supporto di backup, BACKUP esegue una verifica della pagina (checksum della pagina o pagina incompleta), se queste informazioni sono disponibili nella pagina.

    2. Indipendentemente dalla presenza di valori di checksum della pagina, BACKUP genera 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.

    Questo comportamento è quello predefinito per un backup compresso.

• { 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. Questo comportamento è quello 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 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 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 ai dispositivi 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 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 Dispositivi 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.

Opzioni specifiche dei log

Queste opzioni vengono utilizzate solo con BACKUP LOG.

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

    Utilizzare 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 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 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 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. 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 ulteriori informazioni sugli stati del database, vedere Stati del database.

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 sull'identificazione e la gestione dei fattori che provocano il ritardo, vedere Fattori che possono ritardare il troncamento del log..

Per ulteriori informazioni sul troncamento del log in generale, vedere Troncamento del log delle transazioni.

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.

• Operazioni di compattazione di database o file, incluse le operazioni di compattazione automatica.

Se un'operazione di backup si sovrappone a un'operazione di compattazione o di gestione dei file, viene generato 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 durante il periodo di timeout, la seconda operazione continua. Se il periodo di timeout del blocco scade, la seconda operazione ha esito negativo.

I supporti di backup vengono formattati tramite l'istruzione BACKUP esclusivamente quando si verifica una delle condizioni 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.

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 operazioni bulk, 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 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.

  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.

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

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.

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

• backupfile (Transact-SQL)

• backupfilegroup (Transact-SQL)

• backupmediafamily (Transact-SQL)

• backupmediaset (Transact-SQL)

• backupset (Transact-SQL)

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

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

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

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 utilizzati 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 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 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 con striping.

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

In genere, i backup vengono eseguiti senza mirroring e le istruzioni BACKUP includono solo una clausola TO. Ogni set di supporti, tuttavia, può contenere un 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 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

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

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

Nell'esempio seguente viene eseguito il backup del database di esempio AdventureWorks, per il quale viene utilizzato per impostazione predefinita il modello di recupero con registrazione minima. Per consentire il 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 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 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', 
'X:\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

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

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

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'

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 AdventureWorks in entrambi i mirror.

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

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'

[Torna all'inizio degli esempi]

Nell'esempio seguente vengono formattati i supporti, creando un nuovo set di supporti, e viene eseguito un backup compresso completo del database AdventureWorks.

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

[Torna all'inizio degli esempi]