Кто и как админит свои сервера?

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

Иногда выгоднее докупить железа, чем нанимать квалифицированную смену для покрытия 24x365. Разнести по нескольким ДЦ и т.д. Организовать несколько зон, для production и develompent. Это позволяет спокойно спать и держать 100% uptime на протяжении длительного времени. Есть опыт построения систем с разнесением по разным странам... не представляю даже какой катаклизм сможет нарушить запланированный uptime системы... даже если один из администраторов захочет навредить системе, то сделать он ничего не сможет. В общем, есть опыт организации любых капризов.

Держать на зарплате дорого специалиста не всем по карману! Использовать его для старт-ап считается вполне нормальной практикой.

http://esupport.org.ru

Можете и такое сделать. Сами.

Только подумайте об этом ещё при установке системы.

1.

Разделите всё на несколько бекапов, один из которых - система.

Как правило, это раздел /boot и на корне все разделы (каталоги), кроме /home и /var

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

2.

Как вариант (это если точно такой же диск) можно архивировать не файлы, а напрямую данные с диска через "dd if=/dev/hda of=/mnt/hdd/backup bs=8192". Такой бекап менее гибкий, но скорость восстановления сравнима со скоростью записи на диск. Он будет содержать все данные раздела, начиная от загрузчика в MBR. Перед выполнением в /mnt/hdd смонтируйте другой раздел, не бекапируемый.

Второй вариант реализовывал сам для устройства с линуксом на борту.

Об остальных читал. ;-)

IMHO бэкапить надо совсем на другой сервер.

Сервера с hot-swap, биосы с pxe, бэкап сервер посажен в нужный vlan, софт написан на коленке.

Для restore нужно вынуть нафик все харды и вставить харды из ЗИП, потом ребутнуть машинку и бутануться с сетки, произойдёт автоматический restore и нужные recover. Если свичи держат jumbo frames, то MTU можно поставить в 9кил... по гигабитке достаточно шустро заливает... если свичи jumbo не поддерживают, то от бэкап сервера дополнительно воткнуть соплю cross over-ом, а потом, уже с MTU 16кил, рестор будет еще быстрее.

Есть вариант еще быстрее.

Под каждый сервер делаю дистрибут на cd or dvd.. а все что в него не входит бэкаплю на куда-то, как правило по SSH "с системой нипель"... что бы сделать restore достаточно бутануться с cd, выбрать из меню название сервера, а потом инстальнется ОС, автоматически сольются данные с бэкупа и выполнится нужный recover.

Система нипель 😂

Есть два варианта, что бы было секурнее... 1) бэкуп сам ходит на сервера и делает всё что нужно по ssh 2) сервера сами ходят на бэкуп.

Первый вариант мне нравится больше, но на серверах нужно держать ssh ключик для root, а это уже как-то не совсем кошерно смотрится... ну когда ssh открыт только для vpn (ipsec or pptp), то как-то спокойнее.

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

Для mysql, как правило, держу бэкапные сервера такой же версии и рестор всегда делаю на файловом уровне.. т.к. если это хостинговый сервер, то базок там огогогого... бэкап тоже делаю на файловом уровне... причем прямо из binlog, которые раз в полчасика/часик забираются/сливаются over ssh. Журналы от mysql храню как зеницу ока, т.к. они позволяют вытащить snap любой клиентской базы на нужный таймстамп. Т.е. если базу только что грохнули, то отловить можно до самых delete/drop, а потом уже её руками... ну а если ресторить всё, то просто файло с бэкупилки переписать.

Быстрее этого способа пока еще ничего не придумали... если не считать дополнительный сервер в master slave, hot - stand-by и hot - hot.

Если речь идёт за контент сайтов, то применяю различные журнальные системы на базе cvs or rsync, что бы держать бэкуп за как можно дольшее количество времени. Ну и restore делать приятнее... делаешь snap на нужную дату.

Есть два недостатка в этой схеме:

1. Нужен физический доступ, который не всегда можно осуществить, по крайней мере быстро. И не к арендуемому серверу.

2. Если софт регулярно обновляется (читающий, например, bugtrack, это делает), устаревшую версию придется лечить. А еще будут утеряны изменения в конфигах, которые часто делаются "на лету", при подстройке сервера.

Используя dd, обрекаешь себя на поиски идентичного винта, а "по закону подлости" его как раз под рукой не оказывается. Уж лучше "pax -p e". При наложении такого бекапа поверх свежеустановленной системы, ее функциональность сохраняется (по крайней мере FreeBSD). Только и его надо делать с умом, не сливая просто все подряд.

Во всех случаях, кроме второго сервера, реанимация займет заметное время.

Я делаю проще. Первый сервер готовит файлы бекапов. Второй их забирает.