Preguntas generales acerca de Azure Site Recovery

Site Recovery contribuye a su estrategia de continuidad empresarial (BCDR por su sigla en inglés) y recuperación ante desastres mediante la coordinación y la automatización de la replicación de máquinas virtuales de Azure entre regiones, máquinas virtuales locales y servidores físicos a Azure, y máquinas locales a un centro de datos secundario. Más información.

No, Azure Site Recovery no admite las cargas de trabajo de Docker que se ejecutan en máquinas virtuales. Para proteger estas máquinas virtuales con Site Recovery, excluya los discos que tengan instalado Docker.

Site Recovery toma varias medidas para garantizar la integridad de los datos. Se establece una conexión segura entre todos los servicios mediante el protocolo HTTPS. Esto garantiza que cualquier malware o entidad externa no pueda alterar los datos. Otra medida tomada es usar sumas de comprobación. La transferencia de datos entre el origen y el destino se ejecuta mediante el cálculo de sumas de comprobación de datos entre ellas. Esto garantiza que los datos transferidos sean coherentes.

Azure no admite direcciones MAC persistentes y, por tanto, no se puede usar software con modelos de licencia basados en MAC tanto para la migración local a Azure como para la recuperación ante desastres.

No, Azure Site Recovery actualmente no es compatible con discos efímeros.

Agente de Recovery Services de Microsoft Azure: este componente se usa para la configuración y el registro en los servicios de Site Recovery, así como para la supervisión del estado de todos los componentes. Este componente es uno de los bloques de creación básicos de toda la infraestructura local de Azure Site Recovery. Ayuda a replicar las cargas de trabajo en otra región de Azure desde un sitio local y conmutar por error a Azure en caso de desastre.

Sí, Site Recovery admite ambos modelos de infraestructura, dedicados y compartidos.

No. La identidad del inquilino permanece anónima. Los inquilinos no necesitan acceso al portal de Site Recovery. Solo el administrador del proveedor de servicios realiza acciones en el portal.

Al replicar a Azure, los datos de la aplicación se envían al almacenamiento de Azure, pero no al servicio Site Recovery. Los datos se cifran en tránsito (HTTPS) y permanecen cifrados en Azure.

No. La relación de facturación de Azure se entabla directamente con el proveedor de servicios. Los proveedores de servicios son responsables de generar facturas específicas para sus inquilinos.

No, los datos se replican en Azure Storage en su suscripción. Al realizar una conmutación por error de prueba (obtención de detalles de recuperación ante desastres) o una conmutación por error real, Site Recovery creará automáticamente las máquinas virtuales en la suscripción.

Sí.

Se admite Azure Pack, el sistema de plataforma en la nube e implementaciones basadas en System Center (2012 y superiores). Más información acerca de la integración de Azure Pack y Site Recovery.

No, solo puede replicar máquinas virtuales de Hyper-V en Azure.

Consulte los detalles de los precios de Site Recovery.

Puede usar la calculadora de precios para estimar los costos al usar Site Recovery.

Para obtener una estimación detallada de los costos, ejecute la herramienta Deployment Planner para VMware o Hyper-V y use el informe de estimación de costos.

Sí, hay cargos adicionales por el uso de la cuenta de almacenamiento en caché al replicar máquinas virtuales mediante Site Recovery. Los costes de la cuenta de almacenamiento en caché seguirán siendo los mismos cuando el almacenamiento de réplica sea de tipo de discos administrados o de discos no administrados.

Sí. Ninguna instancia protegida incurre en cargos por Azure Site Recovery durante los primeros 31 días. Por ejemplo, si ha estado protegiendo 10 instancias durante los últimos seis meses y conecta una undécima instancia a Azure Site Recovery, no se aplicarán cargos por la undécima instancia durante los primeros 31 días. Las 10 primeras instancias continúan incurriendo en cargos por Azure Site Recovery porque han estado protegidas durante más de 31 días.

