Compartir a través de

Copia de seguridad de SQL Server en la dirección URL de Azure Blob Storage

Se aplica a:SQL ServerAzure SQL Managed Instance

En este artículo se presentan los conceptos, los requisitos y los componentes necesarios para usar Azure Blob Storage como destino de copia de seguridad. La funcionalidad de copia de seguridad y restauración es igual o similar a cuando se usa DISK o TAPE, con algunas diferencias. En este artículo se incluyen esas diferencias y algunos ejemplos de código.

Tip

A partir de SQL Server 2025 (17.x), puede realizar una copia de seguridad de la dirección URL con identidad administrada. Revise Realizar una copia de seguridad en URL con identidad administrada (versión preliminar): SQL Server habilitado por Azure Arc.

Overview

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 File-Snapshot Backups for Database Files en Azure y la 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.

Es importante comprender los componentes y la interacción entre ellos para realizar una copia de seguridad o restaurar desde Azure Blob Storage.

La creación de una cuenta de Azure Storage en su suscripción de Azure es el primer paso de este proceso. 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 Azure Storage y su valor de clave de acceso para autenticar y escribir y leer blobs en Azure Blob Storage, o usar un token de firma de acceso compartido generado en contenedores específicos que le concedan derechos de lectura y escritura. 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 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 BACKUP/RESTORE TO/FROM URL sintaxis agregando compatibilidad con un nuevo conector S3 mediante la API 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 Copia de seguridad en dirección URL para el almacenamiento compatible con S3, consulte Copia de seguridad de SQL Server en dirección URL para el almacenamiento de objetos compatible con S3.

Copia de seguridad en Azure Storage en blobs en bloques y blobs en páginas

Existen dos tipos de blobs que pueden almacenarse en Azure Blob Storage: blobs en páginas y en bloques. 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 usa el blob en páginas; si se usa la firma de acceso compartido, se usa 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 vez de en los blobs en página si ejecuta SQL Server 2016 o 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.
  • El blob en bloques es más barato que el 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
  • Containers
  • Instancia administrada de SQL habilitada por Azure Arc
  • Cualquier otro entorno basado en Linux

La única copia de seguridad en URL para Azure Blob Storage admitida es utilizar blobs en bloques, con una firma de acceso compartido.

Azure Blob Storage (Servicio de almacenamiento de blobs de Azure)

Cuenta de almacenamiento: La cuenta de almacenamiento es el punto de partida para todos los servicios de almacenamiento. Para acceder a Azure Blob Storage, cree primero 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: Un 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.

Diagrama de cuentas, contenedores y blobs de Azure Blob Storage.

Instantánea de Azure: Instantánea de un blob de Azure tomado 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

URL: Una dirección URL especifica un identificador uniforme de recursos (URI) en 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, BACKUP se produce un error, a menos que se especifique la WITH FORMAT opción para sobrescribir el archivo de copia de seguridad existente en el blob.

Este es un valor de dirección URL de ejemplo: https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak.

Note

No se admite la copia de seguridad en la dirección URL mediante HTTP.

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 BACKUP/RESTORE instrucciones determina el tipo de blob y la credencial necesaria.

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 más información sobre las credenciales, consulte Credenciales (motor de base de datos).

Para obtener información sobre otros ejemplos donde se usan credenciales, vea Crear un proxy del Agente SQL Server.

Compatibilidad con el almacenamiento inmutable de Azure

SQL Server 2025 (17.x) presenta compatibilidad con el almacenamiento inmutable de Azure, que protege contra ataques de ransomware. Los archivos escritos en el almacenamiento inmutable no se pueden modificar ni eliminar, tal como se define mediante la inmutabilidad.

Normalmente, las copias de seguridad de SQL Server se crean en dos pasos. Inicialmente, el .bak archivo de copia de seguridad se crea con ceros y, a continuación, el archivo se actualiza con datos. Dado que no se permite la modificación de archivos en el almacenamiento inmutable una vez escrito y confirmado el archivo, el proceso de copia de seguridad ahora omite el paso inicial para crear el archivo de copia de seguridad con ceros. En su lugar, toda la copia de seguridad se crea en un solo paso cuando se escribe en blobs de bloques.

