Скопировать адрес страницыКогда мы создаём сайт, обычно приходится решать два вопроса: где зарегистрировать доменное имя и где разместить сам сайт. Многие предпочитают пользоваться услугами одной компании: так проще оплачивать услуги, управлять ими и обращаться в техническую поддержку.
На первый взгляд, вполне разумное решение. Но есть один нюанс: насколько хорошо такая схема защищает нас от технических проблем?
Представим ситуацию: у хостинг-провайдера произошла серьёзная авария. Сайт перестал открываться, доступ к серверу отсутствует. А если вместе с хостингом недоступна ещё и панель управления доменом, мы можем оказаться в ситуации, когда даже не получится перенаправить посетителей на другой сервер.
Давайте разберёмся, какие существуют варианты размещения домена, DNS и хостинга, чем они отличаются и какую схему я считаю наиболее разумной.
Сначала разберёмся в терминах: домен, DNS и хостинг
Прежде чем обсуждать варианты размещения, важно понимать, что домен, DNS и хостинг — это три разные составляющие, которые часто объединяют в одном пакете услуг.
Домен — это адрес нашего сайта, который мы вводим в адресную строку браузера. Его регистрируют у аккредитованного регистратора или через его партнёра. Регистрация даёт нам право пользоваться доменным именем на определённый срок при соблюдении условий регистрации и своевременном продлении.
DNS (Domain Name System) — система, которая связывает доменное имя с IP-адресами серверов и другими необходимыми параметрами. Именно благодаря DNS браузер понимает, куда обращаться, когда мы вводим адрес сайта. Здесь же могут храниться записи, необходимые для работы электронной почты, проверки домена и других сервисов.
Хостинг — услуга размещения сайта на сервере. Там находятся файлы WordPress, база данных, изображения, настройки и всё остальное, что необходимо для работы сайта.
Все три составляющие могут предоставляться одной компанией, но технически они вполне могут находиться у разных поставщиков. И это открывает несколько вариантов организации инфраструктуры.
Вариант 1. Домен, DNS и хостинг у одной компании
Самая простая схема: регистрируем домен, покупаем хостинг и управляем всем через один личный кабинет.
У такого решения есть вполне очевидные преимущества:
- Один договор и один исполнитель.
- Один счёт на оплату услуг.
- Единый личный кабинет.
- Не нужно самостоятельно разбираться с настройкой DNS между разными компаниями.
- Все вопросы можно адресовать одной службе технической поддержки.
Для небольшого сайта, который не предъявляет особых требований к отказоустойчивости, это вполне рабочий вариант. Но есть и недостатки. Главный из них — зависимость от одного поставщика услуг.
Представим, что у провайдера произошла серьёзная авария. Недоступны серверы, сайт не работает, а вместе с ними перестал открываться и личный кабинет. Если управление доменом и DNS также завязано на инфраструктуру этого провайдера, мы можем лишиться возможности оперативно изменить настройки и направить домен на другой сервер.
Правда, здесь важно сделать уточнение: недоступность хостинга сама по себе не означает, что перестанет работать DNS или личный кабинет регистратора. Часто эти системы технически разделены. Но если они зависят от одной инфраструктуры или одного аккаунта, риск общей недоступности становится выше.
Есть и другая проблема: смена провайдера в такой схеме может оказаться сложнее. Если отношения с хостером испортились или возникли проблемы с оплатой, придётся разбираться ещё и с переносом домена.
Вариант 2. Домен и хостинг у разных компаний
В этом случае домен регистрируем у одного поставщика, а сайт размещаем у другого. Например, домен находится у независимого регистратора, а WordPress работает на сервере выбранного хостинг-провайдера.
Преимущества:
- Домен не зависит от доступности хостинга.
- При проблемах с сервером можно изменить DNS-настройки и направить домен на другой хостинг.
- При смене хостинг-провайдера не нужно переносить домен.
- Можно выбирать компании по качеству каждой конкретной услуги.
Конечно, есть и организационные неудобства:
- Два личных кабинета.
- Два договора и две оплаты.
- Необходимо самостоятельно контролировать сроки продления домена и оплаты хостинга.
- Первоначальная настройка требует понимания принципов работы DNS.
Но это не настолько сложно, как может показаться. Один раз правильно настроить DNS — и в дальнейшем обычно не приходится постоянно возвращаться к этим параметрам. На мой взгляд, для большинства коммерческих и информационных сайтов это уже более разумная схема. Но можно пойти ещё дальше.
Вариант 3. Домен, DNS и хостинг у трёх разных поставщиков
Здесь мы разделяем уже не две, а все три составляющие.
Например:
- Домен зарегистрирован у отдельного регистратора.
- DNS обслуживается независимым DNS-провайдером.
- Сам сайт размещён на хостинге другой компании.
Зачем это нужно? Представим, что хостинг перестал работать. Мы заходим в личный кабинет DNS-провайдера и меняем IP-адрес, на который указывает домен. Если у нас уже подготовлен другой сервер с рабочей копией сайта, посетители постепенно начнут попадать на него.
При этом регистратор домена вообще не участвует в процессе переключения: домен продолжает обслуживаться через прежние DNS-серверы. А если проблемы возникли у DNS-провайдера, мы можем изменить DNS-серверы домена через регистратора и подключить другую DNS-инфраструктуру. Получается, что каждый элемент системы имеет независимую точку управления.
Однако есть важный нюанс: независимость поставщиков ещё не означает автоматическую отказоустойчивость. Нужно заранее подготовить альтернативный сервер, настроить его, обеспечить актуальность данных и продумать переключение.
Кроме того, при смене DNS-провайдера необходимо правильно перенести все DNS-записи. Если забыть, например, записи электронной почты MX или настройки SPF, DKIM и DMARC, можно получить ситуацию, когда сайт уже работает, а почта перестала приходить. Поэтому такая схема оправдана прежде всего для проектов, где простой сайта действительно критичен.
Отдельный разговор — резервные копии
Теперь перейдём к вопросу, который, на мой взгляд, не менее важен, чем разделение домена и хостинга. Где хранить резервные копии сайта?
Распространённая ситуация: на WordPress установлен плагин резервного копирования, который каждую ночь создаёт архив сайта и сохраняет его в отдельной папке на том же хостинге. Формально резервные копии есть. Но насколько они защищены?
Представим, что сервер вышел из строя, произошла серьёзная аппаратная авария или возникла проблема с файловой системой. Вместе с рабочим сайтом мы можем потерять и все его резервные копии.
Или другой сценарий: хостинг-провайдер заблокировал аккаунт из-за задолженности, технической ошибки или нарушения условий обслуживания. Доступ к сайту и хранящимся рядом архивам может оказаться недоступен.
В итоге получается довольно неприятная ситуация: восстанавливать сайт нужно, а восстанавливать его неоткуда. Поэтому резервные копии желательно хранить независимо от основного хостинга
Варианты могут быть разными:
- Облачное хранилище, например S3 или обычный Google-диск или Яндекс-диск.
- Отдельный сервер или другой хостинг.
- Сетевое хранилище NAS.
- Локальный компьютер или внешний накопитель с периодическим копированием.
При этом важно не просто отправлять архивы в другое место, но и обеспечить независимость доступа к ним. Например, если облачное хранилище использует те же учётные данные и тот же аккаунт, что и хостинг, часть рисков сохраняется.
И ещё один момент: резервные копии нужно периодически проверять. Создание архива ещё не гарантирует, что из него получится восстановить сайт. Желательно время от времени выполнять тестовое восстановление и проверять работоспособность файлов и базы данных.
Что произойдёт при разных авариях?
Чтобы лучше понять разницу между схемами, рассмотрим несколько типичных ситуаций.
1. Перестал работать хостинг.
Если домен и DNS независимы от хостинга, мы можем изменить DNS-записи и направить посетителей на подготовленный резервный сервер. Если же всё находится у одного поставщика и его инфраструктура недоступна, такой возможности может не оказаться.
2. Проблемы с регистратором домена.
Если у нас есть доступ к DNS-провайдеру, это не означает, что мы сможем обойти проблему с регистрацией домена. Изменять DNS-серверы и управлять регистрацией домена можно только через регистратора или уполномоченную им сторону.
Поэтому важно не только разделять услуги, но и защищать аккаунт регистратора: использовать надёжный уникальный пароль, двухфакторную аутентификацию и следить за сроком продления домена.
3. Потеряли доступ к основному хостингу.
Если резервные копии находятся отдельно, мы можем развернуть сайт на другом сервере. Если же все копии хранятся на том же хостинге, восстановление может оказаться невозможным.
4. Решили сменить хостинг-провайдера.
При независимой регистрации домена перенос сайта становится относительно простой задачей: переносим файлы и базу данных, проверяем работу на новом сервере и меняем DNS-записи. Сам домен при этом остаётся у прежнего регистратора. Конечно, нужно учитывать время обновления DNS и кеширование записей. Переключение не всегда происходит мгновенно.
Какую схему я рекомендую?
Для большинства небольших сайтов, сайтов организаций и коммерческих проектов я бы рекомендовал следующую организацию:
- Домен — у отдельного регистратора. Желательно, чтобы домен был зарегистрирован непосредственно на владельца сайта или организацию, а не на разработчика или хостинг-провайдера.
- DNS — у независимого DNS-провайдера либо у регистратора, если его DNS-инфраструктура независима от хостинга.
- Хостинг — у компании, которая обеспечивает подходящие условия по производительности, технической поддержке и надёжности.
- Резервные копии — в отдельном хранилище, не связанном с основным сервером.
При этом я не считаю, что каждому небольшому сайту обязательно нужны три разных поставщика услуг. Можно оставить домен и DNS у одного регистратора, а хостинг разместить отдельно. Это уже хорошее решение, которое позволяет избежать многих проблем.
А вот резервные копии я бы в любом случае старался выносить за пределы основного хостинга
Наконец, не стоит забывать о доступах. Владелец сайта должен самостоятельно контролировать домен, хостинг и резервные копии. Учётные записи должны быть защищены, а доступ к ним — не зависеть исключительно от одного сотрудника или подрядчика.
Вместо заключения
Удобство управления и надёжность инфраструктуры — не всегда одно и то же. Держать домен, DNS и хостинг у одной компании действительно проще. Но при таком подходе мы сильнее зависим от одного поставщика.
Разделение услуг позволяет снизить эту зависимость, упростить смену провайдера и сохранить возможность управления отдельными элементами инфраструктуры даже при возникновении проблем с другими. И самое главное: резервные копии должны находиться отдельно от рабочего сайта.
Необязательно строить сложную инфраструктуру с несколькими серверами и облачными платформами. Достаточно продумать, что произойдёт, если одна из используемых услуг внезапно станет недоступна.
Резюмируем — надёжность сайта начинается не только с выбора хорошего хостинга, но и с понимания того, как вы будете действовать, если этот хостинг перестанет работать.