Я работаю в небольшой маркетинговой компании, которая также занимается веб-дизайном и разработкой. Мы размещаем всех наших клиентов по веб-дизайну и разработке на выделенном сервере в Hostgator. У нас есть выделенный сервер с жесткими дисками, настроенными на RAID 1. Мы также делаем еженедельное резервное копирование, которое автоматизируется через cPanel и загружается автоматически с помощью программного обеспечения FTP.
Сегодня мы обсуждали, что мы будем делать, если у Hostgator будет какой-то катастрофический сбой. Это может быть взорванный сервер, у Hostgator были серьезные проблемы с сетью, ФБР провело один из своих знаменитых рейдов «забери каждый сервер, который мы видим» и т. Д. В основном любой сценарий, в котором ожидается длительное отключение. Затем мы подняли его на следующий уровень и задались вопросом, что мы будем делать, если Hostgator будет иметь длительное отключение, и мы не сможем получить доступ к нашим локальным резервным копиям. Это может произойти из-за пожара, наводнения и т. Д. Я знаю, что вероятность того, что наш сервер будет недоступен в течение длительного периода времени, а наши локальные файлы, одновременно недоступные, являются удаленными, но все, что требуется, это всего лишь дваплохие вещи случаются, и вот где мы будем стоять. (Если вы когда-либо приобрели спущенную шину и обнаружили, что ваш запасной элемент был спущен или отсутствует, вы знаете, как легко на самом деле бывает две плохие вещи одновременно).
Излишне говорить, что мы хотим быть готовыми к событиям типа «наихудшего сценария», поскольку это почти наверняка разорит нас. Итак, мои два вопроса:
Что мы можем сделать, чтобы подготовиться к длительному отключению от Hostgator? В идеальном случае веб-сайты наших клиентов и, надеюсь, электронные письма будут снова быстро запущены.
Что будет включать в себя надежный план резервного копирования, чтобы важные данные никогда не терялись? Идеальное решение будет автоматизировано.
Вы можете предположить, что стоимость не является проблемой в ваших ответах, но чем доступнее решения, тем лучше.
Ответы:
Я бы посоветовал вам:
Автоматически зеркалируйте все содержимое и конфигурацию вашего основного сервера на дополнительный резервный сервер в совершенно отдельной сети в другом центре обработки данных. Используйте RSync, FXP, cPanel voodoo или любой другой метод автоматизации синхронизации.
Используйте переключение при сбое DNS для автоматической маршрутизации трафика на сервер резервного копирования, если сервер Hostgator не отвечает.
Это означает, что у вас постоянно есть «горячая» резервная копия, ожидающая запуска в худшем случае, а не «холодная» резервная копия, которая требует ручного вмешательства и большого количества карабкаться и паниковать. Это также означает, что ваши клиенты никогда не узнают, что их сайт вышел из строя раньше вас, что может быть огорчительно для всех.
Вы можете настроить отказоустойчивый DNS с помощью поставщика, такого как DNS Made Easy . Для каждого хостинга домена вы должны настроить до пяти резервных IP-адресов, по одному для каждого из ваших серверов резервного копирования. Как только это будет сделано ...
DNS Made Easy проверяет ваш основной сервер каждые две-четыре минуты и, если он не обнаруживает ответ, маршрутизирует трафик на дополнительный IP-адрес.
DNS Made Easy продолжает проверять основной сервер. Когда это происходит, он перенаправляет трафик на первый сервер или, если хотите, сохраняет его в резервной копии, пока вы диагностируете неисправность и исправляете основной сервер.
Конечно, это решение повысит ваши эксплуатационные расходы, которые вам придется каким-то образом передать клиентам, но - если вы находитесь в отрасли, где простои могут вывести вас из бизнеса, - вероятно, стоит заплатить за избыточно избыточный сервер. это за один раз спасает компанию.
За гранью этого:
Дублировать, дублировать, дублировать
Чем больше у вас независимых резервных копий, тем лучше. Я храню удаленные резервные копии на локальном жестком диске, который зеркально отображается на внешнем жестком диске, в Dropbox, хранилище git и удаленной учетной записи FTP. Не рискуй. Дублируйте столько, сколько сможете. Если вам необходимо выполнить восстановление из резервной копии вручную, лучше выбрать один из пяти вариантов, а не один. Паранойя недооценена.
Практика восстановления резервных копий вручную
Если вы никогда не пытались восстановить одну из своих резервных копий, как вы узнали, что они работают? Стоит сделать аварийные учения, чтобы увидеть, что произойдет, если ваши автоматизированные процедуры не сработают.
ОБНОВЛЕНИЕ: Несколько других сервисов, которые я обнаружил недавно, о которых стоит упомянуть в отношении резервного копирования сайта, аварийного восстановления и поддержания работоспособности:
В частности, Cloudflare выглядит так, что было бы полезно избежать простоев и в целом улучшить отзывчивость сайта.
источник
Аварийное восстановление может быть огромной задачей, особенно при работе с несколькими серверами, сайтами и базами данных. Два ключевых элемента, которые необходимо учитывать в выбранном решении, это целевые показатели времени восстановления (RTO) и целевые точки восстановления (RPO).
RTO - это, по сути, ожидание того, сколько времени потребуется, чтобы сайты снова начали работать. Если у вас RTO минуты или двух (или меньше), то вам следует подумать о решении в соответствии с предложением Ника, которое предполагает репликацию ваших файлов и данных в режиме реального времени во вторичный центр обработки данных и автоматическое переключение DNS, которое может быть сделано с платной услугой или с оборудованием в обоих центрах обработки данных (таких как BIG-IP Global Traffic Managerиз сетей F5. Это может быть дорогостоящим, но во многом зависит от ответа на вопрос "Какова стоимость простоя?" Если ваш RTO составляет несколько часов или даже несколько дней, то вы можете рассмотреть процедуры аварийного восстановления, которые могут включать в себя более ручное участие, такое как подключение серверов, переключение DNS и т. Д. Утомительно, но, безусловно, экономически выгодно, если ваш RTO позволяет это.
RPO - это, в основном, частота выполнения резервного копирования и объем данных, которые вы готовы потерять в случае аварии. Если изменения в контенте и / или данных происходят часто, то, скорее всего, RPO может составлять минуты или часы и может иметь дело с репликацией в реальном времени или высокочастотным резервным копированием. Если содержимое меняется не так часто, или у вас есть клиенты, которым не обязательно беспокоиться о том, что они потеряют данные в течение нескольких дней, резервные копии могут происходить реже.
Как я уже упоминал, я согласен со многим из того, что Ник должен был сказать. Другой альтернативой, которую вы можете рассмотреть, является использование облачных сервисов от одного из более крупных облачных провайдеров, таких как Rackspace или Amazon. Оба этих провайдера, в частности, имеют обширную инфраструктуру, способную справиться практически с любой катастрофой, которая им грозит. Имея что-то вроде облачного сайта или облачного сервера (термины, используемые Rackspace), у вас есть преимущество, заключающееся в возможности масштабирования, и вам не нужно беспокоиться о его физическом аппаратном аспекте.
В Rackspace также доступны настраиваемые параметры, позволяющие смешивать инфраструктуру, используя в качестве решения комбинацию облачных серверов, физических серверов и облачных файлов. Гибридный подход может быть чем-то, что следует учитывать в зависимости от потребностей ваших клиентов, если вы не хотите использовать подход, который подходит всем.
Если это поможет, на сайте Rackspace есть страница, посвященная аварийному восстановлению, которую можно найти здесь . (Также, к сведению, я не связан с Rackspace, но использовал их услуги в прошлом).
Надеюсь, это помогло.
РЕДАКТИРОВАТЬ : думал, что это может помочь, если вы оцениваете облачные решения. Отчет Gartner Magic Quadrant для инфраструктуры, а также услуг и веб-хостинга может дать вам некоторое представление о других поставщиках решений.
источник
Полная репликация сервера на другом объекте другой хостинговой компании представляется наиболее очевидным решением.
Файлы можно синхронизировать с помощью таких инструментов, как rsync и unison. Резервные копии SQL также могут быть rsynced и затем загружены в ведомую базу данных с помощью сценариев.
источник
Убедитесь, что вы используете контроль версий всего своего кода с помощью репозитория исходного кода (SVN или GIT). Вы используете SVN или GIT?
Вы можете получить учетную запись (бесплатную или платную) в стороннем репозитории, таком как Project Locker , и, если вы вернете весь свой код во время работы, по сути, у вас будет резервная копия всего этого в вашем репозитории, который находится в третьем месте. , Тем самым еще больше уменьшаются ваши шансы (почти до нуля) потерять всю работу сразу.
Вы можете выполнять фиксации / извлечения SVN через командную строку или через клиент, такой как Versions (для Mac) или TortoiseSVN (для Windows).
источник