Эксперты в подборе IT-оборудования
Дисковое пространство на сервере виртуализации — ресурс, который заканчивается в пятницу вечером. Именно тогда, когда Вы собрались уходить домой. Proxmox VE честно делает бэкапы по расписанию, складывает их на хранилище — и ни разу не спросит, хватит ли места для следующего. Когда хранилище заполнится на 100%, Вы узнаете об этом не из мониторинга, а из панических сообщений коллег: «Виртуалки не стартуют». Удаление бэкапов Proxmox — рутинная гигиена, о которой вспоминают, когда уже поздно. Давайте разберёмся, как не доводить до этого.
Допустим, у Вас 20 виртуальных машин. Средний размер бэкапа одной VM — 50 ГБ (а для баз данных легко уходит за 200 ГБ). Расписание — раз в сутки, хранить 14 копий. Считаем: 20 × 50 ГБ × 14 = 14 ТБ. Это — идеальный сценарий со стабильными данными. Стоит разработчикам залить пару дампов или нагенерировать логов, и размер каждого последующего бэкапа подрастает.
| Параметр | Маленькая среда (5 VM) | Средняя среда (20 VM) | Крупная среда (100 VM) |
|---|---|---|---|
| Средний размер бэкапа | 30 ГБ | 50 ГБ | 80 ГБ |
| Копий на хранении | 7 | 14 | 30 |
| Объём хранилища | 1,05 ТБ | 14 ТБ | 240 ТБ |
Цифры грубые, но картину рисуют. Неправильное управление бэкапами — одна из частых причин переполнения дисков в Proxmox-инсталляциях. Дисковые полки, NAS, LUN-ы на СХД — всё это «съедается» равномерно и молча. Если при планировании среды Вы не закладывали запас под резервные копии, стоит заранее изучить, сколько дискового пространства требует виртуализация Proxmox. Мониторинг, конечно, спасает — но только если он настроен. А удаление старых резервных копий спасает всегда.
Proxmox предлагает два пути — графический интерфейс и командную строку. Выбор зависит от того, сколько у Вас нод и насколько Вы любите автоматизацию.
Путь: Datacenter → Backup → (выбрать задачу) → Retention. Здесь задаётся, сколько копий хранить. Можно указать количество по дням, неделям, месяцам. Proxmox VE будет автоматически удалять лишние копии при создании новой. Это ключевой момент — пока новый бэкап не создастся, старые никуда не денутся.
Второй путь — на уровне хранилища: Datacenter → Storage → (выбрать хранилище) → Prune. Здесь управление тоньше: prune-опции привязаны к конкретному storage, а не к расписанию.
Для разовой ручной чистки: Datacenter → Storage → Content — выбираете ненужный бэкап и удаляете. Просто, но не масштабируется.
CLI даёт контроль, которого нет в GUI. Основной инструмент — файл /etc/pve/storage.cfg. Для каждого хранилища можно прописать параметры prune-backups:
Эта запись говорит: хранить 5 последних, 7 ежедневных, 4 еженедельных и 6 ежемесячных копий. Всё, что выходит за рамки — удаляется при следующем запуске prune.
Запуск vzdump с параметром remove=1 удаляет старые бэкапы сразу после успешного создания нового:
Автоматическое удаление копий через remove=1 и prune-backups — связка, которая работает «из коробки» без cron-костылей.
Если Вы используете настроенный Proxmox Backup Server как целевое хранилище — логика очистки места на сервере меняется. PBS работает с дедупликацией и инкрементальными бэкапами, а значит, удаление «снимка» не означает мгновенное освобождение дискового пространства.
Вот как это устроено: команда prune в PBS удаляет только метаданные снапшота — ссылку на набор чанков. Сами чанки данных продолжают лежать на диске, потому что на них могут ссылаться другие снапшоты. Реальное освобождение места происходит во время garbage collection (GC) — отдельной процедуры, которая проходит в два этапа:
| Этап | Что происходит | Примерное время |
|---|---|---|
| Mark | PBS обходит все существующие снапшоты и помечает «живые» чанки | Зависит от количества снапшотов |
| Sweep | Непомеченные чанки удаляются с диска | Зависит от объёма «мусора» |
GC запускается автоматически по расписанию (по умолчанию — раз в сутки), но можно запустить вручную:
Между prune и реальным освобождением места может пройти до 24 часов. Если хранилище уже «горит» — запускайте GC руками после prune.
В архитектуре PBS есть два места, откуда можно запускать prune backups Proxmox — с клиента (ноды PVE) и с самого PBS-сервера. Разница — не только в удобстве.
Prune-опции, настроенные на стороне PBS, учитывают серверные права доступа. Клиент с ограниченным токеном не сможет случайно снести чужие бэкапы или обойти retention policy. Серверный prune — это единая политика хранения, которую администратор PBS контролирует централизованно.
Клиентский prune (через vzdump или PVE GUI) удобен для маленьких инсталляций, где один человек управляет и виртуализацией, и бэкапами. Но в среде с несколькими администраторами или тенантами — серверные prune-опции безопаснее, потому что они предотвращают случайное удаление.
| Характеристика | Клиентский prune (PVE) | Серверный prune (PBS) |
|---|---|---|
| Контроль доступа | Зависит от прав пользователя PVE | Управляется правами PBS |
| Область действия | Конкретная задача бэкапа | Весь datastore или namespace |
| Риск случайного удаления | Выше | Ниже |
| Централизация | Нет | Да |
Готовый порядок действий, если хранилище заполняется и нужно навести порядок:
Удаление бэкапов Proxmox — задача не разовая, а регулярная. Retention policy должна быть настроена с первого дня, а не после первого инцидента. Prune без GC на PBS — полумера: место не освободится, пока не пройдёт garbage collection. И если Вы управляете средой с несколькими администраторами — переносите prune-логику на сторону PBS.
