Коли говорять про Proxmox Backup Server (PBS), майже завжди мають на увазі резервне копіювання віртуальних машин Proxmox VE. Саме так я теж сприймав його на початку.

Але з часом виявилося, що разом із Proxmox Backup Client він може значно більше.

Клієнт можна встановити практично на будь-який сучасний Linux-сервер і використовувати для резервного копіювання каталогів, службових даних або навіть цілих блочних пристроїв — незалежно від того, чи працює сервер під керуванням Proxmox VE.

У цій статті хочу поділитися не лише технічними можливостями PBS Client, а й пояснити, чому він став частиною моєї стратегії побудови простої та підтримуваної інфраструктури.

Проблема, яку я намагався вирішити

Майже кожен новий Linux-сервер потребує резервного копіювання. Раніше типовий сценарій виглядав приблизно однаково:

  • Bash-скрипт + cron;
  • Bash-скрипт, який запускає Jenkins;
  • Restic;
  • BorgBackup;
  • rsync для окремих задач.

Усі ці рішення працюють. Проблема не в них. Проблема в тому, що кожен новий інструмент додає ще один компонент, який потрібно підтримувати: власну конфігурацію, автоматизацію, журналювання, моніторинг, оновлення, документацію та окремі процедури відновлення.

Згодом саме ця "дрібна" інфраструктура починає забирати дедалі більше часу. Саме тоді я почав ставити собі просте питання: «Чи не вміє це вже той інструмент, який працює в моїй інфраструктурі?»

Чому саме Proxmox Backup Client

Proxmox Backup Server у мене вже використовувався для резервного копіювання віртуальних машин. Тому замість розгортання ще однієї системи резервного копіювання я вирішив уважніше подивитися на офіційний proxmox-backup-client.

Виявилося, що його можливостей більш ніж достатньо для більшості Linux-серверів.

Що я резервую

На сьогодні через PBS Client резервуються:

  • Docker Volumes;
  • каталоги застосунків;
  • конфігурації /etc, Nginx і HAProxy;
  • дампи PostgreSQL та MySQL;
  • Git-репозиторії;
  • домашні каталоги користувачів;
  • службові директорії;
  • окремі block devices (блочні пристрої).

Фактично майже все, що не є віртуальною машиною.

Файлові резервні копії

Для резервного копіювання каталогів використовується формат pxar (Proxmox File Archive):

proxmox-backup-client backup etc.pxar:/etc \
    --repository root@pam@pbs:backup

Формат pxar надійно зберігає:

  • права доступу та власників файлів;
  • списки контролю доступу (ACL);
  • символічні посилання (symbolic links);
  • розширені атрибути (extended attributes);
  • мітки часу (timestamps).

Тобто після відновлення ми отримуємо максимально точну та робочу копію файлової системи.

Резервне копіювання block devices

Саме ця можливість, на мою думку, є найбільш недооціненою. PBS Client дозволяє резервувати не лише каталоги, а й цілі блочні пристрої.

Наприклад:

proxmox-backup-client backup disk.img:/dev/sda \
    --repository root@pam@pbs:backup

Це особливо зручно для фізичних серверів, Raspberry Pi, промислових комп'ютерів, edge-пристроїв та будь-яких Linux-систем, які не працюють безпосередньо під Proxmox VE, але потребують швидкого відновлення «на голе залізо».

Як працює дедуплікація

Однією з головних переваг PBS є дедуплікація на рівні чанків (chunks). Кожна резервна копія виглядає як повноцінний snapshot, але клієнт фізично передає лише нові або змінені чанки даних. Завдяки цьому:

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

Додатково на рівні PBS забезпечується глобальна дедуплікація (між різними хостами в межах одного datastore), стиснення, клієнтське шифрування, регулярна перевірка цілісності даних на сервері та політики автоматичного видалення старих копій (Retention).

Metadata Change Detection

Починаючи з нових версій PBS Client доступний режим оптимізації порівняння:

--compare-content metadata

