Azure Site Recovery es el servicio de Microsoft que mantiene una copia viva de sus servidores en otra región y la enciende cuando la principal cae. Por eso no devuelve archivos sueltos, como una copia de seguridad, sino el servicio completo: el ERP, la base de datos y el portal, funcionando en otro centro de datos en cuestión de minutos. Sin embargo, esa tranquilidad tiene un precio mensual, exige un plan de recuperación bien ordenado y, sobre todo, pide simulacros; una réplica que nunca se probó es solo una promesa.
Además, esta guía está escrita en dos niveles. Si usted decide el presupuesto, le bastan los primeros apartados, la tabla de precios y la lista de lo que el servicio no hace. En cambio, si administra la plataforma, encontrará la política de replicación, los límites reales, el orden de arranque, las órdenes de PowerShell para el simulacro y una factura calculada con el mismo método de la calculadora oficial de Microsoft.
Qué es Azure Site Recovery y qué problema resuelve
En pocas palabras, Azure Site Recovery replica máquinas virtuales y servidores físicos desde un sitio principal hacia una ubicación secundaria. Así, cuando el sitio principal falla, un administrador lanza la conmutación y las máquinas arrancan en la región de destino con los datos del último punto de recuperación. Después, cuando todo vuelve a la normalidad, el mismo servicio las devuelve a su origen.
En realidad, el problema que resuelve es el tiempo. Una copia de seguridad devuelve los datos, pero reconstruir con ellos un servidor puede llevar horas: hay que crear la máquina, restaurar los discos, reconfigurar la red y arrancar las aplicaciones en orden. En cambio, aquí la máquina ya existe en la otra región, lista para encenderse. Por eso Microsoft lo presenta como la forma de evitar el costo y la complejidad de mantener un segundo centro de datos propio.
Ahora bien, conviene situarlo bien dentro de la estrategia. La alta disponibilidad evita que un servicio se caiga dentro de una misma región; la recuperación de un sitio entero, en cambio, entra cuando lo que se cae es la región completa. Ambas piezas encajan dentro de un plan de continuidad del negocio, que es el documento donde la empresa decide cuánto tiempo puede estar parada y cuántos datos puede perder.
Azure Site Recovery frente a Azure Backup
Es la confusión más frecuente, porque los dos servicios viven en la misma bóveda de Recovery Services y aparecen juntos en el portal. No obstante, resuelven problemas distintos. Esta tabla lo resume con los datos de la documentación de Microsoft; el detalle del segundo está en nuestra guía de Azure Backup.
| Pregunta | Recuperación del sitio | Azure Backup |
|---|---|---|
| Qué devuelve | El servidor encendido en otra región | Los datos, o la máquina restaurada a partir de ellos |
| Cada cuánto copia | De forma continua, con un punto cada cinco minutos | Una vez al día con la política estándar; hasta cada cuatro horas con la mejorada |
| Hasta cuándo se puede volver atrás | Quince días como máximo | Meses o años |
| Cuánto tarda en volver | Minutos; Microsoft ofrece un acuerdo de una hora | Horas, según el volumen |
| Ante un cifrado por ransomware | La réplica recibe el cifrado en minutos; solo sirven los puntos anteriores | Copias aisladas, con eliminación temporal obligatoria |
| Cómo se cobra | 25 USD por instancia y los discos réplica | Instancia protegida y almacenamiento de la bóveda |
De hecho, la fila del ransomware es la que más importa. Es decir, Azure Site Recovery no sustituye a la copia de seguridad: la complementa. Si un atacante cifra el servidor a las nueve, la réplica tendrá el cifrado a las nueve y cinco, y la única salida será un punto anterior dentro de la ventana de retención. Por eso la copia aislada, como explica nuestra guía sobre el respaldo inmutable, sigue siendo imprescindible.
Un aviso para quien usa Hyper-V
Además, hay un detalle para quien tiene servidores Hyper-V en su propia sala: Microsoft no admite configurar Azure Backup y Azure Site Recovery en el mismo host Hyper-V, porque causa problemas de replicación. En ese caso la copia se hace con otra herramienta, y esa decisión conviene tomarla antes de instalar nada.
Qué se puede proteger con Azure Site Recovery
Ante todo, el servicio no protege aplicaciones sueltas, sino máquinas completas. En consecuencia, cualquier carga que corra en una máquina compatible viaja con ella. Estos son los orígenes admitidos que trata esta guía:
| Origen | Destino | Qué hay que instalar |
|---|---|---|
| Máquinas virtuales de Azure | Otra región de Azure, o en algunas regiones otra zona de disponibilidad | Nada: la extensión de movilidad se instala sola |
| Máquinas virtuales de Hyper-V en la oficina | Azure | Un proveedor y un agente en cada host; nada dentro de las máquinas |
| Servidores físicos con Windows o Linux | Azure | Un dispositivo de replicación en la red local y el servicio de movilidad en cada servidor |
| Clústeres de Azure Local | Azure | Integración en versión preliminar |
Dentro de esas máquinas, Microsoft documenta integraciones con SQL Server, incluidos los grupos de disponibilidad Always On, y con Active Directory, SharePoint, Exchange y SAP. Aun así, hay tres casos que no funcionan y que conviene detectar en el inventario: los discos con cargas de Docker, que hay que excluir; los discos efímeros; y el software cuya licencia depende de la dirección MAC, porque Azure no conserva direcciones MAC fijas.
Cómo funciona Azure Site Recovery por dentro
Tomemos el escenario más limpio: la replicación entre regiones de máquinas que ya viven en Azure. Todo el servicio se entiende con seis piezas.
| Pieza | Dónde vive | Para qué sirve |
|---|---|---|
| Bóveda de Recovery Services | En la región de destino, nunca en la del origen | Orquesta la replicación y guarda la configuración |
| Extensión de movilidad | Dentro de cada máquina protegida | Registra la máquina y envía cada escritura de disco |
| Cuenta de caché | En la región de origen | Recibe los cambios antes de enviarlos, para no frenar la producción |
| Discos réplica | En la región de destino, con el sufijo -ASRReplica | Reciben los datos y dan origen a los puntos de recuperación |
| Política de replicación | En la bóveda | Fija la retención y la frecuencia de los puntos coherentes con la aplicación |
| Asignación de red | Entre las dos regiones | Decide a qué red virtual se conecta cada máquina al conmutar |
Qué ocurre cuando se activa la replicación
- La extensión de movilidad se instala sola en la máquina y la registra en el servicio.
- Cada escritura en disco viaja de inmediato a la cuenta de caché de la región de origen.
- El servicio procesa la caché y aplica los cambios a los discos réplica del destino.
- Cada cinco minutos nace un punto coherente ante bloqueo; los coherentes con la aplicación, según la política.
Asimismo, un dato tranquiliza a los responsables de seguridad: el servicio no intercepta los datos de las aplicaciones. Solo recibe los metadatos necesarios para orquestar, y la réplica viaja cifrada en tránsito y queda cifrada en reposo. Además, las máquinas no necesitan conexiones entrantes; basta con salida por el puerto 443 hacia cuatro dominios de Microsoft o hacia sus etiquetas de servicio.
Los dos tipos de punto de recuperación
| Tipo | Qué captura | Frecuencia | Cuándo usarlo |
|---|---|---|---|
| Coherente ante bloqueo | Lo que había en disco, como si alguien desenchufara el servidor | Cada cinco minutos; no se puede cambiar | Servidores de archivos, DHCP, impresión y la mayoría de aplicaciones |
| Coherente con la aplicación | Lo anterior, más la memoria y las transacciones en curso | Como mínimo cada hora, con VSS de solo copia en Windows | Bases de datos como SQL Server |
Por defecto, la política guarda los puntos un día y deja apagados los coherentes con la aplicación. Además, Microsoft advierte que capturarlos muy seguido afecta el rendimiento, y que para una base de datos una hora suele bastar. Por último, en Linux la coherencia con la aplicación exige un guion propio con las opciones –pre y –post para congelar y liberar la escritura.
Cuántos puntos se conservan
Primero, durante las dos últimas horas se conservan todos los puntos. Después, el servicio los poda según la retención elegida, que llega como máximo a quince días con discos administrados.
| Retención elegida | Qué se conserva después de las dos últimas horas |
|---|---|
| 0 días | Nada: solo se puede conmutar al último punto |
| 1 día | Un punto por hora |
| De 2 a 7 días | Un punto cada dos horas |
| De 8 a 15 días | Un punto cada dos horas durante siete días; luego, uno cada cuatro horas |
Cuando varias máquinas sostienen una misma aplicación, la consistencia entre máquinas agrupa hasta dieciséis en un grupo de replicación con puntos compartidos. Aun así, consume CPU, obliga a abrir el puerto 20004 entre ellas e impide conmutar una sola; por eso conviene reservarla para la capa de base de datos.
Azure Site Recovery en un caso de cinco servidores
Para que las cifras tengan sentido, este artículo sigue un caso completo. Una empresa de logística con sede en Bogotá tiene seis máquinas virtuales en la región East US 2 de Azure, todas con discos Standard SSD. La gerencia fijó dos objetivos: el ERP debe volver en menos de una hora y no puede perder más de quince minutos de trabajo.
| Máquina | Función | Tamaño | Discos | Cambio diario | ¿Se protege? |
|---|---|---|---|---|---|
| dc01 | Controlador de dominio y DNS | D2s v5 | SO de 128 GiB | 1 GB | Sí |
| erp01 | Aplicación del ERP | D4s v5 | SO de 128 GiB y datos de 256 GiB al 60 % | 4 GB | Sí |
| sql01 | Base de datos del ERP | D8s v5 | SO de 128 GiB y datos de 512 GiB al 75 % | 14 GB | Sí |
| files01 | Archivos compartidos | D2s v5 | SO de 128 GiB y datos de 1.024 GiB al 80 % | 12 GB | Sí |
| web01 | Portal de clientes | D2s v5 | SO de 128 GiB | 1 GB | Sí |
| print01 | Servidor de impresión | D2s v5 | SO de 128 GiB | 0,5 GB | No |
Ahora bien, la primera decisión no fue técnica. El servidor de impresión se reconstruye desde una plantilla en menos tiempo del que tarda en arrancar una réplica, así que protegerlo no aporta nada. Por tanto, quedó fuera, y con eso la empresa se ahorra al menos 34,60 dólares al mes entre licencia y disco réplica.
Por qué el caso encaja con el servicio
Después, los objetivos encajan con el servicio. Los puntos cada cinco minutos cubren con holgura la pérdida máxima de quince minutos, y para sql01 la política añade un punto coherente con la aplicación cada hora. Además, el cambio diario está lejos del límite: un disco estándar admite de media 2 MB/s, unos 168 GB al día, y sql01 usa 14, apenas el 8,3 %. La región de destino elegida fue Central US.
Cuánto cuesta Azure Site Recovery de verdad
El precio de Azure Site Recovery que todo el mundo repite es 25 dólares al mes por servidor protegido, gratis los primeros 31 días de cada instancia. Es cierto, pero es solo una línea de la factura. Esta tabla aplica al caso las fórmulas de la calculadora oficial de Microsoft, con precios de la API minorista de Azure en dólares, consultados en septiembre de 2026.
| Concepto | Cómo se calcula | Mes 1 | Mes 2 en adelante |
|---|---|---|---|
| Licencia de instancia protegida | 5 × 25 USD; gratis los primeros 31 días | 0,00 | 125,00 |
| Discos réplica en Central US | Tamaño aprovisionado: cinco E10 de 9,60, un E15 de 19,20, un E20 de 38,40 y un E30 de 76,80 | 182,40 | 182,40 |
| Instantáneas en el origen | 0,05 USD/GB × 12 × cambio horario | 0,80 | 0,80 |
| Instantáneas de los puntos | 0,05 USD/GB × 32 GB × 1 día de retención | 1,60 | 1,60 |
| Transferencia entre regiones | 0,02 USD/GB, con la compresión del 50 % que asume la calculadora; el mes 1 suma la réplica inicial de 1.996,8 GB | 49,54 | 9,60 |
| Cuenta de caché | Fórmula de la calculadora para una cuenta de uso general | 4,19 | 4,19 |
| Disco temporal de la réplica inicial | Solo mientras dura la primera copia | 0,86 | — |
| Total | 239,39 | 323,59 |
En total, el primer año sale en unos 3.799 dólares. Las cuentas se pueden repetir con la calculadora de Microsoft para réplicas entre regiones, que advierte que sus resultados son orientativos.
El hallazgo: la licencia es menos de la mitad de la factura
De los 323,59 dólares mensuales, la licencia pesa el 38,6 %. En cambio, los discos réplica pesan el 56,4 %, y se cobran por tamaño aprovisionado, no por lo que ocupan. Por ejemplo, el disco de datos de files01 usa 819 GB, pero su réplica cuesta 76,80 dólares porque el disco mide 1.024 GiB. Además, el tipo de la réplica copia el del origen, así que un disco Premium en producción arrastra otro Premium en la región de destino.
Por eso la palanca de ahorro no es negociar la licencia, sino ordenar los discos. Primero, conviene excluir con PowerShell los discos que no hace falta proteger, como los de datos temporales. Luego, conviene no sobredimensionar los discos de producción, porque cada gigabyte de sobra se paga dos veces.
La retención cuesta poco
| Retención | Instantáneas de los puntos | Factura mensual |
|---|---|---|
| 1 día (por defecto) | 1,60 | 323,59 |
| 3 días | 4,80 | 326,79 |
| 7 días | 11,20 | 333,19 |
| 15 días (máximo) | 24,00 | 345,99 |
Es decir, pasar de un día a quince cuesta 22,40 dólares al mes en este caso. Como las instantáneas incrementales se cobran por lo que ocupan, a tarifa de almacenamiento Standard HDD, alargar la ventana resulta barato. Aun así, quince días es un techo: para volver atrás un mes entero hace falta una copia de seguridad.
La región más cercana no es la más barata
Para una empresa colombiana, Brazil South parece la opción natural por cercanía. Sin embargo, allí un disco Standard SSD E10 cuesta 17,92 dólares frente a 9,60 en Central US, y un E30, 143,36 frente a 76,80: un 87 % más. Además, la transferencia que sale de Brazil South hacia otra región cuesta 0,16 dólares por GB, ocho veces más que desde East US 2. En el caso, la réplica inicial pasaría de 49,54 a 396,29 dólares, y el tráfico mensual, de 9,60 a 76,80.
Por tanto, la región de destino se elige con la calculadora abierta. La latencia pesa en la región de producción; en la de destino, solo mientras dure la contingencia.
Lo que cuesta usarlo
Mientras nada falla, no se paga cómputo en la región de destino, porque las máquinas no existen. Solo aparecen durante un simulacro o una conmutación real, y entonces se cobran por hora.
| Situación | Cuenta | Costo |
|---|---|---|
| Una hora con las cinco máquinas encendidas en Central US | 0,200 + 0,401 + 0,802 + 0,200 + 0,200 | 1,80 USD |
| Un simulacro de cuatro horas | Cómputo de 7,21 más discos de prueba por 1,00 | 8,21 USD |
| Cuatro simulacros al año | 4 × 8,21 | 32,85 USD |
| Tres días de contingencia real | 72 horas de cómputo | 129,82 USD |
Además, esas tarifas incluyen la licencia de Windows Server. En cambio, la de SQL Server depende del contrato de la empresa, y conviene revisarla antes del primer simulacro, no el día del desastre.
Cómo se configura Azure Site Recovery paso a paso
En el portal, el recorrido para máquinas que ya viven en Azure tiene ocho pasos. Además, conviene hacerlos en este orden, porque algunos no se pueden cambiar después.
- Crear la bóveda en la región de destino. La bóveda y las máquinas que protege deben estar en ubicaciones distintas.
- Abrir la máquina y elegir la opción de recuperación ante desastres. Ahí se elige la región de destino y, si hace falta, otra suscripción del mismo inquilino de Entra ID.
- Revisar los recursos de destino. El servicio propone un grupo de recursos y una red virtual con el sufijo asr, y crea los discos réplica.
- Definir la política. Retención de los puntos y frecuencia de los coherentes con la aplicación.
- Decidir la consistencia entre máquinas. Solo para las que comparten una aplicación.
- Activar la replicación. Microsoft estima unas seis horas por cada TB en la réplica inicial; en el caso, unos 2 TB, es decir, una noche.
- Ajustar la red. Una IP privada fija se conserva si está libre en el destino; la IP pública, en cambio, no se conserva nunca.
- Hacer la primera prueba de conmutación por error. Hasta ese momento, la protección es una hipótesis.
La política del caso en PowerShell
Por ejemplo, la política del caso se puede crear con PowerShell. Retiene los puntos un día y pide uno coherente con la aplicación cada hora, que es la frecuencia mínima.
# Contexto de la boveda y politica de replicacion entre regiones
$boveda = Get-AzRecoveryServicesVault -Name "bov-dr-centralus" -ResourceGroupName "rg-dr"
Set-AzRecoveryServicesAsrVaultContext -Vault $boveda
New-AzRecoveryServicesAsrPolicy -AzureToAzure -Name "politica-erp" `
-RecoveryPointRetentionInHours 24 -ApplicationConsistentSnapshotFrequencyInHours 1Por último, dos requisitos de la cuenta de caché que suelen fallar: debe estar en la misma región y la misma suscripción que las máquinas, y no puede tener activada la eliminación temporal, porque el servicio crea y borra archivos de registro sin parar.
El plan de recuperación: el orden en que vuelve la empresa
Conmutar máquinas sueltas funciona en una prueba, pero no en un desastre. Precisamente para eso existe el plan de recuperación, que agrupa las máquinas en hasta siete grupos que arrancan uno detrás de otro. Además, entre grupos admite guiones, runbooks de Azure Automation y acciones manuales que alguien debe confirmar.
| Grupo | Máquinas | Por qué en ese orden |
|---|---|---|
| 1 | dc01 | Sin identidad ni servidor DNS, nada de lo demás inicia sesión |
| 2 | sql01 | El ERP no arranca sin su base de datos |
| 3 | erp01 y files01 | Dependen de los dos grupos anteriores, pero no entre sí |
| 4 | web01 | Acción manual: asignar la IP pública y actualizar el registro DNS público |
Además, hay dos detalles que el plan debe recoger. Primero, las extensiones de las máquinas no viajan con la réplica, así que los agentes de monitoreo y de antivirus se reinstalan después de conmutar. Segundo, con un solo controlador de dominio, Microsoft recomienda replicarlo con el propio servicio, siempre que sea catálogo global y tenga los roles de maestro de operaciones que la prueba necesita.
Cómo se prueba Azure Site Recovery sin tocar producción
El simulacro de recuperación, que Microsoft llama prueba de conmutación por error, es la función más valiosa y la menos usada. Levanta copias de las máquinas en una red virtual aislada, mientras la replicación sigue su curso y la producción no se entera. Microsoft recomienda que esa red use el mismo rango de direcciones que la de producción y que no tenga conexión de sitio a sitio. Por otra parte, el simulacro no tiene un cargo propio: solo se paga el cómputo mientras las máquinas de prueba existen. Así se lanza una prueba de conmutación por error de sql01 con PowerShell, y así se limpia al terminar.
# Simulacro de sql01 en una red aislada
$rpi = Get-AzRecoveryServicesAsrReplicationProtectedItem -FriendlyName "sql01" `
-ProtectionContainer $contenedor
$prueba = Start-AzRecoveryServicesAsrTestFailoverJob -ReplicationProtectedItem $rpi `
-AzureVMNetworkId $redAislada -Direction PrimaryToRecovery
Get-AzRecoveryServicesAsrJob -Job $prueba | Select-Object State, StartTime, EndTime
# Al terminar las comprobaciones, borrar las maquinas de prueba
Start-AzRecoveryServicesAsrTestFailoverCleanupJob -ReplicationProtectedItem $rpiSin embargo, un simulacro útil no termina cuando las máquinas encienden. Estas son las comprobaciones que convierten la prueba en evidencia:
| Comprobación | Qué demuestra |
|---|---|
| Iniciar sesión con una cuenta del dominio | Que la identidad y el DNS volvieron |
| Abrir el ERP y consultar un pedido reciente | Que la aplicación y la base de datos hablan entre sí |
| Abrir una carpeta compartida | Que los permisos viajaron con los datos |
| Anotar la hora del punto usado | La pérdida de datos real, no la teórica |
| Leer la duración del trabajo en el registro de trabajos | El tiempo de recuperación real del plan |
Por último, con el controlador de dominio hay que contar con una sorpresa. Al arrancar en Azure puede cambiar su identificador de generación, y entonces Active Directory activa protecciones que retrasan el inicio de sesión. Por eso Microsoft documenta cómo evitarlo en un controlador dedicado a las pruebas.
El día del desastre: conmutar, confirmar y volver
Ante todo, la conmutación no es automática. La decide una persona, con un clic en el portal o con PowerShell, y no necesita conexión con la región caída. En ese momento hay que elegir el punto de recuperación, y cada opción cambia el equilibrio entre datos perdidos y tiempo parado.
| Opción | Qué hace | Cuándo conviene |
|---|---|---|
| Último | Procesa todo lo recibido antes de conmutar | Cuando importa perder lo mínimo, aunque tarde más |
| Último procesado | Usa el último punto ya listo | Cuando importa volver cuanto antes |
| Último coherente con la aplicación | Usa el último punto con memoria y transacciones | Para bases de datos exigentes |
| Personalizado | Un punto concreto de la lista | Solo con una máquina y sin plan de recuperación |
Después de comprobar que todo funciona, se confirma la conmutación. Ojo, porque confirmar borra todos los puntos de recuperación de esa máquina: ya no se podrá cambiar de punto. Luego llega la reprotección, porque las máquinas arrancan sin protección en la región de destino. Al reprotegerlas, el servicio replica hacia el origen solo las diferencias, lo que suele llevar unas horas. Finalmente, el regreso tarda más o menos lo mismo que la conmutación de ida.
# Conmutacion no planificada al punto mas reciente y confirmacion
$puntos = Get-AzRecoveryServicesAsrRecoveryPoint -ReplicationProtectedItem $rpi |
Sort-Object RecoveryPointTime
$conmutacion = Start-AzRecoveryServicesAsrUnplannedFailoverJob -ReplicationProtectedItem $rpi `
-Direction PrimaryToRecovery -RecoveryPoint $puntos[-1]
Start-AzRecoveryServicesAsrCommitFailoverJob -ReplicationProtectedItem $rpiPor otra parte, conviene hacer dos avisos sobre ese fragmento. La lista de puntos no llega ordenada, por eso se ordena antes de tomar el último; y sus horas vienen en UTC, mientras el portal las muestra en hora local. Además, la capacidad en la región de destino se ofrece según disponibilidad: quien necesite garantizarla debe contratar una reserva de capacidad, que se cobra aparte.
Azure Site Recovery con servidores en la oficina
Sin embargo, muchas empresas no tienen sus servidores en Azure, sino en su propia sala, sobre Hyper-V. Para ellas, replicar Hyper-V a Azure sustituye al segundo centro de datos que nunca llegaron a montar. El mecanismo cambia en varios puntos, como muestra la tabla; la base de la virtualización de servidores sigue siendo la misma.
| Aspecto | Entre regiones de Azure | Desde Hyper-V hacia Azure |
|---|---|---|
| Qué se instala | Una extensión, de forma automática | AzureSiteRecoveryProvider.exe en cada host, que instala el proveedor y el agente |
| Hosts admitidos | No aplica | Windows Server 2016, 2019 y 2022, y 2012 R2 actualizado, aunque ya está fuera de soporte |
| Frecuencia de copia | Continua, con puntos cada cinco minutos | Cada 30 segundos, salvo con almacenamiento Premium, o cada cinco minutos |
| Transferencia de datos | Se cobra al salir de la región de origen | Sin cargo: solo se cobra el tráfico que sale de una región de Azure |
| BitLocker en la máquina | Compatible con el cifrado de discos de Azure | Hay que desactivarlo antes de replicar |
| Añadir o ampliar un disco | Se admite añadir en caliente | Obliga a desactivar y volver a activar la replicación |
| Regreso | Reprotección y conmutación inversa | Descarga de diferencias con parada mínima, o descarga completa |
Además, al replicar Hyper-V a Azure hay tres detalles de instalación que conviene conocer. La clave de registro de la bóveda caduca a los cinco días, así que conviene descargarla el mismo día de la instalación. Si los registros de cambios de Hyper-V llegan al 50 % del tamaño del disco, la máquina pasa a resincronización, que por defecto se programa fuera del horario de oficina. La réplica viaja por internet, por una VPN de sitio a sitio o por ExpressRoute con emparejamiento de Microsoft.
Servidores físicos: el problema es el regreso
Con servidores físicos, la réplica hacia Azure también funciona, pero el regreso tiene una limitación seria: no se puede volver a un servidor físico. Por tanto, la vuelta hay que planearla desde el principio, porque la máquina física se convierte en virtual al primer desastre.
Límites de Azure Site Recovery que conviene conocer
| Límite | Valor |
|---|---|
| Retención máxima de puntos | 15 días con discos administrados |
| Punto coherente ante bloqueo | Cada 5 minutos, sin posibilidad de cambio |
| Punto coherente con la aplicación | Como mínimo cada hora |
| Máquinas por grupo de replicación | 16 |
| Grupos por plan de recuperación | 7 |
| Disco de sistema operativo | Hasta 4.095 GiB |
| Disco de datos | Hasta 32.767 GiB, unos 32 TiB |
| Discos de datos por máquina | Hasta 64 |
| Discos protegidos por suscripción | Hasta 3.000 |
| Cambio admitido por máquina | 54 MB/s en modo normal; hasta 100 MB/s en alto cambio, y 500 MB/s en configuraciones que cumplen requisitos |
| Acuerdo de tiempo de recuperación | Una hora, según Microsoft |
Además, la lista completa, con los sistemas operativos admitidos y los requisitos de red, está en la matriz de compatibilidad para máquinas de Azure y en la matriz para Hyper-V. Conviene revisarlas antes de prometer una fecha, porque cambian con frecuencia.
Lo que Azure Site Recovery no hace
Por eso este apartado existe: para no prometer de más. Estas son las siete cosas que el servicio no cubre y que conviene saber antes de firmar:
- No es una copia de seguridad. Quince días es su techo, y una corrupción o un cifrado llegan a la réplica en minutos.
- No conmuta solo. Siempre hace falta una persona que decida y un procedimiento escrito.
- No garantiza capacidad. Sin reserva de capacidad, el cómputo en el destino depende de la disponibilidad.
- No conserva la IP pública. Hay que asignarla en el destino, a mano o con el plan de recuperación.
- No replica las extensiones. Los agentes se reinstalan después de conmutar.
- No admite todo. Los discos con Docker, los discos efímeros y el software licenciado por dirección MAC quedan fuera.
- No vuelve a un servidor físico. El regreso de un servidor físico siempre es a una máquina virtual.
Cuándo conviene y cuándo no
| Situación | ¿Conviene? | Por qué |
|---|---|---|
| ERP en Azure y la empresa no tolera más de una hora parada | Sí | Es exactamente el problema que resuelve |
| Servidores Hyper-V en la oficina, sin segundo centro de datos | Sí | Sustituye al sitio alterno que habría que comprar y mantener |
| Servicios que se reconstruyen en minutos desde una plantilla | No | Se paga licencia y disco por algo que no lo necesita |
| Solo se quiere recuperar archivos borrados | No | Eso es una copia de seguridad |
| Bases de datos con réplica propia entre regiones | Depende | Hay integración con Always On; conviene no duplicar mecanismos |
Para decidir, basta con dos preguntas. Primero, ¿cuánto cuesta una hora de la empresa sin su ERP? Luego, ¿cuánto de eso cubren los 323,59 dólares mensuales del caso? Si una sola hora parada cuesta más que la factura del mes, la respuesta sale sola. Para completar el cuadro, conviene repasar también los tipos de backup que ya tiene la empresa.
Preguntas frecuentes sobre Azure Site Recovery
¿Los 31 días gratis valen para cada servidor?
Sí. De hecho, cada instancia nueva tiene sus propios 31 días sin cargo de licencia, aunque la empresa lleve años usando el servicio. Eso sí, en esos días se pagan igual el almacenamiento, las transacciones y la transferencia de datos.
¿Cuánto tarda en volver una máquina?
Microsoft ofrece un acuerdo de una hora y, según su documentación, casi siempre lo logra en minutos. Sin embargo, la cifra que vale es la del propio simulacro, que queda registrada como duración del trabajo.
¿Se puede replicar a otra suscripción?
Sí, a cualquier suscripción del mismo inquilino de Entra ID. Además, se puede replicar entre dos regiones cualesquiera del mundo o limitarse a un mismo grupo geográfico por soberanía de datos.
¿Hace falta una VPN?
Entre regiones de Azure, no. En cambio, para replicar Hyper-V a Azure desde la oficina, la réplica puede ir por internet a un punto público cifrado, por una VPN de sitio a sitio o por ExpressRoute. Con ExpressRoute se necesita emparejamiento de Microsoft, salvo que la bóveda use puntos de conexión privados.
¿Qué pasa si la región principal cae entera?
Precisamente para eso existe el servicio. La conmutación no necesita conexión con la región caída, así que se lanza desde la de destino. Por eso la bóveda vive allí, y por eso el procedimiento escrito debe estar fuera de los servidores que protege.
Cómo lo aborda KHARONTE
En definitiva, el servicio funciona bien cuando alguien lo vigila y lo prueba. En KHARONTE diseñamos el plan de recuperación ante desastres con objetivos de tiempo y de pérdida de datos definidos por escrito, y hacemos pruebas periódicas de restauración dentro de nuestro servicio de continuidad operativa y respaldo. Además, administramos las suscripciones y la infraestructura de Azure dentro de la gestión de plataformas, y comercializamos el licenciamiento oficial de Microsoft que el plan necesita.
