Compartir a través de


SQL Server copia de seguridad a URL para Azure Blob Storage

Applies to: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 en una URL con identidad administrada. Revisar Con copia de seguridad a 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 URL dirigida a Azure Blob Storage, usando la sintaxis familiar de T-SQL para escribir copias de seguridad de forma segura en el almacenamiento de Azure. SQL Server 2016 (13.x) introdujo Copias de seguridad de File-Snapshot para archivos de base de datos en Azure y seguridad a través de claves de firma de acceso compartido (SAS), una manera segura y sencilla de autenticar certificados según la política 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 dentro de la 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 almacenamiento Azure 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 Azure Storage, vea About Cuentas de Azure Storage y para obtener más información sobre las firmas de acceso compartido, vea Firmas de acceso compartido, Parte 1: Descripción del modelo de 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.

almacenamiento compatible con Azure Storage y S3

SQL Server 2022 (16.x) presenta la capacidad de escribir copias de seguridad en el almacenamiento de objetos compatible con S3, con funcionalidad de copia de seguridad y restauración conceptualmente similar a trabajar con copia de seguridad en dirección URL mediante Azure Blob Storage como un tipo de dispositivo de copia de seguridad. SQL Server 2022 (16.x) amplía la sintaxis BACKUP/RESTORE TO/FROM URL agregando compatibilidad con un nuevo conector S3 mediante la API REST.

Este artículo contiene información sobre el uso de 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 URL para el almacenamiento compatible con S3, consulte SQL Server copia de seguridad en URL para el almacenamiento de objetos compatible con S3.

Copia de seguridad en Azure Storage blob en bloques frente a blob en páginas

Hay dos tipos de blobs que se pueden almacenar en Azure Blob Storage: blobs en bloques y en páginas. Para SQL Server 2016 y versiones posteriores, se prefiere el 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 versiones posteriores para realizar copias de seguridad a Azure Blob Storage. Realizar la copia de seguridad a blob en bloques en lugar de blob en páginas si está ejecutando 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 Azure SQL Managed Instance diferencias, limitaciones y problemas conocidos de T-SQL.

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 habilitados por Azure Arc

Si la instancia de SQL Server se hospeda en Linux, lo que incluye:

  • Sistema operativo independiente
  • Containers
  • SQL Managed Instance habilitado por Azure Arc
  • Cualquier otro entorno basado en Linux

La única copia de seguridad admitida en dirección URL para Azure Blob Storage es bloquear blobs mediante la firma de acceso compartido.

