Очистка диска: как удалить старые резервные копии в Proxmox VE

Дисковое пространство на сервере виртуализации - ресурс, который заканчивается в пятницу вечером. Именно тогда, когда вы собрались уходить домой. Proxmox VE честно делает бэкапы по расписанию, складывает их на хранилище - и ни разу не спросит, хватит ли места для следующего. Когда хранилище заполнится на 100%, вы узнаете об этом не из мониторинга, а из панических сообщений коллег: «Виртуалки не стартуют».

Короткий ответ, если место нужно прямо сейчас. В Proxmox VE старые копии удаляет prune по политике prune-backups: задаётся в веб-интерфейсе в свойствах хранилища либо строкой в /etc/pve/storage.cfg. В Proxmox Backup Server prune только снимает ссылку на снапшот, а место возвращает отдельная процедура - garbage collection, и не раньше чем через сутки после удаления. Дальше - подробно, включая случаи, когда prune отработал, а свободного места не прибавилось.

Актуальные версии на момент обновления - Proxmox VE 9.2 (21 мая 2026) и Proxmox Backup Server 4.2 (29 апреля 2026). Всё описанное ниже относится к обеим и к предыдущим веткам 8.x/3.x. Если вы ещё на PVE 8, держите в голове дату: поддержка этой ветки заканчивается 31 августа 2026.

Почему бэкапы разрастаются быстрее, чем кажется

Допустим, у вас 20 виртуальных машин. Средний размер бэкапа одной VM - 50 ГБ (а для баз данных легко уходит за 200 ГБ). Расписание - раз в сутки, хранить 14 копий. Считаем: 20 × 50 ГБ × 14 = 14 ТБ. Это идеальный сценарий со стабильными данными. Стоит разработчикам залить пару дампов или нагенерировать логов, и размер каждого последующего бэкапа подрастает.

Цифры грубые, но картину рисуют. Оговорка: так считается только для обычных дампов vzdump, где каждая копия самостоятельна. Proxmox Backup Server хранит данные кусками с дедупликацией, и вторая копия той же машины занимает только разницу с первой. Реальный расход там ниже в разы и зависит от того, насколько сильно меняются данные внутри гостей. Формулой его не предскажешь, только измеришь на своих машинах.

Неправильное управление бэкапами - одна из частых причин переполнения дисков в Proxmox-инсталляциях. Дисковые полки, NAS, LUN-ы на СХД «съедаются» равномерно и молча. Если при планировании среды вы не закладывали запас под резервные копии, стоит заранее изучить, сколько дискового пространства требует виртуализация Proxmox. Мониторинг спасает, но только если он настроен. А удаление старых резервных копий спасает всегда.

Два способа очистки: GUI и CLI

Proxmox предлагает два пути - графический интерфейс и командную строку. Выбор зависит от того, сколько у вас нод и насколько вы любите автоматизацию.

Через веб-интерфейс

Путь: Datacenter → Backup → (выбрать задачу) → Retention. Здесь задаётся, сколько копий хранить. Можно указать количество по дням, неделям, месяцам. Proxmox VE будет автоматически удалять лишние копии при создании новой. Это ключевой момент - пока новый бэкап не создастся, старые никуда не денутся. Копия виртуальной машины целиком не заменяет копию базы внутри неё: для 1С это отдельная процедура, и копия клиент-серверной базы 1С снимается средствами СУБД.

Второй путь - на уровне хранилища: Datacenter → Storage → (выбрать хранилище) → Prune. Здесь управление тоньше: prune-опции привязаны к конкретному storage, а не к расписанию.

Для разовой ручной чистки: Datacenter → Storage → Content - выбираете ненужный бэкап и удаляете. Просто, но не масштабируется.

Через командную строку

CLI даёт контроль, которого нет в GUI. Основной инструмент - файл /etc/pve/storage.cfg. Для каждого хранилища можно прописать параметры prune-backups:

Эта запись говорит: хранить 5 последних, 7 ежедневных, 4 еженедельных и 6 ежемесячных копий. Всё, что выходит за рамки, удаляется при следующем запуске prune. Доступные ключи - keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly и отдельно стоящий keep-all, который отменяет все остальные и оставляет вообще всё.

