root.serverside.ru: процент доставки? это как простите? если ваш ip в блек запихнули то эту проблему нужно решать вручную, перепиской с сапортом mail.ru и настройкой вашего почтового сервера в соотв . с RFC
видимо, ожидается что если провайдер крупненький, то нужно просто сидеть и ждать пока он сам все решит )
Переходите на ППД Яндекс. В этом случае решить проблемы с доставкой сами получатели весьма заинтересованы.
acbirja: Теперь мы думаем использовать Amazon RDS. На сколько это правильно и выгодно (для нас)?
а зачем вы об этом думаете ?
в amazon почти ничего не выгодно для стандартного распланированного бизнеса. если только у вас не взрывной характер посещаемости, расчет на вирусное распространение, разовые рекламные акции и, разумеется, скорое закрытие обменника со всеми деньгами.
iHead, угу. а если сравнить эту информацию с man 2 stat, то обнаружится, что есть еще и поле ctime, которое изменить через utimes нельзя.
хотя это неочевидно , но ctime тоже меняется автоматически.
По крайней мере в описанной ситуации, когда используются две локальные файловые системы линукса и все программы, кроме ssh останавливаются, rsync будет работать правильно.
Где-то там у Андрейки, вероятно, мог и не работать. но к чему он это вспомнил тут - не известно.
Romka_Kharkov: А сложные пути я понимаю, можно и из бекапов поднимать, можно и скопировать данные As is и грузится с sdb (В моем случае) но это все ведет к неизбежному даунтайму системы, который хотелось бы избежать...
К сравнительно небольшому даунтайму если использовать rsync и непосредственно перед перезагрузкой еще раз запустить rsync, потом быстро провести все операции для обеспечения загрузки с нового диска.
esetnod, ну а сделали то они что? может и разламывать не нужно.
а что именно скрывается под опцией Hybrid SoftRAID ? например тут
https://www.ovh.ie/dedicated_servers/infra/2014-EG-32.xml#options
Это потом можно разломать и сделать flashcache ?
процент доставки? это как простите? если ваш ip в блек запихнули то эту проблему нужно решать вручную, перепиской с сапортом mail.ru и настройкой вашего почтового сервера в соотв . с RFC
видимо, ожидается что если провайдер крупненький, то нужно просто сидеть и ждать пока он сам все решит )
Переходите на ППД Яндекс. В этом случае решить проблемы с доставкой сами получатели весьма заинтересованы.
tmatm, будет. но cgi-скрипты на bash - это прикол в пробирке, в дикой природе почти не встречаются. cgi на perl более реальны.
Вроде бы далеко не всегда используется bash. Но если там выведется bash и его не обновляли, то всё весьма печально.
И тоже далеко не однозначно.
Ведь perl-скрипт не обязательно вызывает шелл. И не обязательно вызовет его и при конкретных странных параметрах. Все зависит от логики скрипта.
На всякий случай конечно надо обновлять.
Теперь мы думаем использовать Amazon RDS. На сколько это правильно и выгодно (для нас)?
а зачем вы об этом думаете ?
в amazon почти ничего не выгодно для стандартного распланированного бизнеса. если только у вас не взрывной характер посещаемости, расчет на вирусное распространение, разовые рекламные акции и, разумеется, скорое закрытие обменника со всеми деньгами.
На все можно найти на рынке решения дешевле.
Есть 2 файла, с одинаковым временем и размером. Однако содержимое их разное - при dd нужный файл забит нулями.
Так их не будет. Я предлагаю не использовать dd, а запускать только rsync два раза.
iHead, угу. а если сравнить эту информацию с man 2 stat, то обнаружится, что есть еще и поле ctime, которое изменить через utimes нельзя.
хотя это неочевидно , но ctime тоже меняется автоматически.
По крайней мере в описанной ситуации, когда используются две локальные файловые системы линукса и все программы, кроме ssh останавливаются, rsync будет работать правильно.
Где-то там у Андрейки, вероятно, мог и не работать. но к чему он это вспомнил тут - не известно.
Если в файле дата аналогичная в бекапе
такого не бывает. linux всегда модифицирует время модификации. системного вызова для установки другого времени просто не существует.
А сложные пути я понимаю, можно и из бекапов поднимать, можно и скопировать данные As is и грузится с sdb (В моем случае) но это все ведет к неизбежному даунтайму системы, который хотелось бы избежать...
К сравнительно небольшому даунтайму если использовать rsync и непосредственно перед перезагрузкой еще раз запустить rsync, потом быстро провести все операции для обеспечения загрузки с нового диска.