Sí, aunque Site Recovery sea gratuito los primeros 31 días de una instancia protegida, puede incurrir en cargos por Azure Storage, transacciones de almacenamiento y transferencia de datos. Una máquina virtual recuperada también puede incurrir en cargos por proceso de Azure.

No hay ningún coste independiente para las maniobras de recuperación ante desastres. Hay cargos de proceso una vez creada la máquina virtual después de la conmutación por error de prueba.

No, Site Recovery no intercepta los datos replicados ni tiene información sobre lo que se ejecuta en sus máquinas virtuales o servidores físicos. Los datos de replicación se intercambian entre hosts locales de Hyper-V, hipervisores de VMware o servidores físicos y el Almacenamiento de Azure en el sitio secundario. Site Recovery no tiene capacidad para interceptar los datos. Únicamente se envían los metadatos necesarios para coordinar la replicación y la conmutación por error al servicio Site Recovery.

Site Recovery está certificado según la norma ISO 27001:2013, 27018, además de HIPAA y DPA, y está completando sus evaluaciones de SOC2 y FedRAMP JAB.

Sí. Al crear un almacén de Site Recovery en una región, garantizamos que todos los metadatos que necesitamos para habilitar y coordinar la replicación y la conmutación por error permanezcan dentro del límite geográfico de esa región.

En el caso de las máquinas virtuales y los servidores físicos que se replican en Azure, se admite tanto el cifrado en tránsito como el cifrado en reposo (en Azure).

Sí, el protocolo TLS 1.2 se aplica de forma predeterminada en el escenario de Azure a Azure Site Recovery.

Los agentes de Mobility instalados en los elementos replicados se comunican con el servidor de procesos solo a través de TLS 1.2. Sin embargo, la comunicación del servidor de configuración a Azure y del servidor de procesos a Azure podría usar TLS 1.1 o 1.0. Siga las instrucciones para aplicar TLS 1.2 en todos los servidores de configuración y servidores de procesos configurados por el usuario.

Todas las comunicaciones entre los microservicios de Azure Site Recovery se producen en el protocolo TLS 1.2. Site Recovery usa proveedores de seguridad configurados en el sistema (SO) y utiliza el protocolo TLS más reciente disponible. Hay que habilitar explícitamente TLS 1.2 en el Registro y entonces Site Recovery comenzará a utilizar TLS 1.2 para la comunicación con los servicios.

Puede cambiar a la identidad administrada del almacén de Recovery Services desde la opción Identidad. Una vez que el almacén se registra en Microsoft Entra ID, puede ir a las cuentas de almacenamiento y proporcionar las siguientes asignaciones de roles al almacén:

• Cuentas de almacenamiento basadas en Resource Manager (tipo Estándar):
  • Colaborador
  • Colaborador de datos de blobs de almacenamiento
• Cuentas de almacenamiento basadas en Resource Manager (tipo Premium):
  • Colaborador
  • Propietario de datos de blobs de almacenamiento
• Cuentas de almacenamiento clásicas:
  • Colaborador de cuentas de almacenamiento clásico
  • Rol de servicio de operador de claves de cuentas de almacenamiento clásicas

La cuenta de almacenamiento en caché no se admite para la identidad administrada.

Azure Site Recovery no realiza un seguimiento de los cambios de máquina virtual de origen fuera del sistema operativo de origen. Por ejemplo, si se usa la replicación de Azure a Azure y cambia el tamaño de la máquina virtual de origen, el cambio en el tamaño de la máquina virtual de origen no se replicará en la máquina virtual de destino.

• Máquinas virtuales de Azure: Site Recovery puede replicar cualquier carga de trabajo que se ejecute en una máquina virtual de Azure compatible.
• Máquinas virtuales de Hyper-V: Site Recovery puede proteger cualquier carga de trabajo que se ejecute en una máquina virtual de Hyper-V.
• Servidores físicos: Site Recovery puede proteger servidores físicos con Windows o Linux.
• Máquinas virtuales de VMware: Site Recovery puede proteger cualquier carga de trabajo que se ejecute en una máquina virtual de VMware.

