Свободное место есть, а резервная копия Zimbra падает

Если бэкап Zimbra сообщает «No space left on device», сначала выясните, на какой именно файловой системе он не может записать данные. Свободное место в корне ничего не говорит о целевом разделе, inode, квоте и доступности каталога. Покажу безопасный порядок проверки и отдельно объясню, когда уместны инструменты Zextras.

Сначала найдите раздел, на который жалуется бэкап

«No space left on device» — сообщение о неудачной операции записи. Оно само по себе не говорит, что заполнен именно системный диск или что виноват Zimbra. Процесс мог писать в отдельную точку монтирования, сетевое хранилище, временный каталог либо каталог резервной копии. Команда df -h без аргумента показывает файловые системы, но для диагностики важен путь конкретной операции. Я начинаю с журнала задания и выясняю, какой файл или каталог оно пыталось создать в момент сбоя. Иначе мы лечим адрес, который никто не называл.

Проверьте доступное место для каждого реального пути: df -h -- /путь/к/backup и, если известен временный путь, df -h -- /путь/к/temp. Аргумент-путь помогает увидеть файловую систему, где он расположен. Сопоставьте вывод с findmnt -T /путь/к/backup: это покажет, что именно смонтировано под каталогом. Если путь расположен на сетевом ресурсе, отдельно проверьте состояние монтирования и доступность хранилища. Число на / не описывает свободное место на другом томе; это разные файловые системы, даже если каталоги выглядят как одна структура.

Если блоки доступны, проверьте inode командой df -i -- /путь/к/backup. Файловая система может иметь свободные байты, но не иметь свободных записей для новых файлов. Для резервного копирования, которое создаёт множество мелких объектов, это особенно важное различие. Затем проверьте квоту пользователя или группы, если она настроена: quota -s zimbra применима не во всех системах и может требовать прав администратора. При лимите квоты место на томе остаётся, но конкретный пользователь исчерпал свой лимит. Не называйте это «глюком Zimbra»: сначала сравните путь, файловую систему, inode и квоту.

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

• Найдите путь записи в журнале задания
• Проверьте `df -h -- /путь` и `df -i -- /путь`
• Сверьте точку монтирования и квоту

Каталог резервной копии и права пользователя

У Zextras Backup есть конкретный Backup Path. В документации Zextras Suite путь по умолчанию — /opt/zimbra/backup/zextras/, но администратор мог изменить его в настройках. Поэтому /backup/zimbra нельзя объявлять универсальным каталогом Zimbra: он может быть лишь выбранным вручную путём в отдельной конфигурации. Посмотрите фактическую настройку резервного копирования и сопоставьте её с путём из ошибки. Если используется другое средство или другая версия продукта, опирайтесь на его конфигурацию, а не на пример из чужой инструкции.

Для Zextras Backup целевой путь должен быть читаемым и доступным для записи пользователю zimbra; файловая система также должна быть чувствительна к регистру. Начните с безопасного осмотра: ls -ld /фактический/backup/path и namei -l /фактический/backup/path. Так видны владелец, режим доступа и права прохода по родительским каталогам. Одного ls -ld на конечную папку мало: если у пользователя нет права пройти через один из каталогов выше, до записи он не дойдёт. Сверьте владельца с документацией установленного решения и своей схемой хранения.

Не копируйте в рабочую инструкцию безусловный chown zimbra:zimbra /backup/zimbra и тем более рекурсивную смену владельца. Во-первых, такой путь может не использоваться. Во-вторых, каталог может быть общим для другого сервиса или смонтирован с особенностями, где смена владельца ничего не исправит. Сначала подтвердите фактический Backup Path, тип файловой системы, владельца и причину отказа. Если владелец действительно неверен, меняйте только нужный каталог и только на основании принятой конфигурации. «Починить права на всякий случай» — плохая операция для почтового хранилища.

