Купили сайт, а сервер остался у прежнего владельца: план экстренного переезда

MAATRIX

Деньги переведены, доступ к админке есть, сайт открывается — сделка выглядит закрытой. А потом кто-то из вашей команды спрашивает: «а на чьём сервере это всё крутится?» — и выясняется, что сервер до сих пор в личном кабинете хостинг-провайдера прежнего владельца, оплачивается с его карты, а root-доступ у вас гостевой, выданный на словах. Формально вы купили сайт. Фактически вы арендуете чужую инфраструктуру у человека, с которым больше нет ни одного общего интереса продолжать сотрудничать. Ниже — не про то, кто виноват, а про то, что делать прямо сейчас, пока зависимость не превратилась в полную потерю проекта.

Почему так вообще получилось: сделка была технически неполной, и что это значит на практике

Ситуация возникает не потому, что кто-то обманул, а потому, что стороны говорили о разных вещах, думая, что говорят об одном. Для продавца «продать сайт» — это передать осязаемое: домен, код, контент, базу клиентов. Сервер в этой картине — техническая деталь, а не актив сделки. Покупатель же часто не формулирует явного требования «переоформите хостинг-аккаунт на меня», потому что считает: раз получил пароль от админки и SSH — получил всё.

Юридически и технически это разные передачи. Домен переоформляется сменой регистранта у регистратора — формализуемое действие с историей в WHOIS. Код передаётся архивом или репозиторием — файлы либо у вас, либо нет. А «сервер» в большинстве хостинг-панелей — не актив, который передаётся одной командой: это подписка, привязанная к аккаунту, платёжному методу и email конкретного человека. Передать её по-настоящему — значит либо завести на провайдере новый аккаунт на имя покупателя и мигрировать туда сервер, либо воспользоваться процедурой передачи владения, если провайдер её вообще поддерживает (у части хостеров она есть, у части — нет). Именно поэтому её так легко пропустить: она не входит ни в типовой чек-лист перед покупкой сайта, ни в шаблон договора, если стороны не подумали об инфраструктуре отдельно.

Результат — сделка, закрытая на бумаге, но технически наполовину не завершённая: вы владелец проекта, но не владелец инфраструктуры, на которой он работает. Это не абстрактный риск, а конкретный, который может реализоваться в любой момент — не по злому умыслу, а просто потому, что жизнь идёт своим чередом. Стоит проговорить честно, что именно может пойти не так, потому что «риск» звучит абстрактно, а конкретные сценарии — отрезвляюще:

• Продавец теряет интерес или контакт. Деньги получены, судьба сервера его не волнует — истекающий срок оплаты хостинга он просто не заметит, потому что больше не читает эту почту.
• Продавцу закрывают аккаунт. За нарушение правил (даже не связанное с вашим проектом), подозрительную активность, спор по платежу — ваш сервер блокируется вместе со всем остальным.
• Конфликт интересов. Отношения портятся — из-за цены, из-за спора по гарантиям. Человек с правами администратора при желании может отключить сервер, сменить пароль, удалить бэкапы.
• Форс-мажор. Продавец недоступен физически — болезнь, отъезд без связи, смена номера. Восстановить доступ к чужому кабинету без его участия почти всегда невозможно.
• Двойная зависимость. Если вместе с сервером в аккаунте продавца остался ещё и домен или DNS-зона, риски складываются: даже подняв новый сервер, переключить на него трафик без контроля над DNS не получится.

Ни один из этих сценариев не требует злого умысла — обычной невнимательности достаточно. Поэтому план ниже не про «не доверяйте продавцу», а про то, что доверие — не техническая мера защиты, и полагаться только на него для боевого проекта нельзя, независимо от того, насколько хорошие сейчас отношения.

Шаг 1: немедленный бэкап всего, к чему есть доступ

Первое действие — не аренда нового сервера, а резервная копия. Аренда и настройка займёт часы или дни, а доступ к аккаунту продавца может исчезнуть в любую минуту без предупреждения. Бэкап — страховка на случай, если доступ пропадёт раньше, чем вы успеете переехать.

Если есть SSH-доступ, снимите копию всего, что нужно для полного восстановления, а не только «сайт видно в браузере»:

# файлы сайта — с сохранением прав и атрибутов
rsync -avz --progress -e "ssh -p 22" user@old-server-ip:/var/www/site/ ./backup-site/

