Condividi tramite


Backup di SQL Server nell'URL per Archiviazione BLOB di Azure

Si applica a:SQL ServerIstanza gestita di Azure SQL

Questo articolo presenta i concetti, i requisiti e i componenti necessari per usare Archiviazione BLOB di Azure come destinazione di backup. La funzionalità di backup e ripristino è uguale o simile a quando si usa DISK o TAPE, con alcune differenze. Nell'articolo sono descritte le differenze e sono inclusi alcuni esempi di codice.

Tip

SQL Server 2025 (17.x) Preview introduce il backup su URL con identità gestita. Vedere Eseguire il backup nell'URL con identità gestita (anteprima) - SQL Server abilitato da Azure Arc.

Overview

SQL Server 2012 Service Pack 1 CU2 e SQL Server 2014 hanno introdotto la possibilità di eseguire il backup in un URL a cui punta Archiviazione BLOB di Azure, usando una sintassi T-SQL familiare per scrivere i backup in modo sicuro nell'archiviazione di Azure. SQL Server 2016 (13.x) ha introdotto File-Snapshot Backup per i file di database in Azure e la sicurezza tramite chiavi di firma di accesso condiviso (SAS), un modo sicuro e semplice per autenticare i certificati ai criteri di sicurezza di Archiviazione di Azure.

È importante comprendere i componenti e l'interazione tra di essi per eseguire un backup o eseguire il ripristino da Archiviazione BLOB di Azure.

Il primo passo in questo processo consiste nella creazione di un account di Archiviazione di Azure nella sottoscrizione di Azure. Questo account di archiviazione è un account amministrativo con autorizzazioni amministrative complete per tutti i contenitori e gli oggetti creati con tale account. SQL Server può usare il nome dell'account di archiviazione di Azure e il relativo valore della chiave di accesso per autenticare e scrivere e leggere BLOB nell'archiviazione BLOB di Azure oppure usare un token di firma di accesso condiviso generato in contenitori specifici che concedono diritti di lettura e scrittura. Per altre informazioni sugli account di archiviazione di Azure, vedere Informazioni sugli account di archiviazione di Azure . Per altre informazioni sulle firme di accesso condiviso, vedere Firme di accesso condiviso, parte 1: conoscere il modello di firma di accesso condiviso. Queste informazioni di autenticazione usate durante le operazioni di backup o ripristino vengono archiviate nelle credenziali di SQL Server.

Archiviazione di Azure e archiviazione compatibile con S3

SQL Server 2022 (16.x) introduce la possibilità di scrivere backup in un archivio oggetti compatibile con S3, con funzionalità di backup e ripristino concettualmente simili all'uso del backup nell’URL usando Archiviazione BLOB di Azure come tipo di dispositivo di backup. SQL Server 2022 (16.x) estende la BACKUP/RESTORE TO/FROM URL sintassi aggiungendo il supporto per un nuovo connettore S3 usando l'API REST.

Questo articolo contiene informazioni sull'uso di Backup su URL per Archiviazione BLOB di Azure. Per altre informazioni sull'uso del backup nell'URL per l'archiviazione compatibile con S3, vedere Backup di SQL Server nell'URL per l'archiviazione di oggetti compatibile con S3.

Eseguire il backup su BLOB in blocchi o BLOB di pagine di Archiviazione di Azure

Esistono due tipi di oggetti BLOB che è possibile archiviare in Archiviazione BLOB di Azure: BLOB in blocchi e BLOB di pagine. Per SQL Server 2016 e versioni successive, è preferibile il BLOB in blocchi.

Se la chiave di archiviazione viene utilizzata nelle credenziali, viene utilizzato il blob di pagine; se viene utilizzata la Firma di Accesso Condiviso, viene utilizzato il blob in blocchi.

Il backup su BLOB in blocchi è disponibile solo in SQL Server 2016 o versioni successive, per il backup in Archiviazione BLOB di Azure. Esegui il backup su un BLOB di blocchi anziché su un BLOB di pagine se utilizzi SQL Server 2016 o una versione successiva.

