Proxmox PBS “datastore not found”: por qué PVE no lo detecta y cómo solucionarlo

Qué significa realmente “datastore not found” (y qué no significa)

En PVE, un datastore de PBS se descubre y usa vía la API HTTP de PBS (puerto 8007 por defecto). Cuando PVE dice
“datastore not found”, está ocurriendo una de estas cosas:

• El ID del datastore que configuraste no existe (error tipográfico, mayúsculas/minúsculas, nodo PBS equivocado).
• El datastore existe, pero tus credenciales no pueden listarlo o acceder a él (permisos, realm, token).
• PVE no puede comunicarse con PBS de forma fiable (DNS, enrutamiento, firewall, puerto, proxy, huella TLS).
• Estás lidiando con un desajuste de namespace (el datastore existe, pero el acceso está limitado por scope).
• Estás hablando con la instancia de PBS equivocada (VIP, NAT, DNS dividido, IP obsoleta, confusión de clúster).

Lo que habitualmente no es: un problema del sistema de ficheros en PBS. Si la interfaz de PBS muestra el datastore sano,
la queja de PVE casi siempre está en la capa de API/autenticación/configuración, no en que ZFS se haya comido tus backups.

Un apunte operativo: el texto del error a menudo se reutiliza para múltiples fallos de API. “Datastore not found”
es a veces una mentira piadosa que significa “no tienes permiso para verlo” o “no puedo autenticarte.” Las máquinas hacen esto
porque no sienten vergüenza.

Broma #1 (corta, relevante): Un “datastore not found” es el equivalente de almacenamiento de “no recibí tu correo.” Existe; alguien simplemente no lo admite.

Hechos y contexto interesantes (por qué aparece este error)

Un poco de contexto ayuda porque “datastore not found” es un modo de fallo moderno con raíces clásicas:
identidad, nombres y control de acceso. Aquí hay hechos concretos que influyen en cómo resuelves el problema:

1. Los datastores de PBS se identifican por ID, no por ruta. El ID es lo que expone la API; el directorio de respaldo es secundario.
2. PVE se integra con PBS a través de la API de PBS en el puerto 8007. Si el 8007 está bloqueado o interceptado, el descubrimiento falla aunque la UI de PBS funcione localmente.
3. Los realms de autenticación de Proxmox importan. root@pam y root@pbs son identidades distintas; los tokens heredan semántica de realm.
4. La huella TLS de PBS está fijada por PVE. Si el certificado TLS de PBS cambia (reinstalación, cambio de hostname), PVE puede negarse a conectar hasta actualizarla.
5. Los permisos en PBS son por ruta y por objeto. Tener “Datastore.Audit” no es lo mismo que “Datastore.Backup”. La falta de permisos de listado puede ocultar datastores.
6. Los namespaces introducen una dimensión extra de acceso. Un datastore puede existir y aun así estar bloqueado desde el namespace que intentas usar.
7. PBS guarda su configuración en /etc/proxmox-backup. Las definiciones de datastore son locales al nodo PBS; clústerizar PBS no replica configuraciones a menos que lo hagas explícitamente.
8. PVE guarda las definiciones de almacenamiento PBS en /etc/pve/storage.cfg. En un clúster PVE ese archivo se replica. Un cambio erróneo afecta a todos.
9. “Not found” es un patrón clásico de seguridad. Muchas APIs devuelven 404 para recursos no autorizados para evitar filtrado de información, lo cual es bueno para seguridad y malo para depuración.

Una cita para enmarcar la mentalidad. Es una idea parafraseada, porque la precisión importa:
parafraseado: “La esperanza no es una estrategia; necesitas evidencia.” — atribuida a la cultura de fiabilidad/operaciones.

Guía de diagnóstico rápido (comprueba 1, 2, 3)

Quieres el camino más corto hacia la certeza. No empieces reinstalando PBS ni reformatando nada.
Empieza demostrando dónde se rompe la visibilidad: red, identidad o nombre.

1) Demuestra que PVE puede alcanzar la API de PBS (puerto 8007) y que TLS no miente

• Si la conexión TCP falla: es red/firewall/enrutamiento/DNS.
• Si el handshake TLS se queja del certificado/huella: es confianza fijada.
• Si obtienes una respuesta HTTP: la conexión está bien; pasa a auth/permisos.

2) Demuestra que tus credenciales pueden listar datastores

