Azure Backup es el servicio con el que Microsoft respalda máquinas virtuales, servidores locales, bases de datos y recursos compartidos, y los devuelve cuando alguien borra lo que no debía. Además, no hay servidores de copia que instalar, ni cintas que rotar, ni licencias por agente. Sin embargo, tampoco es gratis ni automático: hay que elegir la bóveda de Recovery Services, la política, la retención de los puntos de recuperación y la redundancia, y cada una de esas cuatro decisiones se ve en la factura. Por eso esta guía explica las cuatro, con un caso de nueve servidores calculado de punta a punta.
Además, está escrita en dos niveles. Si usted aprueba el presupuesto y no toca la consola, le bastan los primeros apartados, la tabla de precios y el caso del final. En cambio, si administra la plataforma, encontrará las diferencias entre las dos políticas de Azure Backup, los límites reales del servicio, las órdenes de la línea de comandos y la cuenta que explica por qué el nivel de archivo, que parece más barato, a veces sale tres veces más caro.
Qué es Azure Backup y qué problema resuelve
En esencia, Azure Backup es un servicio nativo de la nube de Microsoft que copia datos, los guarda en un almacén aislado y permite recuperarlos después. Funciona por políticas: usted define cuándo se copia y cuánto se conserva, y el servicio se encarga del resto. Es decir, sustituye a la infraestructura de respaldo que antes había que comprar, instalar y mantener en la propia sala de servidores.
En realidad, el problema que resuelve es viejo y conocido. Una copia guardada en el mismo edificio que los datos originales no sobrevive a un incendio; una copia conectada al mismo dominio no sobrevive a un cifrado por ransomware. Por lo tanto, la copia tiene que salir de la sede y quedar fuera del alcance de quien administra los servidores. Eso es exactamente lo que hace este servicio, y es también lo que explican con detalle nuestras guías sobre los tipos de backup y sobre el respaldo inmutable.
Ahora bien, conviene decir desde el principio qué no es. Es decir, Azure Backup protege los datos, no la continuidad del servicio. Por ejemplo, para levantar una plataforma completa en otra región tras una caída existe Azure Site Recovery, que es otro producto con otra factura. La alta disponibilidad tampoco se compra aquí: son problemas distintos con soluciones distintas.
Las cuatro piezas de Azure Backup
En primer lugar, todo el servicio se entiende con cuatro conceptos. Quien los tenga claros configura una copia en diez minutos; quien no, se pierde en la consola.
| Pieza | Qué es | Qué decide |
|---|---|---|
| Bóveda | El almacén donde vive la copia, y también el límite de seguridad | La región, la redundancia y quién puede entrar |
| Política | El calendario y la retención | Cada cuánto se copia y cuánto tiempo se guarda |
| Agente o extensión | La pieza que habla con la carga de trabajo | Si la copia es consistente con la aplicación o solo con el disco |
| Puntos de recuperación | Las fotos de los datos en un instante | A qué momento se puede volver |
Bóveda de Recovery Services y bóveda de Backup
Hay dos tipos de bóveda y la confusión es habitual, porque el nombre no dice cuál toca. La bóveda de Recovery Services es la más antigua y la que verá casi cualquier empresa; la bóveda de Backup llegó después, para las cargas más nuevas. La regla es sencilla: el tipo de bóveda lo impone la carga de trabajo, no el gusto del administrador.
| Tipo de bóveda | Qué protege |
|---|---|
| Recovery Services | Máquinas virtuales de Azure, SQL Server y SAP HANA en máquinas virtuales, recursos compartidos de Azure Files y servidores locales con agente, con MABS o con DPM |
| Backup | Discos, blobs, Azure Data Lake Storage, bases de datos PostgreSQL y MySQL, Azure Cosmos DB y clústeres de Azure Kubernetes Service |
Asimismo, hay tres restricciones de la bóveda que conviene conocer antes de crearla, porque después no se pueden deshacer. La copia se queda en la región de la bóveda, de modo que hace falta una bóveda por cada región con servidores. Los datos, por su parte, no se mueven de una bóveda a otra. Y el tipo de redundancia solo se cambia mientras la bóveda esté vacía: en cuanto entra la primera copia, queda fijado.
Los tres niveles donde puede vivir un punto de recuperación
| Nivel | Dónde está | Para qué sirve |
|---|---|---|
| Instantánea | Junto a los discos de la máquina | Restaurar en minutos lo que se rompió ayer |
| Vault-Standard | En la bóveda | El grueso de la retención, de días a años |
| Vault-Archive | En la bóveda, en almacenamiento frío | Retención larga por cumplimiento, con rehidratación previa |
De hecho, el nivel de instantánea es el que hace posible la restauración instantánea. Mientras la copia todavía se está transfiriendo a la bóveda de Recovery Services, ese punto de recuperación ya existe y ya se puede usar. Por su parte, la transferencia posterior puede tardar horas en momentos de mucha carga, aunque la copia diaria completa nunca debería pasar de veinticuatro.
Qué se puede respaldar con Azure Backup
La lista es más larga de lo que suele creerse, y no se limita a lo que ya vive en la nube. De hecho, uno de los usos más frecuentes en empresas medianas es justo el contrario: mandar a Azure las copias de los servidores que siguen en la oficina.
| Categoría | Cargas de trabajo |
|---|---|
| Cómputo de Azure | Máquinas virtuales y discos administrados |
| Bases de datos | SQL Server y SAP HANA sobre máquinas virtuales, SAP ASE, PostgreSQL, MySQL flexible y Azure Cosmos DB |
| Almacenamiento | Azure Files, blobs y Azure Data Lake Storage |
| Contenedores | Azure Kubernetes Service |
| Local | Archivos, carpetas y estado del sistema con el agente MARS; servidores completos a través de MABS o de DPM |
Conviene retener un matiz de esa última fila. El agente MARS, que se instala directamente en el servidor, solo corre en Windows y, además, solo copia archivos, carpetas y estado del sistema. Si hace falta respaldar una máquina local entera, o una aplicación con reconocimiento de su propia consistencia, el camino es MABS o DPM, que hacen de intermediarios entre la sede y la bóveda.
Cómo hace Azure Backup la copia de una máquina virtual
El procedimiento de Azure Backup tiene dos fases y entenderlas ahorra muchos diagnósticos equivocados. Primero se toma una instantánea de los discos; después, los datos viajan a la bóveda. Cada disco se copia en paralelo y solo se transfieren los bloques que cambiaron desde la vez anterior, así que la primera copia es lenta y las siguientes no.
Ahora bien, la calidad de esa instantánea no siempre es la misma, y ahí está la diferencia entre una restauración limpia y una tarde de sobresaltos. Por lo tanto, Azure Backup distingue tres grados de consistencia.
| Consistencia | Cuándo se obtiene | Qué pasa al restaurar |
|---|---|---|
| Con la aplicación | En Windows, cuando todos los escritores de VSS responden; en Linux, con guiones previos y posteriores propios | La máquina arranca y las aplicaciones quedan coherentes |
| Con el sistema de archivos | Cuando algún escritor de VSS falla, o en Linux sin guiones | La máquina arranca sin pérdida de datos, pero cada aplicación debe revisar lo suyo |
| Ante caída | Con la máquina apagada, con copia sin agente, o cuando fallan las dos anteriores | Arranca como tras un corte de luz, con revisión de disco y posible pérdida de lo que no llegó al disco |
En Windows el servicio coordina con VSS y, por omisión, lanza una copia completa de solo copia. Esa elección no es casual: evita truncar los registros de transacciones y, por lo tanto, no rompe la cadena de respaldo que pueda estar usando otra herramienta sobre SQL Server. En Linux, en cambio, la consistencia con la aplicación no viene de fábrica. Hay que escribir los guiones de congelación y descongelación, y la responsabilidad de que funcionen es de quien los escribe.
Política estándar y política mejorada
Para máquinas virtuales, Azure Backup ofrece dos subtipos de política, y la elección condiciona lo que se puede hacer después. Conviene decidirla bien a la primera, porque una máquina protegida con la política mejorada no puede volver a la estándar.
| Criterio | Política estándar | Política mejorada |
|---|---|---|
| Copias por día | Una | Cada 4, 6, 8, 12 o 24 horas |
| Retención de la instantánea | 2 días por omisión, de 1 a 5 | 7 días por omisión, de 1 a 30 |
| Primera copia | Incremental | Completa |
| Discos admitidos | HDD estándar, SSD estándar y SSD premium | Además SSD premium v2 y discos Ultra |
| Arranque confiable | Solo desde la línea de comandos y la API recientes | Sí |
| Costo de instantáneas | Menor | Mayor |
El objetivo de punto de recuperación, es decir, cuánto trabajo se puede perder, es lo que de verdad separa a las dos. Con la política estándar, una copia al día significa que en el peor caso se pierden veinticuatro horas de trabajo. Con la mejorada y una copia cada cuatro horas, esa ventana baja a cuatro. Ahora bien, cuantas más instantáneas al día, menos días se pueden retener: con copias cada cuatro horas el máximo baja a diecisiete días, y con copias cada seis, a veintidós.
La redundancia de Azure Backup: LRS, ZRS y GRS
La redundancia decide cuántas copias de la copia existen y dónde están. En Azure Backup es la decisión más barata de tomar y la más cara de corregir, porque solo se elige una vez.
| Redundancia | Dónde replica | De qué protege |
|---|---|---|
| LRS | Tres copias dentro del mismo centro de datos | Fallas de hardware locales |
| ZRS | Entre zonas de disponibilidad de la misma región | La caída de una zona, sin sacar los datos del país |
| GRS | En una segunda región, a cientos de kilómetros | La caída de una región entera |
De hecho, GRS es la opción recomendada por Microsoft y la que viene marcada por omisión. Asimismo, sobre ella se apoya la restauración entre regiones, que permite levantar la máquina en la región emparejada cuando la principal no responde. Esa función hay que activarla en la bóveda y no funciona desde el nivel de archivo. Por su parte, ZRS es la respuesta cuando hay una exigencia de residencia de datos: replica sin sacar la información de la región.
Restaurar: las opciones que existen
En definitiva, una copia solo vale lo que valga su restauración. Por eso conviene saber, antes del incidente, qué caminos ofrece Azure Backup y cuál sirve en cada caso.
| Opción | Qué hace | Cuándo se usa |
|---|---|---|
| Crear nueva | Levanta una máquina virtual nueva desde el punto elegido | La máquina original se perdió o no se quiere tocar |
| Restaurar discos | Devuelve los discos y una plantilla para armar la máquina | Hace falta una configuración distinta de la original |
| Reemplazar existente | Sustituye los discos de la máquina actual | La máquina sirve, pero sus datos no |
| Recuperación de archivos | Monta el punto como unidad y deja copiar archivos sueltos | Alguien borró una carpeta, no se cayó el servidor |
| Entre regiones | Restaura en la región emparejada | La región principal está caída |
Además, la recuperación de archivos sueltos es la que más se usa en el día a día y la que menos se conoce. De ese modo se evita restaurar un servidor entero para rescatar un documento. Sin embargo, no funciona sobre puntos que ya estén en el nivel de archivo: esos hay que rehidratarlos primero, y la rehidratación tarda y se cobra aparte.
La seguridad que Azure Backup trae puesta
Sin duda, este es el apartado que más ha cambiado en los últimos años, y para bien. La eliminación temporal, que retiene lo borrado antes de destruirlo, ya viene aplicada por omisión y en la mayoría de regiones no se puede desactivar ni desde el portal, ni desde PowerShell, ni desde la API.
| Control | Qué hace | Detalle |
|---|---|---|
| Eliminación temporal | Retiene lo borrado antes de destruirlo | 14 días por omisión y sin costo; ampliable hasta 180, y a partir del día 15 se factura |
| Bóveda inmutable | Impide modificar o borrar puntos de recuperación | Se activa en la bóveda y se puede volver irreversible |
| Control de acceso por roles | Separa quién configura de quién restaura | Roles propios del servicio, no permisos generales |
| Cifrado | Protege el dato en tránsito y en reposo | AES de 256 bits sobre HTTPS; en el agente MARS, con frase de paso propia |
La eliminación temporal alcanza también a la propia bóveda de Recovery Services. Es decir, una bóveda borrada entra en estado eliminado temporalmente y se puede recuperar dentro del plazo configurado. Esa combinación —copia aislada del dominio, borrado retenido e inmutabilidad opcional— es la que convierte a Azure Backup en una defensa real frente al ransomware, que ataca las copias antes de cifrar los datos.
Cuánto cuesta Azure Backup
La factura de Azure Backup tiene dos líneas y no hay una tercera escondida. Se paga por instancia protegida, que es una cuota fija por cada cosa respaldada, y se paga por el almacenamiento que ocupan las copias. Asimismo, la transferencia de datos no se cobra, ni al subir ni al restaurar.
La cuota por instancia protegida
| Instancia protegida | USD al mes |
|---|---|
| Máquina virtual de Azure | 10,00 |
| Servidor local con agente | 10,00 |
| Azure Files con instantáneas | 5,00 |
| Azure Files con bóveda | 10,00 |
| Blobs de Azure | 10,00 |
| SQL Server en máquina virtual | 25,00 |
| Azure Cosmos DB | 25,00 |
| PostgreSQL flexible | 7,50 |
| SAP HANA en máquina virtual | 80,00 |
| Espacio de nombres de Kubernetes | 12,00 |
La cuota de instancia protegida se cobra por cada bloque de 500 GB o fracción, de modo que un servidor de 760 GB paga dos. Y ojo con el tamaño que cuenta: no es el de los discos asignados, sino el de los datos que hay dentro. Por ejemplo, una máquina con dos discos de 32 TB que solo guarde 47 GB factura por 47 GB. La lista de precios define además un tramo reducido para instancias de 50 GB o menos, que conviene consultar en la calculadora antes de presupuestar.
El precio del almacenamiento
| Nivel y redundancia | USD por GB al mes |
|---|---|
| Vault-Standard LRS | 0,0224 |
| Vault-Standard ZRS | 0,0280 |
| Vault-Standard GRS | 0,0448 |
| Vault-Standard RA-GRS | 0,0569 |
| Vault-Archive LRS | 0,0013 |
| Vault-Archive GRS | 0,0040 |
Conviene precisar de dónde salen estos importes: de la lista de precios minoristas de Azure para la región East US, en dólares y consultados el 22 de septiembre de 2026. Son de referencia: cambian por región, por moneda y por acuerdo comercial, así que el número definitivo lo da siempre la página de precios de Azure Backup. Aun así, las proporciones entre niveles se mantienen, y son ellas las que permiten diseñar.
Un caso completo: nueve servidores y su factura
Una empresa distribuidora tiene seis máquinas virtuales en Azure, tres servidores en su bodega y un recurso compartido de archivos. Además, quiere treinta puntos diarios, doce mensuales y siete anuales. Este es el inventario, con el dato que de verdad importa: los datos que hay dentro de cada máquina.
| Servidor | Datos | Bloques de 500 GB | USD al mes |
|---|---|---|---|
| srv-dc-01 | 42 GB | 1 | 10,00 |
| srv-web-01 | 88 GB | 1 | 10,00 |
| srv-erp-01 | 120 GB | 1 | 10,00 |
| srv-arch-01 | 210 GB | 1 | 10,00 |
| srv-file-01 | 320 GB | 1 | 10,00 |
| srv-sql-01 | 760 GB | 2 | 20,00 |
| Tres servidores locales | 900 GB | — | 30,00 |
| Azure Files | 340 GB | — | 5,00 |
| Total de instancias protegidas | 105,00 | ||
Lo que ocupa la bóveda mes a mes
Los datos que viajan a la bóveda suman 2.440 GB, porque el recurso de Azure Files se protege con instantáneas y esas no ocupan la bóveda. Con un cambio diario del 2 %, es decir 48,8 GB, y suponiendo un 3 % de datos únicos en cada punto mensual y anual, el almacenamiento se calcula así.
| Concepto | Cuenta | GB |
|---|---|---|
| Copia inicial | 1.540 + 900 | 2.440,0 |
| 30 puntos diarios | 30 × 48,8 | 1.464,0 |
| 12 puntos mensuales | 12 × 73,2 | 878,4 |
| 7 puntos anuales | 7 × 73,2 | 512,4 |
| Total almacenado | — | 5.294,8 |
La factura de Azure Backup según la redundancia
Con esos 5.294,8 GB ya se puede poner precio a cada opción de redundancia, sumando siempre los 105 dólares de instancia protegida.
| Redundancia | Almacenamiento | Factura mensual | Al año |
|---|---|---|---|
| LRS | 118,60 USD | 223,60 USD | 2.683,20 USD |
| ZRS | 148,25 USD | 253,25 USD | 3.039,00 USD |
| GRS | 237,21 USD | 342,21 USD | 4.106,52 USD |
| RA-GRS | 301,27 USD | 406,27 USD | 4.875,24 USD |
En consecuencia, la diferencia entre LRS y GRS es de 118,60 dólares al mes, o 1.423 al año. Esa es, en una sola cifra, la pregunta que debe responder la dirección: cuánto vale poder restaurar si se cae una región entera. No es una pregunta técnica, aunque se resuelva con una casilla.
Falta una partida que no aparece en la línea de Azure Backup y que sorprende al llegar la factura. En efecto, las instantáneas de restauración instantánea se guardan junto a los discos y se facturan como instantáneas de disco. Es decir, con dos días de retención y 48,8 GB de cambio diario, son 97,6 GB adicionales en otra línea del recibo.
La trampa del nivel de archivo
El nivel de archivo cuesta 0,0040 dólares por GB frente a 0,0448, es decir, once veces menos. Por lo tanto, mover a archivo los puntos de retención larga parece una decisión obvia. Pues no siempre lo es, y el motivo está en la letra pequeña de la documentación: al pasar al archivo, los puntos incrementales se convierten en copias completas.
| 7 puntos anuales del caso | Ocupación | USD al mes con GRS |
|---|---|---|
| En Vault-Standard, incrementales al 3 % | 512,4 GB | 22,96 |
| En Vault-Archive, convertidos a completos | 17.080,0 GB | 68,32 |
En este caso el archivo sale tres veces más caro que el nivel estándar. Sin embargo, la conclusión se invierte cuando los datos cambian mucho: si cada punto anual tuviera un 60 % de datos únicos, el nivel estándar costaría 459,11 dólares al mes y el archivo seguiría en 68,32, con un ahorro de 390,79. La regla, entonces, es esta: el archivo compensa cuando la tasa de cambio es alta, y penaliza cuando es baja. Por eso el propio servicio ofrece una lista de puntos recomendados en vez de archivarlo todo.
Además, el archivo tiene condiciones de entrada que casi nadie recuerda. En primer lugar, solo admite puntos mensuales y anuales, nunca diarios ni semanales. El punto debe llevar al menos tres meses en el nivel estándar y conservar seis meses de retención por delante. Y una vez dentro, cualquier borrado antes de 180 días se cobra prorrateado.
Los límites de Azure Backup que conviene conocer
Son los números de Azure Backup que evitan rediseñar a mitad de camino. Ninguno estorba a una empresa mediana, pero todos importan al planear el crecimiento.
| Límite | Valor |
|---|---|
| Bóvedas por suscripción | 500 |
| Orígenes de datos por bóveda | 2.000 |
| Máquinas virtuales por bóveda | 1.000, con 250 registros al día como máximo |
| Máquinas virtuales por política | 100 |
| Tamaño de un origen de datos | 54.400 GB, salvo máquinas virtuales |
| Puntos de recuperación por instancia | 9.999 |
| Copias al día con agente MARS | 3 |
| Copias al día con MABS o DPM | 2 |
| Cambio admitido entre copias del agente MARS | 22 TB |
Hay un detalle operativo que no es un límite, pero cuesta caro al ignorarlo: el servicio no ajusta el horario al cambio de hora estacional. En Colombia eso da igual, porque no hay horario de verano. En cambio, importa si la política gobierna servidores de una filial en un país que sí lo aplica.
Servidores locales: el agente MARS en la práctica
Muchas empresas llegan a Azure Backup por aquí, no por la nube. Tienen servidores en su propia sala y, aunque quieren sacar una copia del edificio, no están dispuestas a montar otro servidor para lograrlo. El agente MARS resuelve eso con tres condiciones que hay que aceptar de entrada.
- Solo Windows. En Linux no se instala, y esa limitación no tiene rodeo: el camino para Linux local es MABS o DPM.
- Solo archivos, carpetas y estado del sistema. No hace copias con reconocimiento de aplicación, así que una base de datos en caliente no queda coherente.
- Tres copias al día como máximo, con un cambio máximo de 22 TB entre una y otra.
A cambio, la frase de paso de cifrado la guarda el cliente y solo el cliente. Es decir, si se pierde, no hay recuperación posible; ni el soporte de Microsoft puede devolver esos datos. Por eso esa frase de paso pertenece al mismo cajón que las llaves del servidor NAS y las credenciales del hipervisor, y no al escritorio de quien instaló el agente.
Lo que Azure Backup no hace
Por último, este apartado existe para no prometer de más. Cuatro cosas quedan fuera y conviene saberlo antes de firmar, no después.
| No cubre | Qué hay en su lugar |
|---|---|
| Correo, archivos y sitios de Microsoft 365 | Microsoft 365 Backup, que es otro producto y otra factura |
| Recuperación ante desastres con conmutación | Azure Site Recovery |
| Copia hacia un destino local | No existe: la copia de una máquina de Azure se queda en Azure |
| Deduplicación en la nube | Solo la hacen MABS y MARS, no el servicio en Azure |
La primera fila merece un párrafo propio, porque es el malentendido más caro de todos. En efecto, los datos de Exchange Online, SharePoint y OneDrive no los respalda Azure Backup. Microsoft vende para eso un servicio aparte, Microsoft 365 Backup, con pago por consumo a 0,15 dólares por GB al mes y ventanas de recuperación de tres meses a dos años. Quien administre un inquilino conviene que lo revise junto con lo que ya expone el centro de administración de Microsoft 365.
Azure Backup desde la línea de comandos
El portal sirve para aprender; la línea de comandos, para repetir. Por ejemplo, estas son las órdenes mínimas para dejar protegida una máquina virtual con la interfaz de línea de comandos de Azure.
# Crear la boveda y fijar su redundancia ANTES de la primera copia
az backup vault create --resource-group rg-respaldo --name bov-kh-01 --location eastus
az backup vault backup-properties set --resource-group rg-respaldo \
--name bov-kh-01 --backup-storage-redundancy GeoRedundant
# Proteger una maquina virtual con una politica existente
az backup protection enable-for-vm --resource-group rg-respaldo --vault-name bov-kh-01 \
--vm srv-erp-01 --policy-name DefaultPolicy
# Ver las politicas y su subtipo
az backup policy list --resource-group rg-respaldo --vault-name bov-kh-01 \
--workload-type VM --policy-sub-type Enhanced --output tableDespués, lanzar una copia fuera de calendario y comprobar el resultado son las dos operaciones que más se repiten el día de una migración.
# Copia inmediata, reteniendo el punto 60 dias
az backup protection backup-now --resource-group rg-respaldo --vault-name bov-kh-01 \
--container-name srv-erp-01 --item-name srv-erp-01 \
--retain-until 21-11-2026 --backup-management-type AzureIaasVM
# Trabajos de las ultimas horas y sus estados
az backup job list --resource-group rg-respaldo --vault-name bov-kh-01 --output table
# Puntos de recuperacion disponibles de un elemento
az backup recoverypoint list --resource-group rg-respaldo --vault-name bov-kh-01 \
--container-name srv-erp-01 --item-name srv-erp-01 --output tableCon PowerShell la retención de la instantánea se ajusta en dos líneas, y esa es la palanca directa sobre el costo de las instantáneas locales.
$pol = Get-AzRecoveryServicesBackupProtectionPolicy -Name "NewPolicy"
$pol.SnapshotRetentionInDays = 2
Set-AzRecoveryServicesBackupProtectionPolicy -Policy $pol -VaultId <VaultId>Seis errores frecuentes al empezar
- Crear la bóveda en otra región. La copia no cruza regiones, así que una bóveda mal ubicada obliga a empezar de nuevo.
- Dejar la redundancia para después. Solo se cambia con la bóveda vacía; luego queda como esté.
- Programar todas las copias a la misma hora. El calendario por omisión concentra el tráfico y alarga las ventanas.
- Confiar en la consistencia de aplicación en Linux. Sin guiones propios, la copia es solo de sistema de archivos.
- Dar de baja una máquina sin borrar su copia. Mientras haya datos en la bóveda, la instancia se sigue facturando.
- No probar nunca una restauración. Una copia que jamás se restauró es una hipótesis, no un respaldo.
Preguntas frecuentes sobre Azure Backup
¿Se puede desactivar la eliminación temporal?
En las bóvedas de Recovery Services, ya no. De hecho, la protección es obligatoria y no la levanta ninguna versión del portal, de PowerShell, de la interfaz de línea de comandos ni de la API. Lo que sí se puede es alargar el plazo de 14 hasta 180 días.
¿Cuánto tarda en estar lista la primera copia?
Depende del volumen. Las copias siguientes son incrementales y no deberían pasar de veinticuatro horas, pero la inicial transfiere todo y puede tardar bastante más. Conviene planificarla fuera de la ventana de trabajo.
¿Qué pasa si detengo la protección de un servidor?
Si conserva los datos, la facturación continúa, porque la copia sigue ocupando la bóveda. La factura solo se detiene al parar la protección y borrar los datos. Además, el tamaño de la última copia correcta es el que se usa para el cobro mientras tanto.
¿Sirve Azure Backup si no tengo nada en la nube?
Sí, y es uno de sus usos más habituales. Con el agente MARS los servidores Windows de la oficina mandan su copia a la bóveda sin ninguna máquina virtual de por medio. Por lo tanto, la empresa consigue una copia fuera de sede sin construir un segundo centro de datos.
Cómo decidir en diez minutos
| Si su situación es… | La decisión razonable |
|---|---|
| Servidores locales y ninguna copia fuera de sede | Agente MARS, bóveda GRS y retención corta |
| Máquinas virtuales en Azure sin exigencias horarias | Política estándar, una copia diaria, GRS |
| Sistemas donde perder un día es inaceptable | Política mejorada cada 4 o 6 horas |
| Bases de datos con recuperación a un punto exacto | Copia con reconocimiento de SQL Server o SAP HANA |
| Obligación de conservar años de historia | Retención anual y evaluación del nivel de archivo, con la cuenta hecha |
| Exigencia de que el dato no salga de la región | Bóveda ZRS |
Con esa tabla y las cifras de los apartados anteriores, un administrador puede montar un esquema de Azure Backup defendible el mismo día. Para profundizar en cada opción, la documentación oficial de Azure Backup mantiene al día las matrices de compatibilidad, que cambian varias veces al año.
Lo que hay que llevarse
Azure Backup quita trabajo, no responsabilidad. De hecho, sigue haciendo falta alguien que decida la retención, vigile los trabajos fallidos, pruebe las restauraciones y revise la factura cuando el volumen crece. La nube resuelve el dónde y el cómo; el qué y el cada cuánto siguen siendo decisiones de la empresa.
En KHARONTE administramos ese trabajo dentro de la línea de continuidad operativa y respaldo: políticas, vigilancia diaria de los trabajos, pruebas de restauración y el informe de qué se copió y qué no. Y si lo que hace falta es ordenar el inquilino de Microsoft, las licencias y los accesos, eso vive en gestión de plataformas. En los dos casos, el criterio es el mismo: una copia que nadie ha restaurado nunca no cuenta como copia.
