Всем привет. Столкнулся с проблемой и уже голову сломал.
Обновил Proxmox VE с 8.x до 9.2 на днях (решил что пора, а то отстал от жизни). После перезагрузки вроде всё работает, ВМ запускаются, LXC стартуют. А бэкапы — нет.
Смотрю в лог — ошибка: “backup failed: unable to create temporary directory”. Путь к storage правильный, места полно (смотрел через df -h). Пробовал создать файл вручную в /var/lib/vz/dump — создаётся. А через GUI или vzdump — та же ошибка.
Кто сталкивался? Может права доступа сбились после обновления? Или какой-то сервис не стартанул?
Proxmox стоит на выделенном сервере, особо ничего не трогал, только обновление сделал через apt.
1. Проверил права на /var/lib/vz/dump — владелец root, всё как надо. chmod 755 на всякий случай сделал — не помогло.
2. Запустил вручную: vzdump 101 --compress zstd --mode snapshot. Выдаёт ту же ошибку про создание временной директории. При этом в /var/lib/vz/dump/tmp файлы не создаются вообще.
3. Посмотрел, не забился ли inode (было такое на прошлой неделе на другой ноде) — df -i показывает 5% использовано, не в этом дело.
4. Глянул journalctl -u pve-daily-update — там чисто, никаких ошибок.
5. Заглянул в /etc/pve/datacenter.cfg — ничего не изменилось после обновления, всё как было.
Думаю, может при обновлении какой-то пакет не доустановился? pveversion выдаёт 9.2-1. Кто-нибудь сталкивался именно с такой ошибкой после обновления с 8.x?
У меня ZFS, стоят две софтварные зеркала (raid1) на SSD. Гости — файлы в каталоге (images/100/vm-100-disk-0.qcow2, классика). Не LVM-thin.
dmesg глянул — там куча “Buffer I/O error” на одном из дисков в зеркале. Похоже, после обновления zpool поднялся, но один диск сыпется. При этом zpool status показывает ONLINE, scrub ошибок не нашёл. Может, контроллер SATA начал чудить?
Вот думаю — может из-за этого vzdump не может темповую директорию создать? Типа при создании временного файла проверяется весь storage pool и натыкается на проблемный диск?
Проверю заменой диска на днях. У кого-то было похожее?
Ну классика не самая хорошая, я очень сильно не рекомендую использовать файлы (не смотря на то, некоторые техноблогеры предлагают так делать), в рамклах kvm/libvirt это стандартное решение, но я делал разбор процесса создания бэкапа на файлах и там было все очень печально.
Надо посмотреть на каком именно разделе PVE создает временный каталог, проверить, есть там свободное место (уже не помню расположение, но делал разбор на lvm, в вашем случае смотреть надо) и как происходит копирование.
Сам скрипт находится тут /usr/share/perl5/PVE/VZDump/LXC.pm, можно добавить сюда отладочную информацию и посмотреть по процессу дампа что происходит, в свое время мне такой подход помог с локализацией проблемы.
KRom, спасибо за разбор! Про файлы согласен — сам понимаю что не идеал, но исторически сложилось, пока не было времени переезжать на LVM-thin. По поводу временной директории — глянул в коде, PVE создаёт temp в /var/lib/vz/dump/tmp, а он на той же ZFS pool’е. И похоже, что проблема именно в битом диске из зеркала — при создании временного файла происходит ошибка ввода-вывода. Попробую на днях заменить SSD и отпишусь.
KRom, глянул скрипт по твоей подсказке. Там действительно всё упирается во временную директорию, которую vzdump пытается создать на том же пуле, где лежат ВМ. У меня ZFS пул на двух SSD в зеркале — похоже, что при попытке создать temp на пуле происходит какая-то операция, которая триггерит ошибку на подумирающем диске.
Пока жду замену (заказал свежий SSD), решил попробовать костыль — сделал отдельную директорию для temp на другом хранилище (у меня есть отдельный HDD на SATA, чисто для бэкапов) и примонтировал её в /var/lib/vz/dump/tmp. Не помогло. vzdump всё равно идёт на пул.
Нашёл ещё одну штуку — если задать --tmpdir через командную строку при запуске vzdump, вообще игнорирует параметр, создаёт temp где хочет сам. Это бага 9.2 или так было всегда?
Полез глубже — сделал zpool clear, перезапустил, ошибки Buffer I/O в dmesg пропали. Но бэкапы всё равно падают. Как думаешь, может дело не в диске, а в самом механизме создания снапшотов ZFS? После обновления могла измениться совместимость zfsutils-linux с ядром? У тебя какая версия zfsutils?
Как писал выше, у меня LVM и по временной папке можно сделать вывод, что при использовании файлов снепшоты не создаются, как раз таки использование lvm thin и ZFS zvol позволяет задействовать механизм снепшотов. При хранении дисков файлах
vzdump копирует файлы во временный каталог
замораживает или выключает гостя
повторно синхронизирует файлы, которые изменились с момента 1 шага пока гость работал
восстанавливает работу гостя
бэкапирует файлы из временного каталога
удаляет временный каталог
Со снепшотами процесс сводится к
создает снепшот
мнтирует снепшот во /mnt/vzsnap0
бэкапирует /mnt/vzsnap0
Размонтирует и удаляет снепшот
Я бы попробовал обновить PVE до актуальной версии, может еще перезагрузить для того, чтобы примилось новое ядро, ну и дальше ковырять уже
KRom, спасибо за разбор. Версия zfsutils — 2.4.2, да. Я понял твою мысль про файлы vs снепшоты — разница в процессе очевидна, теперь вижу почему все советуют LVM-thin или zvol.
Попробовал обновить PVE до последней (9.2-3, как у тебя). Через apt обновление пришло, ребутнулся — ошибка осталась. Похоже, дело правда в диске.
Попробовал ради интереса отключить один диск из зеркала (zpool detach) и запустить бэкап на оставшемся — и о чудо, всё заработало. Вывод — проблема именно в подумирающем SSD, который при записи давал ошибки. Пока гоняю на одном диске, жду курьером новый.
В любом случае, твоя подсказка про /usr/share/perl5/PVE/VZDump/LXC.pm помогла понять куда копать. Без неё я бы ещё неделю тыкался. Спасибо!
KRom, по поводу zpool status — он показывал ONLINE на обоих дисках. Никаких признаков деградации. Потому что ошибки были на уровне контроллера (Buffer I/O errors в dmesg), а ZFS их не засчитывала как сбой диска — они не доходили до уровня zpool. Видимо, диск сам ретраил операции и в итоге возвращал успех, но с задержкой. А vzdump при создании временного файла натыкался на этот таймаут и падал.
В общем, заменил проблемный SSD — теперь всё летает, бекапы ходят по расписанию. Спасибо за помощь, без твоей подсказки про скрипт я бы ещё долго копал.