# дамп базы данных
mysqldump -u dbuser -p --single-transaction --routines --triggers dbname > backup-db.sql
pg_dump -U dbuser -Fc dbname > backup-db.dump   # для PostgreSQL

# конфигурация веб-сервера, SSL-сертификаты, cron
tar czf configs-backup.tar.gz /etc/nginx /etc/letsencrypt 2>/dev/null
crontab -l > crontab-backup.txt

# если проект в Docker
docker ps -a > docker-containers.txt

Если полноценного SSH-доступа нет, а есть только доступ к панели хостинга (ISPmanager, cPanel, Plesk и подобные) — используйте встроенную функцию полного бэкапа аккаунта: она обычно упаковывает файлы, базы и настройки в один архив для скачивания. Менее гибко, чем через SSH, но лучше, чем ничего.

Отдельно — вещи, которые часто забывают: DNS-зона (экспортируйте или выпишите вручную все записи, включая SPF/DKIM для почты), SSL-сертификаты, купленные отдельно от Let's Encrypt, переменные окружения и секреты (.env, ключи API платёжных систем — без них код не заработает на новом месте) и список интеграций/вебхуков, завязанных на IP или домен старого сервера.

Храните бэкап минимум в двух местах, ни одно из которых не зависит от аккаунта продавца, — на своём компьютере и дополнительно в облаке под вашим контролем. Смысл не в аккуратности, а в том, чтобы у вас в руках оказалась независимая копия проекта раньше, чем что-либо случится с исходным доступом.

Шаг 2: параллельно арендовать свой сервер и развернуть копию

Пока бэкап уже лежит у вас, следующий шаг идёт параллельно, а не последовательно — не нужно ждать, пока «что-то случится», чтобы начать. Арендуйте VPS или выделенный сервер на свой собственный аккаунт, с вашим платёжным методом и учётными данными с самого начала. Это единственный способ гарантированно избавиться от зависимости — не «попросить продавца добавить вас администратором», а получить инфраструктуру, которую физически контролируете только вы.

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

Дальше — развёртывание копии по бэкапу с шага 1. Общая последовательность разворачивания без риска для старого сервера подробно разобрана в статье про перенос сайта на новый VPS без простоя: принцип «сначала рабочая копия, потом переключение» применим и здесь, разница лишь в том, что переезд вынужденный, с чужого аккаунта на свой:

rsync -avz --progress ./backup-site/ user@new-server-ip:/var/www/site/
mysql -u dbuser -p dbname < backup-db.sql          # или pg_restore для PostgreSQL
tar xzf configs-backup.tar.gz -C /                  # сверить пути, домены, версии PHP/Node

Важно не полагаться на автоматику полностью: версии PHP, Node.js, СУБД на новом сервере могут отличаться от старого, и часть конфигурации придётся поправить руками. Разверните проект по IP-адресу нового сервера, не трогая DNS старого домена вообще, — старый сервер должен продолжать полноценно обслуживать посетителей, пока новый не пройдёт проверку.

Шаг 3: полное тестирование до переключения реального трафика

Соблазн переключить домен сразу после того, как сайт «вроде открывается» на новом сервере, — источник большинства проблем при аварийных переездах. Проверка по IP-адресу до смены DNS — обязательный этап, а не перестраховка.

Проще всего временно прописать домен на IP нового сервера только на своей машине, через локальный файл hosts:

# Linux/macOS: /etc/hosts, Windows: C:\Windows\System32\drivers\etc\hosts
НОВЫЙ_IP_АДРЕС  example.com www.example.com

Ваш браузер при этом обращается к новому серверу, а весь остальной мир — по-прежнему к старому: посетители ничего не замечают, пока вы проверяете копию. Пройдите по минимальному списку: навигация и основные страницы, формы (письмо действительно приходит — настройки SMTP не копируются автоматически), авторизация, платежи (тестовая транзакция или хотя бы проверка, что виджет оплаты грузится), cron-задачи, валидность SSL, и error.log — тихие 500-е на редких страницах здесь поймать проще всего.

Если что-то ломается — это чинится на новом сервере без последствий для посетителей, потому что реальный трафик всё ещё идёт на старый. Не переходите к следующему шагу, пока не пройдёте весь список хотя бы один раз без замечаний.

Шаг 4: переключение DNS на сервер под собственным контролем

Когда копия на новом сервере проверена и работает стабильно, наступает момент переключения. Здесь есть развилка, зависящая от того, кто на самом деле контролирует домен.

