Если Mailcow не стартует: сначала спасаем данные

Если Mailcow не запускается, сначала выясните, действительно ли остановилась MariaDB, и сохраните исходные данные. При наличии проверенной копии восстановите сервис штатным скриптом Mailcow; без копии не запускайте наугад ремонт InnoDB и не удаляйте файлы базы. Ниже — порядок диагностики и проверки почты.

Сначала выясните, упала ли именно база Mailcow

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

Из каталога Mailcow выполните команды тем способом, которым управляется установленный Compose-проект. Для плагина Docker Compose это docker compose; в старой установке может использоваться самостоятельная команда docker-compose. Не смешивайте оба варианта в одном сценарии: сначала убедитесь, что обращаетесь к нужному проекту и его контейнерам. docker compose ps docker compose logs --tail=200 mysql-mailcow df -h free -h Имя mysql-mailcow штатное для сервиса базы в Mailcow. Ошибка запуска сама по себе ещё не доказывает поломку InnoDB: в журнале могут быть нехватка места, ошибка монтирования тома, нехватка памяти или проблема конфигурации.

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

В текущей документации Mailcow минимальная конфигурация — 6 GiB оперативной памяти и 1 GiB swap; это именно нижняя планка для стандартного набора сервисов. Для пяти-десяти пользователей Mailcow рекомендует 8 GiB, а антивирус, полнотекстовый поиск и активные подключения могут потребовать больше. Поэтому цифра 7 ГБ из старого текста была ошибочной. Но нехватка памяти и повреждение данных — разные диагнозы; одно нельзя выводить из другого.

Сохраните исходные данные до любых попыток ремонта

Перед изменениями я сохраняю журналы и текущее состояние конфигурации. Нужна копия не одного файла внутри контейнера, а согласованный набор данных Mailcow: почтовые каталоги, SQL-база, криптографические данные и конфигурация. Точные точки хранения зависят от настроек Docker и хоста. Поэтому команда docker cp mysql-mailcow:/var/lib/mysql в произвольный каталог и архив путей /var/vmail или /etc/mailcow-dockerized не являются универсальной резервной копией Mailcow.

Если MariaDB ещё отвечает, пользуйтесь поддерживаемым скриптом из корневого каталога установки: ./helper-scripts/backup_and_restore.sh backup all. Он собирает компоненты Mailcow в ожидаемом формате; путь резервного каталога скрипт запросит отдельно. При неработающей базе этот вызов не заменяет восстановление из бэкапа и может завершиться ошибкой. Не запускайте его снова и снова: сохраните текст ошибки и переходите к копированию исходного состояния.

Если база не запускается, я сохраняю исходный том и остальные Docker-тома целиком через механизм снимков хранилища, согласованный с тем, как реально устроен этот хост. Такой снимок делают на отдельный носитель; при возможности перед ним штатно прекращают запись в данные. Конкретные пути нельзя честно назвать без проверки Compose-конфигурации. Вместе с копией сохраните mailcow.conf и журнал запуска, не меняя оригинал. Иначе новая попытка может затереть следы, по которым ещё можно было восстановить данные.

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

При наличии копии восстановите Mailcow штатным способом

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

Из корневого каталога Mailcow запустите ./helper-scripts/backup_and_restore.sh restore. Скрипт попросит путь к каталогу с резервными точками вида mailcow_DATE, покажет доступные копии и компоненты. Выберите нужную дату и состав восстановления. Не переименовывайте каталоги резервных копий: штатная процедура использует их ожидаемое имя. Для полной копии документация предлагает пункт all; если набор компонентов неполный, восстанавливайте только то, что действительно сохранено.

Перед запуском я сверяю значение MAILDIR_SUB на старой и новой системе. В документации Mailcow отдельно предупреждает: если параметр раньше не был задан, не добавляйте его на новом узле; если был задан, не удаляйте. Dovecot ищет письма в соответствующей подпапке Maildir, и несовпадение может дать пустые ящики при наличии файлов. С этим сценарием связана наша заметка про пустые ящики после восстановления.

