Proxmox PBS «datastore not found»: чому PVE не бачить сховище і як виправити

Що насправді означає «datastore not found» (і чого це не означає)

У PVE сховище PBS виявляється й використовується через HTTP API PBS (порт 8007 за замовчуванням). Коли PVE каже
«datastore not found», відбувається одне з наступного:

• Ідентифікатор datastore, який ви вказали, не існує (описка, регістр символів, неправильний вузол PBS).
• Сховище існує, але ваші облікові дані не можуть його перелічити або отримати доступ (права, realm, токен).
• PVE не може надійно зв’язатися з PBS (DNS, маршрутизація, фаєрвол, порт, проксі, TLS-фінгерпринт).
• Ви зіштовхнулися з несумісністю namespace (сховище існує, але доступ до потрібного namespace заборонений).
• Ви звертаєтеся до неправильної інстанції PBS (VIP, NAT, split DNS, застаріла IP-адреса, плутанина в кластері).

Чого це зазвичай не означає: проблема з файловою системою сховища на PBS. Якщо в інтерфейсі PBS сховище позначене як здорове,
скарга PVE майже завжди стосується шару API/автентифікації/конфігурації, а не того, що ZFS раптово «з’їв» резервні копії.

Один операційний натяк: текст помилки часто використовується повторно для кількох API-збоїв. «Datastore not found»
іноді — ввічлива брехня, що означає «вам заборонено це бачити» або «я не можу аутентифікуватись». Комп’ютери так роблять,
бо у них немає сорому.

Жарт №1 (короткий, по темі): «datastore not found» — це файловий еквівалент «я не отримав твого листа». Воно існує; хтось просто відмовляється це визнати.

Цікаві факти та контекст (чому помилка повторюється)

Трохи контексту корисно, бо «datastore not found» — сучасний режим відмови з давніми корінням:
ідентичність, іменування та контроль доступу. Ось конкретні факти, які впливають на підхід до усунення неполадок:

1. Datastores PBS адресуються за ID, а не за шляхом. ID — те, що показує API; бекапний каталог другорядний.
2. PVE інтегрується з PBS через API PBS на порті 8007. Якщо 8007 заблокований або перехоплюється, виявлення не вдасться, навіть якщо веб-інтерфейс PBS працює локально.
3. Реалми автентифікації в Proxmox мають значення. root@pam і root@pbs — різні ідентичності; токени успадковують семантику realm.
4. Фінгерпринт TLS PBS зафіксований у PVE. Якщо сертифікат PBS змінюється (перевстановлення, зміна імені хоста), PVE може відмовитися підключатися, поки його не оновлять.
5. Права PBS схожі на шляхи й об’єктно-орієнтовані. Наявність «Datastore.Audit» — не те саме, що «Datastore.Backup». Відсутність прав на перелік може приховати datastores.
6. Namespaces додали ще один вимір доступу. Сховище може існувати, але вам може бути закритий доступ до потрібного namespace.
7. PBS зберігає конфігурацію в /etc/proxmox-backup. Визначення datastore локальні для вузла PBS; кластеризація PBS не реплікує конфіги сама по собі без додаткових кроків.
8. PVE зберігає визначення сховищ у /etc/pve/storage.cfg. У PVE-кластері цей файл реплікується. Одна невірна зміна стає проблемою для всіх.
9. «Not found» — класичний шаблон безпеки. Багато API повертають 404 для неавторизованих ресурсів, щоб уникати витоку інформації — добре для безпеки, погано для відлагодження.

Цитата для налаштування мислення. Це переказ ідеї, бо точність важлива:
переказана ідея: «Надія — не стратегія; потрібні докази.» — притаманно культурі надійності/операцій (часто цитують у менеджменті інженерії).

Швидкий план діагностики (перевірити 1, 2, 3)

Ви хочете найкоротший шлях до впевненості. Не починайте з перевстановлення PBS або форматування нічого.
Почніть з доведення, де саме порушується видимість: мережа, ідентичність або іменування.

1) Доведіть, що PVE може дістатися API PBS (порт 8007) і TLS не бреше

• Якщо TCP підключення не вдається: це мережа/фаєрвол/маршрутизація/DNS.
• Якщо TLS handshake скаржиться на сертифікат/фінгерпринт: це питання довіри.
• Якщо ви отримуєте HTTP-відповідь: канал працює; переходьте до автентифікації/прав.

2) Доведіть, що ваші облікові дані можуть перелічити datastores