Отказ в доступе обычно отличается от исчерпания места: Linux сообщает разные ошибки для разных причин, а Zextras может записать в журнал свой контекст операции. Поэтому не следует объяснять ENOSPC неправильными правами как типичную подмену одного другим. Проверьте журналы Zimbra и Zextras рядом со временем сбоя, затем отдельно подтвердите право записи тестом, согласованным с администратором хранилища. Не создавайте тестовый файл в каталоге, если там запрещены ручные записи или действуют требования к целостности бэкапа.

• Уточните настроенный Backup Path
• Проверьте владельца и проход по родительским каталогам
• Сверьте требования к файловой системе

Не путайте BLOB-проверку с проверкой индексов

В исходных инструкциях часто предлагают запускать zmblobchk как «проверку индексов». Это неверное описание: утилита относится к согласованности хранилища BLOB — файлов с содержимым писем и вложений. Она не является универсальным средством проверки индекса почтового ящика и сама по себе не объясняет нехватку места. Если в журнале есть ошибки отсутствующих или несогласованных BLOB, это отдельная проблема целостности данных. Для неё нужны инструменты, подходящие установленной версии и конфигурации Zimbra.

В системах с Zextras Powerstore документация указывает zxsuite powerstore doCheckBlobs для проверки согласованности BLOB; старый zmblobchk там заменён командой модуля Powerstore. Проверка может охватывать соответствие записей базы файлам, содержимое и размер BLOB. Режимы исправления, включая удаление элементов без найденного BLOB, меняют данные. Не запускайте missing_blob_delete_item true только потому, что упал бэкап: сначала сохраните диагностику, изучите результат проверки и оцените возможность восстановления затронутых элементов.

У Zimbra и Zextras состав команд зависит от версии и подключённых модулей. Сверьте справку именно установленной утилиты и документацию к этой версии. Для анализа начните с чтения журналов и статуса операции; не подставляйте случайный mailbox ID, например 6919, из чужого примера. Также нельзя смешивать этапы start, status и stop в одну строку команды: в штатной CLI это отдельные действия управления операцией, а аргументы и формат зависят от инструмента. Команда с потенциальным удалением — не диагностический запрос.

Индекс почтового ящика и BLOB-хранилище связаны с разными частями данных. Если поиск не находит письмо или есть ошибки индекса, разбирайте индекс отдельно по официальному руководству Zimbra и журналам mailbox-сервера. Если нарушена целостность BLOB, используйте соответствующую проверку хранилища. Не объявляйте любую проблему бэкапа следствием «битых индексов»: в этой статье нет основания считать индексы причиной ENOSPC. Уберите эту гипотезу из автоматического чек-листа, пока журнал не покажет конкретный симптом.

• Сначала установите, ошибка относится к BLOB или индексу
• Для Powerstore сверяйте `doCheckBlobs` с документацией версии
• Не включайте удаление элементов без оценки последствий

Что проверить в Zextras Backup и временных каталогах

Zextras Backup хранит данные в настроенном Backup Path; по документации значение по умолчанию — /opt/zimbra/backup/zextras/. В схеме есть метаданные и BLOB, поэтому важны доступность и производительность выбранного хранилища. В документации Zextras отдельно отмечено, что путь должен быть доступен для чтения и записи пользователю zimbra, а файловая система должна учитывать регистр. Для некоторых конфигураций предусмотрено внешнее хранилище: метаданные и кэш остаются локальными, а BLOB размещаются отдельно. Тогда надо проверять и локальный путь, и внешний том, а не только каталог, который первым попался в df.