• Si la lista de datastores está vacía o da error: permisos, realm, token o destino PBS equivocado.
• Si la lista muestra el datastore pero añadir sigue fallando: desajuste de ID del datastore, desajuste de namespace o drift de storage.cfg.

3) Demuestra que el ID del datastore coincide exactamente con lo que expone PBS

• Los IDs de datastore distinguen mayúsculas. Trátalos como nombres de objetos de la API, porque lo son.
• Confirma que no estás usando una ruta de filesystem ni un “nombre amistoso”.

Si solo tienes 10 minutos, haz esas tres comprobaciones. Detectan la mayoría de incidentes reales.

Mapa de fallos: dónde puede “desaparecer” el datastore

Piensa en esto como una cadena. El datastore es visible solo si cada eslabón aguanta.
Rompe cualquier eslabón y PVE dirá que “no se encontró”, porque desde su perspectiva realmente no existe.

Enlace A: PVE resuelve el hostname de PBS a la dirección correcta

DNS dividido, entradas obsoletas en /etc/hosts y reglas NAT “temporales” son clásicos. PVE puede conectarse a un PBS diferente
del que crees —especialmente en migraciones de laboratorio a producción o pruebas de DR.

Enlace B: El puerto 8007 es accesible y nadie lo está proxyando de forma extraña

Un proxy inverso que haga HTTP pero no WebSockets, un firewall que inspeccione TLS, o un balanceador L7
con comprobaciones de salud mal configuradas pueden producir comportamientos raros de la API. PBS es más estable cuando se accede directamente.

Enlace C: La huella TLS fijada en PVE coincide con el certificado actual de PBS

PVE almacena y verifica la huella de PBS. Si reinstalas PBS, regeneras su certificado o cambias el hostname, PVE puede empezar a rechazar conexiones de forma que resurja como “datastore not found” durante añadir/escanear.

Enlace D: La identidad que usas tiene permiso para listar y acceder al datastore

PVE puede autenticarse como un usuario (como backup@pbs) o mediante un token API. Pero el token debe existir,
no estar expirado/desactivado y tener los roles correctos. “Not found” puede ser PBS diciéndote “no tienes permiso.”

Enlace E: El ID del datastore es correcto y consistente

El ID del datastore no es el punto de montaje. No es el nombre del dataset ZFS a menos que lo hubieras hecho igual a propósito.
Si cambias el ID del datastore en PBS, PVE no te seguirá mágicamente.

Enlace F: Namespaces y expectativas de pruning/verification coinciden

Los namespaces pueden hacer que un datastore parezca vacío o inaccesible si no tienes permisos sobre el namespace.
Además, si esperas un namespace que no existe o está restringido, el comportamiento de PVE puede parecer que
el datastore “no existe”.

Tareas prácticas con comandos (12+ comprobaciones que zanjan debates)

Estas son comprobaciones de campo. Están diseñadas para ejecutarse y producir salidas que guíen decisiones.
Ejecútalas desde un nodo PVE primero, luego desde PBS, porque estás depurando una conversación.

Task 1: Confirmar que PVE resuelve PBS a la IP esperada

cr0x@server:~$ getent hosts pbs01
10.20.30.40    pbs01

Qué significa: Esta es la IP que PVE usará. Si está mal, estás depurando la máquina equivocada.
Decisión: Si la IP es inesperada, arregla DNS o /etc/hosts (y elimina las sobreescrituras “temporales”).

Task 2: Comprobar conectividad TCP básica al puerto API 8007 de PBS

