Выключение, а главное - Включение сервера

Раньше в Бивасах это было. Смотри внимательней.

что-то вроде netping не подойдёт?

Или просто wake-on-lan.

Включения/выключения дисков убьет их раньше.

Если вам диски обходятся дешевле электроэнергии, то пожалуйста, продолжайте заниматься фигней

Сделай так: по будильнику падает Nokia 3310 на клаву с корпуса сервака и нажимает рандомно комбинация )))

Сделай так: по будильнику падает Nokia 3310 на клаву с корпуса сервака и нажимает рандомно комбинация )))

А iPad сгодится? :))

Да вот тоже задумался, как в каком режиме дольше проработают диски - 1 час в сутки или все 24 часа непрерывно?
Как-никак износ подшипников тоже присутсвует...

В свое время мы это делали при помощи смартупса.
Запускаем в повершуте шедулер, в котором ставим старт в 6 утра, и стоп в 0 каждый рабочий день (+суббота для бухов, которые очень любят тупую работу в выходные).
На самом серваке ставим в бивасе настройки питания по предыдущему значению.
И все работало годами.

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

кушает энергию

Возьми какую-нибудь старую железку, поставь туда ноутбучный винт и пусть себе крутится постоянно. Ну будет 5 Вт потреблять - что с того?

Умный упс к сожалению в наличии отсутсвует, а про потребляемую энеогию это я приплел за компанию, не обращайте внимания :)
Гораздо важнее 3-я причина - поскольку бекап-сервер выставлен в агрессивный Инет, хорошо бы уменьшить шансы хакеров, для чего пусть лучше сервер будет в выключенном состоянии подольше.
Понятно, что взломоустойчивость достигается грамотным администрированием, но выключенное состояние - еще надежнее ;)

beastie:
Друг, а ты таки оказался прав, респект! :))
В Интельовом Биосе одна штучка, на которую раньше не обращал внимания, оказалась настоящим шедулером - "Wake system from S5"
Когда включил ее, появились пункты:

Wake up date
Wake up hour
Wake up minute
Wake up second

Но теперь возникает другой вопрос - а как погружать Linux в это самое "Wake"?

Ура, кажется понял! Не надо никого никуда выключать - всё уже... придумано до нас! :))
Достаточно не выключать полность компьютер, а погружать систему в сон, а потом пробуждать.
И для этого линуксоиды придумали замечательную утилиту rtcwake

Кому интересно, вот здесь о ней подробно - http://wiki.linux.ru/wiki/index.php/Будим_ваш_компьютер_с_помощью_заданий_в_п...
а я пошел испытывать ее на совместимость со своим жилезом :)

Понятно, что взломоустойчивость достигается грамотным администрированием, но выключенное состояние - еще надежнее ;)

Взломоустойчивость обеспечивается правильно настроенным фаерволом.

Взломоустойчивость обеспечивается правильно настроенным фаерволом.

Мечты-мечты.

Мечты-мечты.

Когда все порты закрыты ломать нечего, поди поломай openssh.

Если на сервере только ssh висит, то какой профит от файрвола?

Если сервер под бекапы, то доступ к сервисам может быть по IP или «по стуку». Ломать сервер у которого наружу нет портов будут разве что, если он где нибудь в пентагоне стоит, т.к иначе это полная безнадежность.

Это всё понятно. Но вот на сервере авторизация по паролю отключена, висит только ssh самой последней версии. Какой профит от файрвола?

реле времени, раз в сутки замыкающее пару проводков с блока питания компа?

Тут уже ответили так же как я хотел, но все же:

1 Вейк он лан
2 В биосе должны быть опции включения по дням недели и времени, если их нет то через биос не включишь.
3 - самое главное, брось заманухи с выключением сервера, пускай работает, электричество все= не наэкономишь сильно, а вот винты не любят старт/стопы, пускай работают 24\7, а если ОС не загрузится по какой то причине? нужно будет идти ковырять сервак...

Извиняюсь, я выше не совсем так прочитал сообщение и фигню спорол. :)

От фаервола профита конечно никакого, от port-knock*инга очевидный профит.

Пусть он в свободное время белки считает в folding@home, больше пользы будет. Выше правильно сказали, что диски сдохнут раньше от перезапусков.

Как-никак износ подшипников тоже присутсвует...

многие диски можно стопорить hdparm -B 3, или что-то там подберёшь.

-B Get/set Advanced Power Management feature, if the drive supports it. A low value means aggressive power management and a high value means better performance. Possible settings range from values 1 through 127 (which permit spin- down), and values 128 through 254 (which do not permit spin-down). The highest degree of power management is attained with a setting of 1, and the highest I/O performance with a setting of 254. A value of 255 tells hdparm to disable Advanced Power Management altogether on the drive (not all drives support disabling it, but most do).

