Revisión del homelab — 19 octubre 2026, noche

Solicitud: investigar caché del NAS, mejor aceleración por host, capacidad N-1 y prioridades de mejora. Tres agentes revisaron almacenamiento, Jellyfin y HA/RAM; revisión central de rutas y un secreto conocido de Vaultwarden. Lecturas en vivo aproximadamente 21:28–21:37 CEST, más dos sondas sintéticas de 15 fotogramas en Jellyfin. No se cambiaron configuraciones ni se reiniciaron equipos durante esta auditoría. La documentación sí se corrige con los resultados.

Conclusiones que sustituyen recomendaciones anteriores

1. Conservar por ahora la caché en writethrough. No está demostrado que causase la corrupción; retirarla inmediatamente no tiene justificación suficiente con los datos recogidos.
2. No ejecutar el scrub sugerido por el traspaso antiguo. Contradice los bloqueos scrub/NFS reproducidos y las reglas operativas vigentes.
3. Jellyfin todavía no usa toda la aceleración disponible. Intel decodifica y escala por GPU, pero codifica por CPU. La GPU AMD está desactivada por configuración, no ausente físicamente.
4. N-1 es condicional y ajustado. El OK depende de reclamar 2 GiB teóricos de VM208; el margen observado es unos 594 MiB.
5. Prioridad de datos: acreditar copia independiente de originales del NAS. Los backups PBS de invitados no incluyen sus montajes NFS.

NAS: hechos, hipótesis y beneficio de la caché

Lectura actual	Resultado
dm-cache	writethrough, smq, metadata2
Bloques sucios	0
SSD	P310 500 GB, 465,5 GiB efectivos
Aciertos/fallos de lectura desde arranque (~11 h)	23.089 / 4.844, 82,7 % por operaciones
SMART SSD	PASSED, 32 °C, 12 % usado, spare 100 %, errores de medios/integridad 0
HDD	Sin realloc/pending/offline-uncorrectable/CRC observados
RAID	RAID5 [UUU], bitmap; no journal/PPL observado
Btrfs	Contadores de dispositivo 0; sin nuevos errores visibles en dmesg
Tareas bloqueadas	Ninguna en D en la muestra

Writethrough completa una escritura cacheada cuando alcanza origen y caché. Los resultados históricos del 18-oct ya muestran este modo antes del incidente; no se acreditó un cambio reciente desde writeback. El histórico lo sitúa desde la sustitución del SSD en mayo.

Los bloques marcados dirty tras un cierre no limpio no prueban corrupción de la caché: dm-cache documenta que los considera todos sucios al reiniciar. Tampoco el patrón de 512 KiB identifica por sí solo al culpable: coincide con el bloque de caché y con el chunk del RAID. La causa sigue abierta. Documentación del kernel.

Retirar caché puede simplificar la pila y eliminar una capa de metadatos y un dispositivo del camino de E/S. A cambio se pierde la aceleración de lectura que aporte. El 82,7 % acredita uso, no ese porcentaje de mejora: faltan bytes, latencias y comparación bajo carga normal. La muestra pasiva corta casi no tuvo lecturas. Medir con las herramientas existentes antes de decidir; no convertir dirty=0 en garantía de retirada instantánea y segura.

La reconstrucción de CSUM_TREE en /root/csum-rebuild/rebuild_csum_leaf.py restauró estructura/legibilidad, pero generar checksums de los bytes actuales no demuestra que todos sean los originales. Comparar con copias o manifiestos anteriores donde existan; no confundir contadores limpios con autenticidad histórica del contenido.

NUT tiene configuración, pero no se acreditaron procesos/dispositivos UPS activos. Esto no demuestra ausencia de SAI físico: falta verificar protección y apagado coordinado. El selfheal escribe algunas líneas de intención antes de sus guardas; contarlas no acredita ese mismo número de reinicios.

Existe un md parity check previsto para 20-oct a las 04:00, limitado a 50 MB/s. No es el scrub Btrfs y no se ha modificado ni iniciado aquí.

Protección de originales

