cyrrus imap - архивация старых писем

1. Никак, это письма пользователей, что вы там собрались архивировать? Вы решили лишить части писем пользователей?
2.

за все время почты накопилось под 120 гб, что создает некоторые сложности с бэкапом

И что за сложности если не секрет? Не такой уж и большой обьем.

и восстановлением, не дай Б-г

не дольше чем развернуть любой другой бэкапап

да и в случае необходимости индексировать почты после некорректного отключения сервака на это уходят почти сутки

Вы как-то не правильно его готовите, это точно! Что еще за «необходимости индексировать почты после некорректного отключения» да и еще которое занимает «почти сутки» ?
ЗЫ Версию цируса можно? Хотя я сомневаюсь, что дело в нем, недавно последний из старых 2.3.12p2 только загасил.

И что за сложности если не секрет? Не такой уж и большой обьем.

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

Вы как-то не правильно его готовите, это точно! Что еще за «необходимости индексировать почты после некорректного отключения» да и еще которое занимает «почти сутки» ?

Было такое один раз, правда. Ну может не сутки, но часов 9 точно занял процесс.

ЗЫ Версию цируса можно? Хотя я сомневаюсь, что дело в нем,

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

Я делаю полный бэкап всей базы на сетевую шару.
Соответственно, времени уходит прилично на это.

А rsync не лучше ? И на ФС со сжатием, как вариант.

Что еще за «необходимости индексировать почты после
некорректного отключения» да и еще которое занимает
«почти сутки» ?

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

Я делаю полный бэкап всей базы на сетевую шару. Соответственно, времени уходит прилично на это.

Да не все ли равно сколько занимает это времени если укладывается в регламентные сроки? Оно же не просит рядом стоять и дровишки подкидывать :)

Сейчас подумал, что нужно попробовать сжимать при помощи многопоточного pigz вместо tar. По идее это должно ускорить процесс

Посмотрел на свою почтовую базу (близко к 200Гб), использую tar.gz + gpg вообще не парит скорость. Кстати когда-то давно заморачивался с разными вариантами компрессии остановился на этом как «средний по больнице» скорость/обьем/загрузка-камня.

и файл писать сначала локально, а потом переносить уже.

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

Было такое один раз, правда. Ну может не сутки, но часов 9 точно занял процесс.

Хм, ну все может быть. Но все равно слабо вериться что бы при некорректном отключении рухнули ВСЕ индексы. А просто пересоздание во всех ящиках «на всякий случай» черевато.

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

1. В теории можно скинуть старые письма в архивные папки и прикрутить сетевое хранилище. Тут тема не так давно была, товарищ перекидывал почтовую базу, но у него задача была как временное использование и условия соединения между сервером и хранилищем очень «вкусные».
2. Есть еще такая тема как murder ( правда почти уверен что 2.3.11 еще не поддерживает). Документации по нему как обычно это у цируса минимум. На 2.5 версии не помню что именно, но что-то не завелось, решить проблему не смог (или поломали или переделали а в документацию написать забыли), поднимал на 2.4. Да и крутиться не на самой большой базе.

А rsync не лучше ?

Это само собой должно быть иначе сервак дольше простаивать будет чем работать :)

Вообще-то, вероятность повреждения индексов, действительно, отличается от нуля. Можно переиндексировать только повреждённое, но вот как это найти, коль скоро оно произошло, это вопрос.

Вообще не вопрос, 1-е логи, 2-е крики пользователей :) Причем второй метод надежнее :)

Так что, необходимость общей переиндексации может случаться.

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

Кроме того, я помню одно изменение формата, когда Cyrus сам начинал переиндексацию при попытке доступа к ящику. Кроме того, я помню одно изменение формата, когда Cyrus сам начинал переиндексацию при попытке доступа к ящику. Когда доступ был одновременно к нескольким, несколько процессов и запускалось. Достаточно проблемно тогда вышло.

Не замечал такого, в смысле что бы это стало именно проблемой. А индексы от версии к версии он переделывает. Может потому что такие работы провожу к выходным (а если везет так и к длинным) а в выходные и нагрузка меньше да и пользователи менее требовательны.

Вообще не вопрос, 1-е логи, 2-е крики пользователей :) Причем второй метод надежнее :)

Логи да, но от криков не спасают. Потому уж проще всем сразу запустить, пока до логов не у всех дошло. :-)

Если пересоздать индексы всем, лучше сразу имигрировать, причем нажимать ентер после команды reconstruct находясь уже «на той стороне» :)