Copia de seguridad de SQL Server en la dirección URL de Microsoft Azure Blob Storage
Se aplica a:
SQL ServerAzure SQL Managed Instance
Este artículo presenta los conceptos, los requisitos y los componentes necesarios para utilizar Microsoft Azure Blob Storage como destino de copia de seguridad. La funcionalidad de copia de seguridad y restauración es igual o similar que la que usa DISK o TAPE, con algunas diferencias. En este artículo se incluyen esas diferencias y algunos ejemplos de código.
Información general
Es importante entender los componentes y la interacción entre ellos para realizar una copia de seguridad o una restauración desde Microsoft Azure Blob Storage.
El primer paso del proceso es crear una cuenta de Azure Storage en la suscripción de Azure. Esta cuenta de almacenamiento es una cuenta administrativa que tiene permisos administrativos completos en todos los contenedores y objetos creados con la cuenta de almacenamiento. SQL Server puede usar el nombre de la cuenta de almacenamiento de Azure y su valor de clave de acceso para autenticarse y escribir y leer los blobs en Microsoft Azure Blob Storage, o bien usar un token de firma de acceso compartido generado en determinados contenedores que le concede derechos de escritura y lectura. Para obtener más información sobre cuentas de almacenamiento de Azure, vea Acerca de las cuentas de almacenamiento de Azure ; para más información sobre las firmas de acceso compartido, vea Firmas de acceso compartido, Parte 1: Descripción del modelo SAS. La credencial de SQL Server almacena esta información de autenticación y se usa durante las operaciones de copia de seguridad o restauración.
Azure Storage y el almacenamiento compatible con S3
SQL Server 2012 Service Pack 1 CU2 y SQL Server 2014 introdujeron la capacidad de realizar copias de seguridad en una dirección URL con destino Azure Blob Storage mediante la conocida sintaxis de T-SQL para escribir copias de seguridad de forma segura en Azure Storage. SQL Server 2016 (13.x) introdujo copias de seguridad de instantáneas de archivos para archivos de base de datos en Azure y funciones de seguridad mediante claves de firma de acceso compartido (SAS), una manera segura y sencilla de autenticar certificados en la directiva de seguridad de Azure Storage. SQL Server 2022 (16.x) presenta la capacidad de escribir copias de seguridad en el almacenamiento de objetos compatible con S3, con la funcionalidad de copia de seguridad y restauración que, en su concepto, es similar a trabajar con la función de copia de seguridad en dirección URL mediante Azure Blob Storage como tipo de dispositivo de copia de seguridad. SQL Server 2022 (16.x) amplía la sintaxis de URL BACKUP/RESTORE TO/FROM añadiendo compatibilidad con el nuevo conector S3 con la API de REST.
Este artículo contiene información sobre el uso de la copia de seguridad en dirección URL para Azure Blob Storage. Para obtener más información sobre el uso de la copia de seguridad en URL para el almacenamiento compatible con S3, consulte Copia de seguridad y restauración de SQL Server para el almacenamiento de objetos compatible con S3.
Copia de seguridad en Azure Storage en blobs en bloques y blobs en páginas
En Microsoft Azure Blob Storage se pueden almacenar dos tipos de blobs: en bloques y en páginas. Para SQL Server 2016 y versiones posteriores, se prefiere utilizar un blob en bloques.
si se usa la clave de almacenamiento en la credencial, se usará el blob en páginas; si se usa la firma de acceso compartido, se usará el blob en bloques.
La copia de seguridad en blobs en bloques solo está disponible en SQL Server 2016 o una versión posterior que permita la copia de seguridad en Azure Blob Storage. Realice una copia de seguridad en los blobs en bloque en lugar de en los blobs en página si ejecuta SQL Server 2016 o una versión posterior.
Estos son los motivos:
- La firma de acceso compartido es una manera más segura de autorizar el acceso al blob en comparación con la clave de almacenamiento.
- Puede realizar copias de seguridad en varios blobs en bloques para obtener un mejor rendimiento de copia de seguridad y restauración y admitir copias de seguridad de base de datos más grandes.
- La opción de blob en bloques es más económica que la de blob en páginas.
- Los clientes que necesiten realizar una copia de seguridad en blobs en página a través de un servidor proxy deberán usar
backuptourl.exe.
La realización de una copia de seguridad de una base de datos grande en Azure Blob Storage está sujeta a las limitaciones enumeradas en el apartado sobre diferencias, limitaciones y problemas conocidos de T-SQL de Azure SQL Managed Instance.
Si la base de datos es demasiado grande, puede:
- Usar la compresión de copia de seguridad
- Hacer una copia de seguridad en varios blobs en bloques
Compatibilidad con Linux, contenedores y SQL Managed Instance habilitada para Azure Arc
Si la instancia de SQL Server está hospedada en Linux, lo que incluye:
- Sistema operativo independiente
- Contenedores
- Instancia administrada de SQL habilitada por Azure Arc
- Cualquier otro entorno basado en Linux
La única copia de seguridad en URL admitida es utilizar blobs en bloques, con una firma de acceso compartido.
Microsoft Azure Blob Storage
Cuenta de almacenamiento : la cuenta de almacenamiento es el punto de partida para todos los servicios de almacenamiento. Para acceder a Microsoft Azure Blob Storage, primero debe crear una cuenta de Azure Storage. Para obtener más información, vea Crear una cuenta de almacenamiento.
Contenedor : un contenedor proporciona una agrupación de un conjunto de blobs y puede almacenar un número ilimitado de blobs. Para realizar una copia de seguridad de SQL Server en Azure Blob Storage, debe haber creado un contenedor raíz como mínimo. Puede generar un token de firma de acceso compartido en un contenedor y conceder acceso a objetos en un único contenedor específico.
Blob: archivo de cualquier tipo y tamaño. Existen dos tipos de blobs que pueden almacenarse en Azure Blob Storage: blobs en páginas y en bloques. La copia de seguridad de SQL Server puede usar cualquier tipo de blob en función de la sintaxis de Transact-SQL que se use. Los blobs son direccionables mediante el siguiente formato de dirección URL: https://<cuenta de almacenamiento>.blob.core.windows.net/<contenedor>/<blob>. Para obtener más información acerca de Azure Blob Storage, consulte Introducción a Azure Blob Storage. Para obtener más información sobre los blobs en páginas y en bloques, vea Descripción de los blobs en bloques, en anexos y en páginas.
Instantánea de Azure: una instantánea de un blob de Azure realizada en un momento dado. Para obtener más información, vea Crear una instantánea de un blob. La copia de seguridad de SQL Server ahora admite copias de seguridad de instantáneas de Azure de los archivos de base de datos almacenados en Azure Blob Storage. Para obtener más información, vea Copias de seguridad de instantánea de archivos para archivos de base de datos de Azure.
Componentes de SQL Server
Dirección URL: una dirección URL especifica un identificador uniforme de recursos (URI) para un archivo de copia de seguridad único. La URL se usa para proporcionar la ubicación y el nombre del archivo de la copia de seguridad de SQL Server. La dirección URL debe apuntar a un blob real, no solo a un contenedor. Si el blob no existe, se crea. Si se especifica un blob existente, se produce un error en BACKUP, a menos que se especifique la opción "WITH FORMAT" para sobrescribir el archivo de copia de seguridad existente en el blob.
Este es un valor de dirección URL de muestra: http[s]://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak. HTTPS no es necesario, pero es recomendable.
Credencial: una credencial de SQL Server es un objeto que se usa para almacenar la información de autenticación necesaria para conectarse a un recurso fuera de SQL Server. Aquí, los procesos de copia de seguridad y restauración de SQL Server usan credenciales para autenticarse en Azure Blob Storage y en sus objetos de contenedor y blob. La credencial almacena el nombre de la cuenta de almacenamiento y los valores de clave de acceso de la cuenta de almacenamiento, o bien la dirección URL del contenedor y su token de firma de acceso compartido. Una vez creada la credencial, la sintaxis de las instrucciones BACKUP/RESTORE determina el tipo de blob y las credenciales que se requieren.
Para obtener un ejemplo sobre cómo crear una firma de acceso compartido, consulte los ejemplos de Crear una firma de acceso compartido más adelante en este artículo; para crear una credencial de SQL Server, vea los ejemplos de Creación de una credencial más adelante en este artículo.
Para obtener información general sobre las credenciales, vea Credenciales.
Para obtener información sobre otros ejemplos donde se usan credenciales, vea Crear un proxy del Agente SQL Server.
Seguridad para Azure Blob Storage
A continuación se muestran los requisitos y las consideraciones de seguridad al hacer copia de seguridad o restaurar desde Azure Blob Storage.
Al crear un contenedor para Azure Blob Storage, se recomienda establecer el acceso en privado. Al configurar el acceso privado se restringe el acceso a los usuarios o las cuentas capaces de proporcionar la información necesaria para autenticarse en la cuenta de Azure.
Importante
SQL Server requiere que se almacenen un nombre de cuenta de Azure y una autenticación de clave de acceso o una Firma de acceso compartido y un token de acceso en una credencial de SQL Server. Esta información se emplea para autenticarse en la cuenta de Azure cuando se realizan operaciones de copia de seguridad o de restauración.
Advertencia
Azure Storage admite la deshabilitación de la autorización de clave compartida para una cuenta de almacenamiento. Si se deshabilita la autorización de clave compartida, Copia de seguridad en URL de SQL Server no funcionará.
La cuenta de usuario que se usa para emitir comandos BACKUP o RESTORE debe tener el rol de base de datos operador de db_backup con permisos Modificar cualquier credencial .
Limitaciones de la copia de seguridad y restauración en Azure Blob Storage
SQL Server limita a 1 TB el tamaño máximo de copia de seguridad admitido con un blob en páginas. El tamaño máximo de copia de seguridad admitido con blobs en bloques está limitado a aproximadamente 200 GB (50 000 bloques * 4 MB MAXTRANSFERSIZE). Los blobs en bloques son compatibles con la creación de franjas para admitir tamaños de copia de seguridad sustancialmente más grandes; el límite es un máximo de 64 URL, lo que da como resultado la siguiente fórmula:
64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB.Importante
Aunque el tamaño máximo de copia de seguridad admitido por cada blob en bloques sea de 200 GB, SQL Server puede escribir en tamaños de bloque más pequeños, lo que puede provocar que SQL Server alcance el límite de 50 000 bloques antes de que se transfiera toda la copia de seguridad. Divida las copias de seguridad en secciones (aunque tengan menos de 200 GB) para evitar el límite de bloques, especialmente cuando use copias de seguridad diferenciales o descomprimidas.
Puedes emitir una copia de seguridad o restaurar instrucciones mediante Transact-SQL, SMO, cmdlets de PowerShell o el Asistente para copia de seguridad o restauración de SQL Server Management Studio.
La copia de seguridad en la cuenta de Azure Storage solo admite la autenticación con tokens de firma de acceso compartido (SAS) o claves de cuenta de almacenamiento. El resto de métodos de autenticación, incluida la autenticación con Microsoft Entra ID (anteriormente, Azure Active Directory), no son compatibles.
No se admite la creación de un nombre de dispositivo lógico. Por tanto, no se admite agregar URL como dispositivo de copia de seguridad mediante sp_dumpdevice o mediante SQL Server Management Studio.
No se admite anexar a blobs de copia de seguridad existentes. Las copias de seguridad en un blob existente solo se pueden sobrescribir mediante la opción WITH FORMAT . Pero cuando se usan copias de seguridad de instantánea de archivos (con el argumento WITH FILE_SNAPSHOT ), no se permite usar el argumento WITH FORMAT para evitar que queden huérfanas las instantáneas de archivos creadas con la copia de seguridad de instantánea de archivos original.
La copia de seguridad en varios blobs en una sola operación de copia de seguridad solo es compatible con blobs en bloques y utilizando un token de firma de acceso compartido (SAS) en lugar de la clave de la cuenta de almacenamiento para la credencial SQL.
No se puede especificar BLOCKSIZE en los blobs en páginas.
No se puede especificar MAXTRANSFERSIZE en los blobs en páginas.
No se pueden especificar las opciones de conjunto de copia de seguridad RETAINDAYS y EXPIREDATE .
SQL Server tiene un límite máximo de 259 caracteres para un nombre de dispositivo de copia de seguridad. BACKUP TO URL consume 36 caracteres para los elementos necesarios que se usan para especificar la dirección URL: "https://.blob.core.windows.net//.bak", y deja 223 caracteres para la cuenta, el contenedor y los nombres de blob.
Las versiones de SQL Server anteriores a 2022 tienen un límite de 256 caracteres para los tokens de Firma de acceso compartido (SAS), que limitarán el tipo de tokens que se pueden usar (por ejemplo, no se admiten tokens de clave de delegación de usuarios).
Si el servidor tiene acceso a Azure a través de un servidor proxy, debe usar la marca de seguimiento 1819 y, a continuación, establecer la configuración del proxy WinHTTP mediante alguno de los métodos siguientes:
- La utilidad proxycfg.exe en Windows XP o Windows Server 2003 y versiones anteriores.
- La utilidad netsh.exe en Windows Vista y Windows Server 2008 o versiones posteriores.
No se admite el almacenamiento inmutable para Azure Blob Storage. Establezca la directiva Almacenamiento inmutable en "false".
Instrucciones y argumentos admitidos en Azure Blob Storage
Compatibilidad con instrucciones de copia de seguridad y restauración en Azure Blob Storage
| Instrucción BACKUP/RESTORE | Compatible | Excepciones | Comentarios |
|---|---|---|---|
| BACKUP | Y | BLOCKSIZE y MAXTRANSFERSIZE admiten los blobs en bloques, pero no admiten los blobs en páginas. | La instrucción BACKUP en un blob en bloques requiere que se guarde una firma de acceso compartido en una credencial de SQL Server. La instrucción BACKUP en un blob en páginas requiere que se guarde la clave de cuenta de almacenamiento en una credencial de SQL Server y que se especifique el argumento WITH CREDENTIAL. |
| RESTORE | Y | Requiere que se defina una credencial de SQL Server y que se especifique el argumento WITH CREDENTIAL si la credencial de SQL Server se define utilizando la clave de la cuenta de almacenamiento como el secreto. | |
| RESTORE FILELISTONLY | Y | Requiere que se defina una credencial de SQL Server y que se especifique el argumento WITH CREDENTIAL si la credencial de SQL Server se define utilizando la clave de la cuenta de almacenamiento como el secreto. | |
| RESTORE HEADERONLY | Y | Requiere que se defina una credencial de SQL Server y que se especifique el argumento WITH CREDENTIAL si la credencial de SQL Server se define utilizando la clave de la cuenta de almacenamiento como el secreto. | |
| RESTORE LABELONLY | Y | Requiere que se defina una credencial de SQL Server y que se especifique el argumento WITH CREDENTIAL si la credencial de SQL Server se define utilizando la clave de la cuenta de almacenamiento como el secreto. | |
| RESTORE VERIFYONLY | Y | Requiere que se defina una credencial de SQL Server y que se especifique el argumento WITH CREDENTIAL si la credencial de SQL Server se define utilizando la clave de la cuenta de almacenamiento como el secreto. | |
| RESTORE REWINDONLY | - |
Para conocer la sintaxis y obtener información general sobre las instrucciones de copia de seguridad, vea BACKUP (Transact-SQL).
Para conocer la sintaxis y obtener información general sobre las instrucciones de restauración, vea RESTORE (Transact-SQL).
Compatibilidad con argumentos de copia de seguridad en Azure Blob Storage
| Argument | Compatible | Exception | Comentarios |
|---|---|---|---|
| DATABASE | Y | ||
| REGISTRO | Y | ||
| TO (URL) | Y | A diferencia de DISK y TAPE, URL no admite especificar o crear un nombre lógico. | Este argumento se emplea para especificar la ruta de acceso de la dirección URL del archivo de copia de seguridad. |
| MIRROR TO | Y | ||
| OPCIONES DE WITH: | |||
| CREDENTIAL | Y | WITH CREDENTIAL solo se admite cuando se usa la opción BACKUP TO URL para hacer una copia de seguridad en Azure Blob Storage, y solo cuando la credencial SQL Server se define con la clave de la cuenta de almacenamiento como el secreto | |
| FILE_SNAPSHOT | Y | ||
| ENCRYPTION | Y | Cuando se especifica el argumento WITH ENCRYPTION, la copia de seguridad de instantánea de archivos de SQL Server se asegura de que toda la base de datos tenga cifrado TDE antes de realizar la copia de seguridad y, si es así, cifra el archivo de copia de seguridad de instantánea de archivos mediante el algoritmo especificado para TDE en la base de datos. Si no están cifrados la totalidad de los datos de la base de datos, se producirá un error en la copia de seguridad (por ejemplo, proceso de cifrado sin finalizar). | |
| DIFFERENTIAL | Y | ||
| COPY_ONLY | Y | ||
| COMPRESSION|NO_COMPRESSION | Y | No compatible con la copia de seguridad de instantánea de archivos | |
| DESCRIPCIÓN | Y | ||
| NOMBRE | Y | ||
| EXPIREDATE | RETAINDAYS | - | ||
| NOINIT | INIT | - | No es posible anexar a blobs. Para sobrescribir una copia de seguridad, use el argumento WITH FORMAT. Pero cuando se usan copias de seguridad de instantánea de archivos (con el argumento WITH FILE_SNAPSHOT ), no se permite usar el argumento WITH FORMAT para evitar que queden huérfanas las instantáneas de archivos creadas con la copia de seguridad original. | |
| NOSKIP | SKIP | - | ||
| NOFORMAT | FORMAT | Y | Una copia de seguridad realizada en un blob existente producirá un error a menos que se especifique WITH FORMAT . El blob existente se sobrescribe si se especifica WITH FORMAT . Pero cuando se usan copias de seguridad de instantánea de archivos (con el argumento WITH FILE_SNAPSHOT ), no se permite usar el argumento FORMAT para evitar que queden huérfanas las instantáneas de archivos creadas con la copia de seguridad de instantánea de archivos original. Pero cuando se usan copias de seguridad de instantánea de archivos (con el argumento WITH FILE_SNAPSHOT ), no se permite usar el argumento WITH FORMAT para evitar que queden huérfanas las instantáneas de archivos creadas con la copia de seguridad original. | |
| MEDIADESCRIPTION | Y | ||
| MEDIANAME | Y | ||
| BLOCKSIZE | Y | No se admite para los blobs en páginas. Se admite para blob en bloques. | Se recomienda BLOCKSIZE=65536 para optimizar el uso de los 50.000 bloques permitidos en un blob en bloques. |
| BUFFERCOUNT | Y | ||
| MAXTRANSFERSIZE | Y | No se admite para los blobs en páginas. Se admite para blob en bloques. | El valor predeterminado es el 1048576. El valor puede llegar a los 4 MB en incrementos de 65.536 bytes. Se recomienda MAXTRANSFERSIZE=4194304 para optimizar el uso de los 50.000 bloques permitidos en un blob en bloques. |
| NO_CHECKSUM | CHECKSUM | Y | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | Y | ||
| STATS | Y | ||
| REWIND | NOREWIND | - | ||
| UNLOAD | NOUNLOAD | - | ||
| NORECOVERY | STANDBY | Y | ||
| NO_TRUNCATE | Y |
Para obtener más información sobre los argumentos de copia de seguridad, vea BACKUP (Transact-SQL).
Compatibilidad con argumentos de restauración en Azure Blob Storage
| Argument | Compatible | Excepciones | Comentarios |
|---|---|---|---|
| DATABASE | Y | ||
| REGISTRO | Y | ||
| FROM (URL) | Y | El argumento FROM URL se emplea para especificar la ruta de acceso de la dirección URL del archivo de copia de seguridad. | |
| WITH Options: | |||
| CREDENTIAL | Y | WITH CREDENTIAL solo se admite cuando se usa la opción RESTORE FROM URL para restaurar desde Microsoft Azure Blob Storage. | |
| PARTIAL | Y | ||
| RECOVERY | NORECOVERY | STANDBY | Y | ||
| LOADHISTORY | Y | ||
| MOVE | Y | ||
| REPLACE | Y | ||
| RESTART | Y | ||
| RESTRICTED_USER | Y | ||
| ARCHIVO | - | ||
| PASSWORD | Y | ||
| MEDIANAME | Y | ||
| MEDIAPASSWORD | Y | ||
| BLOCKSIZE | Y | ||
| BUFFERCOUNT | - | ||
| MAXTRANSFERSIZE | - | ||
| CHECKSUM | NO_CHECKSUM | Y | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | Y | ||
| FILESTREAM | Y | No compatible con la copia de seguridad de instantánea | |
| STATS | Y | ||
| REWIND | NOREWIND | - | ||
| UNLOAD | NOUNLOAD | - | ||
| KEEP_REPLICATION | Y | ||
| KEEP_CDC | Y | ||
| ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER | Y | ||
| STOPAT | STOPATMARK | STOPBEFOREMARK | Y |
Para obtener más información sobre los argumentos de restauración, vea Argumentos RESTORE (Transact-SQL).
Copia de seguridad con SSMS
Puede realizar una copia de seguridad de una base de datos en una dirección URL mediante la tarea Copia de seguridad en SQL Server Management Studio con una credencial de SQL Server.
Nota:
Para crear una copia de seguridad de instantánea de archivos de SQL Server o sobrescribir un conjunto de medios existente, use Transact-SQL, PowerShell o C# en lugar de la tarea Copia de seguridad en SQL Server Management Studio.
En los siguientes pasos se describen los cambios realizados en la tarea Copia de seguridad de la base de datos en SQL Server Management Studio para permitir realizar la copia de seguridad en Azure Storage:
En el Explorador de objetos, conéctese a una instancia del Motor de base de datos de SQL Server y expándala.
Expanda Bases de datos, haga clic con el botón derecho en la base de datos que quiera, seleccione Tareas y seleccione Copia de seguridad...
En la página General de la sección Destino , la opción Dirección URL está disponible en la lista desplegable Copia de seguridad en: . La opción Dirección URL se usa para crear una copia de seguridad para el almacenamiento de Microsoft Azure. Seleccione Agregar y se abrirá el cuadro de diálogo Seleccionar destino de la copia de seguridad:
Contenedor de almacenamiento de Azure : nombre del contenedor de almacenamiento de Microsoft Azure para almacenar los archivos de copia de seguridad. Seleccione un contenedor existente en la lista desplegable o especifique manualmente el contenedor.
Directiva de acceso compartido: especifique la firma de acceso compartido para un contenedor especificado manualmente. Este campo no está disponible si se ha elegido un contenedor existente.
Archivo de copia de seguridad: nombre del archivo de copia de seguridad.
Nuevo contenedor: se usa para registrar un contenedor existente para el que no tiene una firma de acceso compartido. Vea Connect to a Microsoft Azure Subscription (Conectarse a una suscripción de Microsoft Azure).
Nota:
Agregar admite varios contenedores de almacenamiento y archivos de copia de seguridad para un conjunto de medios.
Al seleccionar Dirección URL como destino, ciertas opciones de la página Opciones multimedia están deshabilitadas. Los artículos siguientes tienen más información acerca del cuadro de diálogo Copia de seguridad de la base de datos:
Copia de seguridad de la base de datos (página Opciones multimedia)
Copia de seguridad de la base de datos (página Opciones de copia de seguridad)
Copia de seguridad con el plan de mantenimiento
De manera similar a la tarea de copia de seguridad descrita anteriormente, el Asistente para el plan de mantenimiento en SQL Server Management Studio incluye la URL como una de las opciones de destino y otros objetos de soporte necesarios para realizar una copia de seguridad en Azure Storage, como la credencial SQL. Para obtener más información, consulte la sección Definir las tareas Copia de seguridad en Using Maintenance Plan Wizard.
Nota:
Para crear un conjunto de copia de seguridad seccionada, una copia de seguridad de instantánea de archivos de SQL Server o una credencial SQL con el token de acceso compartido, use Transact-SQL, PowerShell o C# en lugar de la tarea Copia de seguridad en el Asistente para planes de mantenimiento.
Restaurar con SSMS
La tarea Restaurar base de datos incluye Dirección URL como dispositivo desde el que se puede restaurar. Los pasos siguientes describen el uso de la tarea Restaurar para realizar una operación de restauración desde Azure Blob Storage:
Haga clic con el botón derecho en Bases de datos y seleccione Restaurar base de datos...
En la página General , seleccione Dispositivo en la sección Origen.
Seleccione el botón de exploración (...) para abrir el cuadro de diálogo Seleccionar dispositivos de copia de seguridad.
Seleccione Dirección URL en la lista desplegable Tipo de medio de copia de seguridad: . Seleccione Agregar para abrir el cuadro de diálogo Seleccionar ubicación de archivo de copia de seguridad .
Contenedor de Azure Storage: nombre completo del contenedor de Microsoft Azure Storage que contiene los archivos de copia de seguridad. Seleccione un contenedor existente en la lista desplegable o especifique manualmente el nombre completo del contenedor.
Firma de acceso compartido: se usa para especificar la firma de acceso compartido del contenedor designado.
Agregar: se usa para registrar un contenedor existente para el que no tiene una firma de acceso compartido. Vea Connect to a Microsoft Azure Subscription (Conectarse a una suscripción de Microsoft Azure).
Aceptar: SQL Server se conecta al almacenamiento de Microsoft Azure con la información de la credencial SQL proporcionada y abre el cuadro de diálogo Buscar archivo de copia de seguridad en Microsoft Azure. Los archivos de copia de seguridad que residen en el contenedor de almacenamiento se muestran en esta página. Seleccione el archivo que desee usar para restaurar y seleccione Aceptar. Esto le llevará de vuelta al cuadro de diálogo Seleccionar dispositivos de copia de seguridad y, al seleccionar Aceptar en este cuadro de diálogo, vuelve al cuadro de diálogo principal Restaurar donde podrá completar la restauración.
Restaurar la base de datos (página General)
Ejemplos de código
Esta sección contiene los siguientes ejemplos.
Nota:
Puede ver un tutorial sobre el uso de SQL Server 2016 con Azure Blob Storage en Tutorial: Usar Azure Blob Storage con bases de datos de SQL Server 2016
Creación de una firma de acceso compartido
En el siguiente ejemplo se crean firmas de acceso compartido que pueden usarse para crear una credencial de SQL Server en un contenedor recién creado. El script crea una firma de acceso compartido que está asociada a una directiva de acceso almacenada. Para obtener más información, consulte Firmas de acceso compartido, Parte 1: Descripción del modelo SAS. El script también escribe el comando de T-SQL necesario para crear la credencial en SQL Server.
Nota:
Este ejemplo requiere Microsoft Azure PowerShell. Para obtener información sobre la instalación y el uso de Azure PowerShell, vea Cómo instalar y configurar Azure PowerShell.
Estos scripts se verificaron con Azure PowerShell 5.1.15063.
Firma de acceso compartido que está asociada a una directiva de acceso almacenada
# 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
Después de ejecutar el script correctamente, copie el comando CREATE CREDENTIAL en una herramienta de consultas, conéctese a una instancia de SQL Server y ejecute el comando para crear la credencial con la Firma de acceso compartido.
Crear una credencial
En los ejemplos siguientes se crean credenciales de SQL Server para la autenticación en Azure Blob Storage. Realice una de las acciones siguientes.
Uso de la firma de acceso compartido
Si ejecutó el script anterior para crear la Firma de acceso compartido, copie el comando
CREATE CREDENTIALa un editor de consultas conectado a la instancia de SQL Server y ejecútelo.El siguiente código T-SQL es un ejemplo que crea la credencial para usar una firma de acceso compartido.
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>';Uso de la identidad y la clave de acceso de la cuenta de almacenamiento
IF NOT EXISTS (SELECT * FROM sys.credentials WHERE name = '<mycredentialname>') CREATE CREDENTIAL [<mycredentialname>] WITH IDENTITY = '<mystorageaccountname>' ,SECRET = '<mystorageaccountaccesskey>';
Realizar una copia de seguridad completa de la base de datos
En los ejemplos siguientes se realiza una copia de seguridad completa de la base de datos AdventureWorks2022 en Azure Blob Storage. Use una de las siguientes muestras:
En URL con una firma de acceso compartido
BACKUP DATABASE AdventureWorks2022 TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'; GOEn URL con la identidad y la clave de acceso de la cuenta de almacenamiento
BACKUP DATABASE AdventureWorks2022 TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak' WITH CREDENTIAL = '<mycredentialname>' ,COMPRESSION ,STATS = 5; GO
Restauración a un momento dado con STOPAT
En el ejemplo siguiente se restaura la base de datos AdventureWorks2022 de muestra al estado que tenía en un momento dado y se muestra una operación de restauración.
Desde URL con una firma de acceso compartido
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
Contenido relacionado
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de