Запуск vzdump выглядит так:

Отдельно включать удаление старых копий не нужно: параметр --remove в vzdump по умолчанию равен 1, то есть после успешного бэкапа prune запускается сам. Ключ пригодится в обратной ситуации - --remove 0 временно отключает чистку, если вы гоняете внеплановый бэкап и не хотите, чтобы он вытолкнул из ротации старые копии.

Тут кроется распространённая ловушка. --remove включён, prune отрабатывает, в логе пишется строка про retention - а копии не удаляются. Причина в том, что удалять нечего: политика хранилища так и осталась заводской keep-all=1. Сначала задайте retention, потом ждите эффекта от prune. Какие вообще бывают схемы ротации и чем ежедневные копии отличаются от еженедельных, разобрано в статье про виды резервного копирования.

Тем, для кого командная строка Proxmox пока незнакомая территория, стоит начать с базовых операций - управление виртуальными машинами Proxmox через CLI даёт минимальный набор команд, с которым дальше проще.

Prune в Proxmox Backup Server: не всё так просто

Если вы используете настроенный Proxmox Backup Server как целевое хранилище, логика очистки места меняется. PBS работает с дедупликацией и инкрементальными бэкапами, поэтому удаление снапшота не означает мгновенное освобождение дискового пространства.

Устроено это так. Команда prune в PBS удаляет только метаданные снапшота - ссылку на набор чанков. Сами чанки данных продолжают лежать на диске, потому что на них могут ссылаться другие снапшоты. Реальное освобождение места происходит во время garbage collection (GC) - отдельной процедуры, которая проходит в два этапа:

Запускать prune и GC можно из веб-интерфейса, а можно командами. Здесь важно не перепутать, кто что делает:

GC запускается автоматически по расписанию, которое задаётся на хранилище (Datastore → Options → GC Schedule либо proxmox-backup-manager datastore update store1 --gc-schedule daily). Хранилище уже горит - ждать расписания смысла нет, запускайте вручную.

Место не освободилось после prune - что происходит

Самый частый сценарий: снапшоты удалены, GC прогнан, а свободного места прибавилось на считаные мегабайты. Ошибки здесь нет. PBS не удаляет чанки, к которым обращались за последние 24 часа и 5 минут до старта сборки мусора. В отчёте GC они попадают в отдельную строку - Pending removals.

Причина в том, как файловые системы Linux ведут учёт обращений. Обычно они монтируются с опцией relatime: время доступа к файлу обновляется не при каждом чтении, а примерно раз в сутки. Если бы GC удалял чанк сразу после того, как перестал видеть ссылки на него, он рисковал бы снести кусок, который прямо сейчас пишет идущий бэкап - просто потому, что atime у этого куска обновился больше суток назад. Сутки с небольшим запасом - страховка от такой гонки.

Отсюда практический вывод: между prune и реальным возвратом места проходит больше суток. Порядок действий, если ждать некогда:

1. Удалите ненужные снапшоты (prune или вручную через Datastore → Content).
2. Запустите GC. Он честно сработает, но большая часть чанков уйдёт в Pending removals.
3. Загляните в лог задачи. Строка Pending removals покажет, сколько места «зависло» в ожидании.
4. Через сутки с небольшим запустите GC повторно - вот тогда место и вернётся.

Граница может оказаться и дальше суток. Когда в момент старта GC идёт бэкап-задание, отсчёт ведётся от начала самого старого пишущего клиента, а не от текущего момента. Поэтому чистку разумно ставить в окно, когда бэкапы не идут.

Хранилище PBS заполнено на 100%: как выбраться

Отдельная неприятность, о которой стоит знать заранее: сборке мусора нужно немного свободного места, чтобы освободить место. GC пишет служебные данные, и на полностью забитом datastore задача падает с No space left on device. Получается замкнутый круг: почистить нельзя, потому что нет места, а места нет, потому что не почищено.

Выбираются из него по шагам, от простого к радикальному:

