Завершим разговор на тему почты, а точнее iRedMail
Автоматический бэкап
Для начала, стоит уточнить. Что iRedMail после установки, создает задание в crontab, которое бэкапит необходимые базы данных для восстановления.
Посмотреть скрипт, который используется для создания резервных копий, можно набрав команду crontab -e
И найти в файле crontab’а комментарий
# iRedMail: Backup PostgreSQL databases on 03:01 AM
1 3 * * * /bin/bash /var/vmail/backup/backup_pgsql.sh
Получается каждую ночь в 03:01, у нас выполняется данный скрипт который бэкапи базы данных. Если посмотреть на сам скрипт, можно установить ротацию самостоятельно, найти, куда складываются резервные копии и т.д.
Если вы собираетесь оставить скрипт, который iRedMail прелагает по-умолчанию, обратите внимание на переменные
KEEP_DAYS - ротация ваших бэкапов, за сколько дней хранить резервные копии
BACKUP_ROOTDIR - папка, куда будут складываться бэкапы
DATABASES - базы, которые будут забэкаплены
Далее можно рассмотреть директиву Commands, это команды, используемые для создания бэкапов. Если на них присмотреться, то можно понять, каким образом разработчики iRedMail рекомендуют стягивать дампы с баз
export CMD_DATE='/bin/date'
export CMD_DU='du -sh'
export CMD_COMPRESS='bzip2 -9'
export COMPRESS_SUFFIX='bz2'
export CMD_PG_DUMP='pg_dump --clean'
Проблема дефолтной бэкапилки
Мы поняли, что у нас автоматом собираются бэкапы, и можно спокойно жить. Но это не совсем так. Создавать бэкапы баз, хранить на том же севере, что и крутиться почта - плохая затея, если диск умрет, то и бэкапы уйдут вместе с ним.
И еще одна причина, которая не позволяет расслабиться, это папка /var/vmail/vmail1 - если вы не изменяли хранение писем по-умолчанию. Данная папка не бэкапится, получается, если диск отлетает, мы теряем еще и все письма, особенно если клиенты подключаются по IMAP, а не POP3. И то резервной копией хранение почты на компе пользователя не назовешь.
Решить задачу, по резервному копированию вам предстоит самостоятельно. Я написал свой собственный скрипт, который создает бэкапы на маил сервере и хранит их 2 дня. Сервер с бэкапами, стягивает бэкапы себе на RAID6 и хранит у себя. А уже еще один скрипт, на сервере с бэкапами занимается ротацией этих самых бэкапов.
Под бэкапами, имею в виду сами базы данных и папку /var/vmail/vmail1
И так, почта бэкапится, сервак крутиться. Казалось бы, все хорошо. Но все же рекомендую потренироваться, поучиться восстанавливать почту до рабочего состояния. Вы можете развернуть у себя на виртуалке чистый iRedMail и взять бэкап продакшн сервера. На работу прода, это ни как не повлияет, а потренироваться можно будет с реальными данными, для того, чтоб лучше усвоить информацию. Главно во время тренировки не трогайте настройки доменных записей.
Пригодиться это в двух случаях, первое - это обычное восстановление в случае проблем, второе - это переезд сервера на новый домен, железо и т.д.
В случае восстановления данных на рабочем сервере, никаких дополнительных действий не потребуется — можно переходить к следующему шагу.
В случае переноса сервера или его полной переустановки, необходимо сначала выполнить установку iRedMail, желательно, той же версии и на ту же операционную систему. По этому рекомендую не удалять, на рабочем сервере архив с iRedMail, что бы было проще восстанавливаться.
Ну и еще дополню, перед переносом сервера на более свежую версию, сначала надо обновить сам рабочий (продакшн) сервер и взять уже свежий бэкап, а не бэкап старых версий. Это касается только баз данных.
Восстановление баз данных
Для восстановления из бэкапа нам потребуется восстановить вот эти базы, на момент использования iRedMail версии 1.6.2 без LDAP
amavisd
iredadmin
iredapd
roundcubemail
vmail
Архивы баз хранятся в сжатом виде, для начала распакуем все базы
bzip2 -d amavisd_2023-04-28_04-00-02.sql.bz2
bzip2 -d iredadmin_2023-04-28_04-00-02.sql.bz2
bzip2 -d iredapd_2023-04-28_04-00-02.sql.bz2
bzip2 -d roundcubemail_2023-04-28_04-00-02.sql.bz2
bzip2 -d vmail_2023-04-28_04-00-02.sql.bz2
Для распаковки, нам потребуется пакет bzip2, в случае, если получили ошибку при распаковке
И восстановим базу в PostgreSQL
psql amavisd < amavisd_2023-04-28_04-00-02.sql
psql iredadmin < iredadmin_2023-04-28_04-00-02.sql
psql iredapd < iredapd_2023-04-28_04-00-02.sql
psql roundcubemail < roundcubemail_2023-04-28_04-00-02.sql
psql vmail < vmail_2023-04-28_04-00-02.sql
После восстановления баз, мы восстановили пользователей, алиасы и прочие настройки. Но почтовые ящики пользователей все еще пустые
Для этого достаточно распаковать архив с директорией /var/vmail/vmail1 и задать правильные права
Изначально прапа на папку vmail1 выглядят вот так
drwx------ 5 vmail vmail 4096 Apr 14 22:33 vmail1/
cd /var/vmail && chown vmail:vmail -R vmail1/ && chmod 0700 -R vmail1/ - судя по правам пользователя этот набор команд приведет права к нужному виду
LDAP в данной статье по почте я не буду затрагивать. Потому что я не имею с ним дела и не могу проверить восстановление на практике
Восстановление конфигов
Конфиги лучше всего хранить в какой-либо системе оркестрации, ну или на худой конец в архиве, где хранятся бэкапы. В среднем, вам придется хранить следующие файлы
Содержимое папки /var/lib/dkim - сертификаты для подписи DKIM
/etc/dovecot/conf.d, /etc/dovecot/dovecot-mysql.conf, /etc/dovecot/dovecot.conf - настройки dovecot
/etc/postfix/ - настройки Postfix
/var/www/roundcubemail - и папку roundcubemail
Так, же придется хранить файлы, которые вы кастомно настраивали для вашей почты, об этом нужно помнить, если не пользуетесь оркестрацией серверов. Тут поможет только лишь ваша память и команда history
Анонсы и еще больше информации в Telegram-канале