I motivi principali sono:

  • La firma di accesso condiviso è un modo più sicuro per autorizzare l'accesso al BLOB rispetto alla chiave di archiviazione.
  • È possibile eseguire il backup su più BLOB in blocchi per ottenere prestazioni di backup e ripristino superiori e supportare il backup di database più grandi.
  • Il BLOB in blocchi è più economico del BLOB di pagine.
  • I clienti che devono eseguire il backup nei BLOB di pagine tramite un server proxy devono usare backuptourl.exe.

L’esecuzione del backup di un database di grandi dimensioni nell'archiviazione BLOB di Azure è soggetta alle limitazioni elencate in Differenze, limitazioni e problemi noti di T-SQL in Istanza gestita di SQL Azure.

Se le dimensioni del database sono troppo grandi, è possibile:

  • Usare la compressione del backup oppure
  • Eseguire il backup su più BLOB in blocchi

Supporto in Linux, in contenitori e in Istanza gestita di SQL abilitata per Azure Arc

Se l'istanza di SQL Server è ospitata in Linux, tra cui:

  • Sistema operativo autonomo
  • Containers
  • Istanza gestita di SQL con abilitazione di Azure Arc
  • Qualsiasi altro ambiente basato su Linux

L'unico backup su URL per Archiviazione BLOB di Azure supportato è in BLOB in blocchi, usando la firma di accesso condiviso.

Blob Storage di Azure

Account di archiviazione: L'account di archiviazione è il punto di partenza per tutti i servizi di archiviazione. Per accedere ad Archiviazione BLOB di Azure, creare prima di tutto un account di archiviazione di Azure. Per altre informazioni, vedere la pagina relativa alla creazione degli account di archiviazione.

Contenitore: Un contenitore fornisce un raggruppamento di un set di BLOB e può archiviare un numero illimitato di BLOB. Per scrivere un backup di SQL Server in Archiviazione BLOB di Azure, deve prima essere stato creato almeno il contenitore radice. È possibile generare un token di firma di accesso condiviso in un contenitore e concedere l'accesso agli oggetti in un solo contenitore specifico.

Blob: File di qualsiasi tipo e dimensione. Esistono due tipi di oggetti BLOB che è possibile archiviare in Archiviazione BLOB di Azure: BLOB in blocchi e BLOB di pagine. Il backup di SQL Server può usare uno dei due tipi di BLOB, a seconda della sintassi Transact-SQL usata. I BLOB sono indirizzabili tramite questo formato di URL: https://<account di archiviazione>.blob.core.windows.net/<contenitore>/<blob>. Per altre informazioni su Archiviazione BLOB di Azure, vedere Introduzione a Archiviazione BLOB di Azure. Per altre informazioni sui BLOB di pagine e in blocco, vedere Informazioni sui Blob in blocchi, sui BLOB di aggiunta e sui BLOB di pagine.

Diagramma degli account, dei contenitori e dei blob di Azure Blob Storage.

Snapshot di Azure: Snapshot di un BLOB di Azure acquisito in un momento specifico. Per altre informazioni, vedere Creazione di uno snapshot di un BLOB. SQL Server ora supporta i backup di Azure degli snapshot dei file di database archiviati in Archiviazione BLOB di Azure. Per altre informazioni, vedere Backup di snapshot di file per i file di database in Azure.

Componenti di SQL Server

URL: Un URL specifica un URI (Uniform Resource Identifier) in un file di backup univoco. L'URL viene usato per fornire il percorso e il nome del file di backup di SQL Server. L'URL deve puntare a un BLOB effettivo, non solo a un contenitore. Se il BLOB non esiste, viene creato. Se viene specificato un BLOB esistente, BACKUP ha esito negativo, a meno che non venga specificata l'opzione WITH FORMAT per sovrascrivere il file di backup esistente nel BLOB.

Ecco un valore url di esempio: https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak.

Note

Il backup nell'URL tramite HTTP non è supportato.

Credenziale: Una credenziale di SQL Server è un oggetto usato per archiviare le informazioni di autenticazione necessarie per connettersi a una risorsa all'esterno di SQL Server. In questo caso, nei processi di backup e ripristino di SQL Server vengono usate le credenziali per l'autenticazione a Archiviazione BLOB di Azure, nonché ai contenitori e agli oggetti dei BLOB relativi. Le credenziali archivia il nome dell'account di archiviazione e i valori della chiave di accesso dell'account di archiviazione o l'URL del contenitore e il relativo token di firma di accesso condiviso. Dopo aver creato le credenziali, la sintassi delle BACKUP/RESTORE istruzioni determina il tipo di BLOB e le credenziali necessarie.