1. Остановите задания бэкапа. Иначе всё, что вы отвоюете, тут же уйдёт под новую копию. В PVE - отключить задачи в Datacenter → Backup, на PBS - перевести datastore в режим обслуживания (Datastore → Options → Maintenance Mode).
2. Освободите место вне datastore. Кэш пакетов (apt clean), разросшийся журнал (journalctl --vacuum-size=200M), старые логи в /var/log. Когда система PBS живёт на отдельном разделе от хранилища, этот шаг не поможет - смотрите пункт 4.
3. Удалите заведомо ненужные снапшоты - через Datastore → Content или prune. Сами по себе они освободят немного: индексные файлы весят мало. Но без этого шага следующему GC нечего будет собирать, сколько его ни запускай.
4. Последнее средство - временно вынести часть чанков. Каталог .chunks внутри datastore разложен по подкаталогам с шестнадцатеричными именами. Несколько из них переносят на другой носитель, запускают GC (он пожалуется на недостающие чанки - это ожидаемо), возвращают каталоги на место и запускают GC ещё раз.

Профилактика надёжнее любой из этих мер. У datastore есть свойство notification-thresholds - выставьте порог и настройте уведомления так, чтобы узнавать о заполнении на 80%, а не на 100%. Когда хранилище упирается в потолок регулярно, это уже вопрос не чистки, а ёмкости: серверы для резервного копирования и архивного хранения считают под глубину хранения, а не под текущий объём данных.

Серверный prune vs клиентский: где безопаснее

В архитектуре PBS есть два места, откуда можно запускать prune, - с клиента (ноды PVE) и с самого PBS-сервера. Разница между ними глубже, чем удобство.

Prune-опции, настроенные на стороне PBS, учитывают серверные права доступа. Клиент с ограниченным токеном не сможет случайно снести чужие бэкапы или обойти политику хранения. Серверный prune - это единая политика, которую администратор PBS контролирует централизованно.

Клиентский prune (через vzdump или PVE GUI) удобен для маленьких инсталляций, где один человек управляет и виртуализацией, и бэкапами. Но в среде с несколькими администраторами или тенантами серверные prune-опции безопаснее, потому что предотвращают случайное удаление.

У документации Proxmox на этот счёт своё мнение: она рекомендует держать prune на стороне клиента - тот, кто делает бэкапы, лучше знает, какие из них ещё нужны. Практика проще: в инсталляции на одного админа берите клиентский, при нескольких администраторах или внешних заказчиках - серверный.

Prune не запускается: блокировки и lockwait

Отдельная категория обращений - когда чистка вообще не отрабатывает, а в логе висит ошибка про блокировку:

На каждой ноде vzdump берёт глобальную блокировку и может выполняться только в одном экземпляре. Второе задание встаёт в очередь и ждёт освобождения - по умолчанию 180 минут. Если за это время первое не закончилось, второе отваливается с таймаутом, и вместе с ним не отрабатывает prune.

Разбирается это по шагам:

• Проверьте, не идёт ли бэкап прямо сейчас. Задачи видны в веб-интерфейсе, в командной строке - ps aux | grep vzdump. Чаще всего оказывается, что ночное задание просто не уложилось в окно и пересеклось со следующим.
• Разведите расписания или соберите пересекающиеся задачи в одну. Два задания, стартующие с разницей в час на одной ноде, гарантированно будут спотыкаться друг о друга по мере роста данных.
• Увеличьте ожидание, если развести не получается: ключ --lockwait <минуты> при разовом запуске либо параметр lockwait в /etc/vzdump.conf для всех заданий.
• Снимите залипшую блокировку. Ни одного vzdump в процессах нет, а файлы /var/run/vzdump.lock и /var/run/vzdump.pid остались - типичный след аварийной перезагрузки. Их можно удалить и запустить бэкап заново. Убедитесь, что процесса действительно нет, - удалять блокировку у живой задачи не нужно.
• Отдельная история - блокировка конкретной машины, а не всей ноды. Она живёт в конфиге гостя и снимается через qm unlock для VM или pct unlock для контейнера.

Удалили ВМ или диск, а место не вернулось

Ситуация из того же семейства, но причина другая: виртуальная машина уничтожена или внутри гостя стёрли сотню гигабайт, а сводка по хранилищу показывает прежние цифры.

Так ведут себя тонкие тома - LVM-thin, ZFS, Ceph RBD, qcow2. Они выделяют место по мере записи и не забирают его обратно сами. Чтобы место вернулось, гостевая система должна сообщить о высвобожденных блоках, а гипервизор - передать это сообщение хранилищу. Ломается цепочка обычно в одном из трёх мест.

