Эту статью мы не планировали. После ударов по дата-центрам Яндекса, особенно в ночь на 11 октября, у части наших клиентов перестали открываться сайты. У крупных компаний такое встречается чаще, чем кажется: сайт и все его резервные копии хранятся в одном дата-центре, и когда с ним что-то случается, бизнес теряет все разом. Именно так произошло у одного из наших клиентов. К счастью, мы заранее сделали зеркало его сайта на сервере в другом дата-центре и каждый день обновляли там резервную копию, поэтому оперативно за пару часов восстановили данные, и сайт снова заработал. Разбирая этот и другие случаи, мы поняли, что большую часть проблем можно предотвратить заранее и без больших затрат, и решили собрать все, что знаем, в одну статью. В ней то, что мы делаем для собственных проектов, и то, что после этой истории советуем клиентам.
Вряд ли Яндекс станет последним. Готовиться к отключению дата-центров в нынешних обстоятельствах стоит как к пожару в офисе: один раз себя обезопасить и потратить день-два и дальше не переживать (ну либо переживать, но не так сильно).
Кому статья будет полезна. Владельцам и маркетологам корпоративных сайтов, интернет-магазинов, лендингов и других проектов средней сложности.
В статье мы разберем, что сделать заранее, отдельно для виртуального хостинга, собственных серверов и конструкторов вроде Тильды, и что делать, чтобы быстро восстановиться, не потерять клиентов, лидов и наработки по SEO.
Высоконагруженным системам с кластерами и отказоустойчивой архитектурой этот материал покажется базовым.
Как пользоваться статьей. Выполнять все своими руками не нужно. Задача - понять, какие пункты относятся к вашему сайту, и убедиться, что они сделаны. Часть можно проверить самостоятельно в личных кабинетах регистратора домена и хостинга, остальное - уточнить у разработчика, подрядчика или хостера. Если пункт звучит слишком технически, перешлите его своему специалисту с простым вопросом: «Это у нас сделано?»
Главный принцип: разнесите критичные элементы по разным компаниям
Сайт держится на пяти элементах: домен, DNS, хостинг, почта и резервные копии. Если три из них живут у одного провайдера, одна авария выключает все сразу, включая возможность что-то починить.
Типичная ловушка выглядит так: DNS-записи хранятся у того же хостера или в том же облаке, где стоит сайт. Хостинг упал, резервная копия есть, но переключить домен на нее нельзя, потому что панель управления DNS недоступна вместе с хостингом. Плюсом ко всему этому не работает почта, потому что она находилась там же, где и хостинг сайта.
Если нужно запомнить одно правило из этой статьи, то такое: DNS держим отдельно от хостинга - это самая дешевая мера с самым большим эффектом (ребята, которые держали DNS там же где и хостинг - на Яндексе, пару дней назад очень сильно пожалели об этом).
Три типа площадок: в чем разница
От типа площадки зависит, кто отвечает за инфраструктуру, что нужно бэкапить самим и насколько быстро можно переехать.
Базовый чек-лист для любого сайта
Эти восемь шагов нужны всем, независимо от того, где и на чем работает сайт.
Перенесите DNS к независимому провайдеру. Уберите NS-записи с Яндекса, Mail.ru, nic.ru и других массовых сервисов. Небольшая хостинг-компания или отдельный DNS-сервис подойдут. Главное, чтобы это была не та компания, где стоит сайт.
Снизьте TTL A-записей до 300-600 секунд. TTL - это время, в течение которого DNS-серверы интернет-провайдеров помнят IP-адрес вашего сайта, прежде чем запросить его заново. Если TTL равен суткам, после переключения на резервный хостинг часть посетителей еще сутки будет попадать на старый, нерабочий сервер. При TTL 300 секунд новый адрес разойдется по пользователям за несколько минут. Не все DNS-провайдеры позволяют выставить такое низкое значение; если ваш позволяет, снизьте TTL заранее: новое значение начнет действовать только после того, как истечет старое.
Поднимите рабочую копию сайта на другом хостинге. Именно рабочую: развернутую, проверенную и готовую принять трафик. Архив с бэкапом, который еще нужно куда-то залить и настроить, в момент аварии съест часы.
Вынесите корпоративную почту отдельно от хостинга сайта. Если сайт и почта лежат вместе, вы теряете и то, и другое: клиенты не могут ни зайти на сайт, ни написать. Многие по привычке держат почту в Яндексе или Mail.ru, но тарифы этих сервисов заметно выросли по сравнению с прежними. Вполне рабочая альтернатива - почтовый хостинг у хостинг-провайдера, главное, не у того же, где стоит сайт. Для надежности настройте почтовую программу так, чтобы копии писем сохранялись на вашем компьютере: тогда переписка останется под рукой, даже если почтовый сервис недоступен.
Храните локальную копию бэкапа. Хотя бы раз в месяц скачивайте полную копию сайта и базы данных на свой носитель. Облачное хранилище тоже может оказаться недоступным. Для VPS проще будет сделать слепок всего VPS-сервера - также делается достаточно быстро у многих хостинг провайдеров.
Настройте мониторинг доступности. Проверки раз в 5 минут достаточно. Уведомления должны приходить в канал, который не зависит от вашего хостинга и почты: Telegram, SMS.
Соберите доступы в одном защищенном месте. Логины от регистратора, DNS, обоих хостингов, CMS и базы данных должны быть в менеджере паролей, доступном минимум двум людям.
Если есть бюджет - подключите CDN. CDN раздает копии статических страниц и файлов с серверов в разных местах и может какое-то время отдавать сайт, даже если основной сервер недоступен.
Проверьте себя простым вопросом: если основной хостинг сейчас выключится навсегда, сколько времени займет возвращение сайта? Если ответ «не знаю» или больше суток, начните с первых трех пунктов.
Кого выбрать: DNS-провайдеры и резервный хостинг
DNS и резервный хостинг должны быть у разных компаний и не у того провайдера, где стоит основной сайт. Ниже сервисы, с которых можно начать; перед выбором проверьте актуальные тарифы и условия.
DNS-сервис | Чем подходит |
Бесплатный DNS-хостинг входит в тариф хостинга: если у вас в Timeweb размещен любой другой сайт, DNS основного домена можно держать там без доплаты | |
Бесплатная поддержка DNS для клиентов хостинга и VDS (стоит проверить в поддержке IHC: отдельной услуги DNS-хостинга на сайте нет - можно ли держать DNS домена, сайт которого стоит у другого хостера) | |
Бесплатное управление DNS для клиентов хостинга (стоит проверить, можно ли подключить DNS без покупки хостинга) | |
Бесплатная парковка домена: можно держать DNS-записи у Beget, даже если сам сайт размещен у другого хостера |
P.S. ссылки выше реферальные - и вам полезно и нам приятно ^_^
Резервный хостинг. Для дубля сайта подойдут крупные российские хостеры с дата-центрами в нескольких городах: Beget, Timeweb, Спринтхост, REG.RU, FirstVDS, Ihc. Правило выбора одно: другая компания и другой город, чем у основного хостинга.
Если у вас виртуальный хостинг
На виртуальном хостинге вы не управляете сервером, поэтому вся защита строится на дубле сайта у другого хостера и регулярных бэкапах.
Разверните дубль сайта у другого хостера. Выберите компанию с дата-центром в другом городе. Скопируйте файлы и базу, проверьте, что сайт открывается по техническому адресу.
Узнайте, где хостер хранит бэкапы. Спросите в поддержке, в каком дата-центре лежат резервные копии. Если на той же площадке, что и сайт, их встроенные бэкапы при аварии бесполезны, и пункт про локальную копию становится обязательным.
Делайте свои бэкапы, не полагаясь на хостера. Минимум - вручную раз в неделю для активно обновляемых сайтов и раз в месяц для статичных. По возможности настроить автоматическую выгрузку.
Синхронизируйте дубль с основным сайтом. После крупных обновлений контента или каталога обновляйте и резервную копию. Для интернет-магазина договоритесь о регулярности заранее, иначе на резерве окажутся старые цены и остатки.
Проверьте, что дубль работает с вашей CMS. Версии PHP, MySQL и модулей у разных хостеров отличаются. Проверьте это сейчас, а не в момент аварии.
Если у вас свои серверы или VPS
С собственной инфраструктурой можно построить почти бесшовное переключение, но только если резерв физически находится в другом дата-центре, лучше в другом городе.
Ежедневный бэкап в другой ЦОД. Не в соседнюю стойку и не в другой зал того же дата-центра, а к другому провайдеру в другом городе.
Репликация базы данных. Для интернет-магазинов и сайтов с заказами ежедневного бэкапа мало: можно потерять сутки заказов. Настройте репликацию базы на сервер в другом городе.
Полный слепок сервера раз в месяц. Образ со всей конфигурацией, пакетами и настройками позволяет восстановиться за часы, а не собирать окружение заново по памяти.
Код за рубеж, персональные данные - в России. Если хотите хранить копию за пределами российской инфраструктуры, отправляйте туда только код и статику. Базу с персональными данными реплицируйте и бэкапьте только на серверы в РФ, иначе нарушите требования 152-ФЗ о локализации.
Тестовое окружение в другом городе. Если тестовая версия регулярно обновляется и стоит на другой площадке, она становится готовым резервом.
Задокументируйте процедуру переключения. Кто переключает, какие команды, в каком порядке. Документ должен лежать вне основного сервера.
Как это устроено у нас
На своих серверах мы используем такую схему:
Ежедневный бэкап всех проектов.
Репликация базы данных в дата-центр в другом городе.
Тестовое окружение, которое обновляется раз в день и тоже находится в другом городе. В случае аварии оно может превратиться в рабочую версию сайта. Для некоторых проектов тестовое окружение и зеркальная версия сайта - разные площадки.
Если сайт на Тильде или другом конструкторе
Сайт на конструкторе целиком зависит от инфраструктуры платформы, поэтому резервом служит статическая копия на обычном хостинге.
Выгрузите статическую версию сайта. В Тильде это делается через экспорт проекта в настройках сайта (функция доступна на тарифе Business). У других конструкторов проверьте аналогичную возможность или сохраните сайт как статический HTML.
Разместите ее на виртуальном хостинге. Подойдет недорогой тариф у хостера, не связанного с платформой конструктора. Проверьте, что страницы, картинки и стили открываются корректно.
Обновляйте копию регулярно. Так часто, как позволяет ваш процесс: после каждого заметного изменения или хотя бы раз в месяц.
Продумайте формы заявок. Формы в статической копии могут по-прежнему отправлять данные через сервисы конструктора и не работать при его недоступности. Подготовьте запасной вариант: форму через обработчик на хостинге или хотя бы заметные телефон и мессенджер.
В момент аварии переключите домен на копию. Смените A-запись домена на IP резервного хостинга. Именно здесь важен независимый DNS и низкий TTL из базового чек-листа.
Как автоматизировать бэкапы
Ручные бэкапы рано или поздно забывают делать, поэтому резервное копирование стоит поставить на расписание. Готового рецепта для всех нет: многое зависит от хостинга и от того, на чем сделан сайт. Автоматизировать можно двумя путями: настроить скрипт, который сам запускается по расписанию, или поручить запуск внешнему инструменту - сервису резервного копирования или ИИ-агенту, который выполняет задачи по графику.
Виртуальный хостинг с планировщиком задач (cron). Если хостер дает использовать планировщик задач, на нем настраивают скрипт: он сам по расписанию копирует файлы сайта и базу данных и отправляет копию во внешнее хранилище. Для популярных CMS есть готовые решения: у 1С-Битрикс встроенное резервное копирование в облако, для WordPress - плагины вроде UpdraftPlus. Без технических знаний настроить это сложно, поэтому задачу лучше поручить разработчику.
Виртуальный хостинг без планировщика. На многих тарифах виртуального хостинга планировщика нет. Тогда копии делают сторонние сервисы резервного копирования, которые сами подключаются к сайту, или ИИ-агент, запускающий выгрузку по расписанию. Это вариант сложнее, и без специалиста здесь не обойтись.
Свои серверы и VPS. Здесь подойдет любой инструмент: полный доступ к серверу позволяет настроить автоматические бэкапы как угодно. Например, утилиты restic или BorgBackup по расписанию отправляют зашифрованные копии в S3-совместимое хранилище другого провайдера. Перед бэкапом снимается дамп базы (mysqldump, pg_dump), старые копии удаляются по правилу ротации.
Тильда и конструкторы. Экспорт проекта автоматизировать сложно, его делают вручную по графику. Заявки стоит сразу дублировать в CRM или на почту, чтобы они не хранились только на платформе.
Для всех. Правило 3-2-1: три копии, две - на двух разных носителях, одна - на другой площадке. Уведомления об успешном и неудачном бэкапе. Пробное восстановление из копии хотя бы раз в квартал: непроверенный бэкап может оказаться нерабочим.
Что делать во время аварии
В первый час важнее всего быстро понять масштаб и переключиться на резерв, а не ждать, пока починят основную площадку.
Убедитесь, что проблема не на вашей стороне. Откройте сайт с мобильного интернета и через сервисы проверки доступности.
Оцените, что именно недоступно. Сайт, DNS, почта, панель управления - от этого зависит, что переключать. Если не работает только сайт, а DNS доступен, переключение займет минуты.
Примите решение о переключении. Заранее договоритесь о пороге: например, если хостер не обещает восстановление в течение 1-2 часов, переходим на резерв. Ожидание «вот-вот починят» при масштабных авариях может растянуться на дни.
Переключите домен на резервную площадку. Смените A-запись на IP резервного хостинга. При TTL 300-600 секунд большинство посетителей увидят сайт через десяток другой минут.
Проверьте резервную версию. Главная, каталог, корзина, формы заявок, оплата. Отметьте, что не работает, и сообщите об этом клиентам.
Предупредите клиентов и сотрудников. Короткое сообщение в соцсетях и мессенджерах: что случилось, как с вами связаться, работают ли заказы.
Зафиксируйте данные за время аварии. Заказы и заявки, принятые на резервной версии, нужно будет перенести в основную базу после восстановления.
После восстановления вернитесь на основную площадку. Сначала синхронизируйте данные, потом переключайте DNS. Затем разберите, что сработало плохо, и обновите план.
Если резерва не было, не теряйте время: запросите у хостера актуальные бэкапы, поднимите сайт из локальной копии на любом доступном хостинге и обратитесь к специалистам по восстановлению сайтов. Чем раньше начать, тем меньше потери в трафике и позициях.
SEO: как сохранить позиции во время простоя и после него
Поисковые системы спокойно переносят короткие сбои, но многодневный простой может стоить позиций и трафика. Робот Яндекса или Google, который зашел на сайт во время аварии, не знает, что она временная. Если он увидит ошибку «страница не найдена» или пустую страницу, то может решить, что страницы больше нет, и убрать ее из поиска. Поэтому важно заранее настроить, что именно сайт покажет роботу во время сбоя, об этом ниже.
До аварии
Закройте резервную копию на техническом адресе от индексации (robots.txt, метатег noindex), иначе поисковик увидит дубль сайта.
Поставьте на резервную версию те же счетчики Яндекс Метрики и цели, что и на основном сайте.
Храните актуальные robots.txt и sitemap.xml вместе с бэкапом.
Во время аварии
Если сервер отвечает, но сайт не работает, настройте код 503 с заголовком Retry-After. Он сообщает роботу, что сбой временный; ответы 404 или пустая страница могут привести к выпадению страниц из индекса.
После переключения на резерв сразу откройте его для индексации: снимите запрет в robots.txt и уберите noindex. Это одна из самых частых ошибок.
Сохраните прежнюю структуру адресов: URL на резервной версии должны совпадать с основными.
Перенесите на резервную версию все редиректы, настроенные на основном сайте, и проверьте, что они работают. Обычно они хранятся в файле .htaccess или в настройках сервера, поэтому этот файл обязательно должен попадать в бэкап.
Проверьте, что на резервном хостинге работает SSL-сертификат и сайт открывается по HTTPS.
После восстановления
Проверьте Яндекс Вебмастер и Google Search Console: ошибки сканирования, исключенные и выпавшие из индекса страницы.
Отправьте ключевые страницы на переобход и обновите sitemap.xml.
Сравните трафик и позиции с периодом до аварии. После короткого простоя они обычно возвращаются сами за несколько дней или недель.
Убедитесь, что цели Метрики работают, а заявки, принятые на резервной версии, перенесены в CRM.
Коротко: минимум для каждого типа сайта
Без подготовленного резерва переезд занимает от нескольких часов до нескольких суток, и все это время сайт теряет заявки и позиции в поиске.
Начните с трех шагов, которые занимают меньше дня: перенесите DNS к независимому провайдеру, снизьте TTL и скачайте свежую копию сайта себе. Остальное можно делать постепенно.
