Ви встановили Proxmox VE. Веб‑інтерфейс завантажується. Ви можете створити ВМ. Ви відчуваєте впевненість.
Потім о 3‑й годині ночі заповнюється диск, резервні копії «успішні», але не відновлюються, і хтось виявляє, що ваш адмін‑інтерфейс доступний з мережі гостьових систем. Ось коли Proxmox перестає бути лабораторним іграшкою й стає інфраструктурою. Хороша новина: перші 10 виправлень переважно нудні, швидкі та надзвичайно ефективні.
Короткий історичний контекст (бо він пояснює «різкі краї»)
- Корені Proxmox VE — у Debian. Це означає, що ви отримуєте стабільність і культуру пакування Debian — а також очікування, що ви поводитесь як системний адміністратор, а не як чарівник.
- KVM став «гіпервізором Linux» більше десяти років тому. Proxmox користується цією зрілістю. Більшість дивностей, які ви бачите, пов’язані з мережею/сховищем, а не з самим KVM.
- LXC-контейнери старші за Docker. LXC ближчий до семантики «легкої ВМ»: чудово для сервісів, але ви успадковуєте обмеження спільного ядра.
- ZFS не створювався для «ой, я заповнив пул». Це транзакційна файлова система, яка винагороджує планування і карає за брехню про вільне місце.
- Тонке забезпечення (thin provisioning) існувало до хмарного хайпу. Overcommit завжди був обліковим трюком із фізичним рахунком пізніше.
- Файлові системи кластера і кворум — старі, вередливі дисципліни. Corosync — це не нова магія; це реальність розподілених систем із кращими інструментами.
- Позначення «успіх резервного копіювання» оманливе з часів стрічок. Зелена галочка означає «завдання виконано», а не «дані відновлюються».
- «Інфраструктура як домашні улюбленці» колись була нормою. Proxmox гнучкий настільки, що дозволяє вам так і далі працювати. Не робіть цього.
Цитата, яку варто тримати на моніторі, у вільній парафразі від John Allspaw: парафразована ідея: надійність походить від проєктування під відмови і швидкого навчання, а не від ілюзії їхнього виключення.
1) Виправте репозиторії пакетів (і оновлюйте як дорослий)
Одразу після встановлення Proxmox налаштований або на enterprise‑репозиторій (який вимагає підписки), або на щось, що ви успадкували з половинчастого гайду. Ваше перше завдання — зробити оновлення передбачуваними. Передбачуваність краща за геройство.
Завдання 1: Дізнайтеся, які репозиторії ви насправді використовуєте
cr0x@server:~$ grep -R --line-number -E 'pve|proxmox|ceph' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
/etc/apt/sources.list.d/ceph.list:1:deb http://download.proxmox.com/debian/ceph-quincy bookworm no-subscription
Що означає вивід: Наразі ви використовуєте enterprise‑репо для PVE (потрібна підписка) і no‑subscription для Ceph.
Рішення: Якщо у вас немає підписки, відключіть pve-enterprise і використовуйте репозиторій no‑subscription. Якщо підписка є — залиште enterprise і видаліть no‑subscription, щоб уникнути змішаного походження пакетів.
Завдання 2: Вимкніть enterprise‑репо (якщо немає підписки)
cr0x@server:~$ sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list
cr0x@server:~$ cat /etc/apt/sources.list.d/pve-enterprise.list
# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
Що означає вивід: Воно закоментовано. APT не буде намагатися звертатися до enterprise і отримувати 401.
Рішення: Додайте репозиторій no‑subscription, щоб отримувати оновлення безпеки.
Завдання 3: Додайте репо no‑subscription (PVE)
cr0x@server:~$ echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" | tee /etc/apt/sources.list.d/pve-no-subscription.list
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
cr0x@server:~$ apt-get update
Hit:1 http://download.proxmox.com/debian/pve bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Reading package lists... Done
Що означає вивід: Індекси успішно оновлені. Немає червоних «401 Unauthorized» в логах.
Рішення: Патчіть хост зараз, а потім запровадьте рутину (щотижня підходить для більшості невеликих середовищ; щодня — для викритих систем).
Завдання 4: Перевірте, що буде оновлено до того, як робити це
cr0x@server:~$ apt-get -s dist-upgrade | sed -n '1,25p'
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
pve-kernel-6.8.12-4-pve proxmox-ve pve-manager ...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Що означає вивід: Режим симуляції (-s) показує вплив. Оновлення ядра означає перезавантаження. Оновлення менеджменту можуть перезапустити сервіси.
Рішення: Якщо це продакшн, заплануйте вікно перезавантаження. Якщо це ваш перший нод, перезавантажте зараз і вивчіть цикл.
Авторська порада: Не «налаштовуйте і забувайте» оновлення хоста. Proxmox — це керуюча площина. Непатчена керуюча площина — шлях до вихідних уїкендів.
2) Обмежте доступ користувачів, реалмів і прав
Proxmox робить простою роботу під root@pam. Це також шлях до того, що пароль у спільному доступі опиниться на липкій папірці. Використовуйте іменовані облікові записи та принцип найменших привілеїв. Ваш майбутній я пришле листівку подяки.
Завдання 5: Перелічіть користувачів і подивіться, хто що може
cr0x@server:~$ pveum user list
┌─────────────┬───────────┬───────────┬──────────────────────┐
│ userid │ enable │ expire │ firstname │
╞═════════════╪═══════════╪═══════════╪══════════════════════╡
│ root@pam │ 1 │ │ │
│ alice@pam │ 1 │ │ Alice │
└─────────────┴───────────┴───────────┴──────────────────────┘
cr0x@server:~$ pveum acl list | head
/:
user:root@pam role:Administrator
Що означає вивід: Лише root@pam явно має адміністраторські права. Це типово для свіжої інсталяції.
Рішення: Створіть іменованого адміністратора, а потім обмежте щоденне використання root як «лікувальний» доступ.
Завдання 6: Створіть іменованого адміністратора і вимагайте MFA на краю (або принаймні сильну автентифікацію)
cr0x@server:~$ pveum user add sre-admin@pam --comment "Named admin account"
cr0x@server:~$ pveum passwd sre-admin@pam
Enter new password:
Retype new password:
cr0x@server:~$ pveum aclmod / -user sre-admin@pam -role Administrator
cr0x@server:~$ pveum acl list | head -n 10
/:
user:root@pam role:Administrator
user:sre-admin@pam role:Administrator
Що означає вивід: Тепер у вас є другий адміністратор, отже ви можете припинити щоденне використання root.
Рішення: Залишайте root@pam для екстрених випадків і автоматизації, яка дійсно цього потребує, а не для випадкових кліків.
Історія з практики: інцидент через неправильні припущення
У середній компанії новий адміністратор вірив, що «UI Proxmox у мережі управління, тож ніхто не довірений його не бачить». Це було правда в його голові, а не в комутаторах.
Підрядник, підключившись до вільного порту, опинився в тому ж VLAN, що і гіпервізори. Ніхто не помітив, бо «все працювало», а мережеву діаграму оновлювали ще тоді, коли її друкували.
Їх не зламав національний актор; їх знайшов нудьгуючий сканер, який виявив сторінку входу і підібрав слабкий спільний пароль root. Зловмисник створив ВМ, використав її як плацдарм, першим симптомом став стрибок вихідного трафіку.
Виправлення не було екзотичним: відокремити мережу управління, обмежити доступ до UI, вимкнути парольний SSH для root і припинити ділитися обліковими даними. Боляче було лише те, що припущення не замінюють контролі.
3) Загартуйте SSH і перестаньте логінитися як root
SSH — це скелетний ключ. Ставтеся до нього відповідально. Ви хочете: автентифікацію за ключами, заборону логіну root і слід, за яким можна простежити дії.
Завдання 7: Перевірте поточні важливі налаштування SSH
cr0x@server:~$ sshd -T | egrep '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication) '
permitrootlogin yes
passwordauthentication yes
pubkeyauthentication yes
kbdinteractiveauthentication no
Що означає вивід: Дозволені логін root і автентифікація паролем. Це зручно; це також запрошення до проблем.
Рішення: Вимкніть логін root і автентифікацію паролем, коли у вас працюють ключі для іменованого користувача.
Завдання 8: Застосуйте базове посилення як drop‑in
cr0x@server:~$ install -d -m 0755 /etc/ssh/sshd_config.d
cr0x@server:~$ cat > /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOF
cr0x@server:~$ sshd -t && systemctl reload ssh
Що означає вивід: sshd -t перевіряє синтаксис. Reload застосовує зміни, не риваючи існуючі сесії.
Рішення: Протестуйте нову SSH‑сесію перед тим, як закривати поточну. Заблокувати себе — обов’язковий ритуал, але його можна уникнути.
Завдання 9: Підтвердіть, що можете зайти, а root — ні
cr0x@server:~$ ssh -o PreferredAuthentications=publickey sre-admin@192.0.2.10 'id'
uid=1001(sre-admin) gid=1001(sre-admin) groups=1001(sre-admin)
cr0x@server:~$ ssh -o PreferredAuthentications=password root@192.0.2.10 'true'
root@192.0.2.10: Permission denied (publickey).
Що означає вивід: Іменований адміністратор працює з ключами. Root заблокований.
Рішення: Залиште консольний доступ (IPMI/iKVM/фізичний) як шлях для екстрених втручань. Не покладайтеся на SSH як на єдині двері.
4) Увімкніть брандмауер (правильним способом)
У Proxmox є пристойний брандмауер. Він не чарівний. Найпоширеніша помилка — увімкнути його скрізь, не розуміючи порядок правил, і втратити доступ.
Короткий жарт №1: Брандмауери як ремені безпеки: ви лише шкодуєте, що не користувалися ними під час «захоплюючих» моментів.
Завдання 10: Перегляньте поточний стан брандмауера і правила
cr0x@server:~$ pve-firewall status
Status: disabled/running (cluster: disabled)
cr0x@server:~$ pve-firewall localnet
192.0.2.0/24
Що означає вивід: Демон брандмауера запущений, але не застосовується. localnet — це те, що Proxmox вважає «довіреною» мережею. Якщо це неправильно, ваші правила будуть хибними.
Рішення: Визначте підмережі управління як localnet, а потім обережно ввімкніть брандмауер на рівні датацентру, потім на вузлі.
Завдання 11: Підтвердіть IP управління і підмережу, в якій він знаходиться
cr0x@server:~$ ip -br addr show vmbr0
vmbr0 UP 192.0.2.10/24 fe80::5054:ff:fe12:3456/64
cr0x@server:~$ ip route show default
default via 192.0.2.1 dev vmbr0
Що означає вивід: Ваш інтерфейс управління на vmbr0 з адресою 192.0.2.10/24. Маршрут за замовчуванням також там.
Рішення: Якщо гості ділять цю мережу, зупиніться і перерахуйте дизайн. Управління не має бути «просто ще одним VLAN», до якого віртуальні машини можуть підключатися безконтрольно.
Завдання 12: Увімкніть брандмауер і дозвольте лише необхідне для хоста
cr0x@server:~$ pvesh set /cluster/firewall/options --enable 1
cr0x@server:~$ pvesh set /nodes/$(hostname)/firewall/options --enable 1
cr0x@server:~$ pvesh get /nodes/$(hostname)/firewall/options
┌────────────┬────────┐
│ key │ value │
╞════════════╪════════╡
│ enable │ 1 │
└────────────┴────────┘
Що означає вивід: Брандмауер увімкнено на рівні кластера й на вузлі. Вам все ще потрібні явні правила, інакше ви можете втратити доступ залежно від налаштувань за замовчуванням.
Рішення: Додайте правило дозволу для управління веб‑UI та SSH з localnet, потім правило за замовчуванням «drop» для всього іншого.
Завдання 13: Підтвердіть, що порти слухають, і що вони доступні лише з потрібних місць
cr0x@server:~$ ss -lntp | egrep '(:22|:8006)\s'
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1123,fd=3))
LISTEN 0 4096 0.0.0.0:8006 0.0.0.0:* users:(("pveproxy",pid=1876,fd=6))
Що означає вивід: SSH і веб‑проксі Proxmox прив’язані до всіх IPv4‑адрес. Це нормально для вузла з одним інтерфейсом.
Рішення: Якщо не вдається ізолювати прив’язкою, ізолюйте мережевим дизайном і правилами брандмауера. «Bound to 0.0.0.0» — нормально, якщо ваш брандмауер і VLAN‑и налаштовані правильно.
5) Виправте мережу управління та мости
Більшість болю в Proxmox фактично походить від мереж Linux у красивому обгорті. Мости — потужні; вони також чесні. Якщо ваша фізична мережа недбала, Proxmox точно відтворить цю недбалість на швидкості лінії.
Завдання 14: Перевірте фактичну конфігурацію моста, яку використовує Proxmox
cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto enp3s0
iface enp3s0 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.0.2.10/24
gateway 192.0.2.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
Що означає вивід: Проста конфігурація: один NIC, один міст. Гості, приєднані до vmbr0, опиняються в тому ж L2, що й інтерфейс управління.
Рішення: Якщо це не лабораторія, розділіть трафік управління і гостьовий трафік VLAN‑ами або другим NIC. Принаймні: управління має бути на тегованому VLAN, доступному лише ІТ.
Завдання 15: Перевірте стан лінка і проблеми драйвера (швидка вигода)
cr0x@server:~$ ethtool enp3s0 | egrep 'Speed|Duplex|Link detected'
Speed: 1000Mb/s
Duplex: Full
Link detected: yes
Що означає вивід: У вас 1GbE. Це нормально для домашньої лабораторії; це також спосіб випадково створити «повільне сховище», яке насправді є «повільною мережею».
Рішення: Якщо плануєте спільне сховище або резервні копії по мережі, 10GbE — це не розкіш. Це запас міцності.
6) Час, NTP і сертифікати: нудно, поки не підведуть
Якщо час неправильний, TLS свариться, кластери поводяться дивно, а логи стають вигаданими. Якщо сертифікати в безладі, ваш браузер привчить вас ігнорувати попередження — поки не наставатиме ситуація, коли цього не можна робити.
Завдання 16: Перевірте синхронізацію часу і часовий пояс
cr0x@server:~$ timedatectl
Local time: Sun 2025-12-28 11:02:15 UTC
Universal time: Sun 2025-12-28 11:02:15 UTC
RTC time: Sun 2025-12-28 11:02:16
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Що означає вивід: Годинник синхронізовано. UTC — хороший дефолт для серверів, якщо немає вагомих причин інакше.
Рішення: Тримайте хости в UTC. Налаштуйте відображення в моніторингових інструментах, якщо людям важливо бачити локальний час.
Завдання 17: Перевірте стан сертифікатів (і уникайте навчання поганих звичок)
cr0x@server:~$ pvecm status 2>/dev/null | head -n 5
Cluster information
-------------------
Name: pve-cluster
Config Version: 1
Transport: knet
Що означає вивід: Якщо ви вже в кластері, узгодженість сертифікатів і імен хостів має більше значення. Навіть на одиночному вузлі тримайте ім’я хоста стабільним.
Рішення: Не перевстановлюйте та не перейменовуйте вузли без потреби. Proxmox лояльний, але кластери пам’ятають.
7) Оберіть схему сховища, що відповідає реальності
Рішення щодо сховища — місце, де початківці тихо руйнуються. Proxmox охоче дозволить побудувати щось, що дає гарні бенчмарки й вибухає при навантаженні. Потрібно вирішити: локальне сховище чи спільне, ZFS чи LVM‑thin, і куди зберігаються резервні копії.
Три розумні шаблони для початківців
- Одиночний вузол, локальні диски: ZFS‑дзеркало для ВМ + окремий диск/датасет для резервних копій (бажано не в тому ж пулі).
- Малий кластер без спільного сховища: Локальний ZFS на кожному вузлі + резервні копії на виділений Proxmox Backup Server (PBS) + прийняття того, що жива міграція потребує спільного сховища або стратегій реплікації.
- Кластер зі спільним сховищем: Ceph (мінімум 3 вузли для розумної роботи) або виділений SAN/NAS. Це не «для початківця з першого дня», якщо вам не подобається розбиратися в розподілених системах о 2‑й ночі.
Завдання 18: Ідентифікуйте диски та поточний стек сховища
cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME SIZE TYPE FSTYPE MOUNTPOINTS
sda 447.1G disk
├─sda1 1007K part
├─sda2 1G part vfat /boot/efi
└─sda3 446.1G part zfs_member
sdb 3.6T disk
└─sdb1 3.6T part
Що означає вивід: Ваш OS/VM пул на ZFS (zfs_member). Є ще один великий диск (sdb), який наразі не використовується або відформатований інакше.
Рішення: Використовуйте sdb для резервних копій, а не для «додаткового місця для ВМ». Конкуренція резервних копій із I/O віртуальних машин — шлях до латентності.
Завдання 19: Перевірте стан пулу перед тим, як довіряти йому
cr0x@server:~$ zpool status
pool: rpool
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
sda3 ONLINE 0 0 0
errors: No known data errors
Що означає вивід: Пул онлайн без помилок. Також: це один диск. Це не надлишковість; це надія.
Рішення: Якщо це щось важливе, перебудуйте як дзеркало. Однодисковий ZFS root‑пул підходить для лабораторії, але не для вашої платіжної ВМ.
Цікавий факт: ZFS контролює контрольні суми кожного блока і може самовідновлюватися — але лише якщо ви дали йому другу копію (дзеркало/RAIDZ). На одному диску воно може виявити корупцію і просто знизати плечима.
8) Основи ZFS: що налаштовувати, а що залишити
Культура тюнінгу ZFS багатьом нагадує хобі. Частина цього правдива. Багато — це наслідування старих форумних порад 2016 року на ядра 2025. Ваше завдання — тримати все простим, вимірюваним і відновлюваним.
Дефолти ZFS для початківців, з якими не варто боротися
- Дозвольте ARC керувати собою, якщо немає конкретних проблем з пам’яттю.
- Не вмикайте випадкові алгоритми стиснення, бо прочитали, що вони «швидші». Використовуйте
lz4і рухайтеся далі. - Не встановлюйте великий
recordsizeбез розуміння робочого навантаження. ВМ генерують випадкові I/O.
Завдання 20: Підтвердіть ключові властивості датасету ZFS для сховища ВМ
cr0x@server:~$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 98G 300G 96K /rpool
rpool/ROOT 12G 300G 96K /rpool/ROOT
rpool/data 72G 300G 96K /rpool/data
rpool/data/vm-100-disk-0 40G 300G 40G -
cr0x@server:~$ zfs get -o name,property,value compression,atime,recordsize,volblocksize rpool/data
NAME PROPERTY VALUE
rpool/data compression lz4
rpool/data atime off
rpool/data recordsize 128K
rpool/data volblocksize -
Що означає вивід: lz4 і atime=off — добре. recordsize для датасету впливає на файли; ZVOL‑и використовують volblocksize.
Рішення: Для дисків ВМ звертайте увагу на блоковий розмір ZVOL під час створення (часто 16K — хороший компроміс для змішаних навантажень). Не міняйте ці налаштування без потреби.
Завдання 21: Перевірте вільний простір пулу і ризик фрагментації
cr0x@server:~$ zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH
rpool 446G 98G 348G - 12% 22% 1.00x ONLINE
Що означає вивід: 22% використання — нормально. Проблеми починаються, коли ви вважаєте «FREE» доступним до нуля.
Рішення: Тримайте ZFS‑пули нижче ~80% заповнення для стабільної продуктивності. Нижче ~70% — якщо хочете менше сюрпризів зі снапшотами і сильним churn.
Завдання 22: Встановіть явну політику резервування місця (необов’язково, але розумно)
cr0x@server:~$ zfs set refreservation=20G rpool/data
cr0x@server:~$ zfs get refreservation rpool/data
NAME PROPERTY VALUE SOURCE
rpool/data refreservation 20G local
Що означає вивід: Ви зарезервували 20G, щоб пул не досягав «0 байт вільних» так швидко під час зростання снапшотів.
Рішення: На маленьких пулах резервування — недорогий страховий захід. На великих пулах краще моніторинг і жорсткі квоти.
Історія з практики: оптимізація, що зіграла зле
Команда хотіла «зекономити місце» в кластері Proxmox. Вони увімкнули дедуплікацію в ZFS, бо це виглядало як безкоштовні гігабайти на слайді. Також включили агресивні налаштування стиснення і тримали все на тонкому провізіонуванні, бо цифри виглядали приємно.
Тиждень було добре. Потім змінилося навантаження: більше БД, більше churn, більше снапшотів. Використання CPU на хостах підскочило. Латентність стала стрибкоподібною. АС клієнтів назвали це «випадковою повільністю», найнеприємніша категорія проблем.
Корінь: дедуплікація ZFS вимагає багато пам’яті і карає при нестачі. DDT не помістився в RAM, тож операції читання/запису спричинили додаткові I/O. Вони оптимізували за ємністю й ненавмисно придбали генератор латентності.
Откат був болючим: дані були в дедуплікованому стані. Їм довелося мігрувати диски ВМ на новий пул із розумними налаштуваннями: lz4, без дедупа, достатньо вільного місця та чітка політика зберігання снапшотів. Заощадження місця було реальним — але вартість була операційною. Ємність — це метрика. Латентність — це досвід користувача.
9) Резервні копії, які відновлюються: PBS, розклади, зберігання, перевірка
Proxmox полегшує планування резервних копій. Він також полегшує думку, що у вас є резервні копії, коли насправді у вас є тека з файлами, які ніхто ніколи не відновлював.
Робіть це правильно:
- Зберігайте копії на окремій системі (ідеально — PBS). Не в тому ж пулі. Не на тому ж хості.
- Використовуйте розумну політику зберігання. Не «зберігати назавжди», не «зберігати дві версії».
- Перевіряйте. Тестуйте відновлення. Автоматизуйте канаркове відновлення, якщо можете.
Завдання 23: Перевірте наявні завдання резервного копіювання (або їх відсутність)
cr0x@server:~$ pvesh get /cluster/backup --output-format json-pretty
[]
Що означає вивід: Немає запланованих бекапів. Це дефолт і одночасно пастка.
Рішення: Створіть завдання сьогодні. Якщо ви «не готові», ви також не готові втратити дані.
Завдання 24: Перевірте налаштовані цілі сховища (куди можуть іти бекапи)
cr0x@server:~$ pvesm status
Name Type Status Total Used Available %
local dir active 98.00 GiB 12.30 GiB 85.70 GiB 12.55%
local-lvm lvmthin active 300.00 GiB 70.20 GiB 229.80 GiB 23.40%
Що означає вивід: У вас лише локальне сховище. Резервні копії тут кращі за нічого, але не життєздатні, якщо хост помре.
Рішення: Додайте PBS або хоча б NFS‑ціль на іншому сервері. Надавайте перевагу PBS за дедуплікацію й семантику перевірки, спеціально створену для віртуалізації.
Завдання 25: Переконайтеся, що місце для резервних копій не заповниться відразу
cr0x@server:~$ df -h /var/lib/vz
Filesystem Size Used Avail Use% Mounted on
rpool/ROOT/pve-1 98G 13G 86G 13% /
Що означає вивід: Якщо ви робите бекапи в local, то витрачаєте місце кореневого файлового сховища. Так ви можете заблокувати ноду з помилкою «No space left on device» під час вікна резервного копіювання.
Рішення: Не зберігайте бекапи на кореневому файловому сховищі довгостроково. Додайте окреме сховище для резервних копій.
Завдання 26: Запустіть ручний бекап і прочитайте результат, як щось важливе
cr0x@server:~$ vzdump 100 --storage local --mode snapshot --compress zstd --notes-template '{{guestname}} {{vmid}}'
INFO: starting new backup job: vzdump 100 --storage local --mode snapshot --compress zstd
INFO: Backup of VM 100 started at 2025-12-28 11:22:10
INFO: status = running
INFO: VM Name: app01
INFO: include disk 'scsi0' 'local-lvm:vm-100-disk-0' 50G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating vzdump archive 'vzdump-qemu-100-2025_12_28-11_22_10.vma.zst'
INFO: Total bytes written: 9876543210 (9.1GiB, 220.0MiB/s)
INFO: backup ended at 2025-12-28 11:23:05
INFO: Backup job finished successfully
Що означає вивід: Режим snapshot пройшов, стиснення застосовано, показана пропускна здатність. «Завдання успішне» необхідне — але не достатнє для відновлюваності.
Рішення: Негайно протестуйте відновлення у новий VMID або в тестову локацію. Не чекайте інциденту.
Завдання 27: Переконайтеся, що файл резервної копії існує і має розумний розмір
cr0x@server:~$ ls -lh /var/lib/vz/dump | tail -n 3
-rw-r--r-- 1 root root 9.2G Dec 28 11:23 vzdump-qemu-100-2025_12_28-11_22_10.vma.zst
-rw-r--r-- 1 root root 637 Dec 28 11:23 vzdump-qemu-100-2025_12_28-11_22_10.log
Що означає вивід: Архів і лог існують. Якщо ваша «резервна копія» — кілька мегабайт для великої ВМ, ви, ймовірно, бекапили не те або сталася помилка.
Рішення: Прочитайте лог на предмет попереджень і підтвердіть, що диски включені.
Завдання 28: Протестуйте відновлення (те, що всі пропускають)
cr0x@server:~$ qmrestore /var/lib/vz/dump/vzdump-qemu-100-2025_12_28-11_22_10.vma.zst 900 --storage local-lvm
restore vma archive: zstd -q -d -c /var/lib/vz/dump/vzdump-qemu-100-2025_12_28-11_22_10.vma.zst | vma extract -v -r /var/tmp/vzdumptmp1234 - /var/tmp/vzdumptmp1234
progress 1% (reading archive)
progress 55% (reading archive)
progress 100% (reading archive)
restore successful
Що означає вивід: Конвеєр відновлення завершився. Це ваш реальний індикатор.
Рішення: Запустіть відновлену ВМ в ізольованій мережі, перевірте здоров’я додатку, потім видаліть її. Повторюйте регулярно.
Цікавий факт: Фраза «backup window» походить з часів, коли доводилося зупиняти все інше, щоб стрімити на стрічку. SSD не отримали цей месседж, але ваші користувачі все одно відчувають біль, якщо ви насичуєте I/O під час бекапу.
10) Логи, сповіщення та сигнали місткості
Нода Proxmox може бути «здоровою» до того моменту, як різко ні. Вам потрібні ранні сигнали: заповненість дисків, стан пулу, попередження SMART, помилки бекапів і несподівані перезавантаження.
Завдання 29: Перевірте журнал на попереджувальні помилки
cr0x@server:~$ journalctl -p warning -b --no-pager | tail -n 20
Dec 28 09:12:44 server kernel: nvme nvme0: I/O 123 QID 4 timeout, aborting
Dec 28 09:12:45 server kernel: ata1.00: failed command: READ DMA EXT
Dec 28 09:12:45 server kernel: blk_update_request: I/O error, dev sda, sector 1234567 op 0x0:(READ)
Що означає вивід: Це не «шум». Таймаути і I/O‑помилки — апаратні або кабельні попередження, часто за кілька днів до відмови.
Рішення: Якщо бачите помилки I/O сховища, припиніть оптимізації і почніть заміни. Запустіть SMART, перевірте кабелі/бекплейн і плануйте міграцію.
Завдання 30: Швидко перевірте SMART (якщо використовуєте SATA/SAS)
cr0x@server:~$ smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-4-pve] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Що означає вивід: «PASSED» — не означає «мовно новий». Це просто означає, що диск ще не оголосив себе мертвим.
Рішення: Дивіться на перераспреділені сектора, pending сектори і логи помилок, а не лише заголовок.
Завдання 31: Перевірте використання дисків ВМ і ризик thin‑provision
cr0x@server:~$ lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent,lv_attr
lv_name vg_name lv_size data_percent metadata_percent lv_attr
data pve 300.00g 78.12 4.55 twi-aotz--
Що означає вивід: Ваш thin‑pool на 78% заповнений. Thin‑pools погано працюють при 100%: ВМ можуть перейти в режим тільки для читання або впасти залежно від навантаження.
Рішення: Додайте простір або зменшіть виділення до 90%. Також моніторте використання метаданих; коли метадані заповнені — це окрема катастрофа.
Короткий жарт №2: Thin‑pool на 99% — це «кот Шредінгера» сховища: і справний, і у вогні одночасно, поки ви не запишете ще один блок.
Історія з практики: нудна, але правильна процедура, яка врятувала день
Фінансова організація керувала Proxmox для внутрішніх додатків. Нічого гламурного: пара баз даних, файлові сервіси і кілька ВМ, які всі називали «тимчасовими» три роки.
Їхній SRE‑лід наполягав на нудному рутині: щотижневі оновлення хостів, нічні бекапи на PBS і щомісячне тестове відновлення випадково обраної ВМ в ізольованій мережі. Ніхто цього не любив. Це була паперова робота з додатковими кроками.
Під час звітного періоду контролер сховища почав повертати періодичні помилки. ZFS‑пул залишився онлайн, але почав показувати помилки контрольних сум. Продуктивність провалилася. Командир інциденту зробив єдино розумний крок: припинити хитрувати і відновити критичні ВМ на стенд‑нод з чистим сховищем.
Відновлення спрацювало, бо його тестували. Облікові дані були задокументовані. PBS‑датастор перевіряли. Команда не вчилася відновлювати під час, коли бізнес дивився.
Після інциденту ніхто не хвалився героїчними вчинками. Ось у чому суть. Найцінніша робота з надійності — та, яка виглядає нудною в звіті статусу.
Швидкий план діагностики: що перевірити першим/другим/третім
Коли Proxmox «відчувається повільним», люди звинувачують гіпервізор. Зазвичай це одне з трьох: латентність сховища, неправильний мережевий дизайн або нестача пам’яті. Ось як знайти вузьке місце швидко, без гадань.
Перше: чи хост зараз у стресовому стані?
cr0x@server:~$ uptime
11:41:02 up 3 days, 2:17, 2 users, load average: 8.21, 7.95, 7.10
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 64Gi 56Gi 1.2Gi 1.1Gi 6.8Gi 4.0Gi
Swap: 8.0Gi 6.5Gi 1.5Gi
Як інтерпретувати: Високе навантаження з малою доступною пам’яттю і активним свопом вказує на тиск по пам’яті. Саме по собі навантаження неоднозначне; своп — ні.
Рішення: Якщо своп активний і зростає, зменшіть overcommit пам’яті, додайте RAM або перемістіть навантаження. Також перевірте ballooning і кеші хоста.
Друге: чи насправді винен блок сховища?
cr0x@server:~$ iostat -x 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
12.00 0.00 6.00 25.00 0.00 57.00
Device r/s w/s rkB/s wkB/s await svctm %util
sda 5.0 120.0 80.0 9000.0 35.20 2.10 98.00
Як інтерпретувати: %iowait високе, а %util диска близько 100% з великим await. Це класичне насичення сховища.
Рішення: Знайдіть «гучну» ВМ, зменшіть паралельність бекапів/реплікацій, перемістіть «гарячі» диски на швидше сховище або додайте шпинделі/SSD. Не починайте з «налаштування kernel knobs».
Третє: чи справді мережа (особливо для NFS/Ceph/PBS)?
cr0x@server:~$ ip -s link show enp3s0 | sed -n '1,8p'
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
9876543210 6543210 0 120 0 12345
TX: bytes packets errors dropped carrier collsns
8765432109 5432109 0 250 0 0 0
Як інтерпретувати: Втрати пакетів (RX/TX) не є нормою на чистих мережах. Вони вказують на затори, проблеми драйвера або невідповідність MTU/черг.
Рішення: Виправте мережу перед тим, як звинувачувати Ceph/NFS. Потім перевірте узгодженість MTU, якщо використовуєте jumbo‑фрейми.
Бонус: швидко знайдіть «галасливу сусідську» ВМ
cr0x@server:~$ pvesh get /nodes/$(hostname)/qemu --output-format json-pretty | head -n 20
[
{
"cpu": 0.85,
"mem": 4294967296,
"name": "app01",
"pid": 4321,
"status": "running",
"vmid": 100
},
{
"cpu": 3.72,
"mem": 17179869184,
"name": "db01",
"pid": 9876,
"status": "running",
"vmid": 110
}
]
Як інтерпретувати: Швидкий огляд ВМ з використанням CPU. Неідеально, але добре для триажу.
Рішення: Якщо одна ВМ завантажує CPU, перевірте її диск I/O і пам’ять. «Високе CPU» може бути симптомом блокувань сховища, що викликають зайняті цикли.
Типові помилки: симптом → корінна причина → виправлення
1) Симптом: резервні копії «успішні», але відновлення не працює
Корінна причина: Копії зберігаються на тому ж хості/пулі, архів пошкоджений, відсутня конфігурація ВМ або ніколи не тестувалися процедури відновлення.
Виправлення: Зберігайте копії на PBS або зовнішньому сховищі, робіть щомісячні тести відновлення і зберігайте логи. Використовуйте перевірку на PBS і ставтеся до помилок як до інцидентів продакшн.
2) Симптом: випадкові зависання ВМ під час вікна бекапу
Корінна причина: Насичення сховища (особливо з HDD), занадто багато паралельних бекапів або thin‑pool практично заповнений, що створює тиск по метаданих.
Виправлення: Зменшіть паралельність, рознесіть розклади, встановіть I/O‑ліміти для трафіку бекапів, перенесіть бекапи з основного пулу і тримайте запас вільного місця.
3) Симптом: веб‑інтерфейс Proxmox доступний з місць, де не повинен бути
Корінна причина: Мережа управління і гості ділять той самий міст/VLAN; брандмауер вимкнено або неправильно налаштовано; прив’язка до «0.0.0.0» відкрила доступ ширшій LAN.
Виправлення: Відокремте VLAN управління, застосуйте правила брандмауера, обмежте доступ згори (ACL комутаторів) і припиніть вважати «внутрішню мережу» довіреною.
4) Симптом: кластер поводиться дивно після перезавантаження (вузли не погоджуються, GUI показує помилки)
Корінна причина: Розбіжність часу, проблеми DNS або порушення кворуму (два вузли без рішення для вирішення нічиєї).
Виправлення: Виправте NTP, використовуйте стабільні імена хостів і пряму/зворотну DNS, спроєктуйте кворум правильно (непарна кількість голосів або qdevice).
5) Симптом: ZFS‑пул «ONLINE», але продуктивність жахлива
Корінна причина: Пул занадто заповнений, сильний churn снапшотів, повільні диски або невідповідність навантаження (бази даних на HDD RAIDZ з великою кількістю sync‑записів).
Виправлення: Тримайте пул нижче ~80%, перегляньте політику зберігання снапшотів, використовуйте дзеркала для IOPS‑чутливих навантажень, додавайте SLOG лише якщо розумієте sync‑записи і вимірюйте латентність з iostat.
6) Симптом: ВМ раптово стають тільки для читання або падають; в логах хоста — помилки thin‑pool
Корінна причина: LVM‑thin pool досяг 100% по даних або метаданих.
Виправлення: Негайно розширте thin‑pool, звільніть місце і запобігайте повторенню через моніторинг і консервативне провізіонування.
Контрольні списки / покроковий план
День 0 (перша година після встановлення)
- Репозиторії: виберіть enterprise або no‑subscription; запустіть
apt-get updateі симулюйте оновлення. - Іменований адміністратор: створіть
sre-admin@pam, призначте роль адміністратора, перестаньте використовуватиroot@pamщодня. - Загартування SSH: додайте drop‑in, щоб вимкнути root і паролі; перезавантажте SSH і протестуйте входи.
- Перевірка мережі: перегляньте
/etc/network/interfaces. Якщо управління ділиться з містом гостей, плануйте виправлення зараз, а не «пізніше». - Стадія брандмауера: підтвердьте
localnet, увімкніть брандмауер обережно, переконайтеся, що маєте доступ до 8006 і 22 з мережі управління. - Синхронізація часу: переконайтеся, що
timedatectlпоказує синхронізацію.
День 1 (перед тим, як покласти щось важливе)
- Рішення по сховищу: оберіть ZFS‑дзеркало або LVM‑thin свідомо. Уникайте однодискового «продакшну».
- Стан пулу: перевірте
zpool statusіzpool list; встановіть очікування щодо запасу вільного місця. - Ціль бекапів: додайте PBS або зовнішнє сховище. Не вважаєте «бекапи на ноді» остаточним станом.
- Перший бекап + тест відновлення: запустіть
vzdumpіqmrestore, щоб довести відновлюваність.
Тиждень 1 (зробіть це стійким)
- Сигнали моніторингу: оберіть оповіщення: заповненість диска, помилки ZFS, попередження SMART, провали бекапів.
- Каденція патчів: виберіть вікно; задокументуйте очікування щодо перезавантажень для оновлень ядра.
- Політика доступу: хто має консольний доступ, хто — адміністратор, хто — права на рівні ВМ; приберіть спільні облікові дані.
- Runbook: опишіть кроки відновлення і де зберігаються бекапи. У стресі ви не згадаєте.
Питання й відповіді (FAQ)
1) Чи використовувати ZFS чи LVM‑thin для сховища ВМ?
Якщо вам потрібні характеристики цілісності даних (контрольні суми, предиктовані снапшоти, зручна реплікація), обирайте ZFS. Якщо хочете простоти і розумієте моніторинг thin‑pool, LVM‑thin підходить. Початківцям частіше краще ZFS‑дзеркало, ніж thin‑pool, який вони забудуть моніторити.
2) Чи можна зберігати резервні копії на тому ж Proxmox‑хості?
Можна, але не варто називати це «резервним копіюванням» для чого‑небудь критичного. Відмова хоста, рансомвар на хості або корупція пулу видалить і ВМ, і їхні копії одночасно. Використовуйте окрему систему.
3) Чи нормально запускати одиночний вузол Proxmox у продакшн?
Так, якщо ви приймаєте ризик і робите хороші бекапи. Багато малих бізнесів так роблять. Але будьте чесні: одиночний вузол означає простої під час оновлень і відсутність апаратної надлишковості, якщо лише сховище не дзеркалене і немає запасних частин.
4) Чому всі радять «тримати ZFS під 80% заповнення»?
Продуктивність ZFS і поведінка аллокатора погіршуються зі зменшенням вільного місця, особливо з снапшотами і фрагментованими робочими навантаженнями, як образи ВМ. Можна працювати щільніше, але ви міняєте стабільну латентність на здобуття місця.
5) Чи потрібен мені Ceph?
Ні, якщо у вас «два вузли і відчуття». Ceph корисний, коли є достатньо вузлів, мережі і операційної зрілості для керування розподіленим сховищем. Для малого кластера спочатку розгляньте простіші варіанти спільного сховища.
6) Який найлегший безпечний спосіб відкрити веб‑UI Proxmox?
Не виставляйте його прямо в інтернет. Розмістіть його в мережі управління, доступ через VPN або бастіон, і забезпечте MFA там, де ви завершуєте віддалений доступ. Якщо доводиться публікувати, ставтеся до нього як до іншої адміністративної площини і жорстко обмежуйте доступ.
7) Чому моя резервна копія ВМ так довго йшла, хоча диски швидкі?
Резервні копії — це конвеєр: читання дисків ВМ, стиснення і запис у місце призначення. Упором може бути CPU (стиснення), мережа (PBS/NFS) або сховище, затримане паралельними завданнями. Використовуйте iostat, ss/ip -s link і метрики CPU під час вікна бекапу.
8) Як дізнатися, чи безпечне thin‑provisioning?
Воно безпечне, коли ви його моніторите і можете збільшити простір до того, як він заповниться. Якщо у вас немає оповіщення і ви регулярно працюєте вище 85–90%, це не thin‑provisioning — це гра в азартні ігри з додатковими кроками.
9) Чи потрібно змінювати порти за замовчуванням (SSH/8006)?
Зміна портів — це не безпека; це легке зменшення фонової метушні. Реальні контролі — це ізоляція мережі, правила брандмауера, сильна автентифікація і патчі. Якщо зміна портів допомагає вашій моделі загроз — добре, але не плутайте це з захистом.
Практичні наступні кроки
Proxmox дозволяє швидко запуститися і чесно показує всі погані звички, які ви принесли з собою. Виправте базові речі зараз: репозиторії, облікові записи, SSH, брандмауер, мережеве розділення, синхронізацію часу, схему сховища, запас ZFS, реальні резервні копії та реальні сигнали.
Потім зробіть те, що відокремлює «я керую лабораторією» від «я керую продакшном»: внесіть у календар одне тестове відновлення і ставтеся до провалу резервної копії як до справжнього інциденту. Ваші ВМ — це робочі навантаження. Ваш Proxmox‑нод — платформа. Тримайте платформу нудною, оновленою і передбачуваною.