Datos	Ubicación comprobada	Cobertura acreditada
Immich originales	NAS Media/photos, montado en /usr/src/app/upload	Sin copia independiente reciente acreditada
Biblioteca externa iPhone	NAS Media/pics, montado en /mnt/pics	Syncthing en Synology: copia física sin versionado; origen pendiente de certificar
Paperless documentos	NAS Media/documents/media y consume	Rescate manual del 18-oct en pmx-51; actualización posterior no acreditada
Proyectos/documentos	NAS Media/proyectos	Rescate manual del 18-oct; actualización posterior no acreditada
Syncthing NAS	NAS syncthing	Rescate manual, no prueba de backup periódico

pmx-51:zfs-ha/rescate-nas ocupa 2,01 GiB y contiene documents, proyectos y syncthing, sin photos/pics y sin snapshots del dataset. No se encontró tarea que mantenga actualizado ese rescate en las ubicaciones revisadas.

PBS main es independiente del NAS para recuperar invitados: CT186 almacena /datastore en ZFS local de pmx-50. PBS archive depende del propio NAS: /archive usa un loop respaldado por /mnt/pve/terramaster/pbs-archive.img, 1,5 TiB, en NFS .20:/Volume1/backups. La sincronización sigue a las 06:00. Esto protege discos de invitados; no incorpora automáticamente Media del NAS.

El disco virtual de VM208 es de 200 GiB; /mnt/nfs_media es externo. El USB de backup no estaba montado. No se localizaron jobs de photos/pics en cron NAS o RunWisp208. Synology .160 se verificó después en vivo, sin despertar equipos: online 237 días, Syncthing pics en /volume1/backups/terramaster/pics, sendreceive. Declaraba idle, 23.700 archivos y 73.921.743.756 bytes (~68,84 GiB) locales iguales a globales, sin pendientes, errores ni ignore patterns; último cambio a las20:48:43. No tiene versionado configurado. Hay otra copia física, pero borrados y modificaciones pueden propagarse. No se certificó el peer que alimenta la carpeta ni se compararon archivos. No aparecieron carpetas Syncthing activas de photos/documentos ni tareas HyperBackup actuales. Offsite no acreditado. Límites de sincronización y backup.

Prioridad: copia versionada e independiente de fotos/documentos, confirmar destino/capacidad existente y restaurar una muestra de forma aislada antes de cambiar topología de almacenamiento.

Jellyfin: actual y mejor alcanzable

Host	Actual	Mejora alcanzable pendiente
pmx-51 N5095, Jasper Lake	VAAPI decode/scale; libx264 encode por CPU	VAAPI decode y encode H.264/HEVC por GPU, con HuC y low-power correctamente configurados
pmx-50 Ryzen 7735HS	CPU, sin /dev/dri	Radeon 680M VAAPI, tras investigar blacklist y validar estabilidad

En pmx-51 se observó HuC y GuC disabled, enable_guc efectivo 0 y firmware ehl_huc/ehl_guc instalado. Vainfo anuncia EncSliceLP, pero la prueba sintética de 15 frames, 320×180, bitrate 1 Mb/s falla: el driver solo ofrece CQP. La misma prueba con qp24 termina correctamente. Es una limitación real de control de bitrate con HuC inactivo, no un mero problema de permisos.

La vía documentada es preparar i915 enable_guc=2, actualizar initramfs y reiniciar en mantenimiento; después verificar HuC y probar CBR/VBR antes de activar codificación en Jellyfin. No basta crear hw-encode: el selector actual tampoco activa las opciones Intel low-power H.264/HEVC. Debe distinguir perfiles Intel/AMD/CPU y validar capacidades. Para Jasper Lake no cambiar ciegamente de VAAPI a QSV: Intel MediaSDK está retirándose para esa generación. Guía oficial Intel/Jellyfin.

En pmx-50 la Radeon 680M aparece en PCI (1002:1681), sin driver en uso; /etc/modprobe.d/blacklist-amdgpu.conf contiene blacklist amdgpu. No se encontró asignación VFIO a una VM ni ocultación física por BIOS. La razón original de esa blacklist no está demostrada. Investigar antes de habilitarla; introducir el driver mientras se diagnostican cuelgues añade otra variable. AMD/Jellyfin.

Las pruebas previas reales sirven HLS por ambos nodos, y la de Intel confirma HEVC VAAPI + scale_vaapi → libx264. Un resultado de 2,81× a aproximadamente 960×520 no acredita 4K ni concurrencia. Tone-mapping y VPP están desactivados: HDR→SDR requiere validación específica.

N-1: condiciones que el OK oculta