Флаг discard не включён на диске ВМ. Без него Proxmox молча отбрасывает команды TRIM/UNMAP от гостя. Включается в Hardware → Hard Disk → Discard; предсказуемее всего работает на дисках SCSI при контроллере VirtIO SCSI. Изменение подхватывается после выключения и включения машины, перезагрузки изнутри гостя мало.

Гость не отдаёт TRIM. В Linux за это отвечает таймер fstrim.timer (проверить - systemctl status fstrim.timer) либо разовый fstrim -av. В Windows команды отправляет штатная оптимизация дисков, если гость видит диск как SSD.

Блоки освобождены не полностью. LVM-thin оперирует экстентами, по умолчанию размером 2 МБ, а файловая система гостя пишет блоками по 4 КБ. Пока в двухмегабайтном экстенте остаётся хоть один живой блок, целиком он не вернётся. Поэтому после удаления большого файла место возвращается почти всё, а после чистки миллиона мелких - заметно меньше, чем ожидалось. То же справедливо для qcow2, где размер кластера по умолчанию 64 КБ, а «дырку» в файле умеет пробивать не всякая нижележащая файловая система.

Отдельно стоит проверить снимки. Снапшот удерживает старое состояние блоков, и пока он существует, удалённые данные никуда не денутся. Так этот механизм и задуман. Подробнее о том, чем ещё оборачиваются забытые снимки, - в статье про снимки виртуальных машин и их подводные камни.

У ZFS свой набор особенностей: место удерживают снапшоты и резервирование под том, а zfs list -o space показывает, сколько чем занято. Если вы только выбираете файловую систему под ноду, разбор поведения ZFS с плюсами и минусами поможет понять, чего от неё ждать под виртуализацией.

Что ещё съедает диск на ноде: ядра, /boot, журнал, ISO

Бывает и так, что бэкапы ни при чём. Хранилище с копиями в порядке, а кончается системный раздел ноды или маленький /boot. Разбираться стоит по четырём направлениям.

Старые ядра. Proxmox не удаляет их сам - это осознанное решение разработчиков: если новое ядро не заводится, нужно чем-то загрузиться. Расплата в том, что за год-другой обновлений их набирается с десяток. Посмотреть, что установлено и что выбрано на загрузку:

Удаляются они обычным пакетным менеджером - apt autoremove --purge или адресно apt purge proxmox-kernel-6.8.12-4-pve с подстановкой своей версии. Автоудаление сносит не всё: несколько свежих и самое старое ядро система оставляет как запасной вариант. Не удаляйте ядро, с которым сейчас загружены (uname -r покажет, какое это), и после чистки прогоните proxmox-boot-tool refresh.

Отдельная боль - установки с корнем на ZFS. Там загрузчик работает через proxmox-boot-tool, а образы копируются на служебные EFI-разделы фиксированного размера, по умолчанию 512 МБ. Раздел заполняется быстрее, чем корневая файловая система, и первым признаком становится ошибка при обновлении, а не предупреждение мониторинга.

Системный журнал. По умолчанию systemd отдаёт журналу до 10% раздела, но не больше 4 ГБ. На небольшом системном диске это ощутимо. Посмотреть и подрезать:

Постоянное ограничение задаётся параметром SystemMaxUse в /etc/systemd/journald.conf - разово почистить полезно, но без ограничения журнал вырастет снова.

Кэш пакетов. apt clean удаляет скачанные .deb из /var/cache/apt/archives. На ноде, которую давно обновляют, там нередко лежит несколько гигабайт, никому больше не нужных.

Забытые образы и шаблоны. ISO-файлы и шаблоны контейнеров лежат в /var/lib/vz/template/ и видны в веб-интерфейсе через Storage → Content. Удаляются оттуда же. Образ, который не удаляется из интерфейса, чаще всего числится подключённым к выключенной машине: отцепите его в Hardware → CD/DVD Drive и повторите.

Ещё один слой - раскладка самих хранилищ. Когда системный раздел ноды и хранилище данных живут на одном массиве, любое переполнение одного немедленно роняет другое. Как правильно развести это на уровне дисков, разобрано в материале про RAID в Proxmox и настройку отказоустойчивого хранилища.

