После 00 часов сервер постоянно падает, что это?

Все такие простые... Предположим, для какой-то программы работает watchdog - если она в течении какого-то времени не производит действий, программа перезапускается. Засуспенденный бэкап, после восстановления, такую программу с большой вероятностью перезапустит, несмотря на то что она, возможно, выполняла критическую операцию. Возможно, банальный postfix на прыжок времени отреагирует неправильно, zabbix взвоет. Даже локинг и sync в mysql может вызвать совсем не тот эффект который ожидался (хотя если суспендим VPS с сохранением памяти - чего там лочить казалось бы). Две минуты на суспенд - и соединения отвалятся. Много ещё можно чего вспомнить.

Это всё игнорируется, если альтернатива - полная потеря данных, но не принимать во внимание такие эффекты (точнее закрывать глаза на их существование) нельзя. Горячий бэкап - штука крайне сложная, и ни суспендом, ни снапшотами его сделать полноценно не получится. Базовый алгоритм бэкапа должен быть : все процессы прекращают изменять состояние сервера, бэкап или снапшот, все процессы работают как должны. Вроде просто, а как реализовать? Надо же сотрудничество всех процессов. Только CMS'ы тут подстраховались - у них обычно есть режим обслуживания - именно чтобы защититься от изменения состояния.

Понятно, что какие-то сложности всегда возможны, но вы вот время когда-нибудь подводили скачками на типичном сервере хостинга? И что-нибудь рухнуло ? Практически ничего же не происходит.

Насчет соединений не помню чтобы ssh при этом отваливался.

Просто они должны работать корректно - и никаких "опознаваний" не надо. "Скачок времени" о котором вы говорите - можно устроить обычным SIGSTOP. Разорванные соединения - ничего необычного (да и не будет их для TCP за такое время).

Неправда, не то. И оно *уже* есть.

Речь шла о бекапе vps в целом. А не о том как бекапить внутри vps отдельно стоящие приложения.

Хостер по определению не должен расчитывать на то что там хозяин vps запустил. Может быть что угодно, это понятно?

Можно смело увольнять администратора за криво настроеный "watchdog". Объяснять почему?

Начните с того, что вспомните откуда эти ваши "две минуты" вновь появились.

Обязательно.

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

---------- Добавлено 20.12.2012 в 12:55 ----------

Да, внимательно прочитав - не то. К бэкапу вообще никаким боком не относится, кстати.

---------- Добавлено 20.12.2012 в 13:11 ----------

Простейший пример - если в очереди постфикса лежит письмо, то есть хорошие шансы, что отправитель после восстановления из бэкапа получит сообщение о недоставке. Если что-то типа monit настроено на реакцию на одно пропущенное событие, тоже, я думаю, может что-то не то сделать. Если в какой-то программе есть вычисление среднего за текущий и предыдущий интервал - будет падение показателей. И так далее, всё зависит от того насколько тщательно написана программа. ntpd не на пустом месте возник.

Ну, нужно же было подумать о реальной проверке работы программы.

Вам выше пишут - суспенд занимает секунды, а вы опять...

Относится. В той же степени, что и снапшоты на всяких LVM, как и суспенд vps и т.п. Не так много вещей в мире Linux есть, которые гвоздями прибиты к какому-то специфическому use-case.

Это вам надо vps на несколько суток завалить (4-5 дней по RFC, если правильно помню). Я бы сразу сказал вам - это случай, когда проблемы у вас будут посерьезнее одного недоставленного письма 😂

Начнем с того, что реакция на одно событие - моветон. Приемлемо, если это предупреждение или новая проверка события (вне очереди и т.п.) - но не более. Во-вторых - откуда вообще "пропуск"? Что-то похожее вашему описанию можно в monit сделать через внешние (exec) чекреры, с "памятью" - причем явно глючные.

А по описанию - больше похоже на баг...

И каким боком тут синхронизация? Время должно быть правильным, его *коррекция* должна происходить плавно. Это вовсе не означает, что приложения не могут получать здорово различающиеся показатели временных меток в течение их неприрывного снятия. Да запросто - SIGSTOP+SIGCONT. Если от этого программа сходит с ума - давно пора отдать на живодерню ее пейсателя.

Плохой ватчдог, негодный. Он и без бекапа навредить может изрядно :)

дескрипторов может не хватает, бывает

суспенд - секунды, после него для замороженной машины делается бэкап, а это не секунды.

Вот как раз Parallels писала, что их интересует в основном для конкретного use-case, и работали они над CRIU в основном для миграции. Но если Вы приведёте пример бэкапных программ, использующих CRIU, все будут только очень рады.

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

моветон или нет - не важно. Есть системы, в которых один пропуск события требует посылки сообщения что событие пропущено и разбирательство почему пропущено.

Описанное мной поведение postfix ещё оставляет вопросы? postfix на живодёрню? Кстати, ситуация с временными прыжками встречалась, судя по гуглю, в cacti. Тоже на мыло? И совсем не обязательно программе сходить с ума, она может просто выдать неправильную диагностику.

Вы с удивительным упорством защищаете тезис о том, что состояние системы во время бэкапа неважно. Вы действительно так считаете?

Ну так когда уж бэкап делается (со снапшота, забыли?) - это вы сами виноваты, что машину не разморозили. О дампе памяти я говорил - это секунды, как и сама "заморозка".

Да чего уж там "приводить" - все те же, все то же. rsync, к примеру. Бэкап, в каком-то смысле - очень простой случай миграции.

Ок, понял. Здесь также все просто: дело в магической процедуре "восстанавливаем бэкап". Довольно таки очевидно, что она должна быть в общем случае несколько сложнее чем "включили и работаем". И, конечно, никакие интерфейсы от Microsoft тут делу никак не помогут.

Важно - за такое и уволить могут.

С уточнением в вашем предыдущем ответе - нет.

Чушь, совсем не про то. Важно, чтобы бэкап был консистентным. И для VPS вам рассказали про все механизмы, которые позволяют этого достичь (заморозка + дамп + снапшот fs), причем с минимальным простоем (секунды).

Задачи восстановления с него через длительный интервал времени - уже отдельная песня. Здесь действительно, пожалуй, общих методов нет.