В 2026 году хранилище Proxmox Backup Server 4.2 заполнено: сначала очистить или расширить?

Сначала проверьте, выполняются ли prune и garbage collection (GC), затем сопоставьте состояние datastore с фактическим использованием файловой системы; не судите об освобождённом месте по списку снимков и не удаляйте вручную файлы .chunks. Если GC не может работать из-за нехватки места или backend действительно заполнен, сначала подтвердите безопасный путь восстановления для конкретного хранилища — и только после этого освобождайте место либо расширяйте ёмкость.

Этот порядок подходит администраторам самостоятельного экземпляра PBS с растущим datastore, специалистам MSP, отвечающим за резервные копии нескольких клиентов, и небольшим операторам, которые планируют хранилище для нескольких арендаторов. Если причина в политике хранения или неудачной задаче, увеличение диска не исправит её; если же свободного пространства действительно нет, запуск обслуживания без проверки состояния backend может добавить риск.

На этой неделе: зафиксируйте журналы задач, проверьте состояние datastore и файловой системы, затем выберите действие по признакам ниже.

Последнее обновление — 28 октября 2026 года. Дату выпуска PBS 4.2 и сведения о функциях сверяйте с официальным объявлением о выпуске и документацией PBS.

Разделите проблему задачи и нехватку ёмкости

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

• Prune не запускался или завершился ошибкой. Политика хранения может быть задана, но сама задача не обработала ожидаемые снимки. Проверьте расписание, последний запуск и сообщение об ошибке.
• Prune завершился, а GC ещё не запускался или не закончил работу. В таком состоянии нельзя ожидать, что удаление снимков немедленно отразится на свободном месте диска.
• Задачи прошли, но filesystem заполнена. Причина может быть в реальном объёме данных, особенностях backend, других файлах на томе или ограничении пространства вне PBS.
• Задачи не могут выполняться из-за отсутствия рабочего пространства. Это уже ситуация с повышенным риском: сначала выясните предусмотренный для вашего backend путь восстановления, а не пробуйте случайную очистку.

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

Официальное объявление подтверждает, что PBS 4.2 выпущен 29 апреля 2026 года; детали возможностей и изменений сверяйте с описанием самого выпуска, а не выводите из сообщения об ошибке или обсуждения на форуме.

Проверьте prune и GC по отдельности

Prune и GC выполняют разные задачи. Prune применяет правила хранения снимков: по заданной политике он определяет, какие точки восстановления следует оставить, а какие — удалить. GC обслуживает данные datastore и выясняет, какие блоки после этого больше не нужны сохранённым снимкам. Поэтому ответ на вопрос «почему после удаления резервных копий место не освободилось» нельзя получить только из списка снимков.

Откройте в PBS историю задач и проверьте:

• применялась ли к нужному datastore ожидаемая политика prune;
• завершилась ли задача успешно, а не только была создана или запущена;
• запускался ли GC после изменений, завершился ли он и какое сообщение оставил;
• совпадают ли выбранный datastore, расписание и ожидаемая политика хранения;
• не повторяется ли ошибка, связанная с доступом, состоянием backend или свободным местом.

Не считайте число сохранённых снимков эквивалентом объёма, который можно удалить. Разные снимки могут ссылаться на общие данные, а цифры дедупликации отражают особенности учёта и повторного использования блоков, а не гарантированный объём для немедленного освобождения. Точное назначение обслуживающих операций и ограничения PBS сверяйте с официальным руководством по обслуживанию; синтаксис команд — с официальным справочником команд.

Если вы предпочитаете командную строку, сначала определите datastore и изучите справку по командам именно установленной версии. Не переносите команду из старого сообщения или сценария без проверки параметров: опечатка в имени хранилища либо неверное предположение о backend превращают диагностику в изменение данных. Для повторяемой работы сохраните использованные команды, вывод и время выполнения в журнале инцидента.

Сопоставьте datastore с реальным состоянием хранилища

В PBS и на нижележащем уровне вы видите разные показатели. Панель datastore показывает состояние с точки зрения PBS; файловая система или внешний backend показывает собственные ограничения и фактически занятый ресурс. Расхождение между ними — повод выяснить, какой именно уровень достиг лимита, а не объявлять данные ненужными.