• Якщо перелік datastores порожній або викликає помилку: права, realm, токен або неправильна ціль PBS.
• Якщо перелік показує datastore, але додавання все ще не вдається: невідповідність ID, namespace або розбіжність у storage.cfg.

3) Доведіть, що ID datastore точно відповідає тому, що показує PBS

• ID datastore чутливі до регістру. Ставтеся до них як до імен об’єктів API, бо так воно й є.
• Підтвердіть, що ви не використовуєте шлях файлової системи або «зручну» назву.

Якщо у вас є лише 10 хвилин, зробіть ці три перевірки. Вони вловлюють більшість реальних інцидентів.

Карта відмов: де сховище може «зникнути»

Уявіть це як ланцюг. Сховище видно лише коли кожне посилання витримує.
Поруште будь-яке посилання — і PVE скаже, що воно «не знайдене», бо з точки зору PVE його справді немає.

Посилання A: PVE резолює ім’я PBS у правильну адресу

Split DNS, застарілі записи в /etc/hosts і тимчасові NAT-правила — класика. PVE може підключитися до іншого PBS,
ніж ви думаєте — особливо під час міграцій чи тестів відновлення після аварій.

Посилання B: Порт 8007 доступний, і ніхто не проксує його дивно

Reverse proxy, що працює з HTTP, але не з WebSockets, фаєрвол із TLS-інспекцією або L7 балансувальник з невірними health checks
можуть викликати дивну поведінку API. PBS найкраще працює при прямому доступі.

Посилання C: TLS-фінгерпринт, зафіксований у PVE, відповідає поточному сертифікату PBS

PVE зберігає і перевіряє фінгерпринт PBS. Якщо ви перевстановили PBS, згенерували сертифікат або змінили ім’я хоста,
PVE може почати відмовляти у з’єднанні, що проявиться як «datastore not found» під час додавання/сканування.

Посилання D: Ідентичність, якою ви користуєтеся, має право перелічувати й доступатися до datastore

PVE може аутентифікуватися як користувач (наприклад, backup@pbs) або через API-токен. Але токен має існувати,
не бути простроченим/відключеним і мати правильні ролі. «Not found» може означати, що PBS каже «не дозволено».

Посилання E: ID datastore правильний і послідовний

ID datastore — це не точка монтування. Це не ім’я ZFS-датасету, якщо ви навмисно не зробили їх однаковими.
Якщо ви змінили ID datastore в PBS, PVE не підхопить це автоматично.

Посилання F: Взаємні очікування щодо namespace і призначення збережені

Namespaces можуть зробити сховище порожнім або недоступним, якщо у вас немає прав на потрібний namespace.
Також, якщо ви очікуєте namespace, якого не існує або який обмежений, поведінка PVE може виглядати так, ніби datastore «не існує».

Практичні завдання з командами (12+ перевірок, що закінчують суперечки)

Це польові перевірки. Вони призначені для виконання та дають виходи, що напряму направляють рішення.
Виконуйте їх спочатку з вузла PVE, потім з PBS, бо ви налагоджуєте бесіду між ними.

Завдання 1: Підтвердіть, що PVE резолює PBS у очікуваний IP

cr0x@server:~$ getent hosts pbs01
10.20.30.40    pbs01

Що це означає: Це IP, який використовуватиме PVE. Якщо він неправильний, ви налагоджуєте не ту машину.
Рішення: Якщо IP несподіваний — виправте DNS або /etc/hosts (видаліть «тимчасові» обхідні правки).

Завдання 2: Перевірте базову TCP-доступність до API PBS на порті 8007

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

Що це означає: Шлях на рівнях L3/L4 відкритий.
Рішення: Якщо вдається не підключитись або таймаут — зупиніться. Виправте маршрутизацію/фаєрвол; автентифікація ще не має значення.

Завдання 3: Перевірте TLS-handshake та зафіксуйте subject сертифіката

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

Що це означає: Ви бачите, який сертифікат PBS показує і його SHA256-фінгерпринт.
Рішення: Якщо PVE зберіг інший фінгерпринт — оновіть його в визначенні сховища PVE або додайте сховище наново.

Завдання 4: На PVE перегляньте запис сховища PBS у 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

Що це означає: Це базова істина того, до чого PVE звертатиметься.
Рішення: Якщо datastore не точно збігається з ID PBS — виправте його. Якщо server неправильний — виправте. Якщо realm у username неправильний — виправте.

