Restauración de una base de datos desde una copia de seguridad en Azure SQL Managed Instance
Se aplica a: 
Azure SQL Managed Instance
En este artículo se proporcionan pasos para recuperar una base de datos de una copia de seguridad en Azure SQL Managed Instance. Para Azure SQL Database, consulte Restauración de una base de datos a partir de una copia de seguridad en Azure SQL Database.
Información general
Las copias de seguridad automáticas protegen las bases de datos de los errores de usuario y de aplicación, de la eliminación accidental de la base de datos y de las interrupciones prolongadas. Esta funcionalidad integrada está disponible para todos los niveles de servicio y tamaños de proceso. Las siguientes opciones están disponibles para la recuperación de bases de datos mediante copias de seguridad automatizadas:
- Creación de una nueva base de datos en la misma instancia administrada, restaurada a un momento dado durante el período de retención.
- Creación de una nueva base de datos en la misma instancia administrada o una diferente, restaurada a un momento dado durante el período de retención.
- Creación de una base de datos en la misma instancia administrada o una diferente, recuperada al momento de eliminación de una base de datos eliminada.
- Creación de una nueva base de datos en cualquier instancia administrada de la misma suscripción o de una suscripción diferente en el mismo inquilino y en la misma región, recuperada al momento de las copias de seguridad más recientes.
Si ha configurado la retención a largo plazo (LTR), también puede crear una nueva base de datos desde cualquier copia de seguridad de retención a largo plazo en cualquier instancia.
Importante
Durante la restauración no se puede sobrescribir ninguna base de datos existente.
Tiempo de recuperación
El tiempo de recuperación para restaurar una base de datos mediante copias de seguridad de base de datos automatizadas se ve afectado por varios factores:
- El tamaño de la base de datos
- El tamaño de proceso de la base de datos
- El número de registros de transacciones implicados
- La cantidad de actividad que debe reproducirse para la recuperación hasta el punto de restauración
- El ancho de banda de red si la restauración es a una región diferente
- El número de solicitudes de restauración simultáneas que se están procesando en la región de destino
En bases de datos grandes o muy activas, la restauración puede tardar varias horas. Si se produce una interrupción prolongada en una región, es posible que se inicie un elevado número de solicitudes de restauración geográfica para la recuperación ante desastres. Si hay muchas solicitudes, el tiempo de recuperación de las bases de datos individuales puede aumentar. La mayoría de las restauraciones de bases de datos se completan en menos de 12 horas.
Sugerencia
Para Azure SQL Managed Instance, las actualizaciones del sistema tienen prioridad sobre las restauraciones de base de datos en curso. Si hay una actualización del sistema para SQL Managed Instance, todas las restauraciones pendientes se suspenden, y se reanudarán después de aplicar la actualización. Este comportamiento del sistema puede prolongar el tiempo de las restauraciones y podría afectar especialmente a las restauraciones de larga duración.
Para lograr un tiempo predecible de restauraciones de base de datos, considere la posibilidad de configurar ventanas de mantenimiento que permitan programar actualizaciones del sistema en un día y hora específicos. Considere también la posibilidad de ejecutar restauraciones de base de datos fuera de la ventana de mantenimiento programado.
Permisos
Para recuperaciones mediante copias de seguridad automatizadas, se debe ser:
- Un miembro del rol de colaborador de SQL Server o de SQL Managed Instance (en función del destino de recuperación) en la suscripción
- El propietario de la suscripción
Para más información, consulte Azure RBAC: roles integrados.
Las recuperaciones se pueden realizar a través de Azure Portal, PowerShell o la API REST. No se puede utilizar Transact-SQL.
Restauración a un momento dado
Puede restaurar una base de datos a un momento anterior. La solicitud puede especificar cualquier nivel de servicio o calcular el tamaño de la base de datos restaurada. Asegúrese de que tiene suficientes recursos en la instancia en la que se va a restaurar la base de datos.
Una vez completada la restauración, crea una nueva base de datos en la instancia de destino, ya sea la misma instancia o una diferente. La base de datos restaurada se cobra según la tarifa normal en función de su nivel de servicio y tamaño de proceso. No se aplican cargos hasta que finaliza la restauración de la base de datos.
Por lo general, una base de datos se restaura a un punto anterior para fines de recuperación. Puede tratar la base de datos restaurada como sustituta de la base de datos original o usarla como origen de datos para actualizar la base de datos original.
Importante
No se puede realizar una restauración a un momento dado en una base de datos de replicación geográfica secundaria. Solo puede hacerlo en una base de datos principal.
Sustituto de base de datos
Si la base de datos restaurada está pensada como sustituto de la base de datos original, debe especificar el tamaño de proceso y el nivel de servicio de la base de datos original. Luego puede cambiar el nombre de la base de datos original y asignar a la base de datos restaurada el nombre original mediante el comando ALTER DATABASE en T-SQL.
Recuperación de datos
Si va a recuperar datos de la base de datos restaurada para recuperarse de un error de usuario o de aplicación, debe escribir y ejecutar un script de recuperación de datos que extraiga datos de la base de datos restaurada y se aplique a la base de datos original. A pesar de que la operación de restauración puede tardar mucho tiempo en finalizar, la base de datos restaurada será visible en la lista de bases de datos durante todo el proceso de restauración.
Si elimina la base de datos durante la restauración, la operación de restauración se cancelará. No se le cobrará por la base de datos que no han completado la restauración.
Para recuperar una base de datos en SQL Managed Instance a un momento dado mediante Azure Portal, puede ir a la base de datos en el portal y elegir Restaurar. Como alternativa, puede abrir la página de información general de SQL Managed Instance de destino y seleccionar + Nueva base de datos en la barra de herramientas para abrir la página Crear base de datos administrada de Azure SQL.
Proporcione los detalles de la instancia administrada de destino en la pestaña Aspectos básicos y elija un tipo de copia de seguridad en la pestaña Origen de datos.
Para obtener más información, consulte el artículo Restauración a un momento dado.
Restauración de la base de datos eliminada
Puede restaurar una base de datos eliminada al momento en que se eliminó o a un momento anterior en la misma instancia administrada o una diferente de la de origen. La instancia de destino puede estar en la misma suscripción o en una diferente de la instancia de origen. La restauración de una base de datos eliminada se realiza mediante la creación de una nueva base de datos a partir de la copia de seguridad.
Importante
No se puede restaurar una instancia administrada que se ha eliminado. Si elimina una instancia administrada, todas sus bases de datos también se eliminan y no se pueden restaurar a la hora de eliminación o a un momento anterior. Si ha configurado la retención a largo plazo (LTR), todavía puede restaurar una base de datos desde la instancia eliminada a otra instancia y a un momento dado en el que se haya realizado la copia de seguridad de LTR.
Para recuperar una base de datos mediante Azure Portal, abra la página de información general de la instancia administrada y seleccione Copias de seguridad. Elija mostrar las copias de seguridad Eliminadas y, después, seleccione Restaurar junto a la copia de seguridad eliminada que desea recuperar para abrir la página Crear una base de datos administrada de Azure SQL. Proporcione los detalles de la instancia administrada de destino en la pestaña Aspectos básicos y los detalles de la instancia administrada de origen en la pestaña Origen de datos. Configure las opciones de retención en la pestaña Configuración adicional.
Sugerencia
Las bases de datos eliminadas recientemente pueden tardar varios minutos en aparecer en la página Bases de datos eliminadas del portal de Azure, o cuando desee mostrar las bases de datos eliminadas mediante la línea de comandos.
Geo-restore
Importante
- La restauración geográfica solo está disponible para instancias administradas configuradas con almacenamiento de copia de seguridad con redundancia geográfica. Si actualmente no usa copias de seguridad con replicación geográfica para una base de datos, puede cambiarlo configurando la redundancia de almacenamiento de copia de seguridad.
- Puede realizar la restauración geográfica sólo en instancias administradas que residen en la misma suscripción.
La función de restauración geográfica proporciona la opción de recuperación predeterminada cuando la base de datos no está disponible debido a una incidencia en la región de hospedaje. Puede restaurar la base de datos a una instancia de cualquier otra región. Se puede restaurar una base de datos situada en cualquier instancia administrada en cualquier región de Azure desde las copias de seguridad con replicación geográfica más recientes. La restauración geográfica usa una copia de seguridad con replicación geográfica como su origen. Puede solicitar una restauración geográfica, incluso si la base de datos o el centro de datos esté inaccesible debido a una interrupción.
Hay un retraso entre el momento en que se hace una copia de seguridad y el momento en que se replica geográficamente en un blob de Azure de otra región. Como resultado, la base de datos restaurada puede encontrarse hasta una hora por detrás de la base de datos original. En la siguiente ilustración se muestra la restauración de una base de datos a partir de la última copia de seguridad disponible en otra región.
En Azure Portal, puede restaurar una copia de seguridad con replicación geográfica en una instancia existente, o crear una nueva instancia administrada y seleccionar una copia de seguridad de restauración geográfica disponible. La base de datos recién creada contiene los datos de la copia de seguridad de la restauración geográfica.
Para restaurar en una instancia existente, siga los pasos descritos en Restauración a un momento dado y asegúrese de elegir las instancias de origen y de destino adecuadas para restaurar la base de datos a la instancia prevista.
Para restaurar de forma geográfica en una nueva instancia mediante Azure Portal, siga estos pasos:
- Ve a la nueva Azure SQL Managed Instance.
- Seleccione Nueva base de datos.
- Especifique un nombre para la base de datos.
- En Origen de datos, elija el tipo de copia de seguridad adecuado y proporcione detalles para el origen de datos.
- En la lista desplegable de copias de seguridad de restauración geográfica disponibles seleccione una.
Después de completar el proceso de creación de una base de datos de instancia, la base de datos creada contendrá la copia de seguridad de restauración geográfica restaurada.
Consideraciones sobre la restauración geográfica
La restauración geográfica es la solución de recuperación ante desastres más básica disponible en Azure SQL Managed Instance. Se basa en copias de seguridad con replicación geográfica creadas automáticamente en una región secundaria (emparejada). Estas son algunas consideraciones para la restauración geográfica:
- El objetivo de punto de recuperación (RPO) es de hasta 1 hora.
- Los procesos de restauración (objetivo de tiempo de recuperación: RTO) suelen tardar menos de 12 horas, pero pueden variar en función del tamaño y la actividad de la base de datos, por lo que la restauración podría extenderse más allá de este período de tiempo.
- La región secundaria (emparejada) es la configuración de Azure Storage para la región primaria. No puedes cambiar la región secundaria.
- Es posible que las bases de datos recién creadas o restauradas no aparezcan inmediatamente como restaurables en otras regiones debido a un retraso al incorporar los nuevos datos. Si los clientes no ven las copias de seguridad de nuevas bases de datos, deben prever un período de espera de hasta 24 horas.
Es esencial reconocer que la restauración geográfica actúa como una solución de recuperación ante desastres adecuada para las aplicaciones con bases de datos relativamente pequeñas que no son críticas para la empresa. En el caso de las aplicaciones críticas para la empresa que necesitan bases de datos grandes y deben garantizar la continuidad empresarial, usa grupos de conmutación por error. Con esta característica, RPO y RTO son mucho menores, y la capacidad siempre está garantizada.
Para más información sobre las opciones de continuidad empresarial, vea Introducción a la continuidad empresarial.
Limitaciones
Tenga en cuenta las siguientes limitaciones al trabajar con copias de seguridad y Azure SQL Managed Instance:
- La restauración geográfica de una base de datos solo se puede realizar en una instancia de la misma suscripción que la instancia administrada de SQL de origen.
- Las bases de datos de Azure SQL Managed Instance se cifran con TDE de forma predeterminada. Cuando la base de datos de origen usa una clave administrada por el cliente (CMK) como protector de TDE, para restaurar la base de datos a una instancia distinta de la de SQL Managed Instance de origen, la instancia de destino debe tener acceso a la misma clave usada para cifrar la base de datos de origen de Azure Key Vault o debe deshabilitar el cifrado de TDE en la base de datos de origen antes de realizar la copia de seguridad.
- Solamente se podrá realizar un seguimiento del progreso de la restauración mediante las vistas de administración dinámica sys.dm_exec_requests y sys.dm_operation_status.
- Cuando las directivas de punto de conexión de servicio están presentes en una subred delegada a Azure SQL Managed Instance, la restauración a un momento dado (PITR) en instancias administradas de esa subred no se puede realizar desde instancias de regiones diferentes.
- El objetivo de punto de recuperación (RPO) es de hasta 1 hora.
- El objetivo de tiempo de recuperación (RTO) es de aproximadamente 12 horas, pero puede variar en función del tamaño de la base de datos y la actividad podrían ir más allá de este período de tiempo.
- No se puede cambiar la región secundaria (emparejada).
- Es posible que las bases de datos recién creadas o restauradas no aparezcan inmediatamente como restaurables en otras regiones debido a un retraso al incorporar los nuevos datos. Las copias de seguridad de la nueva base de datos pueden tardar hasta 24 horas en estar visibles.
- El número máximo de bases de datos que puede restaurar en paralelo es de 200 por cada suscripción. En algunos casos, es posible aumentar este límite abriendo una incidencia de soporte técnico.
- Las copias de seguridad de base de datos tomadas de instancias configuradas con la directiva de actualización de SQL Server 2022 se pueden restaurar en instancias configuradas con la directiva de actualización de SQL Server 2022 o la directiva de actualización siempre actualizada. Las copias de seguridad de base de datos tomadas de instancias configuradas con la directiva de actualización siempre actualizada se pueden restaurar en instancias configuradas también con la directiva de actualización siempre actualizada.
Contenido relacionado
- Copias de seguridad automatizadas de SQL Managed Instance
- Retención a largo plazo
- Para conocer opciones de recuperación más rápidas, consulta Grupos de conmutación por error.