Skip to content

Recuperación y ensayos PBS

Actualizado el 22 de octubre de 2026. El contenido anterior de esta página usaba VMID fijos 998/999 y ejemplos que arrancaban invitados antes de comprobar su aislamiento. Esos ejemplos están retirados. La versión histórica permanece en Git, no constituye un procedimiento vigente.

La guía del motor compartido es la referencia operativa: perfiles, VMID temporales reservados, validación de propiedad y volúmenes, cancelación, recibos privados y reconciliación de reservas retenidas. Ambos nodos tenían el helper corregido instalado mediante Ansible-pull natural en las observaciones de las07:55/07:58 del20oct. No se ejecutó otro ensayo.

Antes de una recuperación real

  1. Identificar la copia, su cobertura y las dependencias necesarias. Una copia rootfs no acredita datos externos NFS, consistencia de bases o secretos.
  2. Comprobar nodo propietario actual, recursos disponibles y que el destino está libre. No reutilizar un VMID de esta página o de un ejemplo antiguo.
  3. Acreditar el aislamiento antes del primer restore, no sólo antes del arranque: pct restore puede importar configuración raw LXC y montar recursos durante la restauración. El motor rechaza en origen lxc.*, mpN, devN, hooks, templates y rootfs ambiguos; no basta borrarlos después. Preparar también el destino sin red de producción y revisar sus volúmenes.
  4. Definir la validación funcional y de datos, y cómo retirar sólo los recursos creados por ese intento. Estar running no acredita recuperación de la app.
  5. Ante una tarea o propiedad incierta, conservar evidencia y reserva para reconciliación; no reintentar ni destruir recursos a ciegas.

No se proporciona aquí un comando genérico de restore o de arranque: los procedimientos dependen de la copia y del invitado. Los ensayos nuevos necesitan admisión acotada del host, boots/propietarios, espacio y memoria de esa operación, más aislamiento acreditado antes de restaurar; una muestra N-1 positiva no satisface esos gates. La incidencia de estabilidad continúa en el informe actual; esta guía no ordena esperar un plazo fijo ni autoriza un ensayo por sí sola.

CT220 Jellyfin: DATA-ONLY verificado, prueba funcional pendiente

La recuperación HA del mismo CT220 en un único nodo tiene evidencia del 19oct: migración gestionada y retorno, segmento HLS por CPU en pmx50 y VAAPI en pmx51. Es distinto de restaurar una copia tras pérdida/corrupción del rootfs. La fuente de migración acredita la primera copia PBS y la posterior protección del montaje; no acredita un restore PBS de Jellyfin. CT220 no está en la allowlist del motor.

Parte de la recuperación Autoridad y límite
Rootfs y configuración actual /opt/jellyfin/config, incluida data/data/jellyfin.db, viven en CT220. Hay que comprobar su presencia y cobertura en la copia concreta antes de dar esos datos por recuperables.
Seis bibliotecas Binds NFS de sólo lectura, shared=1,replicate=0; la réplica/rootfs no recupera sus contenidos ni demuestra disponibilidad del NAS. Conservar sus mapas como evidencia, sin conectarlos al ensayo.
Runtime Mantener Compose, selector CPU/VAAPI y artefacto de imagen identificado; una etiqueta latest no fija la versión de la restauración. No ejecutar compose up saltándose el selector.
Copia antigua VM208 Congelada al migrar. No es un rollback de los datos actuales: no arrancarla ni volver a ejecutar cutover.sh para recuperar CT220.

Configuración archivada observada el 22 de octubre

Se seleccionó explícitamente pbs:backup/ct/220/2026-10-20T23:13:48Z. La lectura de configuración, terminada a las 01:06:16 CEST del 22 de octubre, dejó el contenido sólo en RAM remota: seis MP RO con alias NAS configurados, ocho entradas raw LXC, idmap propio, reglas de dispositivos y nesting/keyctl. No hay devN ni hookscript. El rootfs declara 25.769.803.776 bytes (24 GiB); no es una medida del payload extraído ni de espacio disponible.

Los mapas u y g son iguales, sin duplicados ni solapamientos numéricos:

Inicio dentro del CT Inicio en host Cantidad, por cada tipo u/g
0 100000 1000
1000 1000 1
1001 101001 64535

La validez de estos rangos no acredita propietarios/ACL del payload ni permisos para crear un namespace destino. En particular, no reutilizar automáticamente el ID host 1000 ni suponer el mapa estándar 100000/65536. Los alias NAS se clasificaron desde la configuración, sin resolver symlinks ni acceder a medios.

Recibos privados conservados bajo ~/.local/state/jellyfin-idmap-native-bracket-5txen38j/:

  • config-ct220.json, SHA256 <REDACTED>.
  • closure.json, SHA256 <REDACTED>: bracket externo con configuración, boot del PBS y montaje estables. El lector de configuración por sí solo no acredita ese backing físico.

