Бэкап Zimbra не открывается: ищу уцелевшие письма

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

Сначала выясняю, что назвали бэкапом Zimbra

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

В Network Edition предусмотрен штатный менеджер резервного копирования. Его набор данных нельзя подменить экспортом одного ящика или результатом работы стороннего скрипта с похожим названием. Я записываю редакцию Zimbra, установленную сборку, название модуля и версию сценария копирования. Для встроенного бэкапа нужны его собственные процедуры и наборы данных; команды для обычного tar к такому хранилищу без проверки формата неприменимы. Если рядом лежат несколько файлов одной задачи, сначала выясняю их связь. Самый большой файл не обязательно содержит всё необходимое.

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

По логам отделяю ошибку чтения от ошибки импорта

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

Путь /opt/zimbra/log/zimbra_backup.log нельзя выдавать за общий журнал резервного копирования Zimbra. В базе он взят из проекта fogmorn/Zimbra-backup; авторы именно этих скриптов направляют туда вывод и ошибки. Если скрипт другой, я смотрю его настройки и журнал запуска. Для классического восстановления Network Edition документация указывает /opt/zimbra/log/mailbox.log, но набор журналов зависит от используемого механизма. Поэтому я ищу не знакомое имя файла, а запись нужной операции в нужное время. Пустой чужой лог — довольно убедительное объяснение отсутствия любых объяснений.

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

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

Проверяю контрольную сумму, gzip и tar по отдельности

Дальше речь только об обычном экспорте TGZ: внутри tar, снаружи gzip. В примерах mailbox.tgz — дубликат исследуемого файла в отдельной рабочей папке. Для сравнения с эталоном нужен mailbox.tgz.sha256, созданный на стороне источника до передачи, с записью для этого имени файла. В этой папке я запускаю:

sha256sum -c mailbox.tgz.sha256

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

Сжатый поток проверяю отдельно:

gzip -t mailbox.tgz

Успешная проверка говорит о целостности gzip, а не о наличии всех писем. После неё прошу GNU tar перечислить записи:

tar -tzf mailbox.tgz

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

Результаты я трактую раздельно: | Что обнаружено | Что это означает | Что проверяю дальше | |---|---|---| | Сумма отличается от исходной | Файлы не совпадают | Сохранился ли исходник для повторной передачи | | gzip сообщает об ошибке | Поток не прошёл проверку сжатия | Другую копию и возможность извлечь фрагмент | | gzip исправен, tar выдаёт ошибку | Упаковка gzip читается, структура tar вызывает проблему | Формат и записи архива | | Обе проверки успешны, импорт отказал | Ошибка импорта остаётся отдельной задачей | Совместимость, права, место и журнал приложения | Таблица задаёт следующий шаг, а не процент спасения. Назначать виновной сеть только по несовпавшей сумме я тоже не стану.

Затем сверяю содержимое с заданием экспорта: какие ящики и папки должны присутствовать, какие периоды писем ожидались и что исключалось настройками. Технически исправный архив может содержать только выбранную папку или результат не того запроса. Если отправитель ещё доступен, повторный корректный экспорт обычно полезнее ковыряния в обрывке. Я прошу владельца почты назвать важные переписки и вложения, чтобы потом проверить именно их. Архиватор подтверждает свойства упаковки; нужный договор он от ненужного письма не отличает. У него довольно узкая должностная инструкция.

Что можно извлечь из обрезанного TGZ

Если другой исправной копии нет, я оцениваю частичное извлечение. У обрезанного в конце gzip иногда удаётся получить начало распакованного потока. При повреждении внутри потока результат может оказаться хуже; доступ к записям после места повреждения не гарантирован. Это извлечение сохранившихся данных, а не ремонт исходного архива. В пустой рабочей папке, где ещё нет файла mailbox.partial.tar, выполняю:

gzip -dc mailbox.tgz > mailbox.partial.tar

Ключ -d распаковывает, -c пишет результат в стандартный вывод и сохраняет исходный файл. Перенаправление создаёт отдельный выходной файл; повторный запуск с тем же именем перезапишет его.

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

tar -tf mailbox.partial.tar

Эта команда лишь перечисляет доступные записи. Если она тоже остановится с ошибкой, список останется частичным. В него могут попасть имена файлов, содержимое которых уже обрезано. Восстановленные элементы приходится извлекать в отдельный каталог и проверять по одному: наличие имени в оглавлении сохранности письма не доказывает.

Извлечение я выполняю без прав root в изолированной рабочей среде после просмотра имён и типов записей. Для отдельной обычной записи можно вывести содержимое в новый файл, не восстанавливая дерево каталогов:

tar -xOf mailbox.partial.tar 'Inbox/123.eml' > message.eml

