Коротко
Как восстановить удаленный сайт, зависит от того, что именно пропало и какие копии остались. Если есть резервная копия файлов и базы данных — у вас, у хостинга или у разработчика, — сайт возвращают полностью, обычно за несколько часов. Если копий нет, можно собрать часть содержимого из веб-архива и других источников, но это уже не восстановление, а воссоздание сайта заново.
Главное в первые минуты — ничего не перезаписывать. Не заливать новые файлы поверх старых, не устанавливать CMS «с нуля» в ту же папку и не удалять остатки аккаунта. Ниже — пошаговый план для разных ситуаций, порядок восстановления из резервной копии для WordPress и 1С-Битрикс и что делать, если бэкапа нет.
| Что случилось | Где искать копию | Шансы вернуть сайт полностью |
|---|---|---|
| Удалили файлы или папку по ошибке | Копии хостинга, локальные архивы, копия у разработчика | Высокие, если копии свежие |
| Сломали сайт обновлением или правкой | Копия до изменения, копии хостинга | Высокие |
| Закончилась оплата хостинга, аккаунт удалён | Хостинг в течение срока хранения, свои архивы | Зависят от срока, прошедшего после удаления |
| Истёк домен | Продление у регистратора в льготный период | Высокие, если успеть вовремя |
| Нет никаких копий | Веб-архив, поисковики, почта, соцсети | Только частичное воссоздание |
Основная мысль
Удалённый сайт восстанавливают не «с сервера», а из копии: поэтому первым делом нужно найти все существующие копии и остановить всё, что может их перезаписать, и только потом выбирать способ восстановления.
Владельцы часто думают, что у хостинга «всё хранится вечно», а у разработчика «наверняка осталось». Иногда так и есть, но у каждой копии есть срок хранения, и каждый день промедления его сокращает. Хостинг хранит резервные копии ограниченное число дней, после чего перезаписывает их новыми — уже сломанным состоянием сайта.
Поэтому порядок действий важнее скорости. Сначала зафиксировать, что пропало и когда, затем собрать все копии, выбрать самую подходящую и восстанавливать сайт так, чтобы не уничтожить данные, появившиеся после её создания.
Что делать в первые часы
Паника толкает к быстрым действиям: переустановить CMS, залить старый архив поверх, начать всё заново. Каждое из этих действий может уничтожить то, что ещё можно вернуть.
Пошаговый план
- Остановите изменения. Не загружайте файлы, не запускайте установщики и не удаляйте то, что осталось в аккаунте хостинга.
- Зафиксируйте картину. Что именно пропало: весь сайт, часть файлов, база данных, домен. Когда это произошло и после каких действий.
- Сделайте копию текущего состояния. Даже если от сайта остался только фрагмент, скачайте его вместе с базой данных.
- Напишите в поддержку хостинга. Спросите, какие резервные копии есть, за какие даты и как долго они будут храниться. Попросите не перезаписывать их.
- Проверьте свои архивы. Компьютер, облачное хранилище, почту: архивы сайта часто пересылают при сдаче проекта.
- Свяжитесь с прежним разработчиком. У него может остаться копия на рабочем компьютере или в репозитории.
- Выберите копию — самую свежую из рабочих, а не просто последнюю по дате.
Каких действий избегать
- Не устанавливайте CMS заново в ту же папку и не подключайте её к той же базе данных.
- Не восстанавливайте старую копию поверх текущей базы без выгрузки текущей: потеряете заказы и заявки, появившиеся позже.
- Не меняйте тариф и не переносите аккаунт хостинга, пока не выяснили судьбу копий.
- Не давайте доступы случайным исполнителям из объявлений: восстановление требует полного доступа к серверу.
Удалил сайт — как восстановить в разных ситуациях
Разные сценарии удаления требуют разных действий. Ниже — самые частые из них.
Файлы удалены по ошибке
Типичная ситуация: при чистке папок на хостинге удалили каталог сайта или часть файлов, например папку с загрузками. База данных при этом обычно не пострадала. Файлы восстанавливают из копии хостинга или своего архива, а базу оставляют текущей. Если нужно восстановить файл сайта или несколько файлов, многие панели хостинга позволяют выбрать из копии отдельные файлы и папки, а не весь аккаунт целиком.
Удалена база данных
Сайт на WordPress или 1С-Битрикс без базы данных — это пустой шаблон без страниц, товаров и настроек. Базу восстанавливают из резервной копии хостинга или дампа. Если копия базы старше последних изменений, недостающее придётся добавить вручную — например, выгрузив заказы из писем или платёжного сервиса.
Закончилась оплата хостинга
После окончания оплаты хостинг обычно блокирует аккаунт, а через какое-то время удаляет его вместе с данными. Срок зависит от конкретного хостинга и указан в его правилах. Если аккаунт ещё не удалён, достаточно продлить услугу. Если удалён, остаётся спросить поддержку о резервных копиях, которые могли сохраниться.
Истёк срок регистрации домена
Сайт перестал открываться, но файлы и база на месте — проблема в домене. У большинства доменных зон есть период после окончания регистрации, в течение которого прежний администратор может продлить домен. Продлевайте его сразу у своего регистратора. Если домен уже освободился и его зарегистрировал кто-то другой, вернуть его сложно, и сайт придётся переносить на новый адрес.
Сайт удалили после взлома
Иногда злоумышленники удаляют файлы или заменяют их своими. Восстанавливать такой сайт из копии нужно осторожно: копия может уже содержать вредоносный код, а уязвимость, через которую произошёл взлом, остаётся открытой. Подробнее — в статье о восстановлении взломанного WordPress.
Восстановление сайта из резервной копии: общий порядок
Нужно восстановить сайт из резервной копии — начинайте с проверки самой копии. Архив может оказаться неполным, повреждённым или содержать только файлы без базы.
Что должно быть в копии
| Компонент | Что содержит | Без него |
|---|---|---|
| Файлы сайта | Ядро CMS, тема или шаблон, плагины и модули, загруженные изображения и документы | Сайт не запустится или останется без картинок |
| Дамп базы данных | Страницы, товары, заказы, пользователи, настройки | Сайт будет пустым |
| Конфигурация | Доступы к базе, настройки сервера, правила в .htaccess или nginx | Сайт не подключится к базе или сломаются ссылки |
Пошаговая инструкция
- Проверьте архив. Распакуйте его на своём компьютере, убедитесь, что есть папка с загрузками и файл дампа базы.
- Подготовьте место. Отдельная пустая папка на хостинге или тестовый поддомен. Восстанавливать сразу поверх рабочего сайта рискованно.
- Создайте базу данных и пользователя в панели хостинга, импортируйте дамп через phpMyAdmin или консоль.
- Загрузите файлы и пропишите в конфигурации новые доступы к базе.
- Проверьте работу на тестовом адресе: главную, каталог, формы, админку.
- Переключите сайт на рабочий адрес, когда всё проверено.
- Перенесите свежие данные, если копия старше последних изменений: заказы, заявки, новые материалы.
Как восстановить бэкап сайта на WordPress
У WordPress два компонента: файлы в корне сайта и база данных. Восстановить их можно из копии хостинга, из архива плагина резервного копирования или вручную.
Через плагин резервного копирования
Если копии делал плагин вроде UpdraftPlus или Duplicator, восстановление проще всего выполнить им же. При живом сайте архив загружают в интерфейс плагина. Если сайт удалён полностью, ставят чистый WordPress во временную папку, устанавливают тот же плагин и загружают архив в него. Duplicator для этого сценария даёт отдельный установщик, который разворачивает архив на пустом хостинге.
Вручную
- Загрузите файлы из архива в корень сайта.
- Импортируйте дамп базы данных.
- В wp-config.php укажите DB_NAME, DB_USER, DB_PASSWORD и DB_HOST новой базы.
- Если домен или протокол изменились, замените старый адрес в базе. На сервере с WP-CLI это делает команда:
wp search-replace 'https://old.example.ru' 'https://example.ru' --dry-run
wp search-replace 'https://old.example.ru' 'https://example.ru'Первый запуск с —dry-run только показывает, сколько замен будет сделано. Простая текстовая замена в дампе может повредить сериализованные данные, поэтому WP-CLI или специализированные инструменты надёжнее.
В завершение откройте «Настройки → Постоянные ссылки» и сохраните их, чтобы пересоздать правила .htaccess. Затем проверьте формы, оплату и отправку писем.
Восстановление сайта на 1С-Битрикс из резервной копии
В 1С-Битрикс есть штатный механизм резервного копирования в разделе «Настройки → Инструменты → Резервное копирование». Он создаёт архив с файлами и дампом базы.
Порядок восстановления
- Скачайте архив копии. Если он разбит на части, нужны все части.
- Загрузите в пустую папку сайта архив и скрипт восстановления restore.php с сайта 1С-Битрикс.
- Откройте restore.php в браузере и следуйте шагам мастера: он распакует архив и попросит данные для подключения к базе.
- После восстановления удалите restore.php и архивы из корня сайта.
- Проверьте /bitrix/.settings.php и /bitrix/php_interface/dbconn.php: доступы к базе и настройки должны соответствовать новому серверу.
- Проверьте лицензию, агенты, обмен с 1С и отправку почты.
Если сайт переезжает при восстановлении на новый сервер или BitrixVM, стоит заранее проверить версию PHP и требования платформы. Подробности переезда — в статье о переносе сайта на другой хостинг.
Что делать, если резервной копии нет
Если ни у хостинга, ни у вас, ни у разработчика копий не осталось, сайт в прежнем виде не вернуть. Можно собрать содержимое и сделать новый сайт на его основе.
Откуда можно достать содержимое
- Веб-архив. Интернет-архив хранит снимки многих сайтов. Из них можно достать тексты, изображения и структуру страниц, но не базу данных, не админку и не работающие формы.
- Почта. Тексты для сайта, фотографии и документы часто пересылались при разработке и наполнении.
- Соцсети и карточки на площадках. Описания товаров и фото нередко дублировались.
- Выгрузки. Прайсы, выгрузки для маркетплейсов, файлы обмена с 1С содержат каталог товаров.
- Компьютеры сотрудников. Исходные фото, макеты, документы.
Как не потерять позиции в поиске
Если сайт отсутствует недолго, после восстановления позиции обычно возвращаются. Если сайт воссоздаётся заново, важно сохранить адреса страниц: восстановить прежние URL или настроить 301-редиректы со старых адресов на новые. Структуру старых адресов можно взять из веб-архива, выгрузки из Яндекс Вебмастера и из данных Метрики.
Сценарии из практики
Ситуации ниже собирательные, но хорошо показывают, от чего зависит результат.
Копия нашлась у хостинга, но старая
Владелец магазина удалил через файловый менеджер папку, которую посчитал лишней, — это оказался каталог сайта. Хостинг предоставил копию недельной давности. Файлы восстановили из неё, а базу данных оставили текущей, потому что её никто не трогал. Заказы за неделю не пострадали, а недостающие изображения товаров, загруженные за эти дни, загрузили повторно из исходных файлов.
Аккаунт удалили за неуплату
Карта для автоплатежа хостинга истекла, уведомления уходили на старую почту. Когда владелец заметил, что сайт не открывается, аккаунт уже был удалён. Поддержка нашла последнюю копию, которую ещё не успели стереть, и развернула её на новом тарифе. Результат — сайт вернулся, но только потому, что обращение пришло в пределах срока хранения.
Копий нет, сайт собирали заново
Небольшой корпоративный сайт делал фрилансер, который потом пропал вместе с доступами к хостингу. Копий не было ни у кого. Тексты и структуру страниц взяли из веб-архива, фотографии — из почты и соцсетей компании. Сайт сделали заново на WordPress, сохранили адреса ключевых страниц и настроили редиректы со старых URL. Регулярные копии и доступы на владельца настроили в первый же день.
Восстановили копию поверх свежей базы
Сотрудник, не выяснив причину сбоя, развернул архив месячной давности поверх рабочего сайта. Сайт заработал, но исчезли заказы и новые товары за месяц. Часть данных вытащили из писем и выгрузок 1С, часть пришлось вносить вручную. Если бы перед восстановлением сохранили текущую базу, потерь можно было бы избежать.
Когда восстановление лучше поручить специалисту
Развернуть проверенную копию небольшого сайта на том же хостинге владелец с доступами может и сам. Но есть ситуации, в которых ошибка стоит дороже, чем работа специалиста.
Ситуации повышенного риска
- Единственная копия. Неудачная попытка распаковки поверх или неверный импорт могут испортить последний шанс вернуть данные.
- Интернет-магазин с активными заказами. Нужно объединить старую копию и свежие данные так, чтобы не потерять ни заказов, ни остатков.
- Сайт с обменом с 1С или CRM. После восстановления нужно проверить, не сломалась ли синхронизация и не задвоились ли данные.
- Смена сервера или версии PHP. Копия со старого сервера может не запуститься на новом без доработки.
- Следы взлома. Восстановление без поиска уязвимости и очистки приводит к повторному заражению.
Что подготовить для специалиста
- Доступы к панели хостинга, FTP или SSH, базе данных и админке.
- Все найденные архивы с датами их создания.
- Описание, что и когда произошло и какие действия уже предпринимались.
- Список самого важного: какие страницы, формы и данные должны работать в первую очередь.
Чем подробнее картина, тем быстрее идёт восстановление и тем меньше оплачиваемых часов уходит на выяснение обстоятельств.
Как не потерять сайт снова
Восстановление без копии обходится несравнимо дороже, чем настройка регулярных бэкапов. Ниже — что должно быть у любого рабочего сайта.
Какие копии нужны
| Что копировать | Как часто | Где хранить |
|---|---|---|
| База данных магазина или сайта с заявками | Ежедневно | Вне сервера сайта: облачное хранилище или отдельный сервер |
| Файлы сайта с загрузками | Еженедельно и перед каждым изменением | Там же, с несколькими версиями |
| Полная копия перед обновлением | Каждый раз перед обновлением ядра, плагинов, модулей | Рядом с сайтом на время работ и вне сервера |
| Конфигурация сервера | После каждого изменения | В хранилище разработчика и у владельца |
Для WordPress регулярные копии в облачное хранилище настраивают плагином резервного копирования, для 1С-Битрикс — штатным механизмом резервного копирования по расписанию или скриптами на сервере. На VPS копии удобнее делать на уровне сервера, чтобы они не зависели от работоспособности самой CMS.
Типичные ошибки
- Копии только у хостинга. Они пропадают вместе с аккаунтом при неоплате или блокировке.
- Копии на том же сервере. Сбой диска или взлом уничтожает и сайт, и архивы.
- Копии без базы данных. Файлы без дампа бесполезны для динамического сайта.
- Ни одной проверки восстановления. Архив может оказаться битым именно тогда, когда он нужен.
- Домен и хостинг оформлены на подрядчика. Владелец не может продлить услуги или получить доступ.
- Нет напоминаний об оплате. Домен и хостинг истекают незаметно.
Чек-лист
- Автоматические ежедневные копии базы и регулярные копии файлов.
- Хранение копий минимум в двух местах, одно из них — вне сервера сайта.
- Проверка восстановления на тестовом адресе раз в квартал.
- Копия перед каждым обновлением и доработкой.
- Домен и хостинг оформлены на владельца, включено автопродление.
- Список доступов: регистратор, хостинг, FTP или SSH, база, админка.
- Ответственный за сайт, который следит за копиями и оплатой. Что обычно входит в такое обслуживание, разобрано в статье о поддержке сайта.
Частые вопросы
Как восстановить удаленный сайт, если его удалил хостинг?
Сразу напишите в поддержку и спросите о резервных копиях. Хостинги хранят копии ограниченное время, поэтому медлить нельзя. Если копии есть, хостинг восстановит аккаунт или выдаст архив.
Удалил сайт, как восстановить его самому?
Найдите свежую копию файлов и базы, разверните её в пустой папке, пропишите доступы к базе и проверьте работу на тестовом адресе. Если опыта нет, лучше поручить это специалисту, чтобы не испортить единственную копию.
Как восстановить файл сайта, если удалили только его?
Многие панели хостинга позволяют восстановить из копии отдельный файл или папку. Если такой функции нет, скачайте архив копии и достаньте нужный файл из него.
Нужно восстановить сайт, а копии нет. Что делать?
Соберите содержимое из веб-архива, почты, выгрузок и соцсетей и сделайте новый сайт, сохранив прежние адреса страниц или настроив редиректы.
Как восстановить бэкап сайта, сделанный плагином WordPress?
Установите чистый WordPress, поставьте тот же плагин и загрузите архив в его интерфейс. Некоторые плагины дают отдельный установщик, который разворачивает архив без предварительной установки WordPress.
Можно ли восстановить сайт из веб-архива полностью?
Нет. В веб-архиве есть только сохранённые страницы в виде HTML и часть изображений. База данных, админка, формы и функции магазина там не сохраняются.
Потеряются ли заказы при восстановлении из резервной копии?
Заказы, созданные после даты копии, не попадут в восстановленную базу. Поэтому перед восстановлением выгружают текущую базу и переносят новые заказы вручную или скриптом.
Сколько времени занимает восстановление сайта из резервной копии?
При наличии рабочей копии — обычно от нескольких часов до одного дня. Воссоздание сайта без копии — это уже разработка со своими сроками.
Что делать, если копия оказалась повреждённой?
Проверьте другие копии за соседние даты, архивы разработчика и копии хостинга. Иногда из повреждённого архива удаётся достать базу данных или часть файлов, а недостающее собрать из других источников.
Сколько стоит восстановить сайт?
Зависит от ситуации: развернуть проверенную копию — задача на несколько часов, разбор повреждённых архивов и перенос свежих данных — дольше. Работа у меня стоит от 2 000 ₽ в час.
Итог
Удалённый сайт возвращают из резервной копии, поэтому первое действие — не восстанавливать, а искать копии и не допускать их перезаписи. Проверьте копии хостинга, свои архивы и архивы разработчика, выберите самую свежую рабочую и разворачивайте её на тестовом адресе.
Если копий нет, сайт придётся воссоздавать, собирая содержимое из веб-архива и других источников. Чтобы не оказаться в этой ситуации, нужны регулярные проверенные копии в двух местах, домен и хостинг на владельце и человек, который за этим следит.
Если ваш сайт удалён или сломан, я как частный разработчик на WordPress и 1С-Битрикс найду и проверю доступные копии, восстановлю сайт с сохранением свежих данных и настрою резервное копирование, чтобы ситуация не повторилась. Работаю напрямую, без посредников — подробности на странице восстановления сайта.
