Как восстановить сайт: все методы, которые действительно работают

Сайты исчезают по самым разным причинам, и владельцы к этому редко готовы. Обновление плагина в 2 часа ночи превращает главную страницу в белый экран. Истёкшая карта банка отключает тариф хостинга, и вместе с ним аккаунт. Взломанный сервер хостер стирает подчистую, чтобы остановить распространение. Я наблюдал, как все три сценария разыгрались у одного клиента за квартал. Хорошая новость: почти в каждом случае контент всё ещё существует где-то. Нужно лишь знать, где искать и в каком порядке.

Это руководство охватывает все практические способы восстановления сайта, от самого быстрого (собственные резервные копии) до последнего варианта (веб-архивы и построчная реконструкция). Проходите методы по порядку: каждый раздел предполагает, что предыдущий не сработал.

Сначала разберитесь, что именно значит «пропал»

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

• Белый экран или HTTP 500: файлы почти наверняка на месте. Что-то сломалось в коде, обычно конфликт плагинов или смена версии PHP. Сначала читайте лог ошибок.
• Страница «Аккаунт приостановлен»: флаг по биллингу или нарушению правил у хостера. Файлы обычно не тронуты. Урегулируйте вопрос с аккаунтом, и сайт вернётся как был.
• Домен истёк или DNS никуда не ведёт: сайт может быть жив на IP-адресе сервера или по временному URL. Сначала продлите домен, всё остальное потом.
• Аккаунт на хостинге удалён: файлы стёрты или в очереди на удаление. Это настоящая авария. Переходите к разделам о бэкапах и архивах ниже.
• Главная страница редиректит на фарм-спам: вас взломали, а не удалили. Файлы есть, но отравлены, восстанавливайтесь из бэкапа, сделанного до заражения.

Восстановление сайта из собственных резервных копий

Если у вас есть бэкап, это самый быстрый путь назад, и всё, что ниже, вам не нужно. Рабочий бэкап означает обе половины сайта: файлы (для WordPress, прежде всего wp-content) и дамп базы данных. Одно без другого, это половина сайта.

1. Найдите самый свежий бэкап, сделанный до проблемы. Проверьте компьютер, Dropbox, Google Drive и почту. Плагины резервного копирования обожают присылать ссылки на скачивание, о которых никто не помнит.
2. Проверьте архив перед восстановлением. Откройте zip, убедитесь, что в wp-content/uploads лежат реальные изображения, а.sql-файл не весит ноль байт.
3. Сначала разворачивайте на стейджинг-поддомене или в локальном окружении, а не поверх боевого домена. Softaculous, Installatron и wp-cli делают это за десять минут.
4. Проверьте то, что ломается тихо: формы обратной связи, авторизацию, поиск и оформление заказа, если что-то продаёте.
5. Переносите на боевой домен, только когда стейджинг работает, и удалите сломанную копию, чтобы она не путала поисковики.

Одна ловушка ловит постоянно: восстановление самого свежего бэкапа взломанного сайта, вместе с ним восстанавливается и взлом. Если дело касается малвари, откатывайтесь к старейшей чистой копии и закрывайте уязвимость перед повторным запуском.

Снапшоты хостинга и восстановление на уровне сервера

Большинство хостеров хранят собственные бэкапы, даже если вы их никогда не настраивали. Срок хранения короткий, обычно от 7 до 30 дней, поэтому скорость решает. Открывайте чат или звоните, а не пишите тикет по почте, и задайте два вопроса: есть ли у вас снапшот моего аккаунта и можете ли вы либо восстановить его, либо отдать мне архив, чтобы я вытянул отдельные файлы? На бюджетных хостингах ожидайте плату от $25 до $150; управляемые хостинги обычно включают это в тариф.