Índice y capacidad observados el 22 de octubre

A las18:31–18:32 CEST, el cliente PBS instalado leyó index.json de la copia seleccionada, usando la autoridad existente de PBSPlugin y manteniendo las credenciales en el nodo. El índice enumera tres archivos (dos didx y un blob); root.pxar.didx declara15.295.508.323 bytes y un checksum. En esa lectura no se leyó ni verificó el payload: esos campos no acreditan integridad, presencia de la configuración ni tamaño del árbol restaurado. PBS186 sigue en pmx50, CT220 en pmx51 y el backing consultado es PBS main local, sin archive NAS.

ZFS51 tenía85.441.917.440 bytes disponibles (79,58GiB). La propuesta de cuota 32GiB dejando64GiB libres requiere96GiB y no queda admitida. Es un presupuesto propuesto del ensayo, no una afirmación de que cualquier extracción sea imposible; una cuota menor requiere dimensionar su contenido y justificar el margen.

Las lecturas del catálogo no dieron tamaños admitidos: el primer proyector no recibió las filas del canal de logging; al incluirlo, la gramática esperada no coincidió con la salida real. Los ceros permanecen UNKNOWN, sin inferir ausencia de DB/WAL/SHM. Un diagnóstico posterior limitado a un nombre estructural del OS tampoco encontró una fila admitida. Esos intentos no crearon destino, CT o namespace ni extrajeron datos. Quedan como antecedentes del ejercicio; la extracción posterior de abajo usa otra copia y un destino admitido. No se convierten los UNKNOWN de catálogo en tamaños conocidos ni se repite el proyector.

Recibos seleccionados privados: jellyfin-index-current-n9lc060g/closure.json (SHA256 <REDACTED>), catalog-review.json, catalog-v2-native.json y catalog-format-diagnostic.json. La lectura de catálogo usa temporales locales propios del cliente PBS; no se exportaron filas privadas, nombres de medios ni credenciales al Mac.

Extracción DATA-ONLY verificada y retirada, 22 de octubre

Ejercicio de datos cerrado; prueba funcional de Jellyfin pendiente. Se extrajo root.pxar de ct/220/2026-10-21T23:12:05Z, PBS main local, a un dataset nuevo exclusivo en pmx50. La lectura previa de la copia20 y los UNKNOWN de catálogo quedan históricos; no se convirtieron en ausencia de datos ni tamaños cero.

El primer destino disponía de unos 185,2 GiB antes de crear. El intento terminó FAILED a las 19:38:17: aplicar ACL devolvió EOPNOTSUPP con acltype off, tras 12.099.944.448 B referenciados. Otro intento explícito comenzó a las 19:40:42 sobre un dataset NUEVO acltype posix/xattr sa, después de set/get/remove ACL correcto dentro de los seis mapas. Había 173,9 GiB disponibles antes de crear; se mantuvieron cuota/refquota 32 GiB más 64 GiB de margen, sin reducirlo para PASS.

El extractor seguro necesita el padre común dedicado root 0755; 0711 no bastaba. Dataset y rootfs admitidos inicialmente como privados 100000:100000/0700, sin exec, setuid, devices o shares; no se afirma ese modo tras aplicar el archivo. Los EACCES previos se conservan como fallos. No se relajó /root ni producción. Sólo se extrajo root.pxar mediante PBSPlugin y el mapa u/g archivado, sin pct restore, CT, configuración importada, HA, red de invitado, app o binds NAS.

  • Extracción: cliente/unidad rc0 a las 19:49:54, una invocación del intento nuevo; 12.101.683.200 B usados/referenciados. Tasa admitida 20 MiB/s frente a 10 MiB/s del intento fallido; CPUQuota 50%, MemoryMax 1 GiB e IO idle conservados.
  • SQLite: a las 19:50:59, dataset readonly y copia privada DB/WAL/SHM; quick_check devuelve una fila ok, 35 tablas contadas. Archivos presentes: DB 362.713.088 B, WAL 14.860.872 B y SHM 720.896 B, estables y con UID/GID dentro del mapa. Fuente sin escritura; copia privada y FD retirados correctamente.
  • Retirada: a las 19:51:07, ambos datasets, montajes y destinos ausentes; cinco unidades propias inactivas, sin force/recursive ni cambios de producción.

Recibos privados seleccionados: sqlite-verification.json, SHA256 <REDACTED>, y cleanup.json, SHA256 <REDACTED>. PR177 y PR178 mantienen candidatos inactivos con CI correcta. Esto prueba extracción y estructura SQLite de la copia, no coherencia completa de un backup en caliente, app funcional, NAS o failover HA. No se encadenan más restores: el alcance restante queda en el backlog global.

Aislamiento previo: límite de advanced restore