Для обычного файлового хранилища определите, на какой файловой системе расположен путь datastore, и проверьте её свободное место, занятые блоки, точки монтирования и ограничения тома. В официальной документации PBS для файлового хранилища рассматриваются, в частности, ext4, XFS и ZFS; применимый набор проверок зависит от реальной конфигурации. Сверьте свой вариант с документацией PBS по хранилищам, прежде чем применять команды обслуживания или менять размер тома.

При ZFS проверяйте состояние соответствующего пула и dataset, а не только показатель свободного места в интерфейсе PBS. Учитывайте резервирование и ограничения dataset, если они настроены. Для ext4 и XFS проверяйте доступную ёмкость именно того файлового раздела, на котором лежит datastore, а также не закончилось ли место на родительском томе. Не выполняйте очистку каталогов PBS только потому, что команда df показывает заполненный раздел: сначала установите, что именно занимает место и кто им управляет.

Если в вашей схеме используется S3-совместимое хранилище или внешний слой интеграции, отдельно подтвердите, что именно поддерживает ваш вариант PBS 4.2. Проверяйте квоты, занятую ёмкость и ошибки средствами самого backend; локальный отчёт файловой системы не описывает полностью объекты во внешнем хранилище. Не считайте S3 datastore стандартным только потому, что он упоминается в чьём-либо обсуждении.

Учитывайте ответственность каждой роли

Если вы обслуживаете один экземпляр PBS, сначала выясните, изменилось ли поведение после правки расписания, политики хранения, конфигурации тома или backend. Сопоставьте последние успешные запуски prune и GC с моментом, когда стало расти использование диска. Если расписание не исполняется, устраните его причину и проверьте результат; не удаляйте вручную старые данные в надежде освободить место.

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

Если вы планируете хранилище для нескольких арендаторов, проверяйте не только общий свободный объём, но и границу ресурсов: файловую систему, dataset, том, квоту или внешний backend. Общая цифра по всему устройству не доказывает, что место доступно конкретному datastore. Для операционной прозрачности используйте согласованные уведомления о заполнении, журналирование задач и учёт изменений; требования к обращению с данными можно соотнести с описанием правил обработки данных.

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

Выберите действие по наблюдаемому состоянию

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

Дать завершиться обслуживанию. Если prune прошёл, а GC ещё не выполнил работу, проверьте его состояние и возможность штатного запуска. Не запускайте несколько конкурирующих операций и не рассчитывайте на мгновенное возвращение пространства. Если GC завершился с ошибкой, сохраните её текст и установите, связано ли это с нехваткой места, состоянием backend или другой причиной.

Освободить место. Этот вариант допустим, когда вы установили, какие данные занимают том, понимаете, как они используются, и подтвердили, что выбранное действие не удалит нужные резервные копии. До изменения сохраните важные журналы и конфигурацию; определите окно обслуживания и путь восстановления. Освобождение пространства в файловой системе, удаление снимков по retention и обслуживание backend — не взаимозаменяемые операции.

Расширить хранилище. Рассматривайте этот вариант, когда текущая политика хранения нужна бизнесу, prune и GC работают ожидаемым образом, а устойчивый объём данных превышает доступную ёмкость. До расширения подтвердите, что позволяет конкретная схема: тип backend, разметка, файловая система, ограничения тома и порядок последующего увеличения datastore. Дополнительная ёмкость не исправит неверный retention, повторяющуюся ошибку задачи или неучтённые данные на том же разделе.

Для всех вариантов используйте последовательность ниже. Отмечайте пункт только после того, как сохранили результат проверки или изменения:

• [ ] Уточните затронутый datastore и его реальный backend; не объединяйте показатели разных хранилищ.
• [ ] Сохраните журналы, сообщения ошибок и историю prune и GC до внесения изменений.
• [ ] Сверьте настроенную политику хранения с требованиями клиента и фактическим расписанием задач.
• [ ] Проверьте статус datastore и доступное пространство на соответствующем нижележащем уровне.
• [ ] Установите причину: пропущенная задача, ошибка выполнения, политика хранения или исчерпание ёмкости.
• [ ] До опасного изменения подготовьте окно обслуживания, согласование и проверенный путь восстановления.
• [ ] После исправления повторно проверьте результаты prune и GC, datastore и фактическое свободное место.
• [ ] Убедитесь, что последующие резервные копии выполняются по расписанию и предупреждения отражают состояние нужного backend.