У цьому режимі клієнт швидко аналізує метадані файлів (mtime, розмір) та не перечитує вміст незмінених файлів для хешування. Для великих файлових дерев із сотнями тисяч файлів це критично скорочує час виконання бекапу та навантаження на диски клієнта.

Відновлення даних

Відновити каталог можна буквально однією командою:

proxmox-backup-client restore etc.pxar ./restore \
    --repository root@pam@pbs:backup

Крім цього, PBS підтримує інтерактивне монтування архівів через FUSE за допомогою команди proxmox-backup-client mount. Це дозволяє здійснювати вибіркове відновлення окремих файлів без необхідності розгортати чи завантажувати весь архів.

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

Як я автоматизую резервне копіювання

Колись мої резервні копії запускалися через cron або Jenkins-конвеєри з купою Bash-скриптів. Сьогодні я майже завжди використовую systemd timers. Це дає кілька важливих переваг:

  • централізоване керування та моніторинг статусів через systemctl;
  • автоматичне журналювання виводу в journald;
  • можливість гнучко налаштовувати залежності між сервісами (наприклад, створювати бекап тільки після успішної зупинки чи дампу БД);
  • простіша діагностика помилок при збоях.

Для сучасних Linux-систем це набагато більш природний та надійний спосіб автоматизації, ніж cron.

Практичні нюанси

Перед впровадженням PBS Client варто врахувати кілька важливих моментів:

  • HTTPS та мережа: Клієнт взаємодіє з PBS через HTTPS (порт 8007 за замовчуванням). У закритих мережах може знадобитися налаштування firewall, VPN або reverse proxy.
  • TLS: Якщо на PBS використовується самопідписаний сертифікат, у клієнті потрібно явно вказувати SSL fingerprint сервера або додавати сертифікат до довірених.
  • Продуктивність: Дедуплікація та шифрування потребують ресурсів процесора на клієнтському хості під час підготовки чанків.
  • Підтримувані ОС: Proxmox Backup Client розроблений під Linux. Нативного клієнта для Windows наразі немає, тому для Windows-серверів доводиться використовувати інші інструменти або проміжні скрипти відновлення.

Коли PBS Client — хороший вибір

На мою думку, він чудово підходить для Docker-хостів, фізичних Linux-серверів, Git-серверів, edge-пристроїв (наприклад, Raspberry Pi), резервування конфігурацій та у середовищах, де Proxmox Backup Server вже успішно функціонує для віртуалізації.

Коли я обрав би інше рішення

PBS Client — не універсальна відповідь на будь-яке завдання. Я б розглянув альтернативи, якщо:

  • потрібно резервувати Windows-системи без додаткових посередників;
  • немає можливості або бажання підтримувати окремий інстанс Proxmox Backup Server;
  • команда вже побудувала надійні процеси навколо Restic, Borg чи Veeam, і їх заміна не дасть очевидного профіту.

Водночас сучасні версії PBS вже підтримують S3-сумісні object storage як backend для datastore. Це дозволяє використовувати хмарне сховище як частину стратегії резервного копіювання 3-2-1. Плануючи таку архітектуру, варто враховувати не лише вартість зберігання, а й ціну API-запитів, вихідного трафіку та швидкість відновлення.

Архітектурний підхід

Я не вважаю Proxmox Backup Client найкращим інструментом для будь-якого сценарію. Але якщо Proxmox Backup Server вже працює в інфраструктурі, логічно спочатку максимально використати його можливості, а вже потім додавати нові компоненти. Такий підхід дозволяє зменшити кількість сервісів, використовувати єдині політики, спростити моніторинг та стандартизувати процес відновлення.

Висновок

Для мене Proxmox Backup Client став прикладом того, як існуючий інструмент може вирішити значно ширше коло задач без появи «зоопарку» утиліт. Він дозволив мені зробити інфраструктуру простішою: менше окремих інструментів, менше власних скриптів, єдиний підхід до резервного копіювання Linux-систем і менше компонентів, які потрібно підтримувати роками. І саме такі рішення, на мою думку, найкраще витримують перевірку часом.

Схожі замітки