El motor actual debe rechazar esta copia: no añadir 220 a la allowlist para eludir el preflight. En las fuentes instaladas de pve-container 6.1.14 capturadas el 21 de octubre, API2/LXC ejecuta recover_config, copia orig_conf.lxc para root@pam, crea/monta discos, extrae y sólo después restaura configuración. Advanced restore con rootfs explícito sustituye rootfs/mpX antes de asignarlos, pero no elimina esa copia temprana de raw LXC/idmap. --unprivileged 1, --start 0 y --onboot 0 no equivalen a ignorar toda configuración archivada. Suprimir entradas después de pct restore llega tarde.

Create.pm usa parse_id_maps y userns_command para extraer root.pxar: el mapa afecta a los propietarios escritos, no sólo al arranque. Quitar idmaps después o aplicar un chown recursivo no acredita una recuperación correcta. El camino PVE restringido, distinto de root@pam, omite raw LXC pero puede recuperar otros campos/redes; tampoco constituye por sí solo un perfil aislado.

Primer hito propuesto: cuarentena de datos sin CT

La alternativa oficial es restaurar sólo el archivo root.pxar a un nuevo directorio local de cuarentena bajo un namespace de usuario admitido. La operación de archivo de proxmox-backup-client no aplica pct.conf como configuración PVE: no crea CT, red, MP ni HA. PVE ya usa esta operación mediante PBSPlugin::run_raw_client_cmd, con userns_cmd explícito. Esto define el mecanismo. Hay candidatos inactivos mantenidos por PR177; cada ejecución requiere su admisión propia, sin reutilizar credenciales o destinos implícitos.

Antes del primer payload deben cerrarse estos gates:

  1. Origen fresco: boots/owners de ambos nodos, PBS186/.22, backing, storage, datastore/namespace y snapshot exactos, más versiones/argv de binarios y helpers de confianza. Preservar la autoridad de credenciales/TLS existente; no exportar secretos a Mac, argumentos o logs.
  2. Namespace destino: definir un mapa seguro y comprobar autorizaciones locales subuid/subgid, newuidmap/newgidmap o lxc-usernsexec y capacidades necesarias. Acreditar cobertura de UID/GID/ACL del payload; si no se conoce, queda pendiente. El mapa observado no concede permiso ni prueba cobertura.
  3. Destino y cuota: directorio nuevo vacío, padres locales nofollow e identidades fijadas, ownership del namespace y montaje local con nodev,nosuid,noexec. Fijar cuota finita y capacidad libre/pool más margen de metadatos antes de extraer. Ni los 24 GiB declarados ni los 15.301.151.407 bytes del listado PBS prueban espacio requerido/disponible. La muestra N-1 instantánea de +681 MiB tampoco admite carga adicional. Este hito no precisa VMID; un CT posterior requerirá reserva fresca mediante el mecanismo existente.
  4. Ejecución finita: límites admitidos de CPU/RAM/IO/banda, cancelación con kill/reap y recibos privados. Ejecutar sólo binarios externos de confianza, nunca código, chroot o aplicaciones del payload. El cliente necesita acceso al PBS; no confundirlo con una red de huésped. Fallo/resultado parcial queda UNKNOWN, sin retry ni retirada destructiva automáticos.
  5. Verificación separada: inspección offline del árbol nuevo con contención de symlinks, propietarios/ACL, presencia de configuración/secretos sin valores y datos SQLite en lectura. No seguir enlaces hacia el host/NAS. Una eventual configuración CT se construirá desde cero, sin red/mp/raw LXC/dev/hooks y con arranque/HA desactivados antes de su materialización.

Fuentes primarias y alcance de autoridad

Las copias instaladas cacheadas de API2/LXC.pm y Create.pm fijan el orden anterior con SHA256 <REDACTED> y <REDACTED>, respectivamente. Son evidencia fechada del 21 de octubre, no atestación del host actual. Las referencias oficiales fijadas explican el mecanismo, sin afirmar que el checkout upstream sea byteidéntico al paquete instalado:

El ensayo posterior se dividirá en restore apagado y verificación de datos, y sólo después arranque aislado con CPU, red separada y medios de prueba locales admitidos. Comprobar SQLite y datos/configuración restaurados no demuestra coherencia funcional por sí solo: harían falta identidad/cuentas/bibliotecas, acceso y transcodificación acotados contra esa copia, sin publicar rutas ni usar credenciales de producción fuera del entorno privado. Los recuentos del 19oct son históricos, no resultados esperados de una copia posterior. La limpieza deberá exigir propiedad del intento; ningún fallo permite destruir CT220 o sus volúmenes/binds originales. Recuperación completa sigue pendiente.

Evidencia y límites

Las cifras de ocupación y retención de agosto que figuraban aquí eran históricas. Consultar la evidencia fechada antes de decidir políticas. No iniciar verify, prune, GC, benchmarks de red o rotación de credenciales para diagnosticar un síntoma sin acreditar primero su causa y su impacto.