Не предполагайте, что резервное копирование обязательно создаёт временные файлы в /tmp, и не ищите наугад несуществующую настройку temp path. Проверяйте временный каталог только если журнал или конфигурация указывают на него, либо если целевая операция действительно пишет туда. Не запускайте автоматическую очистку /tmp: там могут находиться файлы активных процессов и данные других служб. Особенно опасны команды вида rm -rf /tmp/*: они не диагностируют причину, не проверяют владельца и способны повредить работающие задачи. Если временный раздел переполнен, выясните конкретные файлы и их владельцев, затем действуйте по правилам эксплуатации сервера.

Для проверки работы Zextras Backup полезны его собственные статус и журнал. Команда zxsuite backup getBackupInfo документирована как способ получить сведения о резервном копировании; при обращении в поддержку Zextras также просит вывод этой команды, конфигурацию и журналы mailbox-сервера. Сначала сохраните эти сведения и определите, какая операция завершилась ошибкой. SmartScan и Coherency Check решают задачи обновления и проверки Backup Path, а не освобождают место на томе. Запускайте их с учётом нагрузки и описания параметров в документации: глубокая проверка большого набора данных может затронуть ресурсы сервера.

Проверьте состояние подключённого носителя отдельно. Если точка монтирования не поднялась, каталог назначения может оказаться обычной папкой на системном диске; тогда бэкап начнёт писать не туда, куда рассчитывает администратор. Сверьте findmnt -T, конфигурацию монтирования и доступность каталога от имени пользователя процесса. Для NFS, внешнего тома или другого сетевого хранилища добавьте проверку сервера хранения и его свободного объёма. Переключение на /var/tmp без подтверждённой настройки приложения не решает проблему: это лишь другой путь, который тоже может иметь ограничения.

• Сверьте настройки Backup Path и внешних томов
• Проверьте `/tmp`, только если он участвует в записи
• Сохраните `getBackupInfo` и журналы до изменений

Порядок диагностики без риска для почты

Я действую по цепочке от наблюдения к исправлению. Сначала фиксирую полное сообщение, время сбоя и название операции. Затем нахожу соответствующую запись в журнале Zimbra или Zextras и определяю конкретный путь. После этого сверяю точку монтирования, свободные блоки, inode, квоту и доступ пользователя zimbra. Если путь внешний, проверяю хранилище и соединение с ним. Этот порядок не обещает, что каждая ошибка окажется простой; он хотя бы не заставляет удалять данные до понимания причины.

Когда подтверждено заполнение блоков, выясните, что занимает место на конкретной файловой системе, и согласуйте очистку или расширение тома. Не удаляйте файлы резервных копий вручную: для Zextras есть политика хранения и операция Purge, которые учитывают жизненный цикл данных. Изменение срока хранения влияет на возможность восстановления, поэтому сначала убедитесь, что остаются нужные точки восстановления и копия доступна. Если исчерпаны inode или квота, расширение только ёмкости тома может не помочь; исправлять нужно именно обнаруженный лимит.

Когда причина в правах, исправляйте владельца и режим доступа только на подтверждённом каталоге. Когда причина в BLOB, выбирайте версионно подходящую проверку и не включайте удаляющие параметры автоматически. Когда хранилище недоступно или стало read-only, остановите разрушительные эксперименты и разберитесь с файловой системой. zmcontrol restart не является обязательным шагом после проверки места, а перезапуск всех служб способен прервать почту и не устранит заполненный том. Перезапускайте компонент только если документация или конкретный симптом этого требуют.

После исправления повторите резервное копирование и проверьте журнал завершения. Затем проверьте не только факт успешного задания, но и возможность восстановления согласно процедуре вашей организации. У Zextras есть отдельные стратегии восстановления и проверки согласованности Backup Path; план проверки должен соответствовать используемому решению. Хорошая копия — та, из которой можно вернуть данные, а не только зелёная строка в расписании. Запишите фактический путь, ограничения квоты, ответственного за хранилище и точную команду проверки для этой версии. Следующему дежурному не придётся гадать, какой каталог вы имели в виду.

• Зафиксируйте текст ошибки и время
• Проверьте именно путь из журнала
• Исправляйте подтверждённую причину
• Повторите задание и проверьте восстановление

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