Per un esempio di come creare una firma di accesso condiviso, vedere gli esempi in Creare una firma di accesso condiviso più avanti in questo articolo e per creare le credenziali di SQL Server, vedere gli esempi in Creare credenziali più avanti in questo articolo.

Per altre informazioni sulle credenziali, vedere Credenziali (motore di database).

Per informazioni su altri esempi in cui vengono usate le credenziali, vedere Creazione di un proxy di SQL Server Agent.

Supporto dell'archiviazione non modificabile di Azure

SQL Server 2025 (17.x) Preview introduce il supporto per l'archiviazione non modificabile di Azure, che protegge dagli attacchi ransomware. I file scritti nella risorsa di archiviazione non modificabile non possono essere modificati o eliminati, come definito dall'immutabilità.

In genere, i backup di SQL Server vengono creati in due passaggi. Inizialmente, il file di backup .bak viene creato riempito di zeri e successivamente viene aggiornato con dei dati. Poiché la modifica dei file nell'archiviazione non modificabile non è consentita dopo la scrittura e il commit del file, il processo di backup ignora ora il passaggio iniziale per creare il file di backup con zeri. Invece, l'intero backup viene creato in un unico passaggio quando viene scritto nei blob di blocchi.

Durante l'anteprima, il flag di traccia 3012 è necessario per abilitare il supporto dell'archiviazione non modificabile per i backup su URL.

Per usare l'archiviazione non modificabile con il backup dell'anteprima di SQL Server 2025 (17.x) nell'URL, seguire questa procedura:

  1. Configurare l'immutabilità per il contenitore di archiviazione di Azure.

  2. Abilitare il flag di traccia 3012 per l'istanza di SQL Server eseguendo il comando DBCC seguente:

    DBCC TRACEON(3012, -1);
    
  3. Emettere il BACKUP per eseguire il backup del database nel contenitore di archiviazione di Azure. Se si usa l'opzione per l'archiviazione non modificabile WITH FORMAT e un backup esiste già con lo stesso nome, si verifica un errore e il backup non riesce.

    BACKUP DATABASE [<Database>] TO URL = '<url>';
    

Sicurezza per Archiviazione BLOB di Azure

Di seguito sono riportati requisiti e considerazioni sulla sicurezza per l'esecuzione del backup o del ripristino in Archiviazione BLOB di Azure.

  • Quando si crea un contenitore per Archiviazione BLOB di Azure, è consigliabile impostare l'accesso su privato. In questo modo si limita l'accesso a utenti o account in grado di specificare le informazioni necessarie per l'autenticazione all'account di Azure.

    Important

    SQL Server richiede che un nome account di Azure e l'autenticazione della chiave di accesso o una firma di accesso condiviso e un token di accesso vengano archiviati in credenziali di SQL Server. Queste informazioni servono per eseguire l'autenticazione all'account di Azure per operazioni di backup o ripristino.

    Warning

    Archiviazione di Azure supporta la disabilitazione dell'autorizzazione con chiave condivisa per un account di archiviazione. Se l'autorizzazione con chiave condivisa è disabilitata, il backup di SQL Server in URL non funzionerà.

  • L'account utente usato per eseguire BACKUP o RESTORE i comandi deve trovarsi nel ruolo del database dell'operatore db_backup con autorizzazioni Alter any credential .

