Compartir a través de

Copia de seguridad y restauración en Azure Database for MySQL

El servidor flexible de Azure Database for MySQL crea automáticamente copias de seguridad del servidor y las almacena de forma segura en el almacenamiento con redundancia local dentro de la región. Las copias de seguridad se pueden usar para restaurar el servidor a un momento dado. Las copias de seguridad y restauración son una parte esencial de cualquier estrategia de continuidad empresarial porque protegen los datos frente a daños o eliminaciones accidentales.

Introducción a la copia de seguridad

El servidor flexible de Azure Database for MySQL admite dos tipos de copias de seguridad para proporcionar una mayor flexibilidad para mantener las copias de seguridad de los datos críticos para la empresa.

Copia de seguridad automatizada

El servidor flexible de Azure Database for MySQL realiza copias de seguridad de instantáneas de los archivos de datos y las almacena en un almacenamiento con redundancia local. El servidor también realiza la copia de seguridad de los registros de transacciones y también los almacena en el almacenamiento con redundancia local. Estas copias de seguridad permiten restaurar un servidor a cualquier momento dado dentro del período de retención de copia de seguridad configurado. El período de retención de copia de seguridad predeterminado es de siete días. Opcionalmente, puede configurar la copia de seguridad de base de datos de 1 a 35 días. Todas las copias de seguridad se cifran mediante el cifrado AES de 256 bits para los datos almacenados en reposo.

Copia de seguridad bajo demanda

El servidor flexible de Azure Database for MySQL también permite desencadenar copias de seguridad a petición de la carga de trabajo de producción, además de las copias de seguridad automatizadas realizadas por el servicio y almacenarla en consonancia con la directiva de retención de copias de seguridad del servidor. Puede usar estas copias de seguridad como un punto de restauración más rápido para realizar una restauración a un momento dado para reducir los tiempos de restauración hasta un 90 %. El período de retención de copia de seguridad predeterminado es de siete días. Opcionalmente, puede configurar la copia de seguridad de la base de datos de 1 a 35 días. Puede desencadenar un total de 50 copias de seguridad a petición desde el portal. Todas las copias de seguridad se cifran mediante el cifrado AES de 256 bits para los datos almacenados en reposo.

Estos archivos de copia de seguridad no se pueden exportar. Las copias de seguridad solo se pueden usar para las operaciones de restauración en el servidor flexible de Azure Database for MySQL. También puede usar mysqldump desde un cliente MySQL para copiar una base de datos.

Frecuencia de copia de seguridad

Las copias de seguridad en servidores flexibles se basan en instantáneas. La primera copia de seguridad de instantáneas se programa inmediatamente después de crear un servidor. Las copias de seguridad de instantáneas se realizan una vez al día. Las copias de seguridad del registro de transacciones se producen cada cinco minutos.

Si se produce un error en una copia de seguridad programada, el servicio de copia de seguridad intenta realizar una copia de seguridad cada 20 minutos hasta que se realice una copia de seguridad correcta. Estos errores de copia de seguridad pueden producirse debido a cargas de producción transaccionales pesadas en la instancia del servidor.

Para mejorar la frecuencia de las copias de seguridad diarias automatizadas, puede aumentar el intervalo de copia de seguridad. Este ajuste es especialmente beneficioso al anticipar transacciones grandes, ya que reduce significativamente el tiempo de restauración en caso de error. Para modificar el intervalo de copia de seguridad, vaya a la sección Configuración > proceso y almacenamiento y establezca el campo Intervalo de copia de seguridad en consecuencia. Aunque el intervalo predeterminado se establece en 24 horas, se puede ajustar a 12 o 6 horas. La retención de estas copias de seguridad viene determinada por el período de retención configurado en el nivel de servidor.

Actualmente, esta característica está en versión preliminar y está limitada a las regiones Este de EE. UU., Centro-oeste de EE. UU., Este de Japón y Este de Asia .

Captura de pantalla de la modificación de la frecuencia de copia de seguridad.

Nota

  • Si el servidor experimenta una gran carga de transacciones, lo que da lugar a archivos binlog de mayor tamaño y más rápido, el servicio de copia de seguridad realizará varias copias de seguridad al día para garantizar una restauración confiable y rápida mediante estas copias de seguridad.
  • En el caso de los servidores 5.7, las transacciones de larga duración o grandes pueden impedir la adquisición de bloqueos de nivel de instancia global, lo que es necesario para una copia de seguridad diaria correcta. En estos escenarios, se pueden producir errores en las copias de seguridad diarias. Para resolverlo, finalice la transacción de ejecución prolongada O reinicie el servidor. Para garantizar operaciones más fluidas, se recomienda actualizar los servidores MySQL 5.7 a la versión 8.0 mediante una actualización de versión principal.