Use Site Recovery para proteger la mayoría de las cargas de trabajo que se ejecuten en máquinas virtuales o servidores físicos. Site Recovery proporciona compatibilidad para la replicación con reconocimiento de aplicaciones para que estas se puedan recuperar a un estado inteligente. Se integra en aplicaciones de Microsoft, como SharePoint, Exchange, Dynamics, SQL Server y Active Directory; además, colabora estrechamente con los principales proveedores, como Oracle, SAP, IBM y Red Hat. Obtenga más información acerca de la protección de la carga de trabajo.

Sí. Si usa Site Recovery para coordinar la replicación y la conmutación por error en las sucursales, disfrutará de una coordinación unificada y una vista de todas las cargas de trabajo de las sucursales desde un mismo punto. Puede ejecutar con facilidad conmutaciones por error y administrar la recuperación ante desastres de todas las sucursales desde la sede central, sin necesidad de visitar estas sucursales.

Sí, Site Recovery es compatible con la recuperación ante desastres de máquinas virtuales de Azure entre regiones de Azure. Consulte las preguntas frecuentes acerca de la recuperación ante desastres de máquinas virtuales de Azure. Si desea replicar entre dos regiones de Azure en el mismo continente, use la oferta de recuperación ante desastres de Azure a Azure. No es necesario configurar conexiones del servidor de configuración/servidor de procesos y ExpressRoute.

Sí, Site Recovery es compatible con la recuperación ante desastres de máquinas virtuales de VMware locales. Consulte las preguntas frecuentes acerca de la recuperación ante desastres de máquinas virtuales de VMware.

Sí, Site Recovery es compatible con la recuperación ante desastres de máquinas virtuales de Hyper-V locales. Consulte las preguntas frecuentes acerca de la recuperación ante desastres de máquinas virtuales de Hyper-V.

Sí, Site Recovery es compatible con la recuperación ante desastres de servidores físicos locales que ejecutan Windows y Linux en Azure. Obtenga más información acerca de los requisitos de la recuperación ante desastres en Azure. Los servidores físicos se ejecutan como máquinas virtuales en Azure después de la conmutación por error. Actualmente, no se admite la conmutación por recuperación de Azure a un servidor físico local. Solo se puede realizar la conmutación por recuperación a una máquina virtual de VMware.

No, Azure Site Recovery no admite el traslado del almacén de Recovery Services que tiene máquinas virtuales protegidas hospedadas en él.

Azure Site Recovery replica los datos en una cuenta de almacenamiento o discos administrados de Azure a través de un punto de conexión público. Sin embargo, la replicación también se puede realizar a través de VPN de sitio a sitio. La conectividad VPN de sitio a sitio permite a las organizaciones conectar redes existentes a Azure o redes de Azure entre sí. La VPN de sitio a sitio se produce a través de la tunelización IPSec a través de Internet, mediante los equipos de red perimetral y los dispositivos de red locales existentes en Azure, ya sea características nativas como Azure Virtual Private Network (VPN) Gateway u opciones de terceros, como Check Point CloudGaurd, Palo Alto NextGen Firewall.

• Conectividad privada a través de la red pública de Internet para Microsoft Edge
• Almacenes de Recovery Service configurados para la seguridad con puntos de conexión privados
• Replicación a través de una conexión de red virtual privada del cliente
• Transición sencilla a "Estado futuro"
• Sin Acuerdo de Nivel de Servicio y una latencia potencialmente mayor
• Requiere la dispponibilidad de un dispositivo VPN local

Nuestro socio, Riverbed, proporciona instrucciones detalladas sobre cómo trabajar con Azure Site Recovery. Consulte su guía de solución.

Sí, se puede usar ExpressRoute para replicar máquinas virtuales locales en Azure.