Завдання 5: З PVE запитайте версію API PBS, щоб перевірити підключення без автентифікації

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

Що це означає: Мережевий шлях і HTTP-стек принаймні для неавторизованих ендпоїнтів працюють.
Рішення: Якщо це не вдається — не чіпайте права. Виправляйте DNS, TLS-інтерцепцію або фаєрвол.

Завдання 6: На PBS перелічіть datastores і підтвердьте ID datastore

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

Що це означає: ID datastore — vmbackups. Саме цей ID має використовувати PVE.
Рішення: Якщо PVE використовує щось інше (наприклад, /mnt/pbs/vm) — виправте конфіг PVE.

Завдання 7: На PBS підтвердіть, що datastore дійсно доступний і не у дивному стані монтування

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

Що це означає: PBS вважає datastore онлайн.
Рішення: Якщо він офлайн — виправте нижчестояче сховище (монтування/ZFS/диск) перш ніж звинувачувати PVE.

Завдання 8: На PBS перевірте, що API-сервіс запущений і слухає 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

Що це означає: Сервіс працює.
Рішення: Якщо inactive/failed — перезапустіть і перегляньте логи. PVE не побачить datastores, якщо API PBS впав.

Завдання 9: На PBS перевірте стан фаєрволу і дозвольте 8007 при потребі

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

Що це означає: Proxmox firewall активний (PBS використовує ті самі інструменти фаєрволу).
Рішення: Якщо увімкнено — переконайтеся, що є правило allow для TCP/8007 з ваших PVE-вузлів/підмереж.

Завдання 10: З PVE спробуйте перелічити datastores через налаштоване сховище (вид з PVE)

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

Що це означає: Цей вивід іноді неінформативний щодо ємності PBS, але показує, чи вважає PVE сховище «active».
Рішення: Якщо воно не активне — дивіться логи PVE щодо помилок автентифікації та API.

Завдання 11: На PVE прочитайте лог задачі для невдалого додавання/сканування

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

Що це означає: Перший рядок звинувачує ID datastore; другий рядок — справжня причина: permission denied.
Рішення: Виправте права PBS для користувача/токена. Не перейменовуйте datastores, намагаючись впоратися з проблемою прав.

Завдання 12: На PBS перелічіть користувачів і підтвердіть, що аккаунт існує у потрібному realm

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

Що це означає: Користувач існує. Зауважте realm: backup@pbs.
Рішення: Якщо PVE використовує backup@pam, а PBS має лише backup@pbs — виправте ім’я користувача в PVE.

Завдання 13: На PBS перевірте права для користувача на шлях 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           │
└───────────────┴────────────┴──────────────┴───────────────────────────┘

Що це означає: Цьому користувачу призначені ролі, що дають права на datastore. Конкретні ролі залежать від політики організації.
Рішення: Якщо ви не бачите ACL для /datastore/vmbackups (або відповідних шляхів namespace), додайте його. Мінімум — дайте права на перелік/audit і backup для робочого процесу PVE.

Завдання 14: На PBS протестуйте логін через API-токен (рекомендовано)

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

Що це означає: Токен існує і ввімкнений.
Рішення: Надавайте перевагу токенам над паролями для інтеграції PVE → PBS. Якщо токена немає — створіть його з мінімальними ролями.

Завдання 15: На PVE підтвердіть, що збережені облікові дані посилаються на правильний токен/користувача

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

Що це означає: PVE аутентифікуватиметься за допомогою токена, а не інтерактивного пароля.
Рішення: Якщо token відсутній, а ви мали на увазі токени — додайте його. Якщо ім’я токена неправильне — виправте і повторіть сканування сховища.

Завдання 16: Підтвердіть, що ви випадково не вказали на «sync target» PBS або інший вузол

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

Що це означає: Ви звертаєтеся до того вузла PBS, який очікуєте.
Рішення: Якщо бачите інше ім’я вузла — у вас плутанина DNS/LB/NAT. Виправте адресацію перш за все.

Три корпоративні історії з реальних випадків

1) Інцидент через неправильне припущення: «Очевидно, це описка»

Середня SaaS-компанія запровадила PBS, щоб замінити набір NFS-експортів і скриптів з назвами на кшталт
backup_final_v7_really_final.sh. Створили новий datastore у PBS з ім’ям vmbackups.
Команда зберігання перевірила його в веб-інтерфейсі PBS. Зелені індикатори були скрізь.