Opciones de redundancia de copia de seguridad

El servidor flexible de Azure Database for MySQL almacena varias copias de las copias de seguridad para que los datos se protejan de eventos planeados y no planeados, incluidos errores transitorios de hardware, interrupciones de red o de energía y desastres naturales masivos. El servidor flexible de Azure Database for MySQL proporciona la flexibilidad de elegir entre el almacenamiento de copia de seguridad con redundancia local, con redundancia de zona o con redundancia geográfica en los niveles Básico, De uso general y Crítico para la empresa. De manera predeterminada, el almacenamiento de copia de seguridad del servidor flexible de Azure Database for MySQL es redundante localmente para los servidores con alta disponibilidad de la misma zona o sin configuración de alta disponibilidad y redundancia de zona para servidores con configuración de alta disponibilidad con redundancia de zona.

La redundancia de copia de seguridad garantiza que la base de datos cumpla sus objetivos de disponibilidad y durabilidad, incluso en caso de errores y el servidor flexible de Azure Database for MySQL amplía tres opciones a los usuarios -

  • Almacenamiento de copia de seguridad con redundancia local: cuando las copias de seguridad se almacenan en un almacenamiento de copia de seguridad con redundancia local, son varias las copias de seguridad que se almacenan en el mismo centro de datos. Esta opción protege los datos frente a errores en el bastidor del servidor y en las unidades. Además, proporciona una durabilidad mínima del 99,999999999 % (11 nueves) de los objetos de copia de seguridad en un año determinado. De forma predeterminada, el almacenamiento de copia de seguridad para servidores con alta disponibilidad de la misma zona (HA) o ninguna configuración de alta disponibilidad está establecida en redundancia local.

  • Almacenamiento de copia de seguridad con redundancia de zona: cuando las copias de seguridad se almacenan en el almacenamiento de copia de seguridad con redundancia de zona, no solo se almacenan varias copias dentro de la zona de disponibilidad en la que se hospeda el servidor, sino que también se replican en otra zona de disponibilidad de la misma región. Esta opción se puede aprovechar para escenarios que requieren alta disponibilidad o para restringir la replicación de datos a dentro de un país o región para cumplir los requisitos de residencia de datos. Además, proporciona una durabilidad mínima del 99,9999999999 % (12 nueves) de los objetos de copia de seguridad en un año determinado. Puede seleccionar la opción Alta disponibilidad con redundancia de zona en el momento de la creación del servidor para garantizar el almacenamiento de copia de seguridad con redundancia de zona. La alta disponibilidad para un servidor se puede deshabilitar después de la creación, pero el almacenamiento de copia de seguridad sigue siendo redundante de zona.

  • Almacenamiento de copia de seguridad con redundancia geográfica: cuando las copias de seguridad se almacenan en el almacenamiento de copia de seguridad con redundancia geográfica, no solo se almacenan varias copias dentro de la región en la que se hospeda el servidor, sino que también se replican en su región emparejada geográficamente. Esto proporciona una mejor protección y capacidad para restaurar el servidor en una región diferente en caso de desastre. Además, proporciona una durabilidad mínima del 99,99999999999999 % (16 nueves) de los objetos de copia de seguridad en un año determinado. Es posible habilitar la opción de redundancia geográfica en el momento de crear el servidor a fin de garantizar el almacenamiento de copia de seguridad con redundancia geográfica. Además, puede pasar del almacenamiento con redundancia local al almacenamiento con redundancia geográfica luego de la creación del servidor. La redundancia geográfica es admitido con los servidores hospedados en cualquiera de las Regiones emparejadas de Azure.

Nota

La alta disponibilidad con redundancia de zona para admitir la redundancia de zona aparece actualmente solo como una operación en el momento de la creación. Actualmente, para una redundancia geográfica del servidor de alta disponibilidad con redundancia de zona solo se puede habilitar o deshabilitar en tiempo de creación del servidor.

Mover de otras opciones de almacenamiento de copia de seguridad al almacenamiento de copia de seguridad con redundancia geográfica