cr0x@server:~$ nc -vz pbs01 8007
Connection to pbs01 8007 port [tcp/*] succeeded!

Qué significa: La ruta de red L3/L4 está abierta.
Decisión: Si falla o agota el tiempo, detente. Arregla enrutamiento/firewall primero; la autenticación no importará todavía.

Task 3: Verificar el handshake TLS y capturar el subject del certificado presentado

cr0x@server:~$ echo | openssl s_client -connect pbs01:8007 -servername pbs01 2>/dev/null | openssl x509 -noout -subject -issuer -fingerprint -sha256
subject=CN = pbs01
issuer=CN = Proxmox Backup Server
sha256 Fingerprint=AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99

Qué significa: Puedes ver qué certificado presenta PBS y su huella SHA256.
Decisión: Si PVE tiene registrada otra huella, actualízala en la definición de almacenamiento de PVE o vuelve a añadir el almacenamiento limpiamente.

Task 4: En PVE, inspeccionar la entrada PBS en storage.cfg

cr0x@server:~$ grep -nA6 -B2 "pbs:" /etc/pve/storage.cfg
12:pbs: pbs-backups
13:        datastore vmbackups
14:        server pbs01
15:        username backup@pbs
16:        fingerprint AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99
17:        content backup

Qué significa: Esto es la verdad de lo que PVE intentará.
Decisión: Si datastore no es exactamente el ID del datastore de PBS, arréglalo. Si server está mal, corrígelo. Si el username tiene un realm equivocado, corrígelo.

Task 5: Desde PVE, consultar la versión de la API de PBS para validar conectividad sin auth

cr0x@server:~$ curl -k -s https://pbs01:8007/api2/json/version | jq .
{
  "data": {
    "release": "3.2-1",
    "repoid": "f433c2a1",
    "version": "3.2.3"
  }
}

Qué significa: La ruta de red y la pila HTTP funcionan al menos para endpoints no autenticados.
Decisión: Si esto falla, no toques permisos todavía. Arregla DNS, la interceptación TLS o problemas de firewall.

Task 6: En PBS, listar datastores y confirmar el ID del datastore

cr0x@server:~$ proxmox-backup-manager datastore list
┌───────────┬──────────────┬──────────┬─────────────┐
│ name      │ path         │ comment  │ gc-schedule │
╞═══════════╪══════════════╪════════════╪═════════════╡
│ vmbackups │ /mnt/pbs/vm  │          │ daily       │
└───────────┴──────────────┴────────────┴─────────────┘

Qué significa: El ID del datastore es vmbackups. Eso es lo que PVE debe usar.
Decisión: Si PVE usa cualquier otra cosa (como /mnt/pbs/vm), corrige la configuración de PVE.

Task 7: En PBS, confirmar que el datastore está disponible y no en un estado de montaje extraño

cr0x@server:~$ proxmox-backup-manager datastore status
┌───────────┬─────────┬───────────┬─────────────┬───────────┐
│ datastore │ status  │ total     │ used        │ avail     │
╞═══════════╪═════════╪═══════════╪═════════════╪───────────╡
│ vmbackups │ online  │ 10.00 TiB │ 2.10 TiB    │ 7.90 TiB  │
└───────────┴───────────┴───────────┴─────────────┴───────────┘

Qué significa: PBS considera el datastore en línea.
Decisión: Si está offline, arregla el almacenamiento subyacente (montaje/ZFS/disco) antes de culpar a PVE.

Task 8: En PBS, verificar que el servicio API esté en ejecución y escuchando en 8007

cr0x@server:~$ systemctl status proxmox-backup
● proxmox-backup.service - Proxmox Backup Server API and Web UI
     Loaded: loaded (/lib/systemd/system/proxmox-backup.service; enabled)
     Active: active (running) since Mon 2025-12-22 08:10:12 UTC; 3 days ago
     Main PID: 1234 (proxmox-backup)
      Tasks: 24 (limit: 38461)
     Memory: 220.0M
     CGroup: /system.slice/proxmox-backup.service
             └─1234 /usr/lib/x86_64-linux-gnu/proxmox-backup/proxmox-backup-api

Qué significa: El servicio está activo.
Decisión: Si está inactivo/fallado, reinicia e inspecciona los logs. PVE no puede ver datastores si la API de PBS está abajo.

Task 9: En PBS, comprobar el estado del firewall y permitir 8007 si procede

cr0x@server:~$ pve-firewall status
Status: enabled/running
Service: proxmox-firewall
Rules: loaded

Qué significa: El firewall de Proxmox está activo (PBS usa la misma herramienta de firewall).
Decisión: Si está habilitado, confirma que existe una regla allow para TCP/8007 desde tus nodos/subredes PVE.

Task 10: Desde PVE, intentar listar datastores a través del almacenamiento configurado (vista PVE)

cr0x@server:~$ pvesm status
Name         Type     Status           Total            Used       Available        %
pbs-backups  pbs      active              0               0               0       0.00

Qué significa: Esta salida a veces es poco útil para la capacidad de PBS, pero te dice si PVE considera el almacenamiento “activo”.
Decisión: Si no está activo, mira los logs de PVE por errores de autenticación y API.

Task 11: En PVE, leer el log de tareas para la operación fallida de añadir/escanear

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy --since "1 hour ago" | tail -n 40
Dec 26 09:11:02 pve01 pvedaemon[2211]: storage 'pbs-backups' error: datastore 'vmbackup' not found
Dec 26 09:11:02 pve01 pvedaemon[2211]: pbs-api: GET /api2/json/admin/datastore: permission denied

Qué significa: La primera línea culpa al ID del datastore; la segunda línea es la razón real: permiso denegado.
Decisión: Arregla los permisos en PBS para el usuario/token. No renombres datastores para perseguir un problema de permisos.

Task 12: En PBS, listar usuarios y confirmar que la cuenta existe en el realm esperado

cr0x@server:~$ proxmox-backup-manager user list
┌──────────────┬────────┬───────────────────────────┬──────────┐
│ userid       │ enable │ comment                   │ expire   │
╞══════════════╪════════╪═══════════════════════════╪══════════╡
│ root@pam     │ true   │                           │          │
│ backup@pbs   │ true   │ used by PVE for backups   │          │
└──────────────┴────────┴───────────────────────────┴──────────┘

Qué significa: El usuario existe. Observa el realm: backup@pbs.
Decisión: Si PVE usa backup@pam pero PBS solo tiene backup@pbs, corrige el nombre de usuario en PVE.

Task 13: En PBS, comprobar permisos para el usuario sobre la ruta del datastore

cr0x@server:~$ proxmox-backup-manager acl list | sed -n '1,120p'
┌───────────────┬────────────┬──────────────┬───────────────────────────┐
│ path          │ ugid       │ type         │ role                      │
╞═══════════════╪════════════╪══════════════╪═══════════════════════════╡
│ /datastore    │ backup@pbs │ user         │ DatastoreAdmin            │
│ /datastore/vmbackups │ backup@pbs │ user  │ DatastoreBackup           │
└───────────────┴────────────┴──────────────┴───────────────────────────┘

Qué significa: Este usuario tiene roles que otorgan derechos sobre el datastore. Los roles exactos varían según la política de la organización.
Decisión: Si no ves una entrada ACL para /datastore/vmbackups (o rutas de namespace relevantes), añade una. Como mínimo, concede list/audit + backup para el flujo de trabajo de PVE.

Task 14: En PBS, probar el login con estrategia de token API (recomendado)

cr0x@server:~$ proxmox-backup-manager user token list backup@pbs
┌───────────┬────────┬────────────┬────────┐
│ tokenid   │ enable │ expire     │ comment│
╞═══════════╪════════╪════════════╪════════╡
│ pve-prod  │ true   │            │        │
└───────────┴────────┴────────────┴────────┘

Qué significa: Un token existe y está habilitado.
Decisión: Prefiere tokens frente a contraseñas para la integración PVE→PBS. Si no existe un token, créalo y asigna roles mínimos.

Task 15: En PVE, verificar que las credenciales almacenadas referencian el token/usuario correcto

cr0x@server:~$ grep -n "pbs-backups" -nA8 /etc/pve/storage.cfg
12:pbs: pbs-backups
13:        datastore vmbackups
14:        server pbs01
15:        username backup@pbs
16:        token pve-prod
17:        fingerprint AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99
18:        content backup

Qué significa: PVE se autentica usando el token, no una contraseña interactiva.
Decisión: Si falta token y pretendías usar tokens, añádelo. Si el nombre del token es incorrecto, arréglalo y vuelve a intentar el escaneo de almacenamiento.

Task 16: Confirmar que no apuntas accidentalmente a un “sync target” de PBS o a un nodo distinto

cr0x@server:~$ curl -k -s https://pbs01:8007/api2/json/nodes | jq -r '.data[].node'
pbs01

Qué significa: Estás hablando con el nodo PBS que crees.
Decisión: Si ves un nombre de nodo distinto al esperado, tienes confusión de DNS/LB/NAT. Arregla el direccionamiento antes que nada.

Tres microhistorias corporativas desde el terreno

1) El incidente causado por una suposición errónea: “es una falta de ortografía, obviamente”

Una empresa SaaS de tamaño medio desplegó PBS para reemplazar un mosaico de exports NFS y scripts con nombres como
backup_final_v7_really_final.sh. Crearon un nuevo datastore en PBS llamado vmbackups.
El equipo de almacenamiento lo validó en la UI de PBS. Luces verdes por todas partes.

El equipo de virtualización añadió PBS a PVE y recibió “datastore not found.” Hicieron lo que muchos hacen bajo presión:
asumieron que el nombre del datastore estaba mal, lo cambiaron en PVE a vmbackup, luego a VMBackups, luego a la ruta de montaje.
Mismo error. El canal del incidente se llenó de conjeturas seguras, ninguna útil.

La causa real fue más simple y más irritante: los nodos PVE resolvían pbs01 a una IP antigua vía una entrada sobrante
en /etc/hosts de una prueba de staging. Esa IP pertenecía a una VM PBS desmantelada que se había reutilizado para otra prueba.
El “PBS equivocado” no tenía el datastore. Así que sí, “datastore not found” era técnicamente correcto —solo que no del modo que nadie esperaba.

La solución fue inmediata: eliminar la entrada hosts obsoleta, confiar en DNS y volver a añadir el almacenamiento para refrescar huella y endpoint.
El equipo escribió una pequeña política después: no usar entradas estáticas en hosts para endpoints de producción salvo que haya un plan de DR documentado.

La conclusión del postmortem no fue “ten cuidado con las faltas de ortografía.” Fue “verifica que estás hablando con el sistema que crees.”
Lección SRE tan antigua como el pager.

2) La optimización que salió mal: “pongamos un proxy delante”

Otra organización estandarizó en una puerta TLS interna. Todo tenía que ir detrás de ella: métricas, apps internas, paneles de administración.
Alguien decidió que PBS también debería estar detrás de la puerta para “gestión centralizada de certificados.”
Terminaron TLS en la puerta y re-encriptaron hacia PBS con un certificado distinto.

PVE empezó a fallar intermitentemente al añadir almacenamientos PBS con “datastore not found.”
No siempre. Justo lo suficiente para volverlo demoledor. Algunos nodos funcionaban; otros no. Reintentos a veces funcionaban.
Es el tipo de fallo que hace culpar a los rayos cósmicos.

La causa raíz fue la fijación de huella y la selección inconsistente del backend. La puerta ocasionalmente enrutaba un nodo a un backend distinto
durante ventanas de mantenimiento, y el certificado/huella presentada no coincidía con la que tenían almacenada algunos nodos PVE. Algunos nodos PVE estaban fijados a la huella vieja, otros a la nueva.
El error se manifestó como un fallo de descubrimiento del datastore porque la llamada a la API nunca completaba con fiabilidad.

Lo solucionaron retirando la puerta del camino de PBS (acceso directo de PVE a PBS), y en su lugar gestionando certificados en el host PBS
de forma controlada. La “centralización” no valía convertir los backups en un evento probabilístico.

Esta es la optimización que se ve ordenada en un diagrama de red y fea en producción. Los backups no necesitan elegancia. Necesitan aburrimiento.

3) La práctica aburrida pero correcta que salvó el día: “menor privilegio, documentado”

Una empresa regulada tenía la costumbre que suena anticuada: cada integración de servicio tenía una cuenta dedicada, un token API,
un rol con alcance limitado y un runbook de una página con un comando de verificación copiar/pegar. Nada de credenciales root compartidas. Nada de configuraciones únicas.

Durante un ciclo de actualización de PBS, un datastore se movió a un nuevo almacenamiento y se recreó con la misma ruta de respaldo pero un ID de datastore distinto.
Un admin ocupado supuso que PVE referenciaba la ruta, no el ID. PVE empezó a lanzar “datastore not found” tras el mantenimiento.
Parecía un problema de permisos al principio, porque la cuenta seguía pudiendo autenticarse.

El runbook ahorró tiempo. Tenía una comprobación simple: listar datastores vía el manager de PBS, confirmar el ID y compararlo con /etc/pve/storage.cfg.
Sin debate. Sin “tal vez es el firewall.” Era un desajuste de ID.

Actualizaron el ID del datastore en storage.cfg por todo el clúster (un cambio, replicado), ejecutaron una copia de seguridad de prueba y cerraron el incidente.
El token dedicado y los ACLs de mínimo privilegio significaron que no tuvieron que “conceder temporalmente” derechos de admin para depurar.

Práctica aburrida: verificada. Pager: tranquilo. Cumplimiento: feliz. Ese es el trifecta.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: la UI de PBS muestra el datastore, PVE dice “datastore not found”

• Causa raíz: ID de datastore equivocado en PVE (error tipográfico, diferencia de mayúsculas, usaste la ruta en lugar del ID).
• Solución: En PBS ejecuta proxmox-backup-manager datastore list. Copia el name exacto en la configuración de almacenamiento de PVE.

2) Síntoma: funciona desde un nodo PVE, falla desde otro

• Causa raíz: ACL de red, firewall o DNS dividido (los nodos alcanzan endpoints PBS distintos).
• Solución: Compara getent hosts pbs01 y nc -vz pbs01 8007 entre nodos. Normaliza DNS y reglas de firewall.

3) Síntoma: tras reinstalar PBS o cambiar hostname, todo se rompe

• Causa raíz: desajuste de huella TLS fijada en PVE.
• Solución: Recupera la nueva huella con openssl, luego actualiza la huella en el almacenamiento de PVE o vuelve a añadir el almacenamiento.

4) Síntoma: los logs muestran “permission denied” pero la UI dice “not found”

• Causa raíz: PBS devuelve 404/“not found” para accesos no autorizados, o PVE enmascara el error de permiso subyacente.
• Solución: Inspecciona los logs de PVE (journalctl -u pvedaemon -u pveproxy) y los ACLs de PBS (proxmox-backup-manager acl list). Concede los roles requeridos en /datastore/<id>.

5) Síntoma: PVE puede hacer curl /version, pero el escaneo de datastore falla

• Causa raíz: la conectividad está bien; la autenticación/autorización no (realm equivocado, token deshabilitado, usuario expirado, ACL faltante).
• Solución: Verifica realm de usuario y existencia del token en PBS. Usa un token dedicado y confirma entradas ACL para acceso al datastore.

6) Síntoma: añadir almacenamiento en PVE funciona, pero las copias fallan con errores de namespace

• Causa raíz: permisos de namespace faltantes o expectativas mal configuradas sobre dónde aterrizan las copias.
• Solución: Alinea el uso de namespaces y los ACLs. Si usas namespaces, documéntalos y asigna roles con el scope correcto.

Broma #2 (corta, relevante): “Datastore not found” a veces es solo PBS tímido diciendo “no estás invitado.”

Listas de verificación / plan paso a paso (haz esto, en este orden)

Paso a paso: arreglar la visibilidad PVE ↔ PBS del datastore

1. Confirmar identidad del endpoint.
   Desde cada nodo PVE: ejecuta getent hosts pbs01. Asegúrate de que resuelve a la IP correcta.
   Si no, arregla DNS o elimina entradas obsoletas en /etc/hosts.
2. Confirmar alcance de red.
   Desde cada nodo PVE: nc -vz pbs01 8007.
   Si está bloqueado, arregla reglas de firewall (lado PBS y red) y enrutamiento.
3. Confirmar certificado/huella TLS.
   Desde PVE: captura la huella vía openssl s_client.
   Compara con la huella en /etc/pve/storage.cfg. Si difiere, actualízala o vuelve a añadir el almacenamiento.
4. Confirmar el ID del datastore en PBS.
   En PBS: proxmox-backup-manager datastore list.
   Copia el name (ID), no la ruta.
5. Confirmar que PBS está sano.
   En PBS: systemctl status proxmox-backup y proxmox-backup-manager datastore status.
   Si el servicio está caído o el datastore offline, arregla PBS primero.
6. Confirmar identidad (realm) y uso de token.
   En PBS: proxmox-backup-manager user list y proxmox-backup-manager user token list backup@pbs.
   Prefiere autenticación basada en token desde PVE.
7. Confirmar permisos ACL.
   En PBS: proxmox-backup-manager acl list. Asegura que el usuario/token tenga roles en /datastore/<id>.
   Si usas namespaces, ajusta los permisos con el scope correcto.
8. Validar configuración en PVE.
   En PVE: inspecciona /etc/pve/storage.cfg para server, datastore, username, token, fingerprint.
9. Reintentar desde PVE y leer logs inmediatamente.
   Si sigue fallando, ve directo a journalctl -u pvedaemon -u pveproxy y busca “permission denied”, huella o errores de conexión.

Qué evitar (porque te hace perder horas)

• No renombres datastores para “ver si ayuda.” Solo provocarás drift y romperás referencias.
• No pongas PBS detrás de un proxy elegante a menos que garantices identidad de backend estable y comportamiento de certificados.
• No concedas derechos de administrador completos para “probar.” Crea un token dedicado con roles limitados; reduce el radio de impacto.
• No depures primero desde tu portátil. Depura desde un nodo PVE. Ahí es donde ocurre el fallo.

Preguntas frecuentes

1) ¿“Datastore not found” siempre significa que el nombre del datastore está mal?

No. Puede significar ID equivocado, endpoint PBS equivocado, permiso denegado enmascarado como no encontrado, scope de namespace o fallos de huella/confianza.
Confirma el ID en PBS y revisa logs por errores de permisos.

2) ¿Qué es exactamente el “ID del datastore” en PBS?

Es el name del datastore mostrado por proxmox-backup-manager datastore list.
Es un identificador de la API, no una ruta de sistema de ficheros.

3) ¿Por qué funciona en la UI de PBS pero no desde PVE?

La UI de PBS suele tener una sesión con un usuario privilegiado local (a menudo root@pam) y se accede localmente o por una ruta de red distinta.
PVE usa sus propias credenciales y llama a la API remotamente; identidad distinta, red distinta, reglas distintas.

4) ¿Tengo que usar tokens API o puedo usar contraseña?

Puedes usar contraseña, pero los tokens son la mejor opción operativa: revocables, auditable y más fáciles de limitar.
En producción, usa un usuario dedicado y un token dedicado para PVE.

5) ¿Qué permisos necesita PVE en PBS para hacer backups?

Como mínimo, derechos para realizar backups en el datastore objetivo (y suele necesitar capacidades de auditoría/listado para ver qué existe).
Los nombres exactos de roles varían por política; el principio es: concede solo lo que PVE necesita sobre /datastore/<id>.

6) ¿Un firewall puede causar “datastore not found” aunque ping funcione?

Sí. El ping demuestra casi nada. PBS necesita TCP/8007 end-to-end. Usa nc -vz pbs01 8007 o equivalente para comprobarlo.

7) Cambié el certificado de PBS. ¿Por qué PVE no se recuperó automáticamente?

Porque PVE fija la huella TLS de PBS por seguridad. Eso evita ataques man-in-the-middle silenciosos, pero significa que debes actualizar la huella
cuando el certificado de PBS cambie.

8) ¿Cómo afectan los namespaces a la visibilidad del datastore?

Los namespaces pueden restringir lo que un usuario/token puede ver o escribir. Un usuario puede acceder al datastore en general pero estar bloqueado de un namespace específico,
haciendo que algo parezca faltante. Alinea los ACLs de namespaces con tus trabajos de backup.

9) ¿Es seguro editar /etc/pve/storage.cfg manualmente?

Sí, si sabes lo que haces y entiendes que se replica en el clúster PVE. Prefiere la GUI para cambios rutinarios,
pero para respuesta a incidentes, una edición manual cuidadosa (con control de cambios) a veces es la solución más rápida.

10) ¿Por qué el error aparece solo al “Añadir almacenamiento” pero las copias funcionaban antes?

Añadir almacenamiento desencadena operaciones de descubrimiento/listado que pueden requerir permisos adicionales comparado con una configuración previamente cacheada.
Además, certificados y DNS pueden cambiar con el tiempo; la huella almacenada o la IP resuelta pueden ahora diferir.

Conclusión: pasos prácticos siguientes

“Datastore not found” es un problema de visibilidad, no una maldición mística del almacenamiento. Trátalo como cualquier otra integración de producción:
verifica el endpoint, verifica el transporte, verifica la identidad, verifica el nombre del objeto.

1. Desde un nodo PVE: demuestra que pbs01:8007 es accesible y que el certificado es el esperado.
2. Desde PBS: confirma el ID del datastore con proxmox-backup-manager datastore list y que esté online.
3. Desde PBS: verifica que el usuario/token exista y que los ACLs incluyan el datastore (y el namespace, si se usa).
4. Desde PVE: alinea /etc/pve/storage.cfg con el server, datastore, username/token y la fingerprint correctos.
5. Tras la solución: ejecuta una copia de seguridad de prueba y lee los logs inmediatamente si algo parece raro. Los sistemas silenciosos se ganan, no se suponen.

El mejor resultado no es “funciona ahora.” Es “la próxima vez que falle, el de guardia puede demostrar por qué en cinco minutos.”
Anota los IDs de datastore, las huellas esperadas, la regla de firewall y el propietario del token. Haz que tu yo futuro esté un poco menos enfadado.