Команда віртуалізації додала PBS у PVE і отримала «datastore not found». Вони зробили те, що багато хто робить під тиском:
припустили, що ім’я datastore неправильне, змінили його в PVE на vmbackup, потім на VMBackups, потім на шлях монтування.
Та ж помилка. Канал інцидентів наповнився впевненими припущеннями, жодне з яких не вирішило проблему.

Справжня причина була простішою й дратівливішою: вузли PVE резолювали pbs01 в застарілу IP-адресу через залишковий запис у
/etc/hosts з тесту staging. Та IP-адреса належала виведеному з експлуатації PBS VM, який потім використовували для інших тестів.
«Неправильний PBS» не мав datastore. Тому так — повідомлення «datastore not found» було технічно правильним, просто не так, як очікували.

Виправлення було миттєвим: видалили застарілий запис hosts, поклалися на DNS і перевстановили сховище, щоб освіжити фінгерпринт і endpoint.
Команда потім прописала політику: ніяких статичних записів хостів для продакшн-ендпоінтів без документованого плану DR.

Післямова інциденту не була «будьте уважні з описками». Вона полягала в тому, щоб «перевіряти, з якою системою ви справді спілкуєтеся».
Це урок SRE старий, як сигналізація на виклик.

2) Оптимізація, що обернулася проти: «Поставимо проксі попереду»

Інша команда стандартизувала внутрішній TLS-шлюз. Все мусило бути за ним: метрики, внутрішні додатки, адмін-панелі.
Хтось вирішив, що PBS теж має стояти за шлюзом для «централізованого управління сертифікатами».
Вони термінували TLS на шлюзі і повторно шифрували до PBS іншим сертифікатом.

PVE почав періодично відмовляти при додаванні сховищ PBS з «datastore not found».
Не завжди. Достатньо, щоб було нестерпно. Дехто з вузлів працював, дехто — ні. Повторні спроби іноді проходили.
Це той тип відмови, за який команди звинувачують космічні промені.

Корінь проблеми — фіксація фінгерпринту й непослідовний вибір бекенду. Шлюз іноді спрямовував вузол на інший бекенд під час технічних робіт,
і презентований сертифікат/фінгерпринт не відповідав тому, що зберіг PVE. Деякі вузли PVE були зафіксовані на старому фінгерпринті, інші — на новому.
Помилка проявлялася як відмова в виявленні datastore, бо виклик API не завершувався стабільно.

Вони виправили це, прибравши шлюз із шляху PBS (прямий доступ з PVE до PBS) і замість централізації керували сертифікатами безпосередньо на хості PBS.
«Централізація» виявилася не вартісною, якщо робить резерви ймовірнісною подією.

Це один із тих оптимізацій, що красиво виглядають на схемі мережі й некрасиво працюють у продакшні. Резерви не потребують елегантності. Вони потребують стабільності.

3) Нудна, але правильна практика, що врятувала день: «Принцип найменших привілеїв і документування»

Регульоване підприємство дотримувалося нудної практики: кожній інтеграції давали виділений аккаунт, API-токен,
вузько націлену роль і короткий runbook з копіпаст-рядком перевірки. Ніяких спільних root-кредитів. Ніяких унікальних конфігів.

Під час циклу оновлення PBS одне сховище перенесли на нове сховище і відтворили з тим самим шляхом, але іншим ID datastore.
Зайнятий адміністратор припустив, що PVE посилається на шлях, а не на ID. Після обслуговування PVE почав показувати «datastore not found».
Спочатку це виглядало як проблема з правами, бо аккаунт все ще аутентифікувався.

Runbook прискорив рішення. Там була проста перевірка: перелічити datastores через менеджер PBS, підтвердити ID і порівняти з /etc/pve/storage.cfg.
Жодних дискусій. Жодного «можливо це фаєрвол». Це виявився розрив ID.

Вони оновили ID datastore в storage.cfg по кластеру (одне змінення, що реплікувалося), виконали тестовий бекап і закрили інцидент.
Виділений токен і політика найменших привілеїв означали, що не довелося тимчасово надавати права адміністратора для налагодження.

Нудна практика: виправдала себе. Pager: тихий. Відповідність: задоволена. Це тріада перемог.

Поширені помилки: симптом → причина → виправлення

1) Симптом: у UI PBS видно datastore, PVE каже «datastore not found»

• Причина: Неправильний ID datastore у PVE (описка, регістр, використано шлях замість ID).
• Виправлення: На PBS виконайте proxmox-backup-manager datastore list. Скопіюйте точне name у конфіг PVE.

2) Симптом: працює з одного вузла PVE, не працює з іншого

• Причина: Мережеві ACL, фаєрвол або split DNS (вузли дістають різні PBS-ендпоінти).
• Виправлення: Порівняйте getent hosts pbs01 і nc -vz pbs01 8007 на різних вузлах. Узгодьте DNS і правила фаєрволу.

3) Симптом: після перевстановлення PBS або зміни імені хоста все ламається

• Причина: Несумісність TLS-фінгерпринта, зафіксованого в PVE.
• Виправлення: Отримайте новий фінгерпринт через openssl, потім оновіть його в PVE або додайте сховище наново.

4) Симптом: логи показують «permission denied», але UI каже «not found»

• Причина: PBS повертає 404/«not found»-подібні помилки для неавторизованого доступу, або PVE маскує справжню помилку прав.
• Виправлення: Перевірте логи PVE (journalctl -u pvedaemon -u pveproxy) і ACL PBS (proxmox-backup-manager acl list). Надайте потрібні ролі на /datastore/<id>.

5) Симптом: PVE може виконати curl /version, але сканування datastore не вдається

• Причина: Підключення в порядку; автентифікація/авторизація — ні (невірний realm, відключений токен, прострочений користувач, відсутній ACL).
• Виправлення: Перевірте realm користувача й існування токена на PBS. Використовуйте виділений токен і підтвердіть ACL для доступу до datastore.

6) Симптом: додавання сховища в PVE працює, але бекапи падають із помилками, пов’язаними з namespace

• Причина: Відсутні права на namespace або неправильні очікування, куди потрапляють бекапи.
• Виправлення: Узгодьте використання namespace і ACL. Якщо ви використовуєте namespace, задокументуйте їх і призначайте ролі на правильний шлях scope.

Жарт №2 (короткий, по темі): «Datastore not found» іноді означає просто, що PBS соромиться і каже «тебе не запрошено».

Контрольні списки / покроковий план (робити в цьому порядку)

Покроково: виправити видимість PVE ↔ PBS datastore

1. Підтвердіть ідентичність ендпоінта.
   З кожного вузла PVE: виконайте getent hosts pbs01. Переконайтеся, що він резолює у правильну IP-адресу.
   Якщо ні — виправте DNS або видаліть застарілі записи в /etc/hosts.
2. Підтвердіть мережеву доступність.
   З кожного вузла PVE: nc -vz pbs01 8007.
   Якщо заблоковано — виправте правила фаєрволу (на стороні PBS і мережі) і маршрути.
3. Підтвердіть TLS сертифікат/фінгерпринт.
   З PVE: зніміть фінгерпринт через openssl s_client.
   Порівняйте з фінгерпринтом у /etc/pve/storage.cfg. Якщо різні — оновіть або додайте сховище наново.
4. Підтвердіть ID datastore на PBS.
   На PBS: proxmox-backup-manager datastore list.
   Копіюйте name (ID), а не шлях.
5. Підтвердіть працездатність PBS.
   На PBS: systemctl status proxmox-backup і proxmox-backup-manager datastore status.
   Якщо сервіс впав або datastore офлайн — виправте PBS перш ніж продовжувати.
6. Підтвердіть ідентичність (realm) і використання токенів.
   На PBS: proxmox-backup-manager user list і proxmox-backup-manager user token list backup@pbs.
   Надавайте перевагу авторизації через токени з PVE.
7. Підтвердіть ACL-права.
   На PBS: proxmox-backup-manager acl list. Переконайтеся, що користувач/токен має ролі на /datastore/<id>.
   Якщо використовуєте namespace — задайте права відповідно.
8. Валідуйте конфігурацію PVE.
   На PVE: перегляньте /etc/pve/storage.cfg на предмет server, datastore, username, token, fingerprint.
9. Повторіть спробу з PVE і негайно читайте логи.
   Якщо все ще не вдається — одразу дивіться journalctl -u pvedaemon -u pveproxy і шукайте «permission denied», проблеми з фінгерпринтом або помилки підключення.

Чого уникати (бо це витрачає години)

• Не перейменовуйте datastores, щоб «подивитися, чи допоможе». Ви лише створите розбіжності й зламаєте посилання.
• Не ставте PBS за складний проксі, якщо не можете гарантувати стабільну індивідуальність бекенду і поведінку сертифікатів.
• Не надавайте повні права адміністратора для «тестування». Створіть виділений токен зі скопованими ролями; зменшіть радіус впливу.
• Не налагоджуйте з ноутбука першим. Налагоджуйте з вузла PVE. Саме там виникає відмова.

FAQ

1) Чи означає «datastore not found» завжди неправильне ім’я сховища?

Ні. Це може означати неправильний ID, неправильний PBS-ендпоінт, відмову через права, маскування помилки як not-found, namespace-обмеження або проблеми з довірою/фінгерпринтом. Підтвердіть ID на PBS і перевірте логи на наявність помилок прав.

2) Що саме таке «datastore ID» у PBS?

Це name datastore, показане командою proxmox-backup-manager datastore list.
Це ідентифікатор API, а не шлях файлової системи.

3) Чому це працює в веб-UI PBS, але не з PVE?

Веб-інтерфейс PBS зазвичай використовує привілейованого локального користувача (часто root@pam) і доступається локально або іншим шляхом мережі.
PVE використовує власні облікові дані і звертається до API віддалено; інша ідентичність, інша мережа, інші правила.

4) Чи потрібно використовувати API-токени, чи можна пароль?

Можна використовувати пароль, але токени — кращий оперативний вибір: відкличні, контрольовані й легше масштабовані.
У продакшні використовуйте виділеного користувача та токен для PVE.

5) Які права потрібні PVE на PBS для бекапів?

Мінімально — права на виконання бекапів у цілевому datastore (і зазвичай права на перелік/audit, щоб бачити, що вже є).
Конкретні назви ролей залежать від політики; принцип простий: дайте PVE лише те, що йому потрібно на /datastore/<id>.

6) Чи може фаєрвол викликати «datastore not found», хоча ping працює?

Так. Ping майже нічого не доводить. PBS потребує TCP/8007 від початку до кінця. Використовуйте nc -vz pbs01 8007 або еквівалент, щоб перевірити.

7) Я змінив сертифікат PBS. Чому PVE не відновився автоматично?

Бо PVE фіксує фінгерпринт PBS задля безпеки. Це запобігає мовчанню MITM-атак, але означає, що потрібно вручну оновити фінгерпринт при зміні сертифіката.

8) Як namespace впливають на видимість datastore?

Namespaces можуть обмежувати те, що користувач/токен може бачити або куди писати. Користувач може мати доступ до datastore загалом, але бути заблокованим у конкретному namespace,
через що частина функцій виглядатиме як відсутні. Узгодьте namespace і ACL з вашими завданнями бекапу.

9) Чи безпечно редагувати /etc/pve/storage.cfg вручну?

Так, якщо ви знаєте, що робите, і розумієте, що зміни реплікуються по PVE-кластеру. Для рутинних змін краще використовувати GUI,
але під час інциденту уважне ручне редагування (з контролем змін) іноді найшвидший шлях.

10) Чому помилка з’являється лише під час «Додавання сховища», хоча бекапи раніше працювали?

Додавання сховища викликає операції виявлення/переліку, які можуть вимагати додаткових прав у порівнянні з раніше кешованою конфігурацією.
Також сертифікати та DNS з часом можуть змінитися; збережений фінгерпринт або резольв може тепер відрізнятися.

Висновок: практичні наступні кроки

«Datastore not found» — це проблема видимості, а не містичне прокляття зберігання. Ставтесь до неї як до будь-якої інтеграції в продакшні:
перевірте ендпоінт, транспорт, ідентичність і ім’я об’єкта.

1. З вузла PVE: доведіть, що pbs01:8007 доступний і сертифікат — очікуваний.
2. З PBS: підтвердіть ID datastore через proxmox-backup-manager datastore list і що він онлайн.
3. З PBS: перевірте, що користувач/токен існує і ACL включають datastore (і namespace, якщо використовується).
4. З PVE: узгодьте /etc/pve/storage.cfg з правильними server, datastore, username/token і фінгерпринтом.
5. Після виправлення: запустіть тестовий бекап і одразу читаючи логи, якщо щось працює не так. Тихі системи — це заслуга, а не випадок.

Найкращий результат — не «воно зараз працює». Найкращий результат — «наступного разу черговий зможе довести причину за п’ять хвилин».
Запишіть ID datastore, очікувані фінгерпринти, правило фаєрволу і власника токена. Зробіть вашому майбутньому себе трохи менш роздратованим.