Para usar el almacenamiento inmutable con SQL Server 2025 (17.x) para respaldo a URL, siga estos pasos:

  1. Configure la inmutabilidad del contenedor de almacenamiento de Azure.

  2. Emita backup para realizar una copia de seguridad de la base de datos en el contenedor de Azure Storage. Si usa la opción WITH FORMAT en el almacenamiento inmutable y ya existe una copia de seguridad con el mismo nombre, recibirá un error y la copia de seguridad fallará.

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

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

    Important

    SQL Server requiere que un nombre de cuenta de Azure y la autenticación de clave de acceso, o bien una firma de acceso compartido y un token de acceso, se almacenen 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.

    Warning

    Azure Storage admite la deshabilitación de la autorización de clave compartida para una cuenta de almacenamiento. Si la autorización de clave compartida está deshabilitada, la copia de seguridad de SQL Server en la dirección URL no funcionará.

  • La cuenta de usuario que se usa para emitir BACKUP comandos o RESTORE debe estar en el rol de base de datos de operador db_backup con permisos de modificación de credenciales .

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 mediante blobs en bloques se limita 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.

    Important

    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.

  • Puede emitir instrucciones de copia de seguridad o restauración mediante transact-SQL, SMO, cmdlets de PowerShell o el Asistente para copia de seguridad o restauración de SQL Server Management Studio.

  • Al realizar una copia de seguridad en una cuenta de Azure Storage, SQL Server solo admite la autenticación con tokens de firma de acceso compartido (SAS) o claves de cuenta de almacenamiento. No se admiten todos los demás métodos de autenticación, incluida la autenticación con microsoft Entra ID (anteriormente Azure Active Directory).

  • No se admite la creación de un nombre de dispositivo lógico. Por lo tanto, no se admite la adición de direcciones URL como un dispositivo de copia de seguridad mediante sp_dumpdevice o a través de 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. Sin embargo, al usar copias de seguridad de instantáneas de archivos (mediante el argumento WITH FILE_SNAPSHOT), no se permite el uso del argumento WITH FORMAT para evitar que queden instantáneas de archivos huérfanas creadas con la copia de seguridad de instantáneas 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 admite especificar BLOCKSIZE para blobs de página.

  • No se admite especificar MAXTRANSFERSIZE para blobs de página.

  • Especificar las opciones del conjunto de copia de seguridad: RETAINDAYS y EXPIREDATE no se admiten.

  • 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 URLhttps://.blob.core.windows.net//.bak, dejando 223 caracteres para los nombres de cuenta, contenedor y blob juntos.

  • SQL Server 2019 (15.x) y versiones anteriores tienen un límite de 256 caracteres para tokens de firma de acceso compartido (SAS), que limita 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 posterior.

  • No se admite el almacenamiento inmutable para Azure Blob Storage. Establezca la directiva de almacenamiento inmutable en false.

  • La copia de seguridad en la dirección URL no se admite en Premium Storage.

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 Supported Exceptions Comments
BACKUP Yes BLOCKSIZE y MAXTRANSFERSIZE son compatibles con blobs en bloques. No se admiten para los blobs en páginas. BACKUP para un blob en bloques requiere una firma de acceso compartido guardada en una credencial de SQL Server. BACKUP para el blob en páginas requiere la clave de cuenta de almacenamiento guardada en una credencial de SQL Server y requiere que se especifique el WITH CREDENTIAL argumento .
RESTORE Yes Requiere que se defina una credencial de SQL Server y requiere que se especifique el WITH CREDENTIAL argumento si la credencial de SQL Server se define mediante la clave de la cuenta de almacenamiento como secreto.
RESTORE FILELISTONLY Yes Requiere que se defina una credencial de SQL Server y requiere que se especifique el WITH CREDENTIAL argumento si la credencial de SQL Server se define mediante la clave de la cuenta de almacenamiento como secreto.
RESTORE HEADERONLY Yes Requiere que se defina una credencial de SQL Server y requiere que se especifique el WITH CREDENTIAL argumento si la credencial de SQL Server se define mediante la clave de la cuenta de almacenamiento como secreto.
RESTORE LABELONLY Yes Requiere que se defina una credencial de SQL Server y requiere que se especifique el WITH CREDENTIAL argumento si la credencial de SQL Server se define mediante la clave de la cuenta de almacenamiento como secreto.
RESTORE VERIFYONLY Yes Requiere que se defina una credencial de SQL Server y requiere que se especifique el WITH CREDENTIAL argumento si la credencial de SQL Server se define mediante la clave de la cuenta de almacenamiento como secreto.
RESTORE REWINDONLY No