N-1 significa alojar en el superviviente el conjunto de servicios protegido al perder un nodo. No protege automáticamente todos los servicios del homelab.

Foto 21:30, supuesto fallo de pmx-51:

Componente	MiB
MemAvailable actual en pmx-50	13.502
RAM + swap actuales de los diez HA migrables	-12.908
Reserva del comprobador	-2.048
Margen sin reclamar RAM de VM208	-1.454
Balloon recuperable que supone el código	+2.048
Margen publicado como OK	594

VM208 tiene 8 GiB actuales, mínimo 6 GiB, 1.795 MiB disponibles dentro del invitado y 3.433 MiB de swap usada. Quitar 2 GiB supera en unos 253 MiB su disponible instantáneo; puede exigir reclamación o más swap. No se ensayó esa reducción como parte de una auditoría pasiva.

Los límites RAM de los diez migrables suman 19.328 MiB. El cálculo usa consumo actual, no todos sus picos o consumo de arranque. Además, el script toma siempre memory−mínimo como cedible; puede contar memoria ya devuelta en otro momento.

Los migrables son 100/123/155/171/212/213/214/215/216/220. Los estrictos 110/172/217/218 no arrancarán en pmx-50 si cae 51: se pierden temporalmente TV gateway, HA-ML, observabilidad y servicios personales. Si cae 50, los HA ya están en 51; eso no recupera VM208 ni el resto de invitados fuera de HA.

Jellyfin usa réplica cada 15 min: la recuperación incluye un reinicio y usa el último estado replicado. HAOS171 tiene failback=0 deliberado. El comprobador debe evitar tratar ese retorno no automático como fallo inesperado.

El comando normalidad contiene touch /mnt/nfs_media/.normalidad; no es una consulta estrictamente pasiva. Esta auditoría leyó su código y calculó cifras con consultas, sin ejecutarlo.

Mejoras del indicador: mostrar margen sin balloon, margen condicionado, disponible/PSI del invitado y valor balloon actual; enumerar exclusiones y límites de pico; definir cargas prescindibles que liberarían RAM en emergencia.

Salud y mejoras por orden

• Quórum 3 votos con QDevice; 14 HA started en 51; 14 réplicas sin fallos.
• Los 28 invitados tenían copias de menos de 21 h. CT219/220 tenían primera copia reciente. No se hizo una restauración durante esta revisión.
• Pools ZFS saludables: 50 al 76 %, 51 al 58 %. Raíces 17 % y 41 %.
• pmx-50 solo llevaba unos 35 min estable desde 20:55, con otro arranque a las 20:52; sin crash dump. Su causa de reinicio sigue sin demostrarse.
• pmx-51 tenía swap casi llena, pero PSI instantáneo 0 y media de 5 min descendiendo. Vera conserva MemoryHigh=MemoryMax=4 GiB y no se reinició.
• El controlador central mostraba 49 rutas, seis anfitriones y deriva del túnel 0. No se despertaron aplicaciones bajo demanda para repetir smoke.
• Confirmado en runtime que ADMIN_TOKEN de Vaultwarden no usa Argon2. Es un pendiente conocido; no se mostró el secreto ni se demostró exposición pública o compromiso. Endurecimiento oficial.

Orden recomendado: (1) originales y copia independiente/restauración de muestra; (2) estabilizar pmx-50 y acreditar UPS/apagado; (3) margen RAM real y N-1 condicional explícito; (4) completar Intel y mejorar selector en mantenimiento; (5) AMD después de estabilidad; (6) Argon2/secretos y ensayos de recuperación. Una ampliación de RAM es una opción a evaluar tras descartar avería; no se ha validado modelo, compatibilidad ni compra concreta en esta auditoría.

Evidencia histórica localizada

• Memoria local nas_nvme_failure_20260516.md: P310 instalado en writethrough el18mayo.
• Memoria nas_btrfs_metadata_corrupto_20261018.md: diagnóstico y reconstrucción.
• Transcripción local <REDACTED_UUID>.jsonl, resultados de herramientas160/165: writethrough antes del reinicio y0dirty, 18oct17:11–17:12UTC; resultado469: writethrough y~923kdirty después. No copiar íntegramente: contiene datos privados ajenos.
• homelab-docs/operations.md: prohibición de scrub; homelab-docs/evidence/efficiency-apply-2026-09-08/opportunities/coverage-note.md: separación originalesNFS/PBS.