• JetBackup, часто встречается на хостингах с cPanel: самостоятельное полное или частичное восстановление, обычно за последние 7–30 дней.
• Управляемые WordPress-хостинги вроде Kinsta или WP Engine: ежедневные снапшоты с восстановлением в один клик, хранятся от двух до четырёх недель.
• VPS-провайдеры вроде DigitalOcean, Hetzner или Vultr: снапшоты есть, только если вы их включили. По умолчанию они выключены.
• AWS и Lightsail: ничего нет, если кто-то вручную не создал снапшот или не настроил расписание.

Git: кнопка «Отменить» для разработчика

Если сайт когда-либо жил в Git-репозитории, клонирование обратно с GitHub, GitLab или Bitbucket занимает минуты. Но есть нюанс: Git почти никогда не хранит базу данных или пользовательские загрузки. wp-content/uploads обычно в gitignore, и данные MySQL, тем более. Git восстанавливает код, а не контент.

Статические сайты, счастливое исключение. Сайт на Hugo, Jekyll, Eleventy или экспортированный Next.js, это и есть репозиторий. Пересоберите, передеплойте, и готово, пока кофе не остыл. Для чего-либо с базой данных Git, лишь ингредиент, а не блюдо.

Восстановление сайта из Wayback Machine

Wayback Machine на web.archive.org сканирует открытый веб с 1996 года и хранит сотни миллиардов страниц. Если ваш сайт был публичным и у него был хоть какой-то трафик, скорее всего, он там, часто с многолетними снимками. Введите свой домен в строку поиска, и получите календарь снимков.

Просмотр архива страница за страницей подходит для восстановления одной статьи. Восстановить так целый сайт, сотни страниц, изображения, CSS, PDF, это неделя монотонного кликанья, а сохранённые страницы всё равно несут внедрённую Wayback разметку тулбара и битые внутренние ссылки. Именно этот пробел заполняет сервис восстановления сайтов: он вытягивает полный архивный снимок вашего домена, вычищает внедрённый архивом код, переписывает внутренние ссылки так, чтобы они работали на вашем домене, и отдаёт вам рабочий сайт. Оценка бесплатна и показывает точное количество архивных файлов, общий размер и зафиксированную цену до оплаты; туториал проходит весь процесс целиком.

Нет бэкапа, нет Git: восстанавливаем сайт всё равно

Допустим, худший случай реален: бэкапа нет, хостер стёр всё, и сайт никогда не был в Git. Сайт всё ещё можно восстановить из того, что сохранил веб. Wayback Machine, основа, но не единственный кэш в городе.

1. Сначала проверьте web.archive.org на домен и каждый важный URL, который вспомните.
2. Проверьте также archive.today. Он захватывает страницы, которые Wayback пропускает, особенно заблокированные robots.txt.
3. Поищите в отправленной почте черновики, документы с контентом и PDF-файлы, которые прикреплял ваш старый дизайнер. Контент прячется во «Входящих».
4. Спросите всех, кто прикасался к сайту. Дизайнеры хранят исходники и экспорты. Авторы хранят документы. Ящик одного фрилансера может воскресить целый раздел.
5. Вытяните изображения из собственных соцсетей. То фото товара в Facebook от 2019 года, тот же файл, который вы потеряли.
6. Соберите всё в одну папку и пересоберите на чистой установке CMS, а не латайте обрывки на умирающей.

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

После восстановления сайта, закрепите результат

Восстановление, идеальный момент, чтобы закрыть дверь за собой: то, что однажды убило сайт, попробует снова.

• Смените все пароли: панель хостинга, админка CMS, база данных, FTP и SSH.
• Обновите ядро CMS, тему и все плагины до того, как сайт станет публичным, а не после.
• Настройте автоматические бэкапы вне сервера. Минимум еженедельные, а если сайт приносит деньги, ежедневные.
• Включите автопродление домена по карте, которая не скоро истечёт.
• Запишите, где лежат бэкапы и как их восстановить. Бэкап, который никто не может найти, это бэкап, которого у вас нет.

Сделайте эти пять вещей, и следующая авария обернётся afternoon-ным неудобством вместо недели археологических раскопок.