--- title: "RTO 0 y RPO 0 con Proxmox: una arquitectura, no un producto que se compra" description: "RTO 0 y RPO 0 no vienen de serie con ningún hipervisor. En Proxmox VE dependen de cómo se combinen HA, Ceph, la replicación y el almacenamiento síncrono, y no todas las máquinas virtuales los necesitan." url: https://revistacloud.com/rto-0-rpo-0-proxmox-arquitectura-continuidad-negocio/ date: 2026-11-11 modified: 2026-11-11 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2026/11/rto-rpo-cero-proxmox-continuidad.png categories: ["Cloud", "Guías y recursos"] tags: ["alta disponibilidad", "Ceph", "proxmox", "recuperación ante desastres", "stackscale"] type: post lang: es --- # RTO 0 y RPO 0 con Proxmox: una arquitectura, no un producto que se compra **Pedir RTO 0 y RPO 0 para todas las máquinas virtuales es una de las exigencias más habituales en los pliegos de infraestructura, y también una de las más caras de cumplir. Ningún hipervisor los trae de serie, tampoco Proxmox VE: son el resultado de una arquitectura concreta de almacenamiento, red, clúster y procedimientos, y su coste depende de cómo se construya y de cuántas cargas los necesiten de verdad.** **Las claves de RTO 0 y RPO 0 en Proxmox en 20 segundos** - RPO 0 exige replicación síncrona; RTO 0 exige que el servicio no se detenga. - La alta disponibilidad de Proxmox reinicia la VM en otro nodo: reduce el RTO, pero no lo deja en cero. - Lo eficiente es clasificar los servicios y reservar los valores cero para los críticos. Conviene empezar por las definiciones. El RPO (objetivo de punto de recuperación) mide cuántos datos se pueden perder: un RPO 0 significa no perder ninguna transacción confirmada, lo que obliga a que cada escritura esté en al menos dos sitios antes de darse por buena. El RTO (objetivo de tiempo de recuperación) mide cuánto puede estar parado un servicio: un RTO 0 implica que siga disponible o se recupere sin una interrupción que el usuario perciba. Son objetivos de negocio que se escriben en un pliego o en un plan de continuidad. Que se cumplan lo demuestran la arquitectura y, sobre todo, las pruebas. ## Lo que Proxmox VE ofrece de serie, y lo que no La alta disponibilidad (HA) de Proxmox VE vigila los nodos del clúster y, si uno cae, arranca sus máquinas virtuales en otro. Para evitar que dos nodos usen el mismo disco a la vez, el nodo que pierde el quórum se aísla a sí mismo mediante un watchdog que, según la documentación del proyecto, lo reinicia a los 60 segundos. Solo después se recuperan las VM en otro nodo, por lo que en la práctica el servicio está parado del orden de uno a dos minutos, más lo que tarde en arrancar el sistema operativo y la aplicación. Es un RTO bajo, adecuado para muchos servicios, pero no es cero: la VM se reinicia, no continúa. Además, la HA necesita al menos tres nodos para mantener el quórum y que los discos estén en almacenamiento compartido. En el RPO, todo depende del almacenamiento. Con Ceph integrado en Proxmox, cada escritura se replica de forma síncrona entre varios nodos del clúster antes de confirmarse, así que la caída de un servidor no pierde datos confirmados. La replicación de almacenamiento de Proxmox sobre ZFS local es otra cosa: es asíncrona y su intervalo más corto es de un minuto, de modo que en una conmutación se puede perder lo escrito desde la última copia. Es una opción barata y útil, pero no ofrece RPO 0. Y Proxmox Backup Server cubre otra necesidad, la de restaurar ante borrados, corrupción o ransomware, con RPO y RTO de horas. ## Dos caminos: la infraestructura o la carga Para acercarse a los valores cero entre dos centros de datos hay dos enfoques. El primero resuelve el problema en la infraestructura: hardware redundante, almacenamiento con replicación síncrona entre sitios, clústeres extendidos y orquestación desde el hipervisor. Es centralizado y robusto, pero suele ser el más caro. En Proxmox puede plantearse con un clúster extendido sobre almacenamiento compartido replicado de forma síncrona entre los dos centros, o con el modo stretch de Ceph, que exige latencias muy bajas entre sitios y un tercer punto de arbitraje para el quórum. Proveedores como Stackscale, del grupo Aire, ofrecen almacenamiento en red con [replicación síncrona entre dos centros de datos en Madrid](https://www.stackscale.com/products/synchronous-georeplication-storage/), diseñado para RTO 0 y RPO 0, y nubes privadas con Proxmox o VMware sobre esa base. El segundo camino acerca la protección a la carga: software que funciona dentro del sistema operativo o de la propia máquina virtual, o la replicación nativa de la aplicación, como la de una base de datos con réplicas síncronas. Así se pueden proteger servicios entre hipervisores distintos, centros de datos independientes, servidores físicos y virtuales, o entornos locales y nube, y la continuidad deja de depender de un hardware o hipervisor concretos. El coste puede cambiar mucho, pero los problemas no desaparecen. En ambos casos, la distancia sigue importando: la replicación síncrona añade la latencia de ida y vuelta a cada escritura, y el ancho de banda limita cuánto se puede replicar. También hay que resolver la coherencia de las aplicaciones, el orden de arranque de los servicios, la red y las VLAN en el sitio secundario, el DNS, la identidad y la autenticación, la conmutación y, al final, el regreso al sitio principal. Una réplica disponible no garantiza una aplicación operativa. ## Clasificar antes de diseñar Por eso un pliego no debería exigir RTO 0 y RPO 0 para todas las máquinas virtuales como si fueran una sola carga. Lo razonable es clasificar los servicios. Los **críticos**, como pagos, identidad o transacciones principales, necesitan continuidad activa o valores cercanos a cero, con almacenamiento síncrono entre sitios o replicación de la propia aplicación. Los **importantes** pueden recuperarse en minutos, y para ellos un clúster Proxmox con HA y Ceph suele ser suficiente. Los **operativos** admiten horas, con replicación asíncrona o restauración rápida. Y los **no críticos** pueden restaurarse desde copia de seguridad. La pregunta útil no es qué producto ofrece RTO y RPO cero, sino qué procesos lo necesitan de verdad y cuál es la arquitectura más eficiente para demostrarlo. No todas las cargas requieren la solución más cara, pero todas necesitan un objetivo medible, una prueba de recuperación periódica con el tiempo real medido y un responsable. Para quien esté llevando sus cargas a Proxmox, nuestra [guía de migración a Proxmox](https://revistacloud.com/migracion-proxmox/) es un buen punto de partida, y el diseño de la continuidad debería hacerse antes de mover la primera máquina, no después. ## Preguntas frecuentes ### ¿Qué significan RTO 0 y RPO 0? RPO 0 es no perder ninguna transacción confirmada. RTO 0 es que el servicio siga disponible o se recupere sin una interrupción perceptible. ### ¿La alta disponibilidad de Proxmox da RTO 0? No. Reinicia la máquina virtual en otro nodo tras aislar el que ha fallado, lo que suele suponer uno o dos minutos de parada más el arranque del sistema. ### ¿La replicación ZFS de Proxmox ofrece RPO 0? No. Es asíncrona y su intervalo mínimo es un minuto, así que puede perderse lo escrito desde la última réplica. Ceph o el almacenamiento síncrono sí evitan esa pérdida. ### ¿Todas las máquinas virtuales necesitan RTO 0 y RPO 0? No. Lo eficiente es clasificar los servicios en críticos, importantes, operativos y no críticos, y reservar los valores cero para los primeros. **Fuentes:** - [Proxmox VE: High Availability](https://pve.proxmox.com/wiki/High_Availability) - [Proxmox VE: Storage Replication](https://pve.proxmox.com/wiki/Storage_Replication) - [Stackscale: almacenamiento con georreplicación síncrona](https://www.stackscale.com/products/synchronous-georeplication-storage/) - [Stackscale: From High Availability to a Real Plan B](https://www.stackscale.com/blog/from-high-availability-to-a-real-plan-b/)