Auditoría de copias y recuperación — 19 octubre 2026

Observación de solo lectura aproximadamente23:02–23:04CEST. No se han relanzado, interrumpido ni duplicado copias, ni ejecutado restore, scrub, poda o avisos. Se excluye expresamente contenido privado; las consultas de Immich solo devuelven conteos por prefijos públicos de montaje. Las cifras anteriores siguen siendo históricas salvo donde se renuevan aquí.

Primera generación: progresa y sigue incompleta

Grupo	Estado vivo	Muestras restauradas
documents	complete	3
proyectos	complete	3
photos	copying	0
pics	pending	0

Proceso183860, hijo rsync190064 y continuación timeout197548 vivos. Dos muestras del observador,21:02:17 y21:03:48UTC: rchar de rsync74.256.095.501→76.226.243.172B, wchar74.278.673.545→76.249.342.711B. Esto demuestra avance de E/S, no porcentaje ni bytes verificados en destino. No hay motivo observado para relanzar la copia. El cliente antiguo ya activo no publica source_bytes ni capacidad actuales; los ceros de esas métricas significan ausencia de datos y no cero espacio.

La fuente de tamaño conocida de la primera copia es photos~85,85GiB y pics~68,72GiB, con354GiB libres históricos en Synology durante su inicio. Ese inventario es compatible con terminar ambos y conservar64GiB, pero no es capacidad viva. No se calcula espacio restante con rchar/wchar. Acceso batch directo del Mac al Synology rechazado; no se consumió credencial ni se llamó prepare del receptor como consulta porque puede crear directorios. El cliente volverá a comprobar capacidad antes de pics; no se ha ampliado acceso ni cambiado restricciones.

Immich: corregida la frescura documentada, cobertura localizada

La afirmación anterior de15dumps y último19oct18:58UTC contaba todos los archivos, incluido un sentinel de13B. Hay14 *.sql.gz,2.570.127.148B; último real 19oct00:00:31UTC,184.550.835B. Validación gzip -t correcta en4,4s. No se leyó contenido SQL. Se corrige el párrafo en apply-next-backups-20261019.md. No se localiza un colector que reproduzca ese error: pg-dumps.sh filtra dumps por su extensión y publica atómicamente tras CRC. No procede corregir código basándose solo en la equivocación de inventario.

Runtime immich-server:v3.2.0, BD Postgres16/vectorchord0.4.3/pgvectors0.2.0. La consulta agregada a asset devuelve31.621 entradas:

Prefijo de originalPath	Entradas	Fuente host
/usr/src/app/upload/	10.829	/mnt/nfs_media/photos,RW
/mnt/pics/	20.792	/mnt/nfs_media/pics,RO
Otro	0	—

El volumen anónimo adicional /data existe pero está vacío: cero entradas, du4KiB; no contiene originales omitidos por esos grupos. No se deduce un fallo de cobertura de su mera existencia. Los31.621 registros localizan rutas; no demuestran que todos los archivos existan, sean íntegros o estén ya respaldados.

Exportación lógica general _pgdumps: cinco dumps Immich y cinco Paperless; últimos183.486.870B y1.521.715B, edad~21,56h. Son otra línea local cubierta por el disco de VM208/PBS, no prueba independiente de originales ni de restore. La BD y los archivos copiados en caliente siguen sin punto transaccional común. Esperar photos/pics y comprobar manifiestos; después preparar un ensayo aislado con relación explícita dump/generaciones, versiones y conteos de originales.

PBS: reserva cercana en archive, sin alarma actual

Capacidad directa CT186:

Destino	Libre observado	Uso	Margen respecto al umbral15%
main	178,34GiB	63%	amplio en esta muestra
archive	229,19GiB	85%	~2,56GiB

El colector existente funciona: pbs_capacity_collection_success1, originals_collection_success1; Prometheus no tiene alertas Originals/PBSData activas ni pending. Archive tiene15,169% libre; el margen pequeño es hasta el aviso15%, no hasta agotamiento ni hasta la reserva64GiB. Archive/PBS vive en TerraMaster; la copia de originales va al Synology y no consume ese margen. La proyección acumula80muestras: todavía no acredita3d y no se ofrece una ETA. No se recorta historia ni se recomienda borrar por el porcentaje aislado.

Política efectiva confirmada: main daily2/weekly1; archive daily7/weekly8/monthly12. Verify main sábado02:00, archive domingo08:00; sync main→archive06:00 diario. Último sync19octOK; backups CT219/220 de esta tardeOK. Lectores auxiliares con connection error: not connected posteriores al drill/sync no invalidan por sí solos el resultado superior; el restore aislado documentado sigue siendo la prueba de recuperación correspondiente. No se ha repetido para esta auditoría.

Próximas mejoras concretas

1. Completar primera generación y cerrar recuperación Immich. Mantener proceso actual; un éxito del observador o CRC de dump no sustituye ese cierre.
2. Hacer la capacidad Synology observación real de solo lectura mediante el receptor existente, sin prepare ni nuevos permisos de shell. Hoy la métrica reserva conserva una foto al inicio de cada grupo y puede faltar en el cliente antiguo; no detecta crecimiento externo durante el resto del día.
3. Medir tendencia PBS durante al menos3d antes de ajustar retención; archive está cerca de emitir aviso. Mantener última generación buena y reserva; no instalar poda que use la clave de escritura para borrar completados.
4. Automatizar exportación nativa Paperless coherente dentro del propietario RunWisp existente y conservar su bundle independiente. El ensayo anterior ya pasó, pero el bundle documentado no es todavía una línea diaria Synology.
5. Reconciliar el documento canónico backup-retention.md con evidencia actual: misc incluye186/305, CT186 tiene cuatro snapshots recientes en PBS (último 19oct03:30UTC), archive daily7 y la lista antigua de guests/replicación está desactualizada. Backup del rootfs de PBS no elimina la dependencia de poder arrancar otro PBS apuntando al datastore para recuperar ese mismo backup.

Offsite continúa sin evidencia; no se propone destino contratado ni se modifica su custodia. La auditoría no demuestra integridad completa, recuperación de todas las aplicaciones ni estabilidad física futura de almacenamiento.