Para obtener información general sobre la sintaxis y las instrucciones de copia de seguridad, consulte BACKUP.

Para obtener información general y sintaxis sobre las instrucciones de restauración, vea Restore Statements.

Compatibilidad con argumentos de copia de seguridad en Azure Blob Storage

Argument Supported Exception Comments
DATABASE Yes
LOG Yes
TO (URL) Yes A diferencia DISK de y TAPE, la dirección URL no admite especificar ni 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 Yes
WITH Opciones:
CREDENTIAL Yes WITH CREDENTIAL solo se admite cuando se usa BACKUP TO URL la opción para realizar una copia de seguridad en Azure Blob Storage y solo si la credencial de SQL Server se define mediante la clave de cuenta de almacenamiento como secreto.
FILE_SNAPSHOT Yes
ENCRYPTION Yes Cuando se especifica el WITH ENCRYPTION argumento, SQL Server File-Snapshot Backup garantiza que toda la base de datos se cifró con TDE antes de realizar la copia de seguridad y, si es así, cifra el propio archivo de copia de seguridad de instantáneas de archivos mediante el algoritmo especificado para TDE en la base de datos. Si no se cifran todos los datos de la base de datos completa, se produce un error en la copia de seguridad (por ejemplo, el proceso de cifrado aún no se ha completado).
DIFFERENTIAL Yes
COPY_ONLY Yes
COMPRESSION|NO_COMPRESSION Yes No compatible con la copia de seguridad de instantánea de archivos
DESCRIPTION Yes
NAME Yes
EXPIREDATE | RETAINDAYS No
NOINIT | INIT No No es posible anexar a blobs. Para sobrescribir una copia de seguridad, use el WITH FORMAT argumento . Sin embargo, al usar copias de seguridad de instantáneas de archivos (mediante el argumento WITH FILE_SNAPSHOT), no se permite que el argumento WITH FORMAT evite dejar instantáneas de archivo huérfanas creadas con la copia de seguridad original.
NOSKIP | SKIP No
NOFORMAT | FORMAT Yes Se produce un error en una copia de seguridad realizada en un blob existente a menos que WITH FORMAT se especifique. El blob existente se sobrescribe cuando se especifica WITH FORMAT. Sin embargo, al usar copias de seguridad de instantáneas de archivos (mediante el argumento WITH FILE_SNAPSHOT), no se permite el uso del argumento FORMAT para evitar que queden instantáneas de archivos huérfanas creadas con la copia de seguridad de instantáneas de archivos original. Sin embargo, al usar copias de seguridad de instantáneas de archivos (mediante el argumento WITH FILE_SNAPSHOT), no se permite que el argumento WITH FORMAT evite dejar instantáneas de archivo huérfanas creadas con la copia de seguridad original.
MEDIADESCRIPTION Yes
MEDIANAME Yes
BLOCKSIZE Yes No se admite para los blobs en páginas. Se admite para blob en bloques. Se recomienda BLOCKSIZE=65536 optimizar el uso de los 50 000 bloques permitidos en un blob en bloques.
BUFFERCOUNT Yes
MAXTRANSFERSIZE Yes No se admite para los blobs en páginas. Se admite para blob en bloques. El valor predeterminado es 1048576. El valor puede oscilar hasta 4 MB en incrementos de 65 536 bytes.

Se recomienda MAXTRANSFERSIZE=4194304 optimizar el uso de los 50 000 bloques permitidos en un blob en bloques.
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

Para obtener más información sobre los argumentos de copia de seguridad, consulte BACKUP.

Compatibilidad con argumentos de restauración en Azure Blob Storage

Argument Supported Exceptions Comments
DATABASE Yes
LOG Yes
FROM (URL) Yes El FROM URL argumento se usa para especificar la ruta de acceso url del archivo de copia de seguridad.
WITH Opciones:
CREDENTIAL Yes WITH CREDENTIAL solo se admite cuando se usa la RESTORE FROM URL opción para restaurar desde Azure Blob Storage.
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 No compatible con la copia de seguridad de instantánea
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

Para obtener más información sobre los argumentos de Restauración, vea Instrucciones RESTORE: Argumentos.

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.