Limitazioni di backup e ripristino in Archiviazione BLOB di Azure

  • SQL Server limita le dimensioni massime di backup supportate usando un BLOB di pagine di 1 TB. Le dimensioni massime di backup supportate tramite BLOB in blocchi sono limitate a circa 200 GB (50.000 blocchi * 4 MB MAXTRANSFERSIZE). I BLOB in blocchi supportano lo striping per supportare dimensioni di backup notevolmente maggiori: il limite è un massimo di 64 URL, che comporta la formula seguente: 64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB.

    Important

    Anche se le dimensioni massime di backup supportate da un singolo BLOB in blocchi sono di 200 GB, è possibile che SQL Server scriva in dimensioni di blocchi più piccole e ciò può causare il raggiungimento del limite di 50.000 blocchi in SQL Server prima del trasferimento dell'intero backup. Eseguire lo striping dei backup (anche se sono più piccoli di 200 GB) per evitare il limite dei blocchi, soprattutto se si usano backup differenziali o non compressi.

  • È possibile eseguire istruzioni di backup o ripristino usando Transact-SQL, SMO, cmdlet di PowerShell o backup o ripristino guidato di SQL Server Management Studio.

  • L’account di backup in Archiviazione di Azure supporta solo l'autenticazione con token di firma di accesso condiviso o chiavi dell'account di archiviazione. Tutti gli altri metodi di autenticazione, inclusa l'autenticazione con Microsoft Entra ID (in precedenza Azure Active Directory), non sono supportati.

  • La creazione di un nome di dispositivo logico non è supportata. L'aggiunta di URL come dispositivo di backup tramite sp_dumpdevice o tramite SQL Server Management Studio non è quindi supportata.

  • L'accodamento ai BLOB di backup esistenti non è supportato. I backup su un blob esistente possono essere sovrascritti solo usando l'opzione WITH FORMAT. Tuttavia, quando si utilizzano backup di snapshot di file (usando l'argomento WITH FILE_SNAPSHOT), l'argomento WITH FORMAT non è consentito per evitare di lasciare snapshot di file orfani creati con il backup originale dello snapshot di file.

  • Il backup in più BLOB in un'unica operazione è supportato solo tramite i BLOB in blocchi e un token di firma di accesso condiviso, anziché con la chiave dell'account di archiviazione per le credenziali SQL.

  • La specifica BLOCKSIZE non è supportata per i BLOB di pagine.

  • La specifica di MAXTRANSFERSIZE non è supportata per i BLOB di pagina.

  • Specificare le opzioni del set di backup - RETAINDAYS e EXPIREDATE non sono supportate.

  • In SQL Server è previsto un limite massimo di 259 caratteri per il nome di un dispositivo di backup. BACKUP TO URL Utilizza 36 caratteri per gli elementi necessari usati per specificare l'URL https://.blob.core.windows.net//.bak, lasciando 223 caratteri per i nomi di account, contenitore e BLOB messi insieme.

  • SQL Server 2019 (15.x) e versioni precedenti hanno un limite di 256 caratteri per i token di firma di accesso condiviso (SAS), che limita il tipo di token che possono essere usati (ad esempio, i token di chiave di delega utente non sono supportati).

  • Se il server accede ad Azure tramite un server proxy, è necessario usare il flag di traccia 1819 e quindi impostare la configurazione del proxy WinHTTP con uno dei metodi seguenti:

    • Utilità proxycfg.exe in Windows XP o Windows Server 2003 e versioni precedenti.
    • Utilità netsh.exe in Windows Vista e Windows Server 2008 o versione successiva.
  • L'archiviazione non modificabile per Archiviazione BLOB di Azure non è supportata. Impostare i criteri di archiviazione non modificabili su false.

  • Il backup nell'URL non è supportato nell'archiviazione Premium.

Argomenti e dichiarazioni supportati in Archiviazione Blob di Azure

Supporto per istruzioni di backup/ripristino in Archiviazione BLOB di Azure

Istruzione backup/ripristino Supported Exceptions Comments
BACKUP Yes BLOCKSIZE e MAXTRANSFERSIZE sono supportati per i BLOB in blocchi. Non sono supportati per i BLOB di pagine. BACKUP per un BLOB in blocchi è necessaria una firma di accesso condiviso salvata in credenziali di SQL Server. BACKUP per il BLOB di pagine è necessaria la chiave dell'account di archiviazione salvata in una credenziale di SQL Server e richiede che venga specificato l'argomento WITH CREDENTIAL .
RESTORE Yes Richiede la definizione di credenziali di SQL Server e richiede l'argomento WITH CREDENTIAL da specificare se le credenziali di SQL Server vengono definite usando la chiave dell'account di archiviazione come segreto
RESTORE FILELISTONLY Yes Richiede la definizione di credenziali di SQL Server e richiede l'argomento WITH CREDENTIAL da specificare se le credenziali di SQL Server vengono definite usando la chiave dell'account di archiviazione come segreto
RESTORE HEADERONLY Yes Richiede la definizione di credenziali di SQL Server e richiede l'argomento WITH CREDENTIAL da specificare se le credenziali di SQL Server vengono definite usando la chiave dell'account di archiviazione come segreto
RESTORE LABELONLY Yes Richiede la definizione di credenziali di SQL Server e richiede l'argomento WITH CREDENTIAL da specificare se le credenziali di SQL Server vengono definite usando la chiave dell'account di archiviazione come segreto
RESTORE VERIFYONLY Yes Richiede la definizione di credenziali di SQL Server e richiede l'argomento WITH CREDENTIAL da specificare se le credenziali di SQL Server vengono definite usando la chiave dell'account di archiviazione come segreto
RESTORE REWINDONLY No

Per informazioni generali sulla sintassi e sulle istruzioni di backup, vedere BACKUP.

Per informazioni generali sulla sintassi e sulle istruzioni di ripristino, vedere Istruzioni RESTORE.

Supporto per gli argomenti di backup in Archiviazione BLOB di Azure

Argument Supported Exception Comments
DATABASE Yes
LOG Yes
TO (URL) Yes A differenza di DISK e TAPE, l'URL non supporta la specifica o la creazione di un nome logico. Questo argomento viene utilizzato per specificare il percorso URL del file di backup.
MIRROR TO Yes
WITH Opzioni:
CREDENTIAL Yes WITH CREDENTIAL è supportato solo quando si usa l'opzione BACKUP TO URL per eseguire il backup in Archiviazione BLOB di Azure e solo se le credenziali di SQL Server vengono definite usando la chiave dell'account di archiviazione come segreto
FILE_SNAPSHOT Yes
ENCRYPTION Yes Quando si specifica l'argomento WITH ENCRYPTION , SQL Server File-Snapshot Backup garantisce che l'intero database sia stato crittografato tramite TDE prima di eseguire il backup e, in tal caso, crittografa il file di backup dello snapshot di file usando l'algoritmo specificato per TDE nel database. Se tutti i dati nel database dell'intero database non sono crittografati, il backup ha esito negativo, ad esempio il processo di crittografia non è ancora stato completato.
DIFFERENTIAL Yes
COPY_ONLY Yes
COMPRESSION|NO_COMPRESSION Yes Non supportato per il backup con snapshot di file
DESCRIPTION Yes
NAME Yes
EXPIREDATE | RETAINDAYS No
NOINIT | INIT No Non si possono aggiungere dati ai BLOB. Per sovrascrivere un backup, utilizzare l'argomento WITH FORMAT . Tuttavia, quando si utilizzano backup di snapshot di file (usando l'argomento WITH FILE_SNAPSHOT), l'argomento WITH FORMAT non è consentito, per evitare di lasciare snapshot di file orfani che sono stati creati con il backup originale.
NOSKIP | SKIP No
NOFORMAT | FORMAT Yes Un backup eseguito su un BLOB esistente ha esito negativo a meno che WITH FORMAT venga specificato. Il BLOB esistente viene sovrascritto quando WITH FORMAT viene specificato. Tuttavia, quando si utilizzano backup di snapshot di file (usando l'argomento WITH FILE_SNAPSHOT), l'argomento FORMAT non è consentito per evitare di lasciare snapshot di file orfani creati con il backup originale dello snapshot di file. Tuttavia, quando si utilizzano backup di snapshot di file (usando l'argomento WITH FILE_SNAPSHOT), l'argomento WITH FORMAT non è consentito, per evitare di lasciare snapshot di file orfani che sono stati creati con il backup originale.
MEDIADESCRIPTION Yes
MEDIANAME Yes
BLOCKSIZE Yes Non supportati per i BLOB di pagine. Supportati per i BLOB in blocchi. È consigliabile BLOCKSIZE=65536 ottimizzare l'uso dei 50.000 blocchi consentiti in un BLOB in blocchi.
BUFFERCOUNT Yes
MAXTRANSFERSIZE Yes Non supportati per i BLOB di pagine. Supportati per i BLOB in blocchi. Il valore predefinito è 1048576. Il valore può variare fino a 4 MB in incrementi di 65.536 byte.

È consigliabile MAXTRANSFERSIZE=4194304 ottimizzare l'uso dei 50.000 blocchi consentiti in un BLOB in blocchi.
NO_CHECKSUM | CHECKSUM Yes
STOP_ON_ERROR | CONTINUE_AFTER_ERROR Yes
STATS Yes
REWIND | NOREWIND No
UNLOAD | NOUNLOAD No
NORECOVERY | STANDBY Yes
NO_TRUNCATE Yes

Per altre informazioni sugli argomenti di backup, vedere BACKUP.

Supporto per gli argomenti di ripristino in Archiviazione BLOB di Azure

Argument Supported Exceptions Comments
DATABASE Yes
LOG Yes
FROM (URL) Yes L'argomento FROM URL viene usato per specificare il percorso URL per il file di backup.
WITH Opzioni:
CREDENTIAL Yes WITH CREDENTIAL è supportato solo quando si usa RESTORE FROM URL l'opzione per eseguire il ripristino da Archiviazione BLOB di Azure.
PARTIAL Yes
RECOVERY | NORECOVERY | STANDBY Yes
LOADHISTORY Yes
MOVE Yes
REPLACE Yes
RESTART Yes
RESTRICTED_USER Yes
FILE No
PASSWORD Yes
MEDIANAME Yes
MEDIAPASSWORD Yes
BLOCKSIZE Yes
BUFFERCOUNT No
MAXTRANSFERSIZE No
CHECKSUM | NO_CHECKSUM Yes
STOP_ON_ERROR | CONTINUE_AFTER_ERROR Yes
FILESTREAM Yes Non supportato per il backup con snapshot di file
STATS Yes
REWIND | NOREWIND No
UNLOAD | NOUNLOAD No
KEEP_REPLICATION Yes
KEEP_CDC Yes
ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER Yes
STOPAT | STOPATMARK | STOPBEFOREMARK Yes

Per altre informazioni sugli argomenti di ripristino, vedere Istruzioni RESTORE - Argomenti.

Eseguire il backup con SSMS

È possibile eseguire il backup di un database in un URL tramite l'attività di backup in SQL Server Management Studio e credenziali SQL Server.

Note

Per creare un backup di snapshot di file di SQL Server o sovrascrivere un set di supporti esistente, è necessario usare Transact-SQL, PowerShell o C# anziché l'attività Backup in SQL Server Management Studio.

Nei passaggi seguenti vengono descritte le modifiche apportate all'attività di backup di database in SQL Server Management Studio per consentire il backup nel servizio di archiviazione di Azure:

  1. In Esplora oggetticonnettersi a un'istanza del motore di database di SQL Server e, successivamente, espanderla.

  2. Espandere Database, fare clic con il pulsante destro del mouse sul database desiderato, scegliere Attività e quindi selezionare Backup.

  3. Nella pagina Generale, nella sezione Destinazione, l'opzione URL è disponibile nel menu a tendina Backup a:. L'opzione URL viene usata per creare un backup in Archiviazione di Azure. Selezionare Aggiungi e viene visualizzata la finestra di dialogo Seleziona destinazione backup :

    1. Contenitore di archiviazione di Azure: Nome del contenitore di archiviazione di Azure in cui archiviare i file di backup. Selezionare un contenitore esistente dall'elenco a discesa o immettere manualmente il contenitore.

    2. Criteri di accesso condiviso: Immettere la firma di accesso condiviso per un contenitore immesso manualmente. Questo campo non è disponibile se è stato scelto un contenitore esistente.

    3. File di backup: Nome del file di backup.

    4. Nuovo contenitore: Usato per registrare un contenitore esistente per cui non si dispone di una firma di accesso condiviso. Vedere Connettersi a una sottoscrizione di Azure (BACKUP TO URL) .

Note

Add supporta più file di backup e contenitori di archiviazione per un singolo set di supporti.

Quando si seleziona URL come destinazione, alcune opzioni nella pagina Opzioni multimediali sono disabilitate. Negli articoli seguenti vengono fornite ulteriori informazioni sulla finestra di dialogo Backup database:

Eseguire il backup con un piano di manutenzione

Analogamente all'attività di backup descritta in precedenza, la Creazione guidata piano di manutenzione in SQL Server Management Studio include l'URL come una delle opzioni di destinazione e altri oggetti di supporto necessari per eseguire il backup nell'archiviazione di Azure, ad esempio le credenziali SQL. Per altre informazioni, vedere la sezione sulla definizione delle attività di backup in Using Maintenance Plan Wizard.

Note

Per creare un set di backup con striping, un backup di snapshot di file di SQL Server o una credenziale SQL usando un token di accesso condiviso, è necessario usare Transact-SQL, PowerShell o C# anziché l'attività Backup nella Creazione guidata del piano di manutenzione.

Eseguire il ripristino con SSMS

L'attività Ripristina database include l'URL come dispositivo da cui eseguire il ripristino. I passaggi seguenti descrivono come usare l'attività di ripristino per eseguire il ripristino da Archiviazione BLOB di Azure:

  1. Fare clic con il pulsante destro del mouse su Database e scegliere Ripristina database....

  2. Nella pagina Generale selezionare Dispositivo nella sezione Origine .

  3. Selezionare il pulsante Sfoglia (...) per aprire la finestra di dialogo Seleziona dispositivi di backup.

  4. Selezionare URL nell'elenco a discesa Tipo di supporto di backup: . Selezionare Aggiungi per aprire la finestra di dialogo Seleziona percorso file di backup .

    1. Contenitore di archiviazione di Azure: Nome completo del contenitore di archiviazione di Azure che contiene i file di backup. Selezionare un contenitore esistente dall'elenco a discesa o immettere manualmente il nome completo del contenitore.

    2. Firma di accesso condiviso: Usato per immettere la firma di accesso condiviso per il contenitore designato.

    3. Aggiungere: Usato per registrare un contenitore esistente per cui non si dispone di una firma di accesso condiviso. Vedere Connettersi a una sottoscrizione di Microsoft Azure (Backup TO URL).

    4. OK: SQL Server si connette ad Archiviazione di Azure usando le informazioni sulle credenziali SQL fornite e apre la finestra di dialogo Individua file di backup in Microsoft Azure . In questa pagina vengono visualizzati i file di backup che si trovano nel contenitore di archiviazione. Selezionare il file da usare per ripristinare e selezionare OK. Verrà visualizzata nuovamente la finestra di dialogo Seleziona dispositivi di backup e selezionando OK in questa finestra di dialogo viene visualizzata nuovamente la finestra di dialogo Ripristina principale, in cui è possibile completare il ripristino.

Esempi di codice

In questa sezione sono disponibili gli esempi riportati di seguito.

Note

Per un'esercitazione sull'uso di SQL Server 2016 con Archiviazione BLOB di Azure, vedere Esercitazione: Usare Archiviazione BLOB di Azure con SQL Server

Creare una firma di accesso condiviso

Nell'esempio seguente vengono create firme di accesso condiviso che possono essere usate per creare credenziali di SQL Server in un nuovo contenitore. Questo script crea una firma di accesso condiviso associata a un criterio di accesso archiviato. Per altre informazioni, vedere Firme di accesso condiviso, parte 1: conoscere il modello di firma di accesso condiviso. Lo script scrive inoltre il comando T-SQL necessario per creare le credenziali in SQL Server.

Note

L'esempio richiede Azure PowerShell. Per informazioni sull'installazione e l'uso di Azure PowerShell, vedere Come installare e configurare Azure PowerShell. Questi script sono stati verificati con Azure PowerShell 5.1.15063.

Firma di accesso condiviso associata a un criterio di accesso archiviato

# Define global variables for the script
$prefixName = '<a prefix name>'  # used as the prefix for the name for various objects
$subscriptionName = '<your subscription name>'   # the name of subscription name you will use
$locationName = '<a data center location>'  # the data center region you will use
$storageAccountName = $prefixName + 'storage' # the storage account name you will create or use
$containerName = $prefixName + 'container'  # the storage container name to which you will attach the SAS policy with its SAS token
$policyName = $prefixName + 'policy' # the name of the SAS policy

# Set a variable for the name of the resource group you will create or use
$resourceGroupName = $prefixName + 'rg'

# adds an authenticated Azure account for use in the session
Connect-AzAccount

# set the tenant, subscription and environment for use in the rest of
Set-AzContext -SubscriptionName $subscriptionName

# create a new resource group - comment out this line to use an existing resource group
New-AzResourceGroup -Name $resourceGroupName -Location $locationName

# Create a new ARM storage account - comment out this line to use an existing ARM storage account
New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -Type Standard_RAGRS -Location $locationName

# Get the access keys for the ARM storage account
$accountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName

# Create a new storage account context using an ARM storage account
$storageContext = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].value

# Creates a new container in Azure Blob Storage
$container = New-AzStorageContainer -Context $storageContext -Name $containerName
$cbc = $container.CloudBlobContainer

# Sets up a Stored Access Policy and a Shared Access Signature for the new container
$policy = New-AzStorageContainerStoredAccessPolicy -Container $containerName -Policy $policyName -Context $storageContext -ExpiryTime $(Get-Date).ToUniversalTime().AddYears(10) -Permission "rwld"
$sas = New-AzStorageContainerSASToken -Policy $policyName -Context $storageContext -Container $containerName
Write-Host 'Shared Access Signature= '$($sas.TrimStart('?'))''

# Outputs the Transact SQL to the clipboard and to the screen to create the credential using the Shared Access Signature
Write-Host 'Credential T-SQL'
$tSql = "CREATE CREDENTIAL [{0}] WITH IDENTITY='Shared Access Signature', SECRET='{1}'" -f $cbc.Uri, $sas.TrimStart('?')
$tSql | clip
Write-Host $tSql

Dopo aver completato l'esecuzione dello script, copiare il comando CREATE CREDENTIAL in uno strumento di query, connettersi a un'istanza di SQL Server ed eseguire il comando per creare le credenziali con la firma di accesso condiviso.

Crea le credenziali

Nei seguenti esempi vengono create le credenziali di SQL Server per l'autenticazione a Archiviazione BLOB di Azure. Effettuare una delle operazioni seguenti.

  1. Uso della firma di accesso condiviso

    Se si è eseguito lo script precedente per creare la firma di accesso condiviso, copiare il comando CREATE CREDENTIAL in un editor di query connesso all'istanza di SQL Server ed eseguire il comando.

    Il codice T-SQL seguente è un esempio che crea le credenziali per l'uso di una firma di accesso condiviso.

    IF NOT EXISTS (SELECT *
                   FROM sys.credentials
                   WHERE name = 'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>')
        CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>]
            WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '<SAS_TOKEN>';
    
  2. Uso della chiave di identità e di accesso dell'account di archiviazione

    IF NOT EXISTS (SELECT *
                   FROM sys.credentials
                   WHERE name = '<mycredentialname>')
        CREATE CREDENTIAL [<mycredentialname>]
            WITH IDENTITY = '<mystorageaccountname>', SECRET = '<mystorageaccountaccesskey>';
    

