Налаштування PBS та структура datastore для кількох хостів

Вступ

Proxmox Backup Server надає централізоване дедупліковане сховище резервних копій для вузлів Proxmox VE, Linux-клієнтів, віртуальних машин, контейнерів і резервних копій хостів. У цьому посібнику ви виконаєте початкове налаштування Proxmox Backup Server, створите PBS datastore на окремому диску, налаштуєте оновлення та SMTP-сповіщення, а також організуєте резервні копії з кількох хостів за допомогою просторів імен datastore замість ручних папок або кількох невеликих datastores. Отримана схема Proxmox PBS також підготує ваше середовище до подальших задач Proxmox backup restore, зокрема VM backup restore, file-level restore, granular restore і сценаріїв data recovery Proxmox.

Цільова аудиторія: системні адміністратори середнього рівня.
Орієнтовний час виконання: від 45 до 75 хвилин.
Кінцева мета: після вивчення цього посібника у вас буде datastore Proxmox Backup Server на виділеному сховищі, налаштовані репозиторії оновлень, увімкнені email-сповіщення та доступ до namespace для кожного хоста, керований за допомогою ACL.

Передумови

Перед початком переконайтеся, що у вас є таке:

• Встановлений Proxmox Backup Server 4.x, доступний через веб-інтерфейс за адресою https://<PBS_HOSTNAME_OR_IP>:8007.
• Root-доступ або еквівалентний адміністративний доступ до хоста Proxmox Backup Server.
• Один окремий диск для сховища резервних копій, позначений як <DATA_DISK>, наприклад sdb або nvme1n1.
• Мережева доступність від кожного хоста Proxmox VE або backup-клієнта до хоста PBS на TCP-порту 8007.
• Дані SMTP-сервера для сповіщень, зокрема хост, порт, адреса відправника, користувач для автентифікації та пароль або app password.
• Один або кілька хостів Proxmox VE або backup-клієнтів, які використовуватимуть PBS datastore.

У цьому посібнику використовуються наступні placeholders:

• <PBS_HOSTNAME_OR_IP>: DNS-ім'я або IP-адреса Proxmox Backup Server.
• <DATA_DISK>: ім'я диска без /dev/, наприклад sdb.
• <DATA_PARTITION>: шлях до розділу, наприклад /dev/sdb1.
• <DATASTORE_NAME>: ім'я datastore, наприклад main-backup.
• <NAMESPACE_NAME>: ім'я namespace для одного хоста або клієнта, наприклад pve-node-01.
• <PBS_USER>: ім'я користувача PBS, наприклад pve-node-01.
• <TOKEN_NAME>: ім'я API-токена, наприклад backup.
• <TOKEN_SECRET>: секрет API-токена, згенерований PBS.
• <STORAGE_ID>: storage ID у Proxmox VE, наприклад pbs-main.

Крок 1: Перевірте версію PBS і схему дисків

Увійдіть у shell Proxmox Backup Server як root.

Перевірте встановлену версію PBS:

proxmox-backup-manager versions

Очікуваний результат: команда виводить версії встановлених пакетів Proxmox Backup Server.

Виведіть список локальних дисків:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL

Ожидаемый результат: ви можете визначити системний диск і окремий диск сховища. Не використовуйте диск, на якому розміщена операційна система PBS.

Перевірте цільовий диск за допомогою SMART-даних, якщо вони підтримуються:

proxmox-backup-manager disk smart-attributes <DATA_DISK>

Очікуваний результат: PBS виводить SMART-атрибути або повідомляє, що SMART-інформація для пристрою недоступна.

Крок 2: Налаштуйте репозиторій no-subscription

Свіжа інсталяція PBS зазвичай вмикає enterprise-репозиторій. Використовуйте його лише тоді, коли у вас є активна підписка Proxmox. Для лабораторного, оцінювального або непублічного середовища без підписки вимкніть enterprise-репозиторій і ввімкніть PBS no-subscription репозиторій.

Відкрийте файл enterprise-репозиторію:

nano /etc/apt/sources.list.d/pbs-enterprise.sources

Вимкніть enterprise-репозиторій, додавши:

Enabled: false

Очікуваний результат: APT більше не намагається використовувати репозиторій лише для підписників.