Здесь Inbox/123.eml нужно заменить точным именем из списка tar; message.eml до запуска не должен существовать. Ключ -x извлекает, -O направляет содержимое записи в стандартный вывод. Ошибка чтения означает, что полученный файл нельзя считать полным. Я сохраняю журнал и связь письма с исходной копией. У GNU tar есть --ignore-zeros, но он лишь пропускает нулевые блоки, обычно обозначающие конец архива. Отсутствующие данные и повреждённое сжатие ключ не исправляет.

Полностью извлечённое письмо я проверяю вместе с вложениями. Обрыв внутри MIME-содержимого может оставить читаемую тему и текст, но испортить прикреплённый документ. Я не выдаю такой файл за восстановленную переписку без оговорки. Контакты, события календаря, права общего доступа и настройки требуют отдельной проверки; набор EML-файлов их не заменяет. Результат частичного спасения — перечень пригодных элементов и известные пробелы. Если сохранились только фрагменты, так и записываю. Обещание восстановить недостающий хвост сменой расширения — уже не технический метод.

Учебный разбор ООО «Хрусталь»: импорт без подмены понятий

Для условного ООО «Хрусталь» я задам учебную ситуацию: есть экспорт одного ящика, оборванный в конце, и отдельная тестовая Zimbra. Это не подтверждённая авария и не статистика успеха. Сборку и ОС в реальной работе берут из инвентаризации, а не придумывают для убедительности текста. Сценарий такой: я сохраняю оригинал, получаю доступный фрагмент tar и отбираю полностью извлечённые письма. Допустим, в контрольной выборке шесть файлов, один из которых обрезан. Тогда в тестовый импорт допускаю пять кандидатов, а шестой отмечаю как повреждённый. Принятие кандидата сервером ещё предстоит проверить.

Для одного пригодного EML использую addMessage. На тестовом сервере заранее создаю ящик restore-test@example.com; папка /Inbox в нём существует. Под системным пользователем zimbra, который может прочитать выбранный файл, запускаю:

zmmailbox -z -m restore-test@example.com addMessage /Inbox /recovery/message.eml

Здесь /recovery/message.eml — условный путь к уже извлечённому и проверенному письму. Ключ -m выбирает ящик, -z использует локальные административные данные. Затем я открываю письмо в тестовом интерфейсе, сверяю отправителя, дату, текст и вложения. Импорт EML не обещает восстановить все прежние метаданные, метки и права.

Команда recoverItem решает другую задачу: возвращает элементы из Dumpster работающего ящика. Ей нужны идентификаторы элементов и папка назначения; путь к архиву в её синтаксисе отсутствует. Если нужных данных уже нет в Dumpster, команда не извлечёт их из TGZ. В старых инструкциях также встречается импорт экспорта через postRestURL и параметр resolve=skip, который пропускает дубликаты; resolve=reset очищает целевую папку перед импортом. Это полезное различие, но не повод копировать старый пример на рабочий ящик. В документации Zimbra отдельно опубликовано предупреждение о проблемах миграции через REST. Я не делаю этот способ универсальным рецептом спасения.

Если вместо экспорта восстанавливается весь сервер, я выбираю процедуру именно его модуля копирования. Требования к версии и ОС зависят от способа: например, старое руководство Network Edition допускает другую ОС при той же версии ZCS. Это условие конкретной процедуры, а не разрешение смешивать любые сборки. Совет переименовать /opt/zimbra в /opt/zimbra_broken взят из архивной инструкции для старой Open Source Edition; сама страница предупреждает о неприменимости к современным версиям. В этом учебном разборе рабочую установку я не трогаю. Итогом считаю только письма, прошедшие проверку, а обещанные заранее пять успешных импортов в отчёт не записываю.

Как принять результат и убрать причину сбоя

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

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

Затем я исправляю процесс создания копии. Холодное копирование изменяющихся каталогов требует согласованного состояния данных; простое чтение файлов работающей базы этого не обеспечивает. Но останавливать службы перед каждым видом бэкапа тоже неверно: механизмы горячего копирования рассчитаны на работающий сервер. Я проверяю документацию установленного модуля и весь сценарий, включая реакцию на ошибки. Отчёт должен различать завершение экспорта, целостность файла и успешное восстановление. Контрольная сумма, вычисленная уже после аварии, не заменяет ни один из этих этапов.

Расписание тестов я привязываю к допустимой потере почты и времени простоя, а также повторяю проверку после изменения схемы копирования. Универсальный еженедельный интервал не обещает обнаружить неисправность диска. Исправные поколения храню отдельно от исследуемого файла и защищаю от той же очистки, которая обслуживает рабочий сервер. Для каждой проверки записываю фактическое время, набор восстановленных данных и ответственного за реакцию на отказ. Мониторинг должен замечать и отсутствие нового результата. Бэкап, о котором просто давно не было плохих новостей, умеет выглядеть особенно надёжным.

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