Eseguire un backup completo del database

L'esempio seguente esegue un backup completo del database di AdventureWorks2022 in Archiviazione BLOB di Azure. Usare uno degli esempi seguenti:

  1. Nell'URL tramite una firma di accesso condiviso

    BACKUP DATABASE AdventureWorks2022
        TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak';
    GO
    
  2. Nell'URL tramite la chiave di identità e di accesso dell'account di archiviazione

    BACKUP DATABASE AdventureWorks2022
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'
    WITH CREDENTIAL = '<mycredentialname>',
    COMPRESSION, STATS = 5;
    GO
    

Ripristino temporizzato tramite STOPAT

Nell'esempio seguente viene ripristinato lo stato di un database di esempio AdventureWorks2022 in un momento preciso e viene illustrata l'operazione di ripristino.

Dall'URL tramite una firma di accesso condiviso

RESTORE DATABASE AdventureWorks2022
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_16_00_00.bak'
    WITH MOVE 'AdventureWorks2022_data' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.mdf',
    MOVE 'AdventureWorks2022_log' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.ldf',
    NORECOVERY, REPLACE, STATS = 5;
GO

RESTORE LOG AdventureWorks2022
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_18_00_00.trn'
    WITH RECOVERY, STOPAT = 'May 18, 2015 5:35 PM';
GO