Skip to content

Copias, capacidad y recuperación: aplicación 19 octubre 2026

Revisión/aplicación posterior a review-next-backups-20261019.md, alrededor de 22:28–22:35 CEST. Usuario autorizó aplicar las mejoras con agentes simultáneos. No se ha interrumpido ni relanzado la copia de originales; no se ejecutó scrub, no se borraron generaciones y no se modificó la autenticación del NAS.

Aplicado y verificado

  • backup_originals.py publica --metrics: éxito y antigüedad por los cuatro grupos, actividad observada, estado, muestras, reserva y bytes de E/S del proceso. Estos últimos son E/S del proceso, no bytes de archivos verificados ni un porcentaje fiable. El observador reconoce también la transferencia antigua.
  • Cliente mantenido: escritura atómica privada del estado, heartbeat cada10s, progreso E/S, error persistido sin argumentos/rutas privadas y lock ocupado identificado mediante skipped_locked/exit75. El mismo lock protege el cliente y la continuación ya en espera. Un timeout abrupto puede impedir persistir el error: la alerta de proceso ausente cubre ese caso.
  • Muestreo futuro: tres archivos diarios rotativos más un archivo grande de hasta 4GiB si existe candidato. SHA256 completo en origen/destino y restauración aislada completa; ya no se eligen siempre los primeros nombres. El límite evita que una muestra agote los41GB libres observados en VM208. Un archivo vivo cambiante hace fallar la validación y conserva staging; no se publica como bueno.
  • Colector existente pvesr-collect.sh, mismo cron cada5min: pmx51 observa VM208 vía acceso SSH ya existente; pmx50 consulta statvfs de CT186. No se añade cron, daemon, base de datos ni plataforma. VM208 tiene textfile deshabilitado: se reutiliza el textfile existente de los hosts Proxmox.
  • Ocho alertas añadidas a Prometheus existente: colector ausente/fallido, transferencia detenida, error, frescura de originales, reserva de originales, reserva PBS, proyección PBS y colector de capacidad PBS. Primer ciclo de originales tiene24h de gracia; después se exige éxito dentro de48h por grupo. PBS avisa con menos de64GiB o15% libres. Proyección a14d usa7d de datos y no actúa hasta disponer de3d de muestras. No cambia rutas ni receptores de avisos.
  • promtool check rules confirma81reglas válidas. Prometheus recoge los dos colectores con valor1; no había alertas nuevas activas. Diecisiete tests locales pasan: nueve del receptor restringido y cinco del cliente y tres del verificador nativo Paperless.

La copia inicial y su continuación ya habían cargado código antiguo antes de esta aplicación. No adquieren retroactivamente el heartbeat/muestreo nuevo; sí son observadas pasivamente por las métricas nuevas. El cliente instalado y la tarea RunWisp diaria existente usarán las mejoras en invocaciones posteriores.

Ensayo PBS real cerrado

Coordinado con el responsable RAM antes de iniciar, para evitar medir N-1 durante el ensayo. Ejecutado directamente el motor común en pmx50, sin wrapper de avisos:

python3 /usr/local/bin/pbs_restore_drill.py lxc --target 123

Resultado: status=ok, isolated=true,22s. Restauró la copia reciente de CT123 (~828MB comprimidos), eliminó red/mounts/hooks/dispositivos del invitado temporal, arrancó con512MiB/1core y comprobó estado running. Eliminación posterior confirmada: config9901, volúmenes9901 y lock de cluster ausentes. Producción no se modificó. Esto acredita ese arranque aislado desde PBSmain, no el funcionamiento completo de todas las aplicaciones ni de los originales NFS.

Estado y retención conservadora

  • main: aproximadamente179GiB disponibles,63%usado; daily2/weekly1.
  • archive:229GiB disponibles,85%usado; daily7/weekly8/monthly12.
  • GC/prune/sync y verify recientes ya habían finalizado correctamente.
  • Se conserva esa política; no se recorta la historia por el porcentaje aislado. Las métricas nuevas permiten medir tendencia y alertan antes de agotar reserva.
  • Originales: una primera generación; documentos/proyectos completos, fotos copiándose y pics pendiente en continuación. No hay generaciones anteriores elegibles para poda segura. Se conserva todo y la reserva64GiB bloquea nuevas copias antes de llenar el destino. No se ha instalado una poda automática: habilitar borrado con la clave de escritura ampliaría sus permisos sobre las generaciones completadas. Su restricción actual se mantiene.
  • Para una poda futura: exigir al menos dos generaciones completas verificadas, preservar las dos últimas buenas y la base diaria/semanal/mensual elegida, ejecutar primero inventario/estimación de bloques realmente recuperables, conservar parciales de fallo para revisión y comprobar restauración antes de retirar historia. No usar suma de tamaños aparentes de hardlinks como ahorro.