Практический чеклист очистки

Готовый порядок действий, если хранилище заполняется и нужно навести порядок:

1. Определите, что именно кончилось. df -h на ноде и сводка по хранилищу в интерфейсе показывают разное. Системный раздел, /boot, хранилище с бэкапами и datastore на PBS переполняются по разным причинам и лечатся разными способами.
2. Оцените масштаб. Зайдите в Datacenter → Storage → Content и отсортируйте бэкапы по дате. Определите, какие VM генерируют тяжёлые копии.
3. Настройте retention. Пропишите prune-backups в storage.cfg или задайте через GUI. Для типичной инсталляции разумный старт - keep-last=3,keep-daily=7,keep-weekly=4,keep-monthly=3. Помните про заводское keep-all=1: пока политика не задана, prune не удалит ничего.
4. Запустите prune. Для PVE - через GUI или очередным запуском vzdump. Для PBS - через веб-интерфейс datastore, proxmox-backup-client prune с клиента или proxmox-backup-manager prune-job run на сервере.
5. Запустите GC (только PBS). После prune запустите сборку мусора. Строка Pending removals в логе покажет, сколько места вернётся только следующим прогоном.
6. Проверьте результат. Убедитесь, что свободное место появилось. На тонких томах и LUN-ах может потребоваться ещё и fstrim внутри гостя, а на диске ВМ - включённый флаг discard.
7. Настройте мониторинг. Zabbix, Prometheus, хоть df -h в cron - любой способ, который разбудит вас до того, как диск заполнится. Порог ставьте на 80%, а не на 95%: на PBS с последних процентов выбираться заметно сложнее.

Короткие ответы на частые вопросы

Почему после удаления бэкапов в PBS место не освободилось?
Prune убирает только ссылку на снапшот, данные лежат в общих чанках. Место возвращает garbage collection, и не раньше чем через 24 часа 5 минут после последнего обращения к чанку. До этого срока он числится в отчёте GC как Pending removal.

Можно ли заставить PBS освободить место немедленно?
Полностью - нет, окно в сутки обойти штатными средствами нельзя. Ускорить можно только тем, что запустить GC сразу после prune, а затем повторить его на следующий день.

Как удалить datastore в Proxmox Backup Server?
Через Datastore → Options → Remove Datastore либо proxmox-backup-manager datastore remove <имя>. Удаляется только запись в конфигурации: данные на диске остаются, пока вы не добавите ключ --destroy-data (по умолчанию он выключен). Если место нужно вернуть, каталог придётся стереть отдельно или удалять хранилище сразу с этим ключом.

Что такое namespace в PBS и зачем он нужен?
Пространство имён - логический раздел внутри datastore. В нём держат бэкапы разных площадок или заказчиков: хранилище одно, а права и политики хранения у каждого свои. Задаётся при подключении хранилища в PVE и ключом --ns в командах клиента.

Почему prune не трогает некоторые копии?
Скорее всего, они помечены флагом protected. Защищённые бэкапы исключаются из ротации целиком. Их количество на гостя ограничено параметром хранилища max-protected-backups: без права Datastore.Allocate по умолчанию разрешено пять.

Как хранить всё и ничего не удалять?
Значение keep-all=1 в политике хранения. Оно несовместимо с остальными ключами keep-* и отменяет их. Именно оно стоит по умолчанию, поэтому «ничего не удаляется» - штатное поведение свежей установки, а не сбой.

Что запомнить

Удаление бэкапов Proxmox - задача регулярная, а не разовая. Политику хранения задают в первый день, а не после первого инцидента: заводское keep-all=1 означает, что без вашего участия не удалится ничего.

Prune без GC на PBS - полумера: место не освободится, пока не пройдёт сборка мусора, и она обойдёт стороной чанки моложе суток. Планируйте чистку с запасом по времени, а не в ночь перед переполнением.

Если место не вернулось после удаления диска или машины, ищите не в бэкапах, а в цепочке discard: флаг на диске ВМ, TRIM внутри гостя, размер экстента хранилища. И проверьте, не кончился ли системный раздел ноды - старые ядра, журнал и забытые ISO съедают его молча.