Хранение почты в СУБД,лучше или хуже чем стандартно?

При хранении почты в базе встает вопрос о ее бекапе. Всякие Maildir'ы бекапятся (в т.ч. инкрементально) коробочными решениями типа Bacula, а почта в базе - нет.

Формально правильно настроенная БД хороша именно тем, что беспокоиться о бэкапе и консистентности пользователям её нужно.

в том то и дело, 2 реплики и всё, но вопрос больше встаёт в потреблении памяти и процессора и доступности данных, иногда в письме может лежать pdf в 60 метров, а может и psd файл в 600. Хранение такого в бд, на сколько будут тормоза сильными.

Насчет консистентности согласен. Насчет бекапа - хотелось бы более конкретно. Т.е. как надо настроить бекап, чтобы вот на такое (реальный случай) можно было отреагировать? С файлами в maildir-е мне это понятно (так как сам разруливал), а с БД - нет.

«Блондинку» в январе приняли на работу и дали для работы ноутбук. Вначале она пользовалась веб-почтой. В августе настроила там какой-то почтовый клиент, причем неправильно. Этот клиент забирал письма по POP3, сохранял локально. Письма старше 7 дней клиент с сервера стирал. Соответственно, письма хранились на ноутбуке, и проблему долго не замечали.

Потом ноутбук «сломался», пришлось переставлять всю систему. Получилась жалоба на потерянную почту. Итого - надо восстановить из бекапа всю входящую почту конкретного сотрудника с января (т.е. с момента приема на работу) по октябрь.

репликация базы нет?да и из бд клиент не удалит почту.

Как это не удалит? Он сказал клиентом «удалить», почтовый сервер удаляет.

Яндекс-почта именно так и хранит. В постгресе, много-много терабайт её. С шардированием, бэкапами через barman и т.п.

у яндекса оборудование не чита 99% контор рашки, к тому же у яндекса оракл и 1001 чеовек на его обслуживание.

Ну и зачем разрешать pop3?

Вопрос про POP3, конечно, валиден, но задача про восстановление ящика конкретного пользователя на конкретную дату валидна и без POP3.

За хинт про barman спасибо.

у яндекса оборудование не чита 99% контор рашки,

Может быть имелось в виду «не чета»? У них и объёмы обрабатываемых данных сильно другие.

к тому же у яндекса оракл и 1001 чеовек на его обслуживание.

В почте они отказались от оракла в пользу постгреса.

Вообще непонятно, какой профит с хранения файлов в базе. Файлы в БД - всегда медленнее, поиск файла будет занимать значительно больше времени и ресурсов у машины, нежели лежа по-старинке, на ФС. Плюс это еще одна точка отказа. Если хочется резервирования на лету, так это glusterfs или другие распределенные прелести. Потом представьте - у вас 4ТБ данных и одна блондинка поудаляла все письма. Попробуйте расчитать время развертывания бэкапа 4ТБ. Восстановление файлов - 0 секунд даунтайма для всех остальных.

Просто надо не удалять письма, а перемещать в какой-нибудь каталог «Корзина».

В данном конкретном случае неправильно сработал ИТ

В августе настроила там какой-то почтовый клиент, причем неправильно.

и какой результат ожидали?

В смысле? Настроить бэкап средствами БД и скажем еженедельные копии хранить вечно.

Если тебе нужна «Машина времени», то можно сделать что-то вроде: http://www.postgresql.org/docs/9.0/static/continuous-archiving.html

Ну и вообще нужно нормально настраивать почту и ничего нигде не удалять — только складировать.

я вообще думал не много у другом. Например, умирает raid на сервере с почтой, или полетела ос в результате обновы и другие причины, я тупо подключаю этот готовую wm на другом серваке к db и всё, почта снова живая. А у базы 2-3 реплики на разных серверах. Просто вот интересно, сколько бы это жрало ресурсов.

В смысле? Настроить бэкап средствами БД и скажем еженедельные копии хранить вечно.

А вот не катит. Такой бекап можно восстановить только целиком, тем самым потеряв всю новую почту других сотрудников. Точнее, для восстановления почты конкретного сотрудника на определенную дату пришлось бы разворачивать бекап на отдельную машину и возиться с SQL.

Как организовать машину времени я дал ссылку. Ну и ещё раз: удаление из папки совершенно не обязано означать физическое удаление из БД.

Как организовать машину времени я дал ссылку.

Ссылку получил.

Ну и ещё раз: удаление из папки совершенно не обязано означать физическое удаление из БД.

Т.е. осталось повторить уже сделанный вывод: требование «не удалять почту окончательно» применимо к почтовому серверу, хранящему почту в БД, и этого требования не было для почтового сервера, хранящего почту в файлах.

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

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