Montar un homelab desde cero: backups y restauración - Homelab (06/06)

Un backup que nunca has restaurado es una esperanza, no un backup. Este post cuenta cómo se respalda el homelab — qué, cómo y a dónde — y la parte que casi nadie cuenta: cómo se restaura, y qué sé que todavía falta.

La regla número uno ya la conoces de posts anteriores: todo converge en spinoza, el TrueNAS de la red Atenas que corre MinIO, nuestro almacén de objetos compatible con S3 — que en casa tiene nombre propio: cervantes—. Un único destino offsite, al otro lado del túnel WireGuard, lejos de los clústeres de Roma. Y todo lo que se respalda llega hasta cervantes a través de la pasarela Tailscale que lleva su mismo nombre.

Qué se respalda y cómo

PostgreSQL: físico y lógico

La base de datos es lo más valioso del homelab, así que tiene dos capas independientes:

• Física, con CNPG y barman: el operador CloudNativePG archiva el WAL (Write-Ahead Log, el registro de cada cambio de la base) de forma continua y hace una copia base diaria a las 02:15, con 30 días de retención. Con WAL + copia base hay PITR (Point-In-Time Recovery): puedo restaurar la base a cualquier instante de esos 30 días, no solo al backup de anoche.
• Lógica, con un dump diario: además, un pod de pre-backup hace pg_dump en formato personalizado de las bases críticas. Es defensa en profundidad — si el formato físico falla, el dump lógico es portable a cualquier PostgreSQL—.

Typesense: file-level o reindex

El índice de búsqueda se respalda con K8up a nivel de fichero sobre el PVC, cada día a las 04:00. El schedule lleva un límite de 2 GiB de memoria porque restic moría por OOM sin él — un detalle aprendido a las malas—. Y si todo lo demás falla, el índice siempre puede regenerarse desde Postgres: es una derivada, no una fuente.

Lo que NO se respalda: Redis

Redis no tiene backup. Es un broker de colas — su contenido es transitorio por diseño—. Si se pierde, se recrea y los trabajos se reencolan. Respaldar lo efímero solo cuesta dinero.

Y en pizarro, snapshots ZFS

El nodo de pizarro añade una capa propia de protección: sus volúmenes de datos viven en un pool ZFS (OpenEBS ZFS LocalPV). Un planificador mantiene snapshots locales retenidos y VolSync los replica a restic — Harbor y los PVCs de monitorización quedan cubiertos dos veces: snapshot local para volver atrás al instante y réplica offsite para el desastre de verdad—.

El resto de la flota: tolstoi

Los hosts Docker y los VPS corren tolstoi, el agente de backup Restic del que hablamos en el post de seguridad: copia diaria a las 03:00 con retención de 7 diarias, 4 semanales, 12 mensuales y 7 anuales, llegando a MinIO a través de la pasarela Tailscale. En los clústeres, el mismo papel lo hace K8up por namespace.

Cómo se restaura

El runbook de restauración tiene un orden de preferencia:

1. Recovery de CNPG desde el archivo barman — la vía preferida: el operador arranca un clúster nuevo directamente desde las copias físicas.
2. Dump lógico — si solo hacen falta las bases de datos aplicación y auth, el pg_dump se restaura a mano.
3. Typesense — desde el snapshot de K8up, o reindexando desde Postgres si el snapshot falla.

La deuda pendiente

Dos cosas que no están resueltas y conviene decir en voz alta. Primera: no hay drills de restauración automatizados — los restores se han hecho a mano en pruebas, pero ningún proceso verifica cada semana que los backups realmente arrancan—. Segunda: MinIO es un punto único — el propio spinoza no tiene su protección representada en Git; si Atenas arde, el offsite también—.

Ninguna de las dos invalida el sistema, pero son las siguientes en la lista.

Cierre

Un sistema de backup decente es aburrido por dentro: destino único, dos capas para lo crítico, retenciones escalonadas y un runbook escrito. Lo interesante es lo que permite: reconstruir cualquier pieza del homelab sin pánico.

Anterior: Post 5 - Observabilidad