Note

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:

  1. En el Explorador de objetos, conéctese a una instancia del Motor de base de datos de SQL Server y expándala.

  2. Expanda Bases de datos, haga clic con el botón derecho en la base de datos deseada, seleccione Tareas y, a continuación, seleccione Copia de seguridad....

  3. En la página General de la sección Destino , la opción URL está disponible en la lista desplegable Hacer copia de seguridad en: . La opción URL se usa para crear una copia de seguridad en Azure Storage. Seleccione Agregar y se abrirá el cuadro de diálogo Seleccionar destino de copia de seguridad :

    1. Contenedor de Azure Storage: Nombre del contenedor de Azure Storage para almacenar los archivos de copia de seguridad. Seleccione un contenedor existente en la lista desplegable o escriba manualmente el contenedor.

    2. Directiva de acceso compartido: Escriba la firma de acceso compartido para un contenedor especificado manualmente. Este campo no está disponible si se eligió un contenedor existente.

    3. Archivo de copia de seguridad: Nombre del archivo de copia de seguridad.

    4. Nuevo contenedor: Se usa para registrar un contenedor existente para el que no tiene una firma de acceso compartido. Vea Conectarse a una suscripción de Microsoft Azure (Backup TO URL).

Note

Agregar admite varios archivos de copia de seguridad y contenedores de almacenamiento para un único conjunto de medios.

Al seleccionar la dirección URL como destino, algunas 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 con el plan de mantenimiento

De forma similar a la tarea de copia de seguridad descrita anteriormente, el Asistente para planes de mantenimiento de SQL Server Management Studio incluye la dirección URL como una de las opciones de destino y otros objetos auxiliares necesarios para realizar copias de seguridad en Azure Storage, como la credencial de SQL. Para obtener más información, consulte la sección Definir las tareas Copia de seguridad en Using Maintenance Plan Wizard.

Note

Para crear un conjunto de copias de seguridad a franjas, una copia de seguridad de instantáneas de archivos de SQL Server o una credencial de SQL usando un token de acceso compartido, debe utilizar Transact-SQL, PowerShell o C# en lugar de la tarea de Copia de seguridad en el Asistente para planes de mantenimiento.

Restaurar con SSMS

La tarea Restaurar base de datos incluye la dirección URL como un dispositivo desde el que restaurar. Los pasos siguientes describen el uso de la tarea Restaurar para realizar una operación de restauración desde Azure Blob Storage:

  1. Haga clic con el botón derecho en Bases de datos y seleccione Restaurar base de datos....

  2. En la página General , seleccione Dispositivo en la sección Origen .

  3. Seleccione el botón de exploración (...) para abrir el cuadro de diálogo Seleccionar dispositivos de copia de seguridad.

  4. Seleccione URL en la lista desplegable Tipo de medio de copia de seguridad: . Seleccione Agregar para abrir el cuadro de diálogo Seleccionar una ubicación de archivo de copia de seguridad .

    1. Contenedor de Azure Storage: Nombre completo del contenedor de Azure Storage que contiene los archivos de copia de seguridad. Seleccione un contenedor existente en la lista desplegable o escriba manualmente el nombre completo del contenedor.

    2. Firma de acceso compartido: Se usa para escribir la firma de acceso compartido para el contenedor designado.

    3. Agregar: Se usa para registrar un contenedor existente para el que no tiene una firma de acceso compartido. Vea Conectarse a una suscripción de Microsoft Azure (Backup TO URL).

    4. DE ACUERDO: SQL Server se conecta a Azure Storage mediante la información de credenciales de SQL que proporcionó 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 desea usar para restaurar y seleccione Aceptar. Esto le lleva al cuadro de diálogo Seleccionar dispositivos de copia de seguridad y al seleccionar Aceptar en este cuadro de diálogo, volverá al cuadro de diálogo Restauración principal, donde podrá completar la restauración.

Ejemplos de código

Esta sección contiene los siguientes ejemplos.

Note

Para ver un tutorial sobre el uso de SQL Server 2016 con Azure Blob Storage, consulte Tutorial: Uso de Azure Blob Storage con SQL Server

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.

Note

En el ejemplo se requiere Azure PowerShell. Para obtener información sobre cómo instalar y usar Azure PowerShell, consulte Instalación y configuración de 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.

  1. Uso de la firma de acceso compartido

    Si ejecutó el script anterior para crear la Firma de acceso compartido, copie el comando CREATE CREDENTIAL a 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>';

  2. 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 AdventureWorks2025 en Azure Blob Storage. Use una de las siguientes muestras:

  1. En URL con una firma de acceso compartido

    BACKUP DATABASE AdventureWorks2022
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak';
GO

  2. En 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 AdventureWorks2025 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

  • Last updated on