Backup почты + содержание учетных записей на сервере

[sudo]

сделай как в этой статье http://www.lissyara.su/articles/freebsd ... t_cluster/
конкретно пункт

2. Настройка репликации данных посредством HAST.

Больше тебе оттуда ничего не нада. Всегда будет сервер-дубль(бекап). Учитывая кол-во ящиков 70, нагрузка на трафик и харды мизерная. Либо посчитай какой трафик создается и сравни с возможностями канала.

HAST подойдет для создания клона диска(ов) я так понимаю. Не понятно только одно. К примеру есть шлюз. Допустим я на нем поднимаю ХАСТ. Ставлю виртуальную машину, прописываю ее как slave для CARP + pfsync. На шлюзе также присутствуют named и squid. При падении мастера к примеру с адресом 192.168.1.1 виртуальный слэйв с адресом 192.168.1.2 получает адрес мастера. Только как на слейве будут работать вышеперечисленные демоны перед падением, у которых в конфигах прописан адрес слейва ? Да они попросту не запустятся даже. Значит я так понимаю придется костыли вставлять. Или я что-то не понимаю ?

Вопрос был в замене путей учетных записей внутри ЛВС на сетевые ресурсы + создание отдельного удаленного бэкап-сервера, который будет не только содержать клон мэйлдир. У Фокса неплохая статья по поводу ХАСТА, правда ее реализовать лучше с pf+CARP+pfsync, но там задача другая...

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[sudo]

Код: Выделить всё

zfs snapshot zfspool/zfs@snapshot_date_time
zfs send zfspool/zfs@snapshot_date_time | gzip -1 >zfs_backup.gz

копируете на удаленную тачку, потом на удаленной стороне

Код: Выделить всё

gunzip zfs_backup.gz | zfs receive
zfs promote

и т.д.
что-то типа того. Сам делал на локальной тачке send/receive. Вроде работает.
Поднимите виртуалку, да попробуйте. Я думаю, не сильно критично будет для тестовых целей сделать дамп на живой системе.
а так

Код: Выделить всё

man zfs

Или как предложено выше, через HAST

Тестовый сервер пока есть. Сегодня игрался с USB GPT+GPT+ GELI+ZFS - FreeBSD 9.0 ругается, но вроде все делает. Пока курю ZFS. Но я так понимаю, для восстановления снапшота мне нужно будет создать аналогичные разделы ZFS на бэкап-сервере ? Вообще пока ничего не понимаю ))

[mak_v_]

Но я так понимаю, для восстановления снапшота мне нужно будет создать аналогичные разделы ZFS на бэкап-сервере ? Вообще пока ничего не понимаю ))

Зачем? Ваш сервер сам поймёт что от него хотят, сам все разделы создаст, помонтирует, пошифрует......

Вообще пока ничего не понимаю ))

Это 100%, что подтверждает прочтение всего топика.

[sudo]

Но я так понимаю, для восстановления снапшота мне нужно будет создать аналогичные разделы ZFS на бэкап-сервере ? Вообще пока ничего не понимаю ))

Зачем? Ваш сервер сам поймёт что от него хотят, сам все разделы создаст, помонтирует, пошифрует......

Вообще пока ничего не понимаю ))

Это 100%, что подтверждает прочтение всего топика.

Слушай, я смотрю ты единственный, кто вывалился на белый свет уже со знанием всех файловых систем, манов и конфигов FreeBSD на 50 лет вперед. Я задал вопрос, объяснил почему те или иные методы не подходят, попросил подкинуть идею. Идею подкинули, буду пробовать. Хочется сразу найти верный путь, а не тратить время на то, что не в итоге не подойдет, поэтому бегло ознакомившись задаю вопросы. Я же не прошу сделать все за меня. А вот от твоих постов точно толку на 100% 0.

[Alvares]

в прикиньте, сколько у вас займет первичный снапшот и сколько данных будет меняться за период между бекапами. Удобна ли будет такая схема?
У zfs есть инкрементальный снапшот, используйте его.
Мне кажется, что поддержание "горячего резерва" разумно в пределах локальной сети с хорошими сетевыми скоростями и высокой доступностью. В случае с удаленным сервером ИМХО разумнее "холодный резерв" с допустимым отставанием по времени.

[manefesto]

после своего поста читать не стал
Нужны бэкапы, юзай rsync, я только так и делаю

[Morty]

автор юзай винду, она тру

[sudo]

после своего поста читать не стал
Нужны бэкапы, юзай rsync, я только так и делаю

Что в случае с rsync, что с tar - в любом случае надо останавливать почтовые сервисы, чтобы получить актуальный бэкап, т.к. изменения происходят в директории maildir, spool практически ежесекундно. rsync с опцией --delete-after в таком случае без остановки сервисов просто тупо выдает ошибку (не помню какой его код завершения) и пишет, что удалить измененные или удаленные файлы не может, т.к. в процессе синхронизации происходили изменения. В итоге спустя месяц какая там помойка образуется с таким "бэкапом" ?

[sudo]

в прикиньте, сколько у вас займет первичный снапшот и сколько данных будет меняться за период между бекапами. Удобна ли будет такая схема?
У zfs есть инкрементальный снапшот, используйте его.
Мне кажется, что поддержание "горячего резерва" разумно в пределах локальной сети с хорошими сетевыми скоростями и высокой доступностью. В случае с удаленным сервером ИМХО разумнее "холодный резерв" с допустимым отставанием по времени.

Самый разумный ответ из этого флуда. Согласен, сделать точную репликацию удаленно не получится. Но с другой стороны, в случае проблем, описанных моим первым постом - это будут мелочи жизни. Ладно, я думаю изначально надо будет понять, насколько тяжелы будут снапшоты, потом уже решать. А в пределах ЛВС на самом деле установить клона.

[sudo]

автор юзай винду, она тру

Пожалуйста в студию Ваши предложения по бэкапу Unix мэйлдира с венды. Очень внимательно выслушаю

[Morty]

это был намек что , уже можно было давно протестить на своей системе как rsync так и hast а не строить догадки и предположения