- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Специфика проекта такова, что он просто не может, вернее не должен уходить в offline и если вдруг что то случится, времени искать по гуглю и разбираться не будет, нужен человек, который сразу сможет устранить проблему. Вот хотел бы спросить, где взять такого человека и сколько он будет стоить?
Пишите в личку или скайп, может там всё совсем просто и дешево решится. И на руки будет отдан инструмент, который позволит разобраться с ситуацией самостоятельно и в гарантированные сроки. Если есть конкретные вопросы, то задавайте в форуме... тут много кого есть... кто проконсультирует и подскажет.
Иногда выгоднее докупить железа, чем нанимать квалифицированную смену для покрытия 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.
Разделите всё на несколько бекапов, один из которых - система.
Как правило, это раздел /boot и на корне все разделы (каталоги), кроме /home и /var
В случае падения ставите новый жёсткий диск, создаёте точно такую же структуру разделов и распаковываете бекап системы. Получите голую систему со всеми сервисами и тп. Останется распаковать бекапы с данными.
Есть два недостатка в этой схеме:
1. Нужен физический доступ, который не всегда можно осуществить, по крайней мере быстро. И не к арендуемому серверу.
2. Если софт регулярно обновляется (читающий, например, bugtrack, это делает), устаревшую версию придется лечить. А еще будут утеряны изменения в конфигах, которые часто делаются "на лету", при подстройке сервера.
2.
Как вариант (это если точно такой же диск) можно архивировать не файлы, а напрямую данные с диска через "dd if=/dev/hda of=/mnt/hdd/backup bs=8192". Такой бекап менее гибкий, но скорость восстановления сравнима со скоростью записи на диск. Он будет содержать все данные раздела, начиная от загрузчика в MBR. Перед выполнением в /mnt/hdd смонтируйте другой раздел, не бекапируемый.
Используя dd, обрекаешь себя на поиски идентичного винта, а "по закону подлости" его как раз под рукой не оказывается. Уж лучше "pax -p e". При наложении такого бекапа поверх свежеустановленной системы, ее функциональность сохраняется (по крайней мере FreeBSD). Только и его надо делать с умом, не сливая просто все подряд.
Во всех случаях, кроме второго сервера, реанимация займет заметное время.
Есть два варианта, что бы было секурнее... 1) бэкуп сам ходит на сервера и делает всё что нужно по ssh 2) сервера сами ходят на бэкуп.
Первый вариант мне нравится больше, но на серверах нужно держать ssh ключик для root, а это уже как-то не совсем кошерно смотрится... ну когда ssh открыт только для vpn (ipsec or pptp), то как-то спокойнее.
Второй вариант требует большей проработки, т.к. в случаях когда сервер сам льёт на бэкуп нужно писать какой-то врапер, что бы в случаях компрометации сервера файлы из бэкуп нельзя было прибить.
Я делаю проще. Первый сервер готовит файлы бекапов. Второй их забирает.