Для отдельного SQL-дампа у Mailcow есть собственная инструкция с корректным использованием mysql-mailcow и docker compose. Она подходит для SQL-дампа, но не заменяет полный комплект Mailcow: сама база не содержит почтовые файлы пользователей. При переносе и восстановлении сверяйте состав резервной копии и фактические тома, иначе панель может показать ящики без их содержимого или наоборот.

Если копии базы нет, не запускайте ремонт InnoDB наугад

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

В документации MariaDB советуют начинать с наименьшего режима и повышать его по одному только при необходимости. Более высокие режимы накладывают дополнительные ограничения; на уровнях 4–6 возможны повреждение индексов, неполные или несогласованные данные. Значения и поведение зависят от версии. Если специалист применяет recovery, цель — извлечь доступные таблицы в отдельный дамп, затем восстановить их в чистую базу и вернуть штатную конфигурацию. Само появление работающего процесса не означает, что база вылечена.

mysqlcheck или mariadb-check с параметром --auto-repair не чинит таблицы InnoDB. Утилита требует работающего сервера, а REPAIR TABLE применим только к поддерживаемым движкам; для InnoDB MariaDB предписывает отдельный сценарий восстановления. Удалять ibdata1, файлы .frm или подменять их свежими нельзя: это не универсальная операция и может лишить вас оставшихся данных. Рекомендации «сотрите файл, контейнер сам создаст базу» относятся к потере данных, а не к восстановлению. Совет «удалите файл, потом разберёмся» обычно заканчивается тем, что разбираться уже не с чем.

Если в журнале перед отказом есть ошибка обновления, сначала сохраните версию и полный журнал, не повторяйте обновление поверх повреждённой базы. Порядок разбора такого события отличается от обычного восстановления; см. Также материал про ошибки MariaDB после обновления. Без резервной копии результат нельзя гарантировать заранее. Тут честный план — копия исходника, извлечение доступного дампа и отдельная оценка потерь, а не обещание сохранить каждый ящик.

После запуска проверьте не контейнер, а почту

Статус Up у mysql-mailcow подтверждает лишь запуск процесса. Я проверяю, что в панели на месте домены, ящики и алиасы, затем открываю несколько учётных записей через IMAP и проверяю старые письма в разных папках. Сравниваю контрольные ящики и объём хранилища с тем, что было до аварии. Успешная авторизация в SOGo сама по себе не подтверждает сохранность всех Maildir-файлов.

Затем проверяю отправку и приём тестовых сообщений, очередь Postfix и журналы postfix-mailcow, dovecot-mailcow и sogo-mailcow. Для внешнего соединения штатные порты по умолчанию включают SMTP 25, 465 и 587, IMAP 143 и 993, веб-интерфейс 80 и 443. Значения портов можно изменить в конфигурации, а доступность зависит от привязки адреса и внешнего межсетевого экрана. Поэтому список портов сверяю с mailcow.conf и сетевым путём, а не просто отмечаю галочкой.

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

Настройте резервирование так, чтобы его можно было вернуть

После восстановления я настраиваю штатный backup_and_restore.sh по расписанию и направляю резервные копии на отдельный носитель или отдельное хранилище. Скрипт Mailcow умеет сохранять все компоненты командой backup all; для автоматического запуска документация показывает переменную MAILCOW_BACKUP_LOCATION и cron. Частоту выбирают по допустимой потере данных: ежедневная копия удобна, но между копиями всё равно остаётся окно, в котором письма могут не попасть в резерв.

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

В условном примере с «Дельта-Профиль-Трейд» нет подтверждённых логов, версии и фактического результата ремонта. Поэтому я не приписываю компании срок восстановления или сохранённые письма — такие цифры были бы выдумкой. Практический итог для владельца сервера должен быть измеримым: какая точка резервирования выбрана, сколько данных восстановлено, какие ящики проверены и что осталось в очереди. Только после этой сверки можно закрывать инцидент.

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