No se confunde la antigua sincronización pics con una copia acreditada actual: la línea nueva tiene generaciones distintas. No se contrata ni se presupone un destino offsite.

Recuperación de aplicaciones: Paperless verificado, Immich pendiente

Corrección verificada a23:03CEST: Immich v3.2.0 tiene14dumps nativos *.sql.gz bajo photos/backups,2.570.127.148bytes en total; último19oct00:00:31UTC, 184.550.835bytes, CRC gzip correcto. El recuento anterior incluía un sentinel de13bytes y atribuía su mtime a un dump. Ese directorio forma parte de la fuente de fotos en curso. DB runtime: Postgres16 con imagen vectorchord0.4.3/pgvectors0.2.0. Originales y biblioteca externa necesitan, respectivamente, los grupos photos y pics. Paperless usa Postgres17; media/consume están bajo documents, data/export y BD están en VM208. La copia de media sola no equivale a exportación recuperable.

Procedimiento de recuperación: para Immich esperar photos/pics completos; Paperless puede usar su exportación nativa con documents ya completo (ensayo ejecutado y detallado debajo):

  1. Confirmar manifiestos publicados y frescura; comprobar CRC del dump Immich elegido y obtener imagen/digest exactos, sin exportar env/credenciales.
  2. Asociar el dump a su generación de archivos. La copia rsync en caliente no constituye por sí sola un punto transaccional entre BD y archivos; ante cambios concurrentes se necesita una ventana coherente o snapshot coordinado.
  3. Paperless: preparar exportación nativa a un directorio nuevo privado; preservar usuarios, metadatos, originales y manifiesto. No sobrescribir exportaciones anteriores ni usar opciones de borrado sobre producción.
  4. Restaurar en espacio temporal independiente, sin IP pública/red compartida, sin montar NFS de producción con escritura y sin tocar bases vigentes. Dimensionar RAM/espacio y coordinar antes de arrancar otros servicios de prueba.
  5. Importar en una BD vacía del mismo tipo/versiones; verificar conteos y una muestra de originales/documentos abriendo su contenido. Eliminar únicamente recursos temporales identificados como propios; conservar evidencia del fallo.

El ensayo completo de Immich no se declara ejecutado: fotos/pics siguen pendientes. Paperless sí se ha exportado e importado de forma aislada como se detalla debajo. No se ha parado ninguna aplicación para forzar una copia durante la transferencia.

Fuentes oficiales: Immich backup/restore y Paperless administración/exporter.

Recuperación de la configuración

  • VM208 cliente anterior: /home/monxas/scripts/backup_originals.py.before-observability-20261019.
  • Ambos hosts colector anterior: /usr/local/bin/pvesr-collect.sh.before-originals-20261019.
  • CT217 reglas anteriores: /home/monxas/appdata/prometheus/alerts.yml.before-originals-20261019.
  • Revertir solo grupos nas-originals/pbs-capacity, validar con promtool y recargar Prometheus mediante HUP. No sobrescribir otras reglas cambiadas después.
  • La reversión no borra copias, manifests, staging ni cambia calendarios RunWisp.

Corrección tras publicación: entorno cron del colector

El coordinador detectó PBSDataCapacityCollector pending tras publicar: bajo cron, el nuevo bloque ejecutaba pct sin /usr/sbin en PATH. La primera validación interactiva había dado1 pero no cubría cron. Se reprodujo con entorno mínimo: timeout devolvía127 por herramienta ausente. /datastore y /archive existían correctamente en CT186; no era un fallo del almacenamiento.