• Azure Site Recovery replica los datos en una cuenta de Azure Storage a través de un punto de conexión público. Con el fin de usar ExpressRoute para la replicación de Site Recovery, puede configurar el emparejamiento de Microsoft o usar un emparejamiento público existente (en desuso para los nuevos circuitos).
• El emparejamiento de Microsoft es el dominio de enrutamiento recomendado para la replicación.
• La replicación solo se admite a través del emparejamiento privado cuando los puntos de conexión privados están habilitados para el almacén.
• En caso de que esté protegiendo máquinas de VMware o máquinas físicas, asegúrese de que los requisitos de Redes también se cumplan para el servidor de configuración. El servidor de configuración requiere conectividad a direcciones URL específicas para la orquestación de la replicación de Site Recovery. Para esta conectividad no se puede usar ExpressRoute.
• Una vez que las máquinas virtuales se hayan conmutado por error a una red virtual de Azure,podrá acceder a ellas mediante la configuración de emparejamiento privado con la red virtual de Azure.

Azure Site Recovery no admite el uso de cuentas de almacenamiento como almacenamiento de destino. En su lugar, se recomienda usar discos administrados como almacenamiento de destino de las máquinas. Los discos administrados solo admiten el tipo LRS para favorecer la resistencia de los datos.

• Hyper-V: las máquinas virtuales de Hyper-V se pueden replicar cada 30 segundos (excepto en el caso de Premium Storage) o cinco minutos.
• Máquinas virtuales de Azure, máquinas virtuales de VMware y servidores físicos: en estos casos no es relevante la frecuencia de replicación. La replicación es continua.

No se admite la replicación extendida o encadenada. Solicite esta característica en el foro de comentarios.

No es una opción admitida. Solicite esta característica en el foro de comentarios.

Esto se admite al replicar máquinas virtuales de VMware y máquinas virtuales de Hyper-V en Azure mediante Azure Portal.

Se admiten discos dinámicos al replicar máquinas virtuales de Hyper-V y también al replicar máquinas virtuales de VMware y máquinas físicas en Azure. El disco del sistema operativo debe ser un disco básico.

Sí. Puede obtener más información acerca de la limitación de ancho de banda en estos artículos:

• Planeamiento de capacidad para replicar servidores físicos y máquinas virtuales de VMware
• Planeamiento de capacidad para replicar servidores físicos y máquinas virtuales de Hyper-V

Sí. Azure Site Recovery para el sistema operativo Linux admite scripts personalizados de aplicaciones para la coherencia de aplicaciones. El agente de movilidad de Azure Site Recovery usará el script personalizado con opciones previas y posteriores durante la coherencia de aplicaciones. A continuación se indican los pasos para habilitarlo.

1. Inicie sesión como usuario raíz en la máquina.

2. Cambie el directorio a la ubicación de instalación del agente de movilidad de Azure Site Recovery. El valor predeterminado es "/usr/local/ASR".
   # cd /usr/local/ASR

3. Cambie el directorio a "VX/scripts" en la ubicación de instalación.
   # cd VX/scripts

4. Cree un script de Shell de Bash denominado "customscript.sh" con permisos de ejecución para el usuario raíz.
   a. El script debe ser compatible con las opciones de línea de comandos "--pre" y "--post" (tenga en cuenta los guiones dobles).
   b. Cuando se llama al script con la opción "pre", se debe inmovilizar la entrada/salida de la aplicación y, cuando se llama con la opción "post", se debe reanudar la entrada/salida de la aplicación.
   c. Plantilla de ejemplo
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. Agregue los comandos para inmovilizar y liberar la entrada/salida en los pasos "pre" y "post" de las aplicaciones que requieren coherencia de la aplicación. Puede optar por agregar otro script que los especifique y llamarlo desde "customscript.sh" con las opciones "pre" y "post".

Una directiva de replicación define la configuración del historial de retención de puntos de recuperación. La directiva también define la frecuencia de las instantáneas coherentes con la aplicación. De forma predeterminada, Azure Site Recovery crea una nueva directiva de replicación con la configuración predeterminada de:

• Un día para el historial de retención de puntos de recuperación.
• Sin instantáneas coherentes con la aplicación.

Un punto de recuperación coherente con los bloqueos tiene los datos en el disco, como si se tirara del cable de alimentación del servidor durante la instantánea. No incluye nada que estuviera en memoria cuando se tomó la instantánea.

Hoy en día, la mayoría de las aplicaciones se pueden recuperar bien a partir de instantáneas coherentes con los bloqueos. Un punto de recuperación consistente entre bloqueos es suficiente para aplicaciones y sistemas operativos que no tienen bases de datos, como los servidores de archivos, los servidores DHCP y los servidores de impresión.

Site Recovery crea un punto de recuperación coherente con los bloqueos cada 5 minutos.

Los puntos de recuperación coherentes con la aplicación se crean a partir de instantáneas coherentes con la aplicación. Los puntos de recuperación coherentes con la aplicación capturan los mismos datos que las instantáneas coherentes con los bloqueos, al tiempo que también se capturan los datos en memoria y todas las transacciones en curso.

Debido a su contenido adicional, las instantáneas coherentes con la aplicación son las más complejas y las que más tardan. Se recomiendan puntos de recuperación coherentes con la aplicación para sistemas operativos de bases de datos y aplicaciones como SQL Server.

Los puntos de recuperación coherentes con la aplicación capturan todos los datos en memoria y en curso. Como los puntos de recuperación capturan esas datos, requieren un marco como el Servicio de instantáneas de volumen de Windows para poner en modo inactivo la aplicación. Si el proceso de captura es frecuente, puede afectar al rendimiento cuando la carga de trabajo ya está ocupada. No se recomienda usar baja frecuencia con los puntos de recuperación coherentes con la aplicación en cargas de trabajo que no son de base de datos. Incluso con cargas de trabajo de base de datos, 1 hora es suficiente.

Site Recovery puede crear un punto de recuperación coherente con la aplicación con una frecuencia mínima de 1 hora.

Para comprender cómo Site Recovery genera puntos de recuperación, veamos un ejemplo de una directiva de replicación. Esta directiva de replicación tiene un punto de recuperación con una ventana de retención de 1 día, y una instantánea con una frecuencia coherente con la aplicación de 1 hora.

Site Recovery crea un punto de recuperación coherente con los bloqueos cada 5 minutos. No se puede cambiar esta frecuencia. Durante las últimas 2 horas, puede elegir entre 24 puntos coherentes con los bloqueos y 2 puntos coherentes con la aplicación. Conforme transcurre el tiempo, Site Recovery elimina todos los puntos de recuperación de hace más de 2 horas y solo guarda 24 punto de recuperación por hora durante un máximo de 24 horas.

La siguiente captura de pantalla ilustra el ejemplo. En la captura de pantalla:

• En las últimas 2 horas, hay puntos de recuperación con una frecuencia de 5 minutos.

• Más allá de las últimas 2 horas, Site Recovery conserva solo 1 punto de recuperación por hora.

  

El punto de recuperación más antiguo que puede usar es de 15 días con disco administrado y de tres días con disco no administrado.

No, Site Recovery mantiene todos los puntos de recuperación anteriores. En función de la ventana de retención de los puntos de recuperación, Site Recovery reemplaza el punto más antiguo solo si genera nuevos puntos. A consecuencia de este problema, Site Recovery no puede generar ningún punto de recuperación nuevo. Hasta que no haya nuevos puntos de recuperación, todos los puntos anteriores permanecerán después de alcanzar la ventana de retención.

Vaya a Almacén de Site Recovery>Site Recovery Infrastructure (Infraestructura de Site Recovery)>Directivas de replicación. Seleccione la directiva que quiera editar y guarde los cambios. Todos los cambios se aplican también a todas las replicaciones existentes.