Puede mover el almacenamiento de copias de seguridad existentes al almacenamiento con redundancia geográfica mediante las siguientes maneras sugeridas:

  • Cambio de almacenamiento de copia de seguridad con redundancia local a otro con redundancia geográfica: Si desea cambiar el almacenamiento de copia de seguridad desde el almacenamiento con redundancia local al almacenamiento con redundancia geográfica, puede cambiar la configuración del servidor de Proceso y almacenamiento en Azure Portal para habilitar la redundancia geográfica para el servidor de origen con redundancia local. Los mismos servidores de alta disponibilidad con redundancia de zona también se pueden restaurar como un servidor con redundancia geográfica de forma similar que el almacenamiento de copia de seguridad subyacente es localmente redundante para lo mismo.

  • Mover de almacenamiento de copia de seguridad con redundancia de zona a almacenamiento de copia de seguridad con redundancia geográfica : El servidor flexible de Azure Database for MySQL no admite el almacenamiento con redundancia de zona a la conversión de almacenamiento con redundancia geográfica mediante el cambio de configuración de Proceso + Almacenamiento después de aprovisionar el servidor. Para mover el almacenamiento de copia de seguridad del almacenamiento con redundancia de zona al almacenamiento con redundancia geográfica, hay dos opciones: a) Usar PITR (restauración a un momento dado) para restaurar el servidor con la configuración deseada. b) Cree un nuevo servidor con la configuración deseada y migre los datos mediante volcado de memoria y restauración.

Retención de copia de seguridad

Las copias de seguridad se conservan en función de la configuración del período de retención de copia de seguridad en el servidor. Puede seleccionar un período de retención de 1 a 35 días con un período de retención predeterminado de siete días. Puede establecer el período de retención durante la creación del servidor o una versión posterior mediante la actualización de la configuración de copia de seguridad mediante Azure Portal.

El período de retención de copia de seguridad rige cuánto tiempo puede realizarse una operación de restauración a un momento dado, ya que se basa en las copias de seguridad disponibles. El período de retención de copia de seguridad también se puede tratar como una ventana de recuperación desde una perspectiva de restauración. Todas las copias de seguridad necesarias para realizar una restauración a un momento dado dentro del período de retención de copia de seguridad se conservan en el almacenamiento de copia de seguridad. Por ejemplo, si el período de retención de la copia de seguridad se establece en siete días, la ventana de recuperación comprenderá los últimos siete días. En este escenario, se conservan todas las copias de seguridad necesarias para restaurar el servidor en los últimos siete días. Con una ventana de retención de copia de seguridad de siete días, las instantáneas de base de datos y las copias de seguridad del registro de transacciones se almacenan durante los últimos ocho días (1 día antes de la ventana).

Costo de almacenamiento de copia de seguridad

El servidor flexible de Azure Database for MySQL proporciona hasta el 100 % del almacenamiento de servidor aprovisionado como almacenamiento de copia de seguridad sin costo adicional. Cualquier almacenamiento de copia de seguridad adicional usado se cobra en GB al mes. Por ejemplo, si ha aprovisionado un servidor con 250 GB de almacenamiento, tiene 250 GB de almacenamiento disponible para las copias de seguridad del servidor sin ningún cargo adicional. Si el uso diario de la copia de seguridad es de 25 GB, puede tener hasta 10 días de almacenamiento de copia de seguridad gratuito. El almacenamiento consumido para copias de seguridad que supere los 250 GB se cobra según el modelo de precios.

Puede usar la métrica Monitor de Azure Database for MySQL: servidor flexible métrica en Azure Monitor disponible en Azure Portal para supervisar el almacenamiento de copia de seguridad consumido por un servidor. La Almacenamiento de copia de seguridad métrica usada representa la suma del almacenamiento consumido por todas las copias de seguridad de base de datos y las copias de seguridad de registros conservadas en función del período de retención de copia de seguridad establecido para el servidor. La actividad transaccional intensiva en el servidor puede hacer que el uso del almacenamiento de copia de seguridad aumente independientemente del tamaño total de la base de datos. El almacenamiento de copia de seguridad que se usa para un servidor con redundancia geográfica es el doble que el de un servidor con redundancia local.

El medio principal para controlar el costo del almacenamiento de copia de seguridad es establecer el período de retención de copia de seguridad adecuado. Puede seleccionar un período de retención entre 1 y 35 días.

Importante

Las copias de seguridad de un servidor de bases de datos configurados en una configuración de alta disponibilidad con redundancia de zona se producen desde el servidor de bases de datos principal, ya que la sobrecarga es mínima con las copias de seguridad de instantáneas.

Ver copias de seguridad completas disponibles