Azure Blob Storage (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 almacenamiento de Azure. 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 escribir una copia de seguridad de SQL Server en Azure Blob Storage, debe tener al menos el contenedor raíz creado. 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. Hay dos tipos de blobs que se pueden almacenar en Azure Blob Storage: blobs en bloques y en páginas. La copia de seguridad de SQL Server puede usar uno u otro tipo de blob en función de la sintaxis Transact-SQL usada. 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 sobre 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.

Azure Snapshot: 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. SQL Server ahora admite copias de seguridad de instantáneas de archivos de base de datos almacenados en Azure Blob Storage. Para obtener más información, vea File-Snapshot Backups for Database Files in 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 dirección URL se usa para proporcionar la ubicación y el nombre del archivo de 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 mediante HTTP en la dirección URL.

Credential: 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 utilizan credenciales para autenticarse en Azure Blob Storage y sus contenedores y objetos 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, vea Crear una firma de acceso compartido ejemplos más adelante en este artículo y para crear una credencial de SQL Server, consulte Crear una credencial ejemplos más adelante en este artículo.

Para obtener más información sobre las credenciales, consulte Credentials (Motor de base de datos).

Para obtener información sobre otros ejemplos en los que se usan las credenciales, vea Create a Agente SQL Server Proxy.

compatibilidad con el almacenamiento inmutable Azure

SQL Server 2025 (17.x) presenta compatibilidad con Azure almacenamiento inmutable, 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.

Azure almacenamiento proporciona dos tipos de inmutabilidad, nivel de contenedor y nivel de versión. Actualmente, solo se admite el almacenamiento inmutable de nivel de contenedor.

Para usar el almacenamiento inmutable con la copia de seguridad de SQL Server 2025 (17.x) en la dirección URL, siga estos pasos:

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

  2. Emita el BACKUP para realizar una copia de seguridad de la base de datos en el contenedor de almacenamiento de Azure. 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 consideraciones y requisitos de seguridad al realizar copias de seguridad o restaurar desde Azure Blob Storage.

  • Al crear un contenedor para Azure Blob Storage, se recomienda establecer el acceso a private. Si se establece el acceso a privado, se restringe el acceso a usuarios o cuentas que pueden 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 usa para autenticarse en la cuenta de Azure al realizar operaciones de copia de seguridad o restauración.

    Warning

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

  • La cuenta de usuario que se utiliza para emitir BACKUP o RESTORE comandos debe estar en el rol de base de datos db_backup operator con permisos de Alterar cualquier credencial.

Limitaciones de la copia de seguridad o restauración en Azure Blob Storage

  • SQL Server limita el tamaño máximo de copia de seguridad admitido mediante un blob en páginas a 1 TB. El tamaño máximo de copia de seguridad admitido mediante blobs en bloques se limita a aproximadamente 195,3 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 una única blob de bloques es de aproximadamente 195,3 GB, es posible que SQL Server escriba 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.

  • Las copias de seguridad del registro de transacciones omiten lo especificado por el usuario MAXTRANSFERSIZE al hacer copias de seguridad en varios archivos de respaldo. En su lugar, se usa 64 KB si se especifica más de un archivo, independientemente del MAXTRANSFERSIZE valor del comando de copia de seguridad. Por lo tanto, el tamaño máximo de una copia de seguridad del registro de transacciones en la dirección URL es de aproximadamente 195,3 GB (50 000 bloques * 4 MB MAXTRANSFERSIZE * 1 archivo O 50 000 bloques * 64 KB * 64 archivos). La compresión puede permitir que se realice una copia de seguridad de un registro de transacciones mayor, pero las relaciones de compresión variarán.

  • 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 (formerly 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 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 URL https://.blob.core.windows.net//.bak, dejando 223 caracteres para los nombres de cuenta, contenedor y blob en conjunto.

  • 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 accede 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 a través de uno de los métodos siguientes:

    • 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.
  • Almacenamiento inmutable para Azure Blob Storage no se admite antes de SQL Server 2025. Establezca la directiva de almacenamiento inmutable en false.

  • Para obtener soporte en SQL Server 2025 y versiones posteriores, consulte soporte de almacenamiento inmutable de Azure.

    • Azure almacenamiento proporciona dos tipos de inmutabilidad, nivel de contenedor y nivel de versión. Actualmente, solo se admite el almacenamiento inmutable de nivel de contenedor.
  • La copia de seguridad en URL no se admite en Premium Storage.

Argumentos y declaraciones 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 a un blob de bloques requiere una firma de acceso compartido guardada en una credencial de SQL Server. BACKUP para el blob de página requiere la clave de la cuenta de almacenamiento guardada en una credencial de SQL Server y que el argumento WITH CREDENTIAL esté especificado.
RESTORE Yes Requiere que se defina una credencial SQL Server y requiere que se especifique el argumento /< >c0 /> si la credencial de SQL Server se define mediante la clave de cuenta de almacenamiento como secreto.
RESTORE FILELISTONLY Yes Requiere que se defina una credencial SQL Server y requiere que se especifique el argumento /< >c0 /> si la credencial de SQL Server se define mediante la clave de cuenta de almacenamiento como secreto.
RESTORE HEADERONLY Yes Requiere que se defina una credencial SQL Server y requiere que se especifique el argumento /< >c0 /> si la credencial de SQL Server se define mediante la clave de cuenta de almacenamiento como secreto.
RESTORE LABELONLY Yes Requiere que se defina una credencial SQL Server y requiere que se especifique el argumento /< >c0 /> si la credencial de SQL Server se define mediante la clave de cuenta de almacenamiento como secreto.
RESTORE VERIFYONLY Yes Requiere que se defina una credencial SQL Server y requiere que se especifique el argumento /< >c0 /> si la credencial de SQL Server se define mediante la clave de 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 al usar la opción BACKUP TO URL para hacer un backup en el almacenamiento en blobs de Azure, y solo si la credencial de SQL Server se define utilizando la clave de cuenta de almacenamiento como secreto.
FILE_SNAPSHOT Yes
ENCRYPTION Yes Cuando se especifica el argumento WITH ENCRYPTION, SQL Server File-Snapshot Backup asegura que toda la base de datos haya sido cifrada con TDE antes de realizar la copia de seguridad. Si es así, el archivo de copia de seguridad de la instantánea del archivo se cifra usando 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 para optimizar el uso de los 50 000 bloques permitidos en un blob de 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 opción RESTORE FROM URL 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 a través de la tarea Copia de seguridad de SQL Server Management Studio mediante una credencial de SQL Server.

Note

Para crear una copia de seguridad de instantáneas de archivos de SQL Server o sobrescribir un conjunto de medios existente, debe usar Transact-SQL, PowerShell o C# en lugar de la tarea Copia de seguridad en SQL Server Management Studio.

En los pasos siguientes se describen los cambios realizados en la tarea de copia de seguridad de la base de datos en SQL Server Management Studio para permitir la copia de seguridad en almacenamiento de Azure.

  1. En Explorador de objetos, conéctese a una instancia del Motor de base de datos de SQL Server y expanda esa instancia.

  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 para Azure almacenamiento. Seleccione Agregar y se abrirá el cuadro de diálogo Seleccionar destino de copia de seguridad :

    1. Azure contenedor de almacenamiento: Nombre del contenedor de almacenamiento de Azure 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. Consulte el documento Connect to a Microsoft Azure Subscription (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 URL como una de las opciones de destino y otros objetos auxiliares necesarios para realizar copias de seguridad en Azure almacenamiento 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 copia de seguridad dividido en franjas, una copia de seguridad de instantáneas de archivos de SQL Server o una credencial de SQL utilizando un token de acceso compartido, debe usar Transact-SQL, PowerShell o C# en lugar de utilizar 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. En los pasos siguientes se describe el uso de la tarea Restaurar para restaurar 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. Azure contenedor de almacenamiento: Nombre completo del contenedor de almacenamiento de Azure 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. Consulte Connect to a Microsoft Azure Subscription (Backup TO URL).

    4. OK: SQL Server se conecta al almacenamiento de Azure con la información de credenciales de SQL que proporcionó y abre el cuadro de diálogo Locate 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 ejemplo siguiente se crean firmas de acceso compartido que se pueden usar 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 T-SQL necesario para crear la credencial en SQL Server.

Note

El ejemplo requiere Azure PowerShell. Para obtener información sobre cómo instalar y usar Azure PowerShell, consulte Cómo instalar y configurar Azure PowerShell. Estos scripts se comprobaron 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 correctamente el script, copie el comando CREATE CREDENTIAL en una herramienta de consulta, 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 CREATE CREDENTIAL en un editor de consultas conectado a la instancia de SQL Server y ejecute el comando .

    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