проц сам засыпает, остальное жрёт копейки. Профит.

Как-никак износ подшипников тоже присутсвует...

Гидродинамический подшипник не изнашивается.

поскольку бекап-сервер выставлен в агрессивный Инет, хорошо бы уменьшить шансы хакеров

смысла нет особого. Если захотят взломать, взломают и за час.

Гидродинамический подшипник не изнашивается.

изнашивается ВСЁ. Даже SSD.

изнашивается ВСЁ.

И энтропия растёт, я в курсе. Скажем так, за время актуальности харда с подшипником ничего не случится.

И энтропия растёт, я в курсе. Скажем так, за время актуальности харда с подшипником ничего не случится.

именно с подшипником — не знаю. Но сдохнуть может легко.

Господа, давайте пока оставим в покое долговечность и подшипники, всё равно, пока кто-то не выложит графики зависимости долговечности от числа включений и непрерывной работы, спор будет бесконечен и бесполезен.

Давайте лучше расскажу о своих экспериментах с утилитой rtcwake
Использовал ее таким образом:

Вписал в конце rc.local такой скрипт:

sleep 600 # (прогрев сервера)
backup.sh # (бекапирование)
rtcwake -m off  -t `date +%s -d 22:00` # (пробуждение сервера в 22:00)

Недостатки:
1. Загрузка физической консоли не завершается стандартным приглашением на ввод логина/пароля, пока не завершится скрипт, что не кошерно.
2. Ключ off реально не срабатывает (что особо и не обещалось в мане к rtcwake)

Пришлось опуститься на уровень BIOS и задать время пробуждение там с помощью опции Wake system from S5, а скрипт вместо строки

rtcwake -m off  -t `date +%s -d 22:00` # пробуждение компьютера в 22:00

shutdown - h now

Но как-то некрасиво всё получилось - там Биос, сям rc.local и shutdown.
Может, есть более красивое решение, без участия Биос?
Хорошо бы с участием той же rtcwake...

прогрев сервера

О_о надеюсь в сервере провода золотые?

О_о надеюсь в сервере провода золотые?

Блин, вот не пойму, почему в ответах первыми всегда пролазят флудерасты?!!

Ну хотя бы потому что вы извращенец все делаете в rc.local

Господа, давайте пока оставим в покое долговечность и подшипники, всё равно, пока кто-то не выложит графики зависимости долговечности от числа включений и непрерывной работы, спор будет бесконечен и бесполезен.

ну вот например СТРАШНАЯ история пятилетней давности. Там вроде-бы только парковка, а если б ещё диск тормозился, то вообще было-бы КСЖ.

Разве тебе не очевидно, что раскрутка диска — сложная задача, требует много энергии, и сильно снижает ресурс девайса? У меня достаточно большая статистика, когда HDD помирал именно на ВКЛЮЧЕНИИ. Т.е. если HDD работает 24/7, то вероятность выхода его из строя мала (во всяком случае первые 5 лет), но вот если его ВКЛЮЧАТЬ, вероятность выхода из строя повышается.

Впрочем — твои проблемы, делай как хочешь. Я-бы на твоём месте вообще вырубал-бы сервак, а включал-бы его по запросу из LAN. В принципе можно для большей защиты замутить шлюз, который работает 24/7, и включает сервер бекапов. Для шлюзва достаточно чего-то типа первого пня и без HDD. Можно роутер например использовать. Или собрать что-то времён 1995го года. Хотя смысл данного убердевайса от меня всё равно ускользает…

sleep 600 # (прогрев сервера) backup.sh # (бекапирование)

вам уже указали, что это бред.

Удалённая сторона сама должна инициализировать бэкап. Т.е. должен запускаться sshd (средствами системы, а не вашим костылём rc.local), и уже удалённая сторона должна заталкивать на сервер бекапов свои файлики. Для безопасности можно использовать режим append ONLY (БЕЗ чтения), дабы злоумышленник в принципе не мог подменить или прочитать бекапы.

ну вот например СТРАШНАЯ история пятилетней давности. Там вроде-бы только парковка, а если б ещё диск тормозился, то вообще было-бы КСЖ.

Да, знаю о парковках для Линукса, вот еще подобное: http://habrahabr.ru/post/106273/ Ну хорошо, можно не выключать сервак, а переводить его в standby.

Я-бы на твоём месте вообще вырубал-бы сервак, а включал-бы его по запросу из LAN.

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