La hoja Copia de seguridad y restauración de Azure Portal proporciona una lista completa de las copias de seguridad completas disponibles en cualquier momento dado. Esto incluye copias de seguridad automatizadas, así como las copias de seguridad a petición. Puede usar esta hoja para ver las marcas de tiempo de finalización de todas las copias de seguridad completas disponibles dentro del período de retención del servidor y para realizar operaciones de restauración mediante estas copias de seguridad completas. La lista de copias de seguridad disponibles incluye todas las copias de seguridad completas dentro del período de retención, una marca de tiempo que muestra la finalización correcta, una marca de tiempo que indica cuánto tiempo se conservará una copia de seguridad y una acción de restauración.

Restauración

En el servidor flexible de Azure Database for MySQL, al realizar una restauración se crea un nuevo servidor a partir de las copias de seguridad del servidor original. Hay dos tipos de restauración disponibles:

  • Restauración a un momento dado: está disponible con cualquiera de las opciones de redundancia de copia de seguridad y crea un nuevo servidor en la misma región que el servidor original.
  • Restauración geográfica: solo está disponible si configuró el servidor para el almacenamiento con redundancia geográfica y le permite restaurar el servidor a una región emparejada geográficamente o a cualquier otra región compatible con Azure en la que el servidor flexible esté disponible.

El tiempo estimado para la recuperación del servidor depende de varios factores:

  • El tamaño de las bases 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
  • La presencia de la clave principal en las tablas de la base de datos. Para una recuperación más rápida, considere la posibilidad de agregar la clave principal para todas las tablas de la base de datos.

Nota

Un servidor habilitado para alta disponibilidad se convertirá en no alta disponibilidad (alta disponibilidad deshabilitada) después de la restauración para la restauración a un momento dado y la restauración geográfica.

Restauración a un momento dado

En el servidor flexible de Azure Database for MySQL, al realizar una restauración a un momento dado se crea un nuevo servidor a partir de las copias de seguridad del servidor flexible de la misma región que el servidor de origen. Se crea con la configuración del servidor original para el nivel de proceso, el número de núcleos virtuales, el tamaño de almacenamiento, el período de retención de copia de seguridad y la opción de redundancia de copia de seguridad. Además, las etiquetas y la configuración, como la red virtual y el firewall, se heredan del servidor de origen. El nivel de proceso y almacenamiento del servidor restaurado, la configuración y la configuración de seguridad se pueden cambiar una vez completada la restauración.

Nota

Hay dos parámetros de servidor que se restablecen a valores predeterminados (y no se copian desde el servidor principal) después de la operación de restauración

  • time_zone: este valor se establece en valor PREDETERMINADO SISTEMA
  • event_scheduler: para los servidores mySQL versión 5.7, el parámetro de servidor event_scheduler se desactiva automáticamente cuando se inicia la copia de seguridad y el parámetro del servidor event_scheduler se vuelve a activar después de que la copia de seguridad se complete correctamente. En la versión 8.0 de MySQL para Azure Database for MySQL: servidor flexible, el event_scheduler sigue sin verse afectado durante las copias de seguridad. Para garantizar operaciones más fluidas, se recomienda actualizar los servidores MySQL 5.7 a la versión 8.0 mediante una actualización de versión principal.

La restauración a un momento dado es útil en varios escenarios. Algunos de los casos de uso comunes incluyen los siguientes:

  • Cuando un usuario elimina accidentalmente datos de la base de datos.
  • El usuario quita una tabla o base de datos importante.
  • La aplicación de usuario sobrescribe accidentalmente los datos correctos con datos incorrectos debido a un defecto de la aplicación.

Puede elegir entre el punto de restauración más reciente, el punto de restauración personalizado y el punto de restauración más rápido (restauración mediante copia de seguridad completa) a través de Restauración a un momento dado en Azure Database for MySQL: servidor flexible con Azure Portal.

  • Punto de restauración más reciente: la opción de punto de restauración más reciente le ayuda a restaurar el servidor a la marca de tiempo cuando se desencadenó la operación de restauración. Esta opción es útil para restaurar rápidamente el servidor al estado más actualizado.
  • Punto de restauración personalizado: esta opción le permite elegir cualquier momento dentro del período de retención definido para este servidor. Esta opción es útil para restaurar el servidor en el momento preciso de recuperación de un error de usuario.
  • Punto de restauración más rápido: esta opción permite a los usuarios restaurar el servidor en el tiempo más rápido posible durante un día determinado dentro del período de retención definido para su servidor. La restauración más rápida es posible eligiendo el momento dado de restauración en el que se completa la copia de seguridad completa. Esta operación de restauración simplemente restaura la copia de seguridad de instantánea completa y no garantiza la restauración o recuperación de los registros, lo que hace que sea rápida. Se recomienda seleccionar una marca de tiempo de copia de seguridad completa que sea mayor que el primer punto de restauración en el tiempo para una operación de restauración correcta.