Если в результате стало ясно, что требуется именно расширение, пересчитайте потребность по фактической динамике данных и утверждённым срокам хранения. Не экстраполируйте рост по одному месяцу, одной системе или единичному случаю из сообщества. Для MSP и небольшого IDC расчёт должен учитывать отдельные datastore, правила клиентов и запас для обслуживания, а не только текущий общий объём.

Частые вопросы

Почему удаление снимков не сразу освобождает диск

Prune удаляет снимки в соответствии с политикой, но освобождение используемых блоков данных зависит от того, нужны ли они другим сохранённым снимкам и завершилась ли garbage collection. Проверьте оба результата и состояние файловой системы. Значение в интерфейсе datastore или изменение числа снимков само по себе не является подтверждением, что соответствующий объём уже свободен.

В чём различие между prune и GC

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

Как выбрать между очисткой и расширением

Сначала выясните, почему занято место. Если нужная задача не выполнялась или retention задан неверно, исправьте настройку и проверьте результат. Если задачи проходят, политика соответствует требованиям, а ёмкости всё равно не хватает, сравните безопасное расширение с допустимым изменением срока хранения. Перед обоими вариантами оцените риски backend и возможность восстановления данных.

Если диск заполнен и GC не запускается

Не удаляйте .chunks вручную. Зафиксируйте ошибки, определите backend и проверьте доступный для него официальный путь восстановления. Если штатная операция невозможна из-за исчерпания пространства, сначала подтвердите безопасный способ освободить ресурс или увеличить ёмкость и подготовьте условия восстановления. Не применяйте команды из единичного обсуждения без проверки применимости к своей конфигурации.

Если вы планируете отдельную ёмкость для PBS, отталкивайтесь от фактического роста резервных данных, срока хранения, требований к избыточности и наличия внешней копии. Независимый сервер может быть отдельной платформой для самостоятельно администрируемого backup-назначения, но аренда сервера не означает предоставление управляемого PBS или услуги резервного копирования. В каталоге конфигураций OVN Cloud сверяйте доступные варианты по текущему описанию, а условия помесячной оплаты — по действующей странице. Если текущий PBS размещён на общей виртуальной платформе, учитывайте возможные ограничения тома и влияние соседней нагрузки; для собственной PBS-системы на независимой машине отдельно планируйте резервирование данных и копию вне основного хранилища.

Частые вопросы

1. Почему после удаления старых снимков свободного места почти не прибавилось? Удаление снимков по политике prune убирает ссылки на точки восстановления, но не обязательно сразу удаляет все связанные блоки данных. Общие блоки могут использоваться другими снимками, а освобождение неподдерживаемых данных выполняет garbage collection. Поэтому проверьте результат prune, состояние GC и фактическое свободное место на файловой системе; список снимков сам по себе не показывает, сколько блоков можно безопасно удалить.
2. Чем prune отличается от garbage collection в PBS? Prune применяет правила хранения и удаляет снимки, которые больше не должны сохраняться по выбранной политике. Garbage collection затем проверяет, какие блоки данных больше не нужны ни одному сохранённому снимку, и очищает их согласно механизму обслуживания PBS. Это разные задачи: успешный prune не доказывает, что GC завершился, а запуск GC не исправляет неверную политику хранения.
3. Когда для datastore разумнее увеличить ёмкость, а не удалять резервные копии? Расширение стоит рассматривать, когда политика хранения соответствует требованиям, ненужных снимков нет, задачи prune и GC завершаются, но фактический объём данных всё равно превышает доступное место. До изменения проверьте ограничения backend, способ расширения файловой системы, резервную копию конфигурации и путь восстановления. Если причина — неисполненная задача или ошибочная политика, сначала исправьте её, а не маскируйте проблему дополнительным диском.
4. Что делать, если на диске PBS уже нет места и garbage collection не запускается? Не удаляйте вручную файлы из .chunks и не переносите их по совету из отдельного обсуждения. Сохраните журналы и сведения о backend, проверьте доступные штатные способы восстановления именно для вашей файловой системы и выясните, можно ли безопасно освободить место или расширить том. Если свободного места недостаточно для обслуживания, остановитесь перед рискованными изменениями и подготовьте проверенный путь восстановления.