Copias de originales NAS — aplicación del 19 de octubre de 2026¶
Estado provisional, 22:04 CEST¶
Usuario autorizó aplicar la auditoría con varios agentes. Se reutiliza RunWisp208.
Documentos completos; proyectos completos; fotos en transferencia. La copia inicial
de pics del NAS queda encadenada automáticamente al terminar el proceso
actual, que cargó únicamente los tres primeros grupos. Un proceso finito espera
el mismo lock y continúa con el script mantenido de cuatro grupos. No presentar una copia
iniciada como terminada. El coordinador debe actualizar este estado al finalizar.
Última muestra:4.626.936KiB (~4,4GiB) en staging de fotos, aproximadamente5% de su
tamaño previsto; Synology354GiB disponibles. No es progreso verificado.
No se ejecutó scrub ni modificaron originales, exports, HA o almacenamiento.
Fuentes y destino¶
| Grupo | Fuente VM208 | Tamaño observado NAS (KiB) | Destino relativo Synology |
|---|---|---|---|
| documents | /mnt/nfs_media/documents |
80.132 | documents/FECHA |
| proyectos | /mnt/nfs_media/proyectos |
2.176.052 | proyectos/FECHA |
| photos | /mnt/nfs_media/photos |
90.021.872 | photos/FECHA |
| pics | /mnt/nfs_media/pics |
72.056.272 | pics/FECHA |
Raíz independiente Synology192.168.0.XXX:
/volume1/backups/terramaster/snapshots-originales.
Había360GiB disponibles antes de copiar. No es offsite. La copia preserva el estado
actual, sin reemplazar históricos ni demostrar autenticidad anterior a la corrupción.
Implementación¶
Fuentes: scripts/original-backups/backup_originals.py,
synology-receiver.py y runwisp-task.toml.
Cliente desplegado en /home/monxas/scripts/backup_originals.py.
Receptor en /var/services/homes/monxas/.ssh/originals-receiver.py.
Se añadió una clave Ed25519 específica VM208, restringida en Synology al origen 192.168.0.XXX, sin PTY/forwarding y con comando forzado. El login existente no cambió; no se almacenó la contraseña Synology en VM208. Se reutilizó la clave de host ya confiada del Mac; no se aceptaron claves nuevas.
RunWisp registró y validó originals_backup, diaria11:10 Europe/Madrid; recarga
sin reiniciar aplicaciones. Configuración previa:
/home/monxas/backups/runwisp-task-originals_backup-20261019T195612Z/runwisp.toml.
Se usa sudo -n para leer proyectos con backups root-only. Un intento inicial sin
sudo falló explícitamente; no se consideró completo ni se cambiaron sus permisos.
Copia serial finita, timeout5h, bloqueo contra solapamiento, comprobación del montaje y reserva64GiB más el tamaño entero del grupo siguiente. Proceso inicial24MiB/s; código mantenido48MiB/s para invocaciones posteriores, sin reiniciar la transferencia activa. Proyectos transfirió2.228.132.650bytes en~113s (~19,6MB/s).
Solo recibe en .incomplete-FECHA. Publica con rename tras rsync exitoso, tres
comparaciones SHA256 completas y tres restauraciones a directorios temporales
separados. Versiones posteriores utilizan --link-dest, sin --inplace, --delete
ni poda de anteriores. Receptor: cuatro grupos, opciones allowlist, escritura solo
sobre raíz staging exacta, lectura validada y link-dest únicamente completado del
mismo grupo. La clave de copias no permite modificar copias completadas. No es WORM:
el administrador del destino sí puede modificar los datos.
Un fallo conserva staging sin publicarlo. La siguiente ejecución reanuda la generación pendiente, incluso al cambiar de día. No hay borrado automático de históricos/parciales; el control de capacidad falla antes de agotar la reserva. Vigilar espacio y revisar retención antes de necesitar purgar. Son archivos y enlaces seguros, no un snapshot transaccional de todos los servicios. Las restauraciones de muestra no demuestran el arranque de Immich/Paperless ni la integridad criptográfica de toda la biblioteca.
Pics que ya existía en Synology¶
Peer identificado como Terramaster, pero desconectado. Índice local23.700archivos,
73.921.743.756bytes, needFiles0: no prueba sincronización actual con el NAS.
Antes del cambio se conservó la carpeta mediante cp -al en
snapshots-originales/pics-synology-before-versioning-20261019.
Conserva inodos frente a sustituciones/borrados de Syncthing, pero no frente a edición
administrativa in-place del mismo inodo.
Configuración previa:
/volume1/@appstore/syncthing/var/config.xml.before-originals-20261019.
API existente: únicamente carpeta fxcfs-3fth6 cambió de sendreceive a receiveonly,
con staggered365d (maxAge31536000s, cleanup3600s). Lectura posterior confirmó ambos.
La copia vieja queda separada de la nueva línea pics del NAS, sin mezclar fuentes
ni asumir que fueran idénticas. No se reactivó el Syncthing histórico del NAS,
que no escuchaba en el puerto local.
Verificación y continuación¶
Estado/manifiestos privados:
/home/monxas/.local/state/original-backups/last.json y GRUPO-FECHA.json.
Contienen nombres y hashes de muestras: no publicarlos completos.
Log inicial: 20261019.log en el mismo directorio.
Proceso inicial: timeout183858 → python183860.
Continuación finita: timeout197548, --after-current, espera el lock y ejecuta
los grupos pendientes; log 20261019-followup.log, límite exterior10h.
Documentos/proyectos tienen tres SHA256 y tres restores aislados correctos cada uno.
Nueve tests de regresión del receptor pasan en árbol temporal aislado, sin datos
reales. Cuatro intentos negativos por la clave real también fueron rechazados:
escribir completado, inplace, grupo ajeno y lectura fuera del árbol.
La continuación automática copiará pics tras documents/proyectos/photos; la tarea
diaria también incorpora cuatro grupos. Para reintento manual si hiciera falta
(el bloqueo evita carreras):
Consulta de estado sin nombres privados ni secretos:
Muestra inicial: RAID [UUU], sin resync, Dtasks0, iowait1–3%, load0,69;
Synology359GiB libres. No se ejecutaron tests extensos.
Se evaluó NFS directo para acelerar: UID1000/root-only fuente difiere del usuario1026
destino; exigiría ACL nuevas o helper root persistente. Se conservó SSH restringido.
Un montaje temporal diagnóstico de Synology en VM208 se desmontó y retiró;
fstab/exports no cambiaron.
Reversión¶
Retirar solo [tasks.originals_backup] del RunWisp actual, validar y recargar;
no restaurar el TOML antiguo sobre cambios ajenos. Retirar únicamente la entrada
originals-backups-vm208 de authorized_keys si se retira la automatización;
copia previa Synology: ~/.ssh/authorized_keys.before-originals-20261019.
No borrar snapshots/parciales al revertir configuración. Para Syncthing recuperar
únicamente campos de esa carpeta del backup previo, preservando otros cambios.
Volver a sendreceive permitiría enviar otra vez cambios locales hacia el peer.
Incidente de manejo de credencial¶
En la primera autenticación sudo de Synology, el PTY hizo eco de la contraseña en una salida de herramienta. No se reproduce aquí ni se guardó en scripts, argumentos, manifiestos o VM208. El canal se corrigió deshabilitando ECHO antes de enviar la credencial; las siguientes autenticaciones no la imprimieron. Se informó al coordinador para comunicarlo al usuario. No se rotó automáticamente: la credencial existente puede estar compartida por otros accesos e integraciones; hay que coordinar esa actualización para no dejar accesos incoherentes.