El tiempo estimado de recuperación depende de varios factores, incluidos los tamaños de la base de datos, el tamaño de copia de seguridad del registro de transacciones, el tamaño de proceso de la SKU y el tiempo de la restauración. La recuperación del registro de transacciones es la parte más lenta del proceso de restauración. Si el tiempo de restauración se elige más cerca de la programación de copia de seguridad de instantáneas, las operaciones de restauración son más rápidas, ya que la aplicación del registro de transacciones es mínima. A fin de calcular el tiempo de recuperación preciso para el servidor, se recomienda encarecidamente probarla en el entorno, ya que tiene demasiadas variables específicas del entorno.

Importante

Si va a restaurar una instancia de servidor flexible de Azure Database for MySQL configurada con alta disponibilidad con redundancia de zona, el servidor restaurado se configura en la misma región y zona que el servidor principal y se implementa como un único servidor en modo que no es de alta disponibilidad. Consulte alta disponibilidad con redundancia de zona para servidor flexible.

Importante

Puede recuperar un recurso de servidor flexible de Azure Database for MySQL eliminado en un plazo de 5 días a partir del momento de la eliminación del servidor. Para obtener instrucciones detalladas sobre cómo restaurar un servidor eliminado, referirse a los pasos documentados. Para proteger los recursos del servidor después de la implementación de cambios accidentales o inesperados, los administradores pueden usar bloqueos de administración.

Restauración geográfica

Puede restaurar un servidor a su región emparejada geográficamente donde el servicio está disponible si ha configurado el servidor para copias de seguridad con redundancia geográfica o cualquier otra región compatible de Azure donde esté disponible el servidor flexible de Azure Database for MySQL. Capacidad de restaurar a cualquier región admitida de Azure no emparejada (excepto Brazil South, USGov Virginia y West US 3) se conoce como "Restauración geográfica universal".

La restauración geográfica es la opción de recuperación predeterminada cuando el servidor no está disponible debido a un incidente en la región donde se hospeda el servidor. Si un incidente a gran escala en una región produce una falta de disponibilidad de la aplicación de base de datos, puede restaurar un servidor desde las copias de seguridad con redundancia geográfica a un servidor de cualquier otra región. La restauración geográfica utiliza la copia de seguridad más reciente del servidor. Hay un retraso entre cuándo se realiza una copia de seguridad y cuándo se replica en otra región. Este retraso puede ser de hasta una hora, por lo que si se produce un desastre, puede haber una pérdida de datos de hasta una hora.

La restauración geográfica también se puede realizar en un servidor detenido aprovechando la CLI de Azure. Lea Restauración a un momento dado en Azure Database for MySQL: servidor flexible con la CLI de Azure para más información sobre la restauración geográfica de un servidor con la CLI de Azure.

El tiempo estimado de recuperación depende de varios factores, incluidos los tamaños de la base de datos, el tamaño del registro de transacciones, el ancho de banda de red y el número total de bases de datos que se recuperan en la misma región al mismo tiempo.

Nota

Si va a restaurar geográficamente una instancia de servidor flexible de Azure Database for MySQL configurada con alta disponibilidad con redundancia de zona, el servidor restaurado se configura en la región emparejada geográficamente y la misma zona que el servidor principal y se implementa como una única instancia de servidor flexible de Azure Database for MySQL en modo que no es de alta disponibilidad. Consulte alta disponibilidad con redundancia de zona para el servidor flexible de Azure Database for MySQL.

Importante

Cuando la región primaria está inactiva, no se pueden crear servidores con redundancia geográfica en la región emparejada geográfica correspondiente porque el almacenamiento no se puede aprovisionar en la región primaria. Debe esperar a que la región primaria esté al día de aprovisionar servidores con redundancia geográfica en la región emparejada geográficamente.
Con la región primaria inactiva, todavía puede restaurar geográficamente el servidor de origen en la región emparejada geográficamente deshabilitando la opción de redundancia geográfica en la configuración de Compute + Storage Configure Server en la experiencia del portal de restauración y restaurar como un servidor con redundancia local para garantizar la continuidad empresarial.

Realizar tareas posteriores a la restauración