Створіть або відредагуйте файл репозиторію Proxmox:

nano /etc/apt/sources.list.d/proxmox.sources

Додайте PBS no-subscription репозиторій для інсталяцій PBS 4.x на базі Debian 13 Trixie:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Оновіть метадані пакетів:

apt update

Очікуваний результат: APT оновлює індекси пакетів без помилок 401 Unauthorized від enterprise.proxmox.com.

Оновіть встановлені пакети:

apt full-upgrade

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

reboot

Крок 3: Підготуйте окремий диск для datastore

PBS зберігає дані datastore всередині каталогу на підтримуваній файловій системі Linux. Використовуйте ext4, xfs або zfs для сховища datastore. Виберіть одну з наведених нижче схем сховища.

Варіант A: Створіть directory datastore на XFS або ext4

Використовуйте цей варіант для простого datastore на одному диску. XFS є хорошим типовим вибором для великих наборів резервних копій. ext4 також підтримується, якщо використовує звичайні параметри directory links.

Очистіть старі сигнатури з диска:

apt install parted
wipefs -a /dev/<DATA_DISK>

Створіть нову таблицю розділів GPT і один розділ:

parted -s /dev/<DATA_DISK> \
  mklabel gpt \
  mkpart primary 1MiB 100%

Очікуваний результат: на диску є один новий розділ.

Оновіть таблицю розділів у ядрі:

partprobe /dev/<DATA_DISK>

Відформатуйте розділ у XFS:

mkfs.xfs -f <DATA_PARTITION>

Використовуйте ext4 замість XFS лише тоді, коли це ваш локальний стандарт:

mkfs.ext4 -F <DATA_PARTITION>

Створіть mount point:

mkdir -p /mnt/datastore/<DATASTORE_NAME>

Отримайте UUID розділу:

blkid <DATA_PARTITION>

Очікуваний вивід:

<DATA_PARTITION>: UUID="<FILESYSTEM_UUID>" BLOCK_SIZE="4096" TYPE="xfs"

Додайте mount до /etc/fstab:

nano /etc/fstab

Для XFS додайте цей рядок:

UUID=<FILESYSTEM_UUID> /mnt/datastore/<DATASTORE_NAME> xfs defaults,noatime 0 2

Для ext4 додайте цей рядок:

UUID=<FILESYSTEM_UUID> /mnt/datastore/<DATASTORE_NAME> ext4 defaults,noatime 0 2

Змонтуйте шлях datastore:

systemctl daemon-reload
mount -a

Перевірте mount:

df -h /mnt/datastore/<DATASTORE_NAME>

Очікуваний результат: команда показує новий диск, змонтований у /mnt/datastore/<DATASTORE_NAME>.

Варіант B: Створіть datastore на LVM

Використовуйте цей варіант, коли вам потрібне керування логічними томами для диска datastore.

Очистіть старі сигнатури з диска:

wipefs -a /dev/<DATA_DISK>

Створіть physical volume, volume group і logical volume:

pvcreate /dev/<DATA_DISK>
vgcreate pbs-vg /dev/<DATA_DISK>
lvcreate -n <DATASTORE_NAME> -l 100%FREE pbs-vg

Очікуваний результат: LVM створює /dev/pbs-vg/<DATASTORE_NAME>.

Відформатуйте logical volume у XFS:

mkfs.xfs -f /dev/pbs-vg/<DATASTORE_NAME>

Створіть mount point:

mkdir -p /mnt/datastore/<DATASTORE_NAME>

Додайте mount до /etc/fstab:

nano /etc/fstab

Додайте цей рядок:

/dev/pbs-vg/<DATASTORE_NAME> /mnt/datastore/<DATASTORE_NAME> xfs defaults,noatime 0 2

Змонтуйте шлях datastore:

mount -a

Перевірте mount:

df -h /mnt/datastore/<DATASTORE_NAME>

Очікуваний результат: logical volume змонтований у /mnt/datastore/<DATASTORE_NAME>.

Варіант C: Створіть ZFS pool і datastore

Використовуйте цей варіант, коли вам потрібні можливості ZFS, такі як checksumming, snapshots, compression, mirrors або RAIDZ. ZFS найкраще використовувати з прямим доступом до дисків, а не поверх hardware RAID, який приховує стан дисків від операційної системи.