Se añadió al inicio del colector export PATH=/usr/sbin:/usr/bin:/sbin:/bin, desplegado en ambos hosts y publicado por el coordinador en 515801a. Prueba exacta con env -i HOME=/root PATH=/usr/bin:/bin /bin/bash …: capacidadPBS1, originales1 y réplicas presentes en el nodo con jobs origen. En pmx50 sin jobs origen es correcto que pvesr.prom solo tenga las cabeceras. Tras el siguiente scrape Prometheus devuelve ambos colectores1 y ninguna alerta Originals/PBSData.

Paperless: exportación nativa y restauración aislada desde cero

Cerrado alrededor de22:49CEST. Producción3.3.2,146documentos. Exportación nativa nueva privada en VM208:400archivos/84.596.701bytes, batch25, un CPU y límite virtual 512MiB solo al proceso exportador; conexión PostgreSQL con PGOPTIONS read-only. Una primera carpeta vacía falló por permisos y quedó preservada; la exportación buena no sobrescribe ninguna anterior. Producción siguió running/healthy/OOMfalse.

Bundle privado: /home/monxas/appdata/paperless/export/recovery-20261019T203532Z. Copia independiente del NAS en CT218: /root/paperless-recovery-20261019T203532Z/input. El verificador mantenido paperless-verify-export.py comprueba todos los originales contra checksums del manifiesto y produce únicamente conteos/hash agregado.

Ensayo final de la fuente mantenida paperless-recovery-drill.py desde destinos vacíos, no reparación de una importación previa: migraciones SQLite, importador nativo, reconstrucción del índice, lectura/validación. EntradaRO, directorios temporales propios, usuario1000, cap-dropALL/no-new-privileges, filesystem raízRO, sin puertos y sin credenciales de conexión a producción. Se omite /init para no iniciar workers/web/supervisor. El fixture crea explícitamente el directorio del índice y emplea Redis efímero en el mismo namespace networknone:768+64MiB, sin swap adicional, CPU conjunto1. No hay acceso al NAS ni a la BD de producción.

Imagen de origen 48c4b518…, destino b20d8cd1…: Docker de origen y destino representan los IDs con formatos diferentes. Antes de ejecutar se compararon RootFS, Config, arquitectura y OS idénticos, no solo tag3.3.2/latest. SHA256 canónico RootFS: <REDACTED>; Config: <REDACTED>.

Cobertura Exportado Restaurado
Documentos y originales con checksum completo 146 146
Tags 44 44
Corresponsales 14 14
Tipos documentales 9 9
Notas 37 37
Usuarios exportados 3 3
PDFs abiertos y páginas comprobadas — 3

Guardian crea además su usuario AnonymousUser durante las migraciones. El validador exige los tres PK de usuarios exportados y permite únicamente ese usuario generado; cualquier otro extra falla. No se excluyó una diferencia sin explicarla: la tabla tiene cuatro usuarios, tres restaurados y uno generado.

SHA256 agregado de todos los originales, ordenados porPK, idéntico en export e import: <REDACTED>. Se abrieron3PDF con pikepdf y páginas no vacías, sin publicar su contenido. La prueba comprueba importación, datos, archivos e índice; no incluye login/UI ni integraciones externas, precisamente porque la red del fixture está aislada.

Tentativas previas expusieron requisitos del fixture: Redis para migraciones, UID1000 para leer el bundle privado y directorio de índice al omitir /init. No hubo OOM. Una validación provisional detectó el AnonymousUser antes de ajustar la comparación a usuarios exportados. La ejecución final pasó desde cero con la fuente final completa; no se declara reproducible basándose solo en reparar un directorio parcialmente importado.

Limpieza confirmada: los dos contenedores de la ejecución buena se eliminaron; se retiraron otros siete contenedores propios de pruebas detenidas y la imagen importada2,5GB. No queda contenedor homelab.recovery, daemon ni namespace de prueba activo. Redis previo de producción no cambió. Se mantienen bundle/input, SQLite/media restaurados, resultados y logs privados bajo el directorio del ensayo. El bundle ya es una copia independiente del NAS; aún no se ha publicado como nueva línea Synology ni como exportación nativa diaria automática. No se amplían permisos de su clave ni se contamina una generación originals completada.

La fuente del drill y el verificador están versionados para repetir el ensayo. Los resultados privados contienen la evidencia detallada sin copiar documentos, nombres personales, URLs privadas ni contenido a este informe.