Cuando efectúe la restauración con el mecanismo de recuperación último punto de restauración o punto de restauración personalizado, deberá realizar las tareas siguientes para que los usuarios y las aplicaciones vuelvan a conectarse:

  • Si el servidor nuevo está destinado a reemplazar al servidor original, redirija a los clientes y las aplicaciones cliente al servidor nuevo.
  • Asegúrese de aplicar reglas de red virtual y de firewall de nivel de servidor adecuadas para que se conecten los usuarios.
  • No se olvide de emplear los permisos de nivel de base de datos y los inicios de sesión apropiados.
  • Configure alertas, según corresponda.

Retención a largo plazo (versión preliminar)

Nota

La característica de versión preliminar: solución "Retención a largo plazo" para la protección de servidores flexibles de Azure Database for MySQL mediante Azure Backup está actualmente en pausa. No configure las nuevas copias de seguridad hasta que se note más. Asegúrese de que todos los datos de copia de seguridad existentes son seguros y están disponibles para la restauración.

Los servicios de Servidor flexible de Azure Backup y Azure Database for MySQL han creado una solución de copia de seguridad a largo plazo de clase empresarial para instancias de servidor flexible de Azure Database for MySQL que conserva las copias de seguridad durante hasta 10 años. Puede usar la retención a largo plazo de forma independiente o además de la solución de copia de seguridad automatizada que ofrece El servidor flexible de Azure Database for MySQL, que ofrece retención de hasta 35 días. Las copias de seguridad automatizadas son copias de seguridad de instantáneas adecuadas para las recuperaciones operativas, especialmente cuando se desea restaurar a partir de las copias de seguridad más recientes. Las copias de seguridad a largo plazo le ayudan con las necesidades de cumplimiento y las necesidades de auditoría. Además de la retención a largo plazo, la solución ofrece las siguientes funcionalidades:

  • Copias de seguridad programadas y a petición controladas por el cliente
  • Administre y supervise todas las operaciones y trabajos relacionados con la copia de seguridad en servidores, grupos de recursos, ubicaciones, suscripciones e inquilinos desde un único panel de vidrio denominado Centro de copia de seguridad.
  • Las copias de seguridad se almacenan en dominios de seguridad y de error independientes. Si el servidor de origen o la suscripción están en peligro, las copias de seguridad permanecen seguras en el almacén de Backup (en cuentas de almacenamiento administradas de Azure Backup).

Limitaciones y consideraciones

  • En versión preliminar, la restauración de LTR está disponible actualmente como RestoreasFiles en cuentas de almacenamiento. La funcionalidad RestoreasServer se agregará en el futuro.
  • Actualmente no se admite la compatibilidad con la creación y administración de LTR a través de la CLI de Azure.

Para obtener más información sobre cómo realizar una copia de seguridad a largo plazo, visite la guía paso a paso

Copia de seguridad a petición y exportación (versión preliminar)

Nota

La característica "Copia de seguridad y exportación a petición" del servidor flexible de Azure Database for MySQL, actualmente en versión preliminar, se ha pausado temporalmente. Esta decisión se tomó para abordar determinados bloqueadores técnicos identificados durante la fase de versión preliminar, lo que afecta a la capacidad de restauración de las copias de seguridad exportadas. Como resultado, la exportación de copias de seguridad a cuentas de almacenamiento externas no estará disponible hasta que se note más.

El servidor flexible de Azure Database for MySQL ahora ofrece la posibilidad de desencadenar una copia de seguridad física a petición del servidor y exportarla a una cuenta de Azure Storage (Azure Blob Storage). Una vez exportadas, estas copias de seguridad se pueden usar para la recuperación, migración y redundancia de datos. Estos archivos de copia de seguridad física exportados se pueden usar para restaurarlos de nuevo en un servidor MySQL local para ayudar a satisfacer las necesidades de auditoría, cumplimiento o archivado de una organización. La característica se encuentra actualmente en versión preliminar pública y solo está disponible en regiones de nube pública.

Para obtener más información sobre la copia de seguridad de exportación, visite la guía paso a paso

