Voy a mostrar a continuación mi estrategia de backups en el homelab: Proxmox, PBS y Hetzner. Estoy seguro que ni es la mejor estrategia ni la mas completa, pero con las pruebas que he hecho a mi me sirve.
La inclusión mas fuerte en el último año y sin dudas la que mas tranquilidad me da es el servidor externo de respaldo de segundo nivel.
Montar un homelab es divertido, muy divertido ... de hecho he conseguido verlo como una mejora en la rentabilidad financiera, pues me he ahorrado servidores que tenía alojados en terceros que me empezaban a sumar una pasta. Mantenerlo funcionando también. Pero hay algo bastante menos divertido al menos para mi: asegurarse de que cuando todo falla, es factible recuperar el servicio.
Mi infraestructura ha ido creciendo a lo largo de los años hasta llegar a ser un cluster de 3 nodos, dentro de los cuales hay un par de máquinas virtuales, varios contenedores linux (LXCs) y en general múltiples servicios que uso todos los días. Con este crecimiento viene acompañada una responsabilidad y cuando empiezas a meter datos serios la pregunta que te haces es: ¿qué pasa si mañana cae frito uno de los servidores, un disco o arde el mini CPD?
Y así es como surge esta estrategia de backups, ha ido creciendo poco a poco, pero esta es la que tengo implementanda a día de hoy.
1. Mi objetivo: redundancia física y lógica
La solución pivota alrededor de Proxmox Backup Server (PBS), que se encarga de centralizar las copias, aplicar políticas de retención y verificar su integridad.
La arquitectura es relativamente sencilla:
flowchart TB
subgraph HOME["🏠 HOMELAB · Infraestructura local"]
direction TB
subgraph PVE["⚡ PROXMOX VE · Cluster"]
direction LR
OBUXO["🖥️ OBUXO"]
OTOXO["🖥️ OTOXO"]
OCARBALLO["🖥️ OCARBALLO"]
end
QNAP["💾 QNAP NAS<br/>Almacenamiento local"]
PBS["🛡️ PROXMOX BACKUP SERVER"]
end
subgraph CLOUD["☁️ OFFSITE · Infraestructura externa"]
direction TB
S3["☁️ HETZNER OBJECT STORAGE<br/>Repositorio S3 · Backup externo"]
end
OBUXO & OTOXO & OCARBALLO -->|"Backup de VMs y LXC"| PBS
PBS --- QNAP
PBS ==>|"Sincronización diaria"| S3
classDef node fill:#172b4d,stroke:#60a5fa,color:#ffffff,stroke-width:1.5px,rx:12,ry:12
classDef storage fill:#164e63,stroke:#22d3ee,color:#ffffff,stroke-width:2px,rx:12,ry:12
classDef backup fill:#14532d,stroke:#4ade80,color:#ffffff,stroke-width:2px,rx:12,ry:12
classDef remote fill:#4c1d95,stroke:#c084fc,color:#ffffff,stroke-width:2px,rx:12,ry:12
class OBUXO,OTOXO,OCARBALLO node
class QNAP storage
class PBS backup
class S3 remote
style HOME fill:#0f172a,stroke:#475569,stroke-width:1.5px,color:#e2e8f0
style PVE fill:#1e293b,stroke:#3b82f6,stroke-width:1.5px,color:#f8fafc
style CLOUD fill:#1e1b4b,stroke:#8b5cf6,stroke-width:1.5px,color:#f8fafc
linkStyle default stroke:#94a3b8,stroke-width:2px
Como bien dije, al principio mi único destino de backup era local, una maquina con un datastore local en el que almacenaba la copia de todos los contenedores, discos, etc ... todo ello metido en un USB externo de 4 TB montado en RAID. Pero, que pasa si ese RAID acaba frito ?
El objetivo es mantener dos backups totalmente independientes, tanto física como lógicamente:
- Qnap: este es el datastore local de PBS, donde venía haciendo las copias desde siempre, aquí se realizan las copias diarias y desde este sistema puedo recuperar mis sistemas rápidamente.
- HetznerOffsite: este es el nuevo proveedor que he incorporado y que ha motivado este artículo, es el datastore de respaldo externo que va por almacenamiento S3 de la empresa Hetzner, y en él mantengo una copia de todo fuera de mi casa.
Para el backup remoto se usan los cubos de S3 a través de PBS. No es una infraestructura de la leche, pero me proporciona la protección adicional que buscaba, frente a fallos que afecten a mi infraestructura local.
2. No se copia todo de la misma manera
Una de las decisiones que tomé fue diferenciar las copias de sistemas completos de las copias de grandes volúmenes de datos.
Máquinas virtuales y contenedores
PBS es muy eficaz para automatizar las copias de seguridad de Proxmox, de hecho es la herramienta ligada por completo a Proxmox. De este modo puedo hacer copias de los LXCs y las maquinas enteras (cualquiera de los tres nodos ) directamente mediante Proxmox Backup Server y en el propio PBS elijo donde quiero que guarde fisicamente esa copia. Esto permite recuperar una máquina completa sin tener que reconstruirla desde cero, simplemente indicándole lo que quieres restaurar y dónde.
Documentos
Para mis documentos, que tengo principalmente almacenados en Nextcloud, por ejemplo, ocupan unos 300 GB que copio mediante un script independiente, utilizando el cliente de PBS, de hecho este es el proceso mas manual y que menos me gusta, pero dado que tengo separada la propia LXC del almacenamiento en este caso parece lo mas eficaz, aunque engorroso y sin duda uno de los puntos mas débiles de toda la infraestructura.
Biblioteca digital
El resto de información digital no sería complicado de volver a obtener, aunque si sería un proceso laborioso; libros, cómics, audiolibros, etc ... ocupan aproximadamente 81 GB. También utilizo un script específico para respaldar este contenido desde el servidor correspondiente.
Esta separación me permite controlar cada proceso, programarlo de forma independiente y evitar mezclar los backups de infraestructura con los grandes conjuntos de archivos personales.
Código fuente
Esta es una de las cosas que más me preocupa, pues últimamente ha crecido enormemente, en el código fuente se incluye todas mis webs, con sus datos y las aplicaciones que he ido desarrollando desde hace 20 años, con lo que me jodería bastante perderlo.
LXCs
El resto de maquinas se respaldan completamente y la recuperación de las mismas es entera, sin necesidad de scripts ni nada por el estilo, todo con las propias copias de Proxmox.
3. Horas de los backups
Seleccionar el horario de los backups no es sencillo. Muchas herramientas (nextcloud por ejemplo) realizan procesos internos de madrugada, y sino te fijas pueden llegar a chocar con tus propios backups y montar un buen pollo (hablo por mi propia experiencia concretamente con nextcloud y un proceso que tiene a las 2.00 ó 3.00 AM ). Por eso, todos los días se ejecuta una secuencia de tareas. La distribución de los horarios se hace para tratar de evitar que se solapen con procesos intensivos de lectura, escritura o transferencia.
| Hora | Proceso | Duración aproximada |
|---|---|---|
| 00:00 | Garbage Collection | 18 min |
| 01:30 | Biblioteca digital | 4 min |
| 03:00 | Datos de Nextcloud | 20 min |
| 06:30 | VMs y contenedores Proxmox | 11 min |
| 08:00 | Prune (retención) | Segundos |
| 08:30 | Sincronización con Hetzner | 6–20 min |
| Domingo 04:00 | Verificación de integridad | 2 h 10 min |
En mi caso, una infraestructura con cientos de GBs de información no necesita pasar horas transfiriendo datos todos los días. Aquí es donde PBS resulta especialmente interesante.
Gracias a las copias incrementales y a la deduplicación, tras el primer backup lo único que es necesario transferir son los nuevos bloques. La duración dependerá de la cantidad de información modificada, pero como se puede ver en la tabla anterior el tiempo empleado es bastante bajo. Por simplificarlo, solo se envía al backup la parte modificada.
Por otro lado, separo la sincronización con el servidor remoto de la ventana de backups locales para evitar en la medida de lo posible competir por recursos.
4. Guardar todo acabaría consumiendo todo el espacio del mundo
Hay que decidir que guardar y cuanto tiempo guardarlo, yo me he decantado por la técnica mas común porque lo que tengo claro es que conservar indefinidamente todas las versiones de nuestros backups es inviable y absurdo. En mi caso he optado por guardar la ultima semana completa, y después la ultima copia semanal, mensual y anual. Así siempre conservo una copia de cada mes y una copia de cada año.
Mi política de retención local es la siguiente:
| Frecuencia | Copias conservadas |
|---|---|
| Última copia | 1 |
| Diarias | 7 |
| Semanales | 5 |
| Mensuales | 12 |
| Anuales | 3 |
PBS se encarga de gestionar todo esto con sus trabajos Prune, que se encargan de eliminarlas referencias a los snapshots que ya no deben conservarse. Luego pasa el Garbage Collection (GC), que se encarga de sacar la basura, liberar el espacio según los bloques dejen de estar referenciados por ningún backup y como dice su propio nombre indica libera espacio.
Son dos operaciones diferentes: por un lado eliminamos los snapshots antiguos y por otro lado recuperamos el espacio inmediatamente.
5. El backup externo: Hetzner Object Storage
Tener copias en otro disco o incluso en otro servidor de casa no es suficiente para ciertos escenarios. Me preocupaba especialmente la ubicación física.
Un fallo eléctrico grave, un robo o cualquier incidente que afecte a toda la instalación podría dejarnos sin los servidores y sin las copias, y hay muchas cosas que me han llevado mucho tiempo guardar.
Por eso incorporé Hetzner Object Storage, utilizando su interfaz compatible con S3 y la integración de PBS.
Cada mañana, a las 08:30, se ejecuta un trabajo de sincronización desde Qnap hacia HetznerOffsite.
La ventaja es que no necesito volver a generar todas las copias ni desarrollar un mecanismo propio de transferencia: PBS administra la replicación de los backups.
Hay una precaución importante: replicar backups no equivale automáticamente a tener copias inmutables. Una protección robusta también requiere revisar permisos, credenciales y retención del destino externo para evitar borrados accidentales o maliciosos.
6. Verificación de los backups
Parte crítica que no solemos hacer es la verificación de los backups, y es parte crítica. Todos los domingos a las 04:00 se ejecuta un trabajo de verificación sobre Qnap.
PBS comprueba la integridad de los datos almacenados, evitando tener que descubrir un problema de corrupción justo cuando necesito restaurar una máquina.
Actualmente utilizo una ventana de reverificación de 60 días, omitiendo los snapshots recientemente verificados. En mi infraestructura, este trabajo tarda aproximadamente dos horas y diez minutos. Aun así, una verificación no es suficiente.
Verificar la integridad de un backup no es lo mismo que probar su restauración.
Una práctica que recomiendo es restaurar periódicamente una VM de prueba, recuperar algunos archivos y comprobar que los servicios realmente arrancan.
Es la única forma de verificar todo el procedimiento de recuperación, no solamente los datos almacenados. Con Proxmox es bastante sencillo, simplemente indicas que quieres restaurar una maquina, seleccionas el backup (puede ser externo o local) y lo despliegas en una maquina nueva (teniendo en cuenta que tendrás que cambiar la IP y el hostname al menos).
7. Queda mucho por hacer
Mi estrategia no está completamente terminada. Y es que siempre hay cosas que se quedan fuera por un motivo u otro. Hay un conjunto importante de fotografías, aproximadamente 341 GB, cuya copia independiente todavía tengo pendiente de probar e incorporar.
También quiero seguir mejorando los procedimientos de restauración, especialmente para situaciones en las que haya que recuperar el entorno completo. He hecho ya alguna prueba debido a algún problema reciente y ya lo compartiré aquí mismo.
No persigo una disponibilidad empresarial: en mi caso puedo asumir varios días de recuperación ante un desastre grave. Lo que no quiero asumir es la pérdida definitiva de mis datos.
Conclusión
La lección más importante que he aprendido montando esta infraestructura es que una buena estrategia de backups no necesita ser compleja, pero sí automática, verificable y estar distribuida físicamente.
Proxmox Backup Server hace gran parte del trabajo pesado: copias incrementales, deduplicación, retención, garbage collection, verificación y sincronización.
Hetzner proporciona el almacenamiento externo.
Y yo puedo seguir cacharreando con mi homelab sabiendo que, si algo sale mal, tengo opciones reales de recuperación.
Porque romper cosas forma parte de tener un homelab. Perder todos tus datos no debería formar parte de la experiencia.