Если домен уже переоформлен на вас (регистрант в WHOIS — вы, доступ к панели регистратора — ваш), задача сводится к обычной смене DNS-записей: A-запись домена и www-поддомена указывают на IP нового сервера. Если знали о переезде заранее, снизьте TTL записей за сутки-двое до переключения — чем ниже TTL, тем быстрее закончится переходный период, когда часть посетителей видит старый сервер, а часть — уже новый.

Если домен тоже остался в аккаунте продавца — проблема отдельная и более срочная: без контроля над DNS переключение невозможно, как бы ни был готов новый сервер. Шаг 4 раздваивается: параллельно с переездом нужно добиваться переоформления домена — смены регистранта у текущего регистратора или переноса к другому по EPP/auth-коду. Порядок и грабли такого переноса (Registrar Lock, ограничение на повторный перенос, DNSSEC) разобраны в статье про перенос домена к другому регистратору. Пока домен формально не ваш — это отдельный незавершённый актив сделки.

После смены записей проверьте распространение инструментом, а не по интуиции «наверное, обновилось»:

dig A example.com @8.8.8.8 +short
dig A example.com @1.1.1.1 +short

Полное распространение по всем резолверам может занять от нескольких минут до суток в зависимости от TTL и кэширования у конкретных провайдеров. Старый сервер в переходный период не выключайте — часть посетителей ещё какое-то время будет попадать именно на него, пока их DNS-кэш не обновится.

Шаг 5: разрыв зависимости только после подтверждённого переезда

Финальный шаг — самый простой технически, но именно его чаще всего делают преждевременно. Прекращать зависимость от старого аккаунта нужно только после того, как переезд подтверждён, а не сразу после смены DNS-записей.

Что считать подтверждением: несколько дней стабильной работы под реальным трафиком, отсутствие всплеска ошибок в логах, подтверждённая доставка писем, отработавшие cron-задачи, и по возможности проверка через whatsmydns.net, что большинство точек мира уже резолвит домен на новый IP. Если что-то не выполнено, откатить DNS-запись обратно — секундное дело, а вот восстановить данные с недоступного старого сервера — нет.

Только после подтверждения имеет смысл формально закрывать зависимость: скачайте финальный слепок старого сервера, зафиксируйте письменно (в переписке с продавцом, если контакт поддерживается) факт завершения переезда, уберите оставшиеся точки зависимости — почтовые ящики на старом хостинге, интеграции, всё ещё стучащиеся на старый IP. Если у вас остался административный доступ к аккаунту продавца — сообщите об этом и договоритесь о его закрытии.

С этого момента проект физически и административно работает на инфраструктуре, которую контролируете только вы, — независимо от того, что происходит с прежним владельцем, его аккаунтом хостинга или его отношением к сделке.

Как не оказаться в этой ситуации в следующий раз

Честный вывод: проблема не в том, что продавец оказался недобросовестным, а в том, что техническая передача инфраструктуры не была явно прописана как условие сделки. Она осталась на уровне «ну подразумевается же», а подразумеваемые договорённости не выполняются сами по себе — особенно в рутине вроде продления хостинга через полгода после продажи.

Для будущих покупок это означает конкретное изменение подхода: технический переезд сервера должен быть явным пунктом условий сделки, а не фактом, который додумывают после подписания. На практике это то же самое, что приёмка сервера у подрядчика после разработки, с той разницей, что покупатель здесь получает не только код, но и инфраструктуру целиком. Полезный ориентир — методика из статьи про акт приёмки сервера у подрядчика: фиксировать не «сайт работает», а проверяемые пункты — кто провайдер, на чей аккаунт оформлен сервер, кто администрирует. К покупке готового проекта стоит явно добавить:

• Срок и способ передачи хостинг-аккаунта — переоформление на покупателя, если провайдер это поддерживает, либо обязательство продавца помочь развернуть проект на сервере, арендованном покупателем самостоятельно.
• Переоформление регистранта домена — дата, до которой домен должен смотреть на покупателя в WHOIS.
• Полную опись инфраструктуры до перевода денег — какие сервисы завязаны на аккаунт продавца, у кого DNS, где хостится почта. Тот же принцип инвентаризации, только постфактум, применим и к уже доставшемуся проекту: методика в статье про проверку сервера, доставшегося по наследству.
• Часть оплаты, привязанную к завершению переезда — финальный транш переводится после подтверждённого переноса сервера и домена, а не в момент подписания.

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

Частые вопросы