Preguntas más frecuentes (P+F)

  • ¿Cómo hago una copia de seguridad de mi servidor?

    De forma predeterminada, el servidor flexible de Azure Database for MySQL permite copias de seguridad automatizadas de todo el servidor (que abarcan todas las bases de datos creadas) con un período de retención predeterminado de 7 días. También puede desencadenar una copia de seguridad manual mediante la característica de copia de seguridad a petición. La otra manera de realizar una copia de seguridad manualmente es mediante herramientas de la comunidad como mysqldump, como se documenta aquí o mydumper, tal como se documenta aquí. Si desea realizar una copia de seguridad de una instancia de servidor flexible de Azure Database for MySQL en un almacenamiento de blobs, consulte nuestro blog de la comunidad tecnológica Copia de seguridad de azure Database for MySQL con servidor flexible en un blob Storage.

  • ¿Puedo configurar copias de seguridad automáticas para que se conserven a largo plazo?

    No, actualmente solo se admite un máximo de 35 días de retención de copia de seguridad automatizada. Puede realizar copias de seguridad manuales y usarlas para los requisitos de retención a largo plazo.

  • ¿Cuáles son las ventanas de copia de seguridad de mi servidor? ¿Se puede personalizar?

    La primera copia de seguridad de instantáneas se programa inmediatamente después de crear un servidor. Las copias de seguridad de instantáneas se realizan una vez al día. Las copias de seguridad del registro de transacciones se producen cada cinco minutos. Azure administra de forma inherente las ventanas de copia de seguridad y no se puede personalizar.

  • ¿Mis copias de seguridad están cifradas?

    Todos los datos, copias de seguridad y archivos temporales del servidor flexible de Azure Database for MySQL creados durante la ejecución de consultas se cifran mediante el cifrado AES de 256 bits. El cifrado de almacenamiento está siempre activado y no se puede deshabilitar.

  • ¿Puedo restaurar una o varias bases de datos?

    No se admite la restauración de una o varias bases de datos o tablas. En caso de que quiera restaurar bases de datos específicas, realice una restauración a un momento dado y, a continuación, extraiga las tablas o bases de datos necesarias.

  • ¿Mi servidor está disponible durante la ventana de copia de seguridad?

    Sí. Las copias de seguridad son operaciones en línea y se basan en instantáneas. La operación de instantánea solo tarda unos segundos y no interfiere con las cargas de trabajo de producción, lo que garantiza la alta disponibilidad del servidor.

  • Al configurar la ventana de mantenimiento para el servidor, ¿es necesario tener en cuenta la ventana de copia de seguridad?

    No, las copias de seguridad se desencadenan internamente como parte del servicio administrado y no tienen ningún efecto en la ventana de mantenimiento administrado.

  • ¿Dónde se almacenan mis copias de seguridad automatizadas y cómo se administra su retención?

    El servidor flexible de Azure Database for MySQL crea automáticamente copias de seguridad del servidor y las almacena en almacenamiento configurado por el usuario, con almacenamiento con redundancia local o en almacenamiento con redundancia geográfica. Estos archivos de copia de seguridad no se pueden exportar. El período de retención de copia de seguridad predeterminado es de siete días. Opcionalmente, puede configurar la copia de seguridad de la base de datos de 1 a 35 días.

  • ¿Cómo puedo validar mis copias de seguridad?

    La mejor manera de validar la disponibilidad de las copias de seguridad completadas correctamente es ver las copias de seguridad automatizadas completas realizadas dentro del período de retención en la hoja Copia de seguridad y restauración. Si se produce un error en una copia de seguridad, no aparece en la lista de copias de seguridad disponibles y el servicio de copia de seguridad intentará cada 20 minutos realizar una copia de seguridad hasta que se realice una copia de seguridad correcta. Estos errores de copia de seguridad se deben a cargas de producción transaccionales pesadas en el servidor.

  • ¿Dónde puedo ver el uso de la copia de seguridad?

    En Azure Portal, en la sección Supervisión: métricas, puede encontrar la métrica Monitor azure Database for MySQL: servidor flexible, que puede ayudarle a supervisar el uso total de la copia de seguridad.

  • ¿Qué ocurre con mis copias de seguridad si se elimina el servidor?

    Si elimina el servidor, todas las copias de seguridad que pertenecen al servidor también se eliminan y no se pueden recuperar. Para proteger los recursos del servidor después de la implementación de cambios accidentales o inesperados, los administradores pueden usar bloqueos de administración.

  • ¿Qué ocurre con mis copias de seguridad al restaurar un servidor?

    Si restaura un servidor, siempre da como resultado la creación de un nuevo servidor neto que se ha restaurado mediante las copias de seguridad del servidor original. La copia de seguridad antigua del servidor original no se copia en el servidor recién restaurado y permanece con el servidor original. Sin embargo, para el servidor recién creado, la primera copia de seguridad de instantáneas se programa inmediatamente después de crear un servidor y el servicio garantiza que las copias de seguridad automatizadas diarias se realicen y se almacenen según el período de retención del servidor configurado.

  • ¿Cómo se me cobra y factura por el uso de copias de seguridad?

    El servidor flexible de Azure Database for MySQL proporciona hasta el 100 % del almacenamiento de servidor aprovisionado como almacenamiento de copia de seguridad sin costo adicional. El cargo de cualquier almacenamiento de copia de seguridad adicional que se use se realizará por GB/mes según el modelo de precios. La facturación del almacenamiento de copia de seguridad también se rige por el período de retención de copia de seguridad seleccionado y la opción de redundancia de copia de seguridad elegida, aparte de la actividad transaccional en el servidor, lo que afecta al almacenamiento de copia de seguridad total que se usa directamente.

  • ¿Cómo se conservan las copias de seguridad de los servidores detenidos?

    No se realizan nuevas copias de seguridad para los servidores detenidos. Todas las copias de seguridad anteriores (dentro de la ventana de retención) en el momento de detener el servidor se conservan hasta que se reinicia el servidor, después de la cual la retención de copia de seguridad del servidor activo se rige por su ventana de retención de copia de seguridad.

  • ¿Cómo se facturarán las copias de seguridad de un servidor detenido?

    Mientras se detiene la instancia del servidor, se le cobra por el almacenamiento aprovisionado (incluidas las IOPS aprovisionadas) y el almacenamiento de copia de seguridad (las copias de seguridad almacenadas en la ventana de retención especificada). El almacenamiento de copia de seguridad gratuito se limita al tamaño de la base de datos aprovisionada y solo se aplica a los servidores activos.

  • ¿Cómo están protegidos mis datos de copia de seguridad?

    El servidor flexible de Azure Database for MySQL protege los datos de copia de seguridad bloqueando las operaciones que podrían provocar la pérdida de puntos de recuperación durante el período de retención configurado. Las copias de seguridad realizadas durante el período de retención solo se pueden leer para el propósito de la restauración y se eliminan después del período de retención. Además, todas las copias de seguridad del servidor flexible de Azure Database for MySQL se cifran mediante el cifrado AES de 256 bits para los datos almacenados en reposo.

  • ¿Cómo afecta una operación de restauración a un momento dado (PITR) al uso de IOPS?

    Durante una operación PITR en Azure Database for MySQL: servidor flexible, se crea un nuevo servidor y los datos se copian del almacenamiento del servidor de origen al almacenamiento del nuevo servidor. Este proceso da como resultado un aumento del uso de IOPS en el servidor de origen. Este aumento del uso de IOPS es una repetición normal y no indica ningún problema con el servidor de origen ni con la operación PITR. Una vez completada la operación PITR, el uso de IOPS en el servidor de origen volverá a sus niveles habituales.

  • ¿Cómo se restaura mi servidor? Azure Portal admite la restauración a un momento dado para todos los servidores, lo que permite a los usuarios restaurar a puntos de restauración más recientes o personalizados. Para restaurar manualmente el servidor desde las copias de seguridad realizadas por mysqldump/myDumper, consulte Restaurar la base de datos mediante myLoader.

  • ¿Por qué mi restauración tarda tanto tiempo?

    El tiempo estimado para la recuperación del servidor depende de varios factores:

    • El tamaño de las bases de datos. Como parte del proceso de recuperación, la base de datos debe hidratarse de la última copia de seguridad física y, por lo tanto, el tiempo necesario para recuperarse será proporcional al tamaño de la base de datos.
    • La parte activa de la actividad de la transacción que debe reproducirse para recuperarse. La recuperación puede tardar más en función de la actividad de transacción adicional del último punto de control correcto.
    • Ancho de banda de red si la restauración es a otra región.
    • Número de solicitudes de restauración simultáneas que se procesan en la región de destino.
    • La presencia de claves principales en las tablas de la base de datos. Para una recuperación más rápida, considere la posibilidad de agregar claves principales para todas las tablas de la base de datos.

  • ¿La modificación de las variables de base de datos de nivel de sesión afectará a la restauración?

    La modificación de variables de nivel de sesión y la ejecución de instrucciones DML en la sesión de cliente de MySQL puede afectar a la operación PITR (restauración a un momento dado), ya que estas modificaciones no se registran en el registro binario que se usa para la operación de copia de seguridad y restauración. Por ejemplo, foreign_key_checks es una variable de nivel de sesión que, si está deshabilitada para ejecutar una instrucción DML que infringe la restricción de clave externa, se producirá un error de PITR (restauración a un momento dado). La única solución alternativa en este escenario sería seleccionar una hora PITR anterior a la hora en la que se deshabilitó foreign_key_checks. Nuestra recomendación es NO modificar ninguna variable de sesión para una operación PITR correcta.

Contenido relacionado