El primer punto de recuperación que se genera tiene la copia completa. Los puntos de recuperación sucesivos tienen los cambios diferenciales.

Sí, si se aumenta el período de retención de 1 a 3 días, Site Recovery guardará los puntos de recuperación durante otros 2 días. El tiempo agregado conllevará gastos de almacenamiento, ya que habrá 12 puntos de recuperación adicionales que deben guardarse con el aumento en el período de retención de 1 a 3 días. Por ejemplo, un único punto de recuperación podría tener cambios diferenciales de 10 GB con un costo por GB de 0,16 USD al mes. Los cargos adicionales serían de 1,60 USD × 12 al mes.

Es posible tener acceso a las máquinas virtuales de Azure a través de una conexión segura a Internet, a través de una VPN de sitio a sitio o mediante Azure ExpressRoute. Debe preparar algunas cosas para la conexión. Más información.

Azure está diseñado para la resistencia. Site Recovery ya está diseñado para la conmutación por error en un centro de datos de Azure secundario, según el Acuerdo de Nivel de Servicio de Azure. Si esto ocurre, nos aseguraremos de que los metadatos y los almacenes permanecen en la misma región geográfica que eligió para su almacén.

Puede desencadenar una conmutación por error no planeada desde el sitio secundario. Site Recovery no necesita conectividad desde el sitio principal para realizar la conmutación por error.

La conmutación por error no es automática. Puede iniciar las conmutaciones por error con solo un clic en el portal o bien puede usar Site Recovery PowerShell para desencadenar una conmutación por error. La conmutación por recuperación también es una acción sencilla en el portal de Site Recovery.

Para automatizar estos procesos, puede utilizar Orchestrator u Operations Manager locales para detectar un error de la máquina virtual y desencadenar luego la conmutación por error mediante el SDK.

• Obtenga más información sobre los planes de recuperación.
• Más información acerca de la conmutación por error.
• Más información acerca de la conmutación por recuperación de servidores físicos y máquinas virtuales de VMware

Sí, puede usar la recuperación en una ubicación alternativa para realizar la conmutación por recuperación a otro host de Azure.

• Para máquinas virtuales de VMware
• Para máquinas virtuales de Hyper-V

Una vez que se ha conmutado por error una máquina desde la ubicación de origen a la ubicación de destino, podrá elegit entre tres opciones. Las tres sirven para distintos propósitos:

1. Completar la migración significa que ya no volverá a la ubicación de origen. Esto es porque migró a la región de destino y ya ha terminado. Al hacer clic en Completar la migración, se desencadena Commit y, luego, Deshabilitar la replicación, internamente.
2. Commit significa que no es el final del proceso de replicación. Se conservará el elemento de replicación junto con toda la configuración, y podrá hacer clic en Volver a proteger en un momento posterior para volver a habilitar la replicación de las máquinas en la región de origen.
3. Deshabilitar la replicación deshabilitará la replicación y quitará toda la configuración relacionada. No afectará a la máquina que ya existe en la región de destino.

Sí. Puede automatizar los flujos de trabajo de Site Recovery mediante la API REST, PowerShell o el SDK de Azure. Escenarios admitidos actualmente para la implementación de Site Recovery con PowerShell:

• Replicación de máquinas virtuales de Hyper-V en nubes VMM en Azure PowerShell Resource Manager
• Replicación de máquinas virtuales de Hyper-V sin VMM en Azure PowerShell Resource Manager
• Replicación de máquinas virtuales de VMware en Azure con el Administrador de recursos de PowerShell

No, la retirada del módulo AzureRM no afecta al funcionamiento de las actualizaciones automáticas de Azure Site Recovery. No se necesitan cambios para el libro de ejecución interno, y la API REST utilizada en su lugar, sigue funcionando según lo previsto con la cuenta de automatización.

Obtenga información acerca de nuevas actualizaciones y de la acumulación.

Pasos siguientes

• Lea la Información general sobre Site Recovery