В принципе можно для большей защиты замутить шлюз, который работает 24/7, и включает сервер бекапов. Для шлюзва достаточно чего-то типа первого пня и без HDD.

Понимаю, но не хотелось бы усложнять систему.

Удалённая сторона сама должна инициализировать бэкап. Т.е. должен запускаться sshd (средствами системы, а не вашим костылём rc.local), и уже удалённая сторона должна заталкивать на сервер бекапов свои файлики.

А вот тут непонятно, поясни, какая выгода в том, что удаленная сторона инициализирует бекап? Про rc.local я и сам знаю, что не фонтан, но никто еще не сказал, как можно сделать лучше. Если заменить инициативой удаленной стороны - как бы чересур.

--------------

Ну хотя бы потому что вы извращенец все делаете в rc.local

Так об этом и надо было написать, а не нести всякий бред насчет золотых проводов. Но видать, флудерастам это сложно втолковать :(

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

скриптом невозможно. Возможно только таймером BIOS или внешним сигналом.

не выключать сервак, а переводить его в standby.

по другому тоже нельзя. Выключенный не включится сам.

В принципе можно для большей защиты замутить шлюз, который работает 24/7, и включает сервер бекапов. Для шлюзва достаточно чего-то типа первого пня и без HDD.

Понимаю, но не хотелось бы усложнять систему.

вот пусть и работает 24/7. а винты в standby. CPU сам заснёт.

А вот тут непонятно, поясни, какая выгода в том, что удаленная сторона инициализирует бекап?

там куча профитов:

• можно делать внеплановый бекап, если хочется ремонтировать боевой сервер.
• не нужно делать бекап, если боевой сервер упал, или нет связи.
• в качестве бекапа можно использовать просто append-only каталог, в который можно ТОЛЬКО добавлять файлы. Даже если враги смогут сломать боевой сервер, они смогут только добавить внеплановый бекап или отменить плановый.
• не нужно принимать никаких мер для переноса времени бекапа (если скажем во время планового бекапа боевой сервер сильно загружен, бекап можно отложить, или наоборот сделать предварительно)

Всё-таки сделал по своему, как мне понятно, и оно работает.
Кратко по ремаркам уважаемого drBatty:

скриптом невозможно. Возможно только таймером BIOS или внешним сигналом.

Возможно, и оно работает. Ведь утилита rtcwake как раз и взаимодействует с Биос.

по другому тоже нельзя. Выключенный не включится сам.

Включается очень даже охотно, конфигурирование за счет той же rtcwake

вот пусть и работает 24/7. а винты в standby. CPU сам заснёт.

Ок, пусть вы и правы, но мне больше понравилось, когда бекап-сервер работает полчаса в сутки, остальное время выключен.

там куча профитов:
можно делать внеплановый бекап, если хочется ремонтировать боевой сервер.

И здесь тоже он делается без трудностей

не нужно делать бекап, если боевой сервер упал, или нет связи.

И здесь бекап-сервер просто не будет копировать, поскольку нечего

в качестве бекапа можно использовать просто append-only каталог, в который можно ТОЛЬКО добавлять файлы. Даже если враги смогут сломать боевой сервер, они смогут только добавить внеплановый бекап или отменить плановый.

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

не нужно принимать никаких мер для переноса времени бекапа (если скажем во время планового бекапа боевой сервер сильно загружен, бекап можно отложить, или наоборот сделать предварительно)

Это да, но на фоне всего остального не столь важно.

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

Скрипт включения/выключения и запуска процесса бекапа занимает всего пару-тройку строк и использует rc.local, за что критиковали.
Кому это очень не нравится, его можно легко подвесить к cron.

Спасибо всем, кто был небезучастен к этой теме! :)

wake on lan. Если сервер на самом деле не сервер, а писюк, то можно воспользоваться intel small business advantage (на новых платах есть) - там такая штука есть.

Пусть его включают другие сервера по wake-on-lan, тоже по крону перед бэкапом.

Типа забекапь меня

ща дай проснуться

всё я забекапил я спать.

вот пусть и работает 24/7. а винты в standby. CPU сам заснёт.

Ок, пусть вы и правы, но мне больше понравилось, когда бекап-сервер работает полчаса в сутки, остальное время выключен.

составьте список основных железок, и галки вкл/выкл в двух решениях. У вас _только_ память(RAM) будет НЕ работать. Ну и ещё сетевая карта, и то не факт, что НЕ будет. Всё остальное будет аналогично.

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

нет. Append only — дополнительная мера. Шифрование данных и каналов связи никто не отменял.

К тому же пока не знаю, как этот режим отнесётся к модифицируемым файлам

вместо имени используйте md5/sha, а имя храните где-то сбоку. В xattr например.