TPTito Pinardo Gutiérrez
← Artículos
English

De «sin copias» a copias cifradas que el propio servidor no puede borrar

Durante semanas, mi homelab tuvo un hueco reconocido: el código tenía dos respaldos, pero los datos no tenían copias periódicas. En un día monté Proxmox Backup Server con un disco solo para él, copias cifradas de todo cada noche, un permiso que no deja borrar y una restauración de prueba. Por el camino aparecieron dos sorpresas: un permiso que no bastaba y 158 GB que no iban en ninguna copia.

  • Proxmox Backup Server
  • Proxmox VE
  • ZFS
  • Linux / SSH hardening

El punto de partida

Los datos importantes viven en espejos y en RAIDZ, y eso protege de que muera un disco. Pero un borrado, un error o una corrupción llegan a todos los discos a la vez: un RAID no es una copia. Lo tenía escrito como pendiente, en rojo, y así lo contaba también la unidad de copias de esta web.

Lo que monté

  • Proxmox Backup Server en su propio contenedor, con un disco de 4,5 TB solo para él. Si el disco no está montado, el contenedor no arranca: nunca escribe copias en el disco del sistema.
  • Cada noche, a las 2:30, todos los contenedores, también los de documentos. Incrementales y con deduplicación: solo viaja lo que cambió.
  • Cifradas en el servidor antes de salir. La clave tiene una copia en mi gestor de contraseñas; quien se lleve el disco no lee nada.
  • Poda en el propio servidor de copias: 7 diarias, 4 semanales y 6 mensuales. Verificación todos los domingos: relee cada copia.
  • Avisos solo de fallos, en la sala de incidencias. Si no llega nada, ha ido bien.

Quien copia no borra

El servidor principal entra en el de copias con un token que puede hacer copias y restaurar, pero no borrar ni podar: eso solo lo hace el servidor de copias. Si alguien se hiciera con el servidor principal, lo primero que intentaría sería borrar las copias, y no podría.

Primera sorpresa: con el permiso puesto en el token, Proxmox decía que el almacén no existía. Lo que puede hacer un token es la intersección de sus permisos y los de su usuario, y el usuario no tenía ninguno. Con el mismo permiso en los dos, funcionó. Un «no existe» era un «no lo puedes ver».

158 GB fuera de la copia

Segunda sorpresa, al repasar qué entraba: los mundos de los juegos no estaban en la copia de su contenedor. Viven en el almacenamiento del servidor y se montan dentro, y Proxmox copia el disco del contenedor, no lo montado.

Ahora tienen su propia copia a las 3:30: una instantánea del almacenamiento, para copiar un estado coherente aunque haya alguien jugando, cifrada y al mismo servidor de copias. Y una regla escrita: si un contenedor guarda algo irrecuperable en un montaje, se añade a esa lista.

La prueba

Una copia sin restaurar no prueba nada. Restauré la del cliente de mensajería en un contenedor nuevo, sin arrancarlo para que no chocara con el original, y comparé fichero a fichero: 1.381 de 1.381, idénticos.

Qué no entra, a propósito: películas, series y juegos de Steam (decenas de terabytes que se vuelven a bajar) y el clúster de laboratorio, que se reconstruye desde código.

Lo que sigue faltando

Todo está en casa: el disco de copias está enchufado al mismo servidor. Protege de borrados, corrupción y discos que mueren, que es lo que ha pasado de verdad, pero no de un robo o un incendio. El siguiente paso es una copia fuera: un disco que se rota o un segundo servidor de copias en otro sitio. Sigue escrito en rojo hasta entonces.

Tres días después: la prueba cumple

Desde el 15-10, cada domingo se restaura sola una tanda de contenedores y se compara con los originales. El primer domingo falló en todos con «Permission denied». Las copias estaban bien: esa mañana, un despliegue del gestor de descargas había cambiado el dueño de todo lo que había en los discos de medios, y las copias viven en uno de ellos. 96.672 trozos pasaron a otro usuario.

Devolverles el dueño lo arregló, y el rol ya salta las carpetas que no son medios. Lo importante es cuándo lo supe: el mismo día, por la prueba, y no el día que hubiera necesitado una copia.