Очистіть старі сигнатури з диска:

wipefs -a /dev/<DATA_DISK>

Створіть однодисковий ZFS pool і додайте його як PBS datastore:

proxmox-backup-manager disk zpool create <DATASTORE_NAME> \
  --devices <DATA_DISK> \
  --raidlevel single \
  --compression lz4 \
  --add-datastore true

Очікуваний результат: PBS створює ZFS pool і реєструє datastore з тим самим іменем.

Перевірте pool:

zpool status <DATASTORE_NAME>

Очікуваний результат: pool перебуває в стані online, а диск відображається під ним.

Якщо ви використали цей ZFS-варіант з --add-datastore true, пропустіть крок 4 і перейдіть до кроку 5.

Крок 4: Створіть PBS datastore

Установіть власника каталогу datastore для backup-служб PBS:

chown backup:backup /mnt/datastore/<DATASTORE_NAME>
chmod 750 /mnt/datastore/<DATASTORE_NAME>

Створіть конфігурацію datastore:

proxmox-backup-manager datastore create \
  <DATASTORE_NAME> \
  /mnt/datastore/<DATASTORE_NAME>

Очікуваний результат: PBS реєструє каталог як datastore.

Виведіть список datastores:

proxmox-backup-manager datastore list

Очікуваний результат: <DATASTORE_NAME> з'являється у списку datastores.

Перевірте деталі datastore:

proxmox-backup-manager datastore show <DATASTORE_NAME>

Очікуваний результат: PBS показує шлях datastore і поточні параметри datastore.

Крок 5: Налаштуйте prune, garbage collection і verification

Налаштуйте retention і garbage collection після створення datastore. Prune видаляє прострочені backup indexes відповідно до правил retention. Garbage collection видаляє unreferenced chunks після того, як prune зробить їх невикористовуваними.

Налаштуйте базову retention, щоденний prune, garbage collection і verification для нових резервних копій:

proxmox-backup-manager datastore update <DATASTORE_NAME> \
  --gc-schedule 'Sun 03:00' \
  --verify-new true

proxmox-backup-manager prune-job create prune-<DATASTORE_NAME> \
  --store <DATASTORE_NAME> \
  --schedule daily \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --comment 'Default retention for <DATASTORE_NAME>'

Очікуваний результат: PBS зберігає retention policy datastore і планує cleanup tasks.

Покажіть оновлену конфігурацію datastore:

proxmox-backup-manager datastore show <DATASTORE_NAME>

Очікуваний результат: вивід містить налаштування prune, garbage collection і retention.

Крок 6: Налаштуйте SMTP-сповіщення

Налаштуйте сповіщення до того, як почнете покладатися на backup server. Це допоможе виявляти невдалі резервні копії, помилки garbage collection, збої verification і доступні оновлення пакетів.

У веб-інтерфейсі PBS відкрийте Configuration > Notifications.

Створіть notification target:

1. Натисніть Add.
2. Виберіть SMTP.
3. Введіть target name, наприклад smtp-main.
4. Вкажіть SMTP server, port, username, password, encryption mode, sender address і recipient address.
5. Збережіть target.

Очікуваний результат: PBS зберігає SMTP notification target.

Створіть matcher для важливих подій PBS:

1. Відкрийте Configuration > Notifications > Notification Matchers.
2. Створіть matcher з іменем admin-mail.
3. Виберіть створений SMTP target.
4. Налаштуйте match для подій datastore, system, verification, garbage collection і package update.
5. Збережіть matcher.

Очікуваний результат: PBS спрямовує відповідні сповіщення до SMTP target.

Надішліть тестове сповіщення з notification target, якщо веб-інтерфейс пропонує test action.

Очікуваний результат: поштова скринька отримувача отримує тестовий email від PBS.

Крок 7: Створіть користувачів і API-токени для backup-клієнтів

Використовуйте окремого користувача PBS і API-токен для кожного хоста Proxmox VE, кластера Proxmox VE або standalone backup-клієнта. Це спрощує ротацію облікових даних і дозволяє надавати вузькі права для кожного namespace.

Створіть користувача PBS для одного хоста або клієнта:

proxmox-backup-manager user create <PBS_USER>@pbs \
  --comment "Backup identity for <NAMESPACE_NAME>"

Очікуваний результат: PBS створює обліковий запис користувача. Установіть пароль у веб-інтерфейсі в Configuration > Access Control > User Management, якщо користувачу потрібен інтерактивний вхід.

Згенеруйте API-токен:

proxmox-backup-manager user generate-token \
  <PBS_USER>@pbs \
  <TOKEN_NAME> \
  --comment "Backup token for <NAMESPACE_NAME>"

Ви також можете згенерувати токен у веб-інтерфейсі під пунктом Configuration > Access Control > API Token.

Очікуваний результат: PBS виводить секрет API-токена лише один раз. Негайно скопіюйте його та збережіть у безпечному місці. Пізніше отримати той самий секрет неможливо.

Крок 8: Створіть namespace для кожного хоста або клієнта

PBS namespaces організовують backup groups всередині одного datastore. Використовуйте namespace для кожного хоста Proxmox VE, кластера Proxmox VE або standalone client замість створення ручних папок всередині шляху datastore.

Створіть namespace для одного хоста або клієнта:

proxmox-backup-client namespace create <NAMESPACE_NAME> \
  --repository root@pam@localhost:<DATASTORE_NAME>

Очікуваний результат: PBS створює namespace всередині <DATASTORE_NAME>.

Виведіть список namespaces:

proxmox-backup-client namespace list \
  --repository root@pam@localhost:<DATASTORE_NAME>

Очікуваний результат: вивід містить <NAMESPACE_NAME>.

Створіть додаткові namespaces для інших хостів або клієнтів:

proxmox-backup-client namespace create pve-node-02 \
  --repository root@pam@localhost:<DATASTORE_NAME>

proxmox-backup-client namespace create linux-client-01 \
  --repository root@pam@localhost:<DATASTORE_NAME>

Очікуваний результат: кожен хост або клієнт має окремий namespace у тому самому datastore.

Крок 9: Надайте кожному клієнту доступ лише до його namespace

Надайте API-токену доступ лише до його власного namespace path. Формат ACL path: /datastore/<DATASTORE_NAME>/<NAMESPACE_NAME>.

Надайте token backup-доступ:

proxmox-backup-manager acl update \
  /datastore/<DATASTORE_NAME>/<NAMESPACE_NAME> \
  DatastoreBackup \
  --auth-id '<PBS_USER>@pbs'

proxmox-backup-manager acl update \
  /datastore/<DATASTORE_NAME>/<NAMESPACE_NAME> \
  DatastoreBackup \
  --auth-id '<PBS_USER>@pbs!<TOKEN_NAME>'

Очікуваний результат: token може створювати резервні копії та відновлювати власні резервні копії в цьому namespace, але не може керувати всім datastore.

Виведіть список ACL entries:

proxmox-backup-manager acl list

Очікуваний результат: список ACL містить token і namespace-specific path.

Крок 10: Підключіть хост Proxmox VE до namespace

На хості Proxmox VE додайте PBS storage через веб-інтерфейс або за допомогою pvesm.

Щоб використати веб-інтерфейс, відкрийте Datacenter > Storage > Add > Proxmox Backup Server і введіть такі значення:

• ID: <STORAGE_ID>.
• Server: <PBS_HOSTNAME_OR_IP>.
• Datastore: <DATASTORE_NAME>.
• Namespace: <NAMESPACE_NAME>.
• Username: <PBS_USER>@pbs!<TOKEN_NAME>.
• Password: <TOKEN_SECRET>.
• Fingerprint: fingerprint сертифіката PBS, якщо інтерфейс запитує його.

Очікуваний результат: Proxmox VE додає namespace PBS datastore як backup storage.

Щоб використати командний рядок на хості Proxmox VE, додайте storage:

pvesm add pbs <STORAGE_ID> \
  --server <PBS_HOSTNAME_OR_IP> \
  --datastore <DATASTORE_NAME> \
  --namespace <NAMESPACE_NAME> \
  --username '<PBS_USER>@pbs!<TOKEN_NAME>' \
  --password '<TOKEN_SECRET>'

Очікуваний результат: Proxmox VE створює storage entry, який вказує на правильний PBS namespace.

Перевірте status storage:

pvesm status

Очікуваний результат: <STORAGE_ID> відображається як доступний.

Крок 11: Створіть тестову резервну копію VM

На хості Proxmox VE створіть невелику тестову резервну копію VM у PBS storage. Замініть <VMID> на ID віртуальної машини або контейнера. Це підтверджує, що backup jobs Proxmox VE можуть записувати в namespace до того, як ви почнете покладатися на це сховище для disaster recovery Proxmox planning.

vzdump <VMID> \
  --storage <STORAGE_ID> \
  --mode snapshot

Очікуваний результат: backup task завершується успішно та завантажує backup data до namespace.

У веб-інтерфейсі PBS відкрийте Datastore > <DATASTORE_NAME>. Виберіть namespace <NAMESPACE_NAME>.

Очікуваний результат: ви бачите нову backup group і backup snapshot всередині namespace.

Крок 12: Підтвердьте перегляд резервних копій і готовність до відновлення

Після завершення першого backup підтвердьте, що PBS може переглядати VM backups всередині namespace. Це не повний restore test, але він перевіряє організацію, яка надалі підтримує операції restore from backup PBS, процедури Proxmox PBS restore, задачі Proxmox backup restore і доступ до VM backup з правильного namespace.

У веб-інтерфейсі PBS відкрийте Datastore > <DATASTORE_NAME>, виберіть <NAMESPACE_NAME> і відкрийте backup group, створену на кроці 11.

Очікуваний результат: PBS показує backup snapshots, збережені в namespace для цього хоста або клієнта.

Виберіть один backup snapshot і перегляньте доступні restore actions.

Очікуваний результат: PBS показує restore options, які пізніше можна використовувати для VM backup restore, restore from VM backup і процедур data restoration Proxmox.

Перевірка

Перевірте, що datastore існує:

proxmox-backup-manager datastore list

Очікуваний результат: <DATASTORE_NAME> з'являється у списку datastores.

Перевірте mount:

findmnt /mnt/datastore/<DATASTORE_NAME>

Очікуваний результат: шлях datastore змонтований з окремого диска, logical volume або ZFS pool.

Перевірте доступ до namespace:

proxmox-backup-manager user permissions \
  '<PBS_USER>@pbs!<TOKEN_NAME>' \
  --path /datastore/<DATASTORE_NAME>/<NAMESPACE_NAME>

Очікуваний результат: token має Datastore.Backup на своєму namespace path.

Перевірте, що резервні копії з'являються в namespace:

proxmox-backup-client snapshots \
  --repository root@pam@localhost:<DATASTORE_NAME> \
  --ns <NAMESPACE_NAME>

Очікуваний результат: команда виводить snapshots для вибраного namespace.

Перевірте, що ви можете переглядати VM backups у namespace через веб-інтерфейс PBS.

Очікуваний результат: ви можете відкрити backup group і побачити snapshots для вибраного хоста або клієнта. Це підтверджує, що namespace готовий до подальших workflows file-level restore, granular restore і restore individual files.

Виконайте ручну перевірку status garbage collection:

proxmox-backup-manager garbage-collection status <DATASTORE_NAME>

Очікуваний результат: PBS виводить status garbage collection для datastore.

Навіщо використовувати namespaces замість окремих datastores

Namespaces є рекомендованим механізмом організації, коли кілька хостів або клієнтів спільно використовують один фізичний backup storage pool.

Вони надають такі переваги:

• Один спільний chunk store для кращої дедуплікації між подібними віртуальними машинами та хостами.
• Одне місце для налаштування retention, verification і garbage collection policies.
• Чітке розділення у веб-інтерфейсі PBS без непідтримуваних ручних папок.
• Namespace-specific ACL paths для least-privilege client access.
• Простіше масштабування, коли ви додаєте більше хостів Proxmox VE або Linux-клієнтів.
• Менше datastore objects для моніторингу та обслуговування.

Використовуйте окремі datastores, коли вам потрібне окреме фізичне сховище, різні backup media, різні performance tiers, різне адміністративне володіння або суворе розділення retention і garbage collection schedules.

Відкат змін

Щоб видалити один namespace ACL з token, використовуйте веб-інтерфейс PBS у Configuration > Access Control > Permissions і видаліть ACL entry для /datastore/<DATASTORE_NAME>/<NAMESPACE_NAME>.

Щоб видалити API-токен:

proxmox-backup-manager user delete-token <PBS_USER>@pbs <TOKEN_NAME>

Очікуваний результат: PBS відкликає token.

Щоб видалити користувача PBS:

proxmox-backup-manager user remove <PBS_USER>@pbs

Очікуваний результат: PBS видаляє обліковий запис користувача.

Щоб видалити конфігурацію datastore без видалення backup data:

proxmox-backup-manager datastore remove <DATASTORE_NAME>

Очікуваний результат: PBS видаляє datastore зі своєї конфігурації, але underlying directory залишається на диску.

Щоб видалити mount для datastore на базі XFS, ext4 або LVM, відредагуйте /etc/fstab, видаліть рядок datastore і відмонтуйте шлях:

umount /mnt/datastore/<DATASTORE_NAME>

Очікуваний результат: шлях datastore більше не змонтований.

Щоб видалити ZFS pool після видалення або міграції всіх потрібних резервних копій:

zpool export <DATASTORE_NAME>

Очікуваний результат: ZFS експортує pool. За потреби імпортуйте його пізніше командою zpool import <DATASTORE_NAME>.

Усунення несправностей

APT показує 401 Unauthorized для enterprise-репозиторію

Причина: enterprise-репозиторій увімкнений без дійсної підписки.
Виправлення: вимкніть /etc/apt/sources.list.d/pbs-enterprise.sources за допомогою Enabled: false, додайте no-subscription репозиторій і знову виконайте apt update.

Створення datastore завершується помилкою на непідтримуваній файловій системі

Причина: шлях datastore розміщений на файловій системі, яка не підтримує потрібну структуру каталогів, або файлова система була створена з несумісними параметрами.
Виправлення: використовуйте xfs, ext4 або zfs. Уникайте ext3 і уникайте конфігурацій ext4 з вимкненим dir_nlink.

Mount datastore зникає після перезавантаження

Причина: у /etc/fstab відсутній запис, вказано неправильний UUID або запис вказує на неправильний пристрій.
Виправлення: виконайте blkid <DATA_PARTITION>, виправте UUID у /etc/fstab, потім виконайте mount -a.

Клієнт бачить неправильний namespace

Причина: конфігурація client storage використовує неправильний namespace або має ACLs на root datastore.
Виправлення: видаліть broad ACLs з /datastore/<DATASTORE_NAME>, надайте права лише на /datastore/<DATASTORE_NAME>/<NAMESPACE_NAME> і підтвердьте, що storage entry Proxmox VE використовує правильний namespace.

Тестовий SMTP email не надходить

Причина: SMTP authentication, TLS settings, sender policy або firewall rules неправильні.
Виправлення: перевірте SMTP host, port, encryption mode, username, password, sender address, recipient address і outbound network access з PBS.

Backups працюють, але garbage collection не звільняє місце негайно

Причина: garbage collection видаляє лише chunks, які більше не мають посилань після того, як prune видалив backup indexes. PBS також зберігає safety windows, щоб не видалити chunks, які ще можуть використовуватися.
Виправлення: перевірте prune settings, запустите або дочекайтеся garbage collection і перегляньте datastore task logs.

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

Ви налаштували Proxmox Backup Server для початкового production-style використання: оновлення спрямовуються через правильний репозиторій, сповіщення використовують SMTP, backup storage розміщене на окремому диску, а кілька хостів розділені за допомогою namespaces і namespace-specific ACLs. Така структура зберігає один ефективний PBS datastore і водночас надає кожному хосту Proxmox VE або клієнту власну контрольовану backup area.

Як наступні кроки, налаштуйте scheduled backup jobs на кожному хості Proxmox VE, додайте verification jobs для збережених резервних копій, задокументуйте процес granular restore і restore individual files, протестуйте file-level restore і повне відновлення VM, а також розгляньте remote sync або tape backup для off-site protection.

Версія документа: 1.0
Останнє оновлення: Травень 2026
Власник: Команда технічної документації