Бэкап сайта на компьютер: что именно скачивать с хостинга, чтобы копия реально восстановилась
Резервная копия сайта — это не только папка public_html. Если сайт работает на WordPress, другой CMS или самописном PHP с MySQL, для полного восстановления обычно нужны как минимум файлы и база данных. Дополнительно могут понадобиться конфигурация, пользовательские загрузки, задания cron, настройки домена и почты. Главная ошибка — скачать только картинки и PHP-файлы, а потом обнаружить, что статьи, заказы или пользователи были в базе. Правильный бэкап нужно не просто получить, но и проверить: архив открывается, дамп базы не пустой, а копия хранится вне того же сервера.
Коротко: что сделать сразу
- Определите корневую папку сайта и скачайте все файлы, включая скрытые .htaccess и другие служебные файлы проекта.
- Отдельно выгрузите базу MySQL, если сайт её использует.
- Сохраните config.php, .env или другой конфигурационный файл безопасно: в нём могут быть пароли.
- Зафиксируйте версию PHP, домен, DNS-записи и важные настройки cron перед переносом.
- Скачайте архив на компьютер и сделайте вторую копию на другом носителе или в независимом хранилище.
- Проверьте архив и дамп до удаления сайта со старого сервера.
Сначала выясните, из чего состоит именно ваш сайт
Статический сайт может состоять только из HTML, CSS, JavaScript и изображений. Такой проект действительно восстанавливается из файлов. Но WordPress, интернет-магазин, форум, CRM и большинство динамических сайтов используют базу MySQL или MariaDB. Тексты страниц, пользователи, заказы, настройки и другие данные могут храниться именно там.
Откройте панель хостинга и найдите разделы «Сайты», «Файлы», «Базы данных» и «Резервные копии». Названия в cPanel, ISPmanager и собственной панели провайдера отличаются. Смотрите не на точное слово из инструкции, а на назначение раздела.
Перед любым удалением составьте простой список: корень сайта, имя базы, пользовательские загрузки, конфигурация, почта, задания cron и DNS. Это превращает бэкап из «какого-то архива» в понятный комплект восстановления.
Что скачивать из файлов сайта
Найдите webroot домена: public_html, www, httpdocs или каталог, указанный в настройках сайта. Скачивать нужно не только index.php и папку с картинками, а весь проект, который необходим приложению для запуска.
Не забудьте скрытые файлы. На Apache-сайтах .htaccess может отвечать за ЧПУ, HTTPS, ограничения доступа и перенаправления. Если файловый менеджер скрывает файлы, включите отображение dotfiles штатной настройкой панели.
Если конфигурация проекта специально находится выше public_html, включите её в резервную копию отдельно. Не переносите такой файл внутрь webroot только потому, что так удобнее скачать: он может содержать пароль базы, SMTP и другие секреты.
База данных: часть сайта, которую чаще всего забывают
В панели найдите MySQL Databases, «Базы данных» или похожий раздел и определите, какая база относится к сайту. Связь обычно видна в config.php, wp-config.php, .env или другом конфигурационном файле. Перед чтением и правкой конфигурации сделайте её копию.
Для ручной выгрузки часто используется phpMyAdmin: выберите нужную базу, откройте «Экспорт» и сохраните SQL-файл. Для обычной резервной копии небольшой базы стандартного быстрого экспорта часто достаточно, но крупный проект может требовать штатного механизма хостинга из-за лимитов браузера.
После загрузки посмотрите размер .sql. Файл в несколько байт для действующего магазина с тысячами записей — повод перепроверить экспорт. Текстовый дамп должен содержать определения таблиц и данные, если выбран полный экспорт.
Штатный бэкап панели часто удобнее ручного
Если хостер предоставляет «Резервные копии», «Backup» или «Backup Wizard», начинающему пользователю разумно сначала использовать его. В cPanel Backup Wizard позволяет создать полный бэкап аккаунта или частичные копии. Официальная документация находится по адресу https://docs.cpanel.net/cpanel/files/backup-wizard/.
В cPanel частичная копия Home Directory включает принадлежащие аккаунту файлы, в том числе public_html и почтовые данные в домашнем каталоге, а MySQL Databases выгружаются отдельным SQL-файлом. Полный бэкап сохраняется как tar.gz и предназначен для полного снимка аккаунта, однако автоматическое восстановление такого полного архива через обычный cPanel недоступно — для него может потребоваться хостер или WHM.
У ISPmanager и собственных панелей механизм другой, поэтому заранее выясните, что именно входит в создаваемый архив. Название «полный бэкап» не заменяет проверку состава.
Если бэкап делаете через файловый менеджер
В файловом менеджере выделите каталог проекта и создайте ZIP или tar.gz средствами хостинга. Архивация на сервере обычно быстрее, чем скачивание тысяч мелких файлов по одному. После завершения скачайте архив на компьютер.
Не оставляйте архив с полным сайтом надолго внутри public_html. Если веб-сервер отдаёт его по прямой ссылке, посторонний может скачать исходники и конфигурацию. После проверки локальной копии удалите временный архив с публичного сервера или храните его выше webroot в защищённом месте.
Если хостинг почти заполнен, создание большого архива может завершиться ошибкой из-за нехватки места. В таком случае используйте штатный бэкап провайдера или выгружайте данные частями.
Файлы и база должны относиться примерно к одному моменту
На информационном сайте несколько минут разницы обычно не критичны. В интернет-магазине или сервисе с заявками во время бэкапа могут появляться новые заказы, загрузки и изменения профилей. Тогда архив файлов и дамп базы, сделанные с большим интервалом, могут не совпасть.
Планируйте копирование на период низкой активности или используйте предусмотренный приложением режим обслуживания, если он безопасен для бизнеса. Не включайте maintenance вслепую на час: сначала оцените, сколько займёт операция.
Для переноса рабочего сайта особенно важно решить, в какой момент прекращается запись на старом сервере и начинается на новом. Иначе две базы расходятся, и часть новых данных останется на старой площадке.
Входит ли почта в резервную копию сайта
Не всегда. Сайт и почтовые ящики могут находиться на одном хостинге, но резервироваться разными инструментами. Если адреса info@domain.ru и другие ящики важны, отдельно уточните, включаются ли сообщения, фильтры, пересылки и настройки в выбранный тип бэкапа.
Не считайте содержимое почтовой программы на одном компьютере гарантированной копией сервера: IMAP и POP3 работают по-разному, а часть папок может быть локальной. Для переноса почты составьте отдельный план.
Что сохранить кроме файлов и базы перед переносом хостинга
Сделайте скриншоты или экспорт DNS-зоны: A, AAAA, CNAME, MX и TXT-записи. Особенно важны записи корпоративной почты, SPF, DKIM и DMARC. Перед изменением DNS всегда сохраняйте исходную конфигурацию.
Зафиксируйте выбранную версию PHP и необходимые расширения, задания cron, редиректы, параметры SSL и нестандартные настройки домена. Если новый сервер имеет другую версию PHP, сайт может не заработать даже при идеальной копии файлов и базы.
После смены DNS изменения распространяются не мгновенно. Из-за TTL и кэшей часть сетей увидит новый сервер быстро, а часть может обращаться к старому до 24–48 часов. Поэтому старый хостинг нельзя удалять сразу после переключения.
Как хранить копию с паролями безопасно
В архиве сайта могут оказаться пароли базы, SMTP, API-ключи и другие секреты. Не отправляйте полный бэкап в публичную ссылку и не храните его годами в папке «Загрузки» на общем офисном компьютере без защиты.
Если копия записана на внешний диск, ограничьте доступ к нему и не держите единственный экземпляр постоянно подключённым к компьютеру. Шифровальщик способен повредить и подключённые резервные диски.
Для важных проектов полезен принцип независимой второй копии в другом месте. Один архив на том же хостинге не спасает от блокировки аккаунта, аварии или ошибочного удаления всего содержимого.
Как проверить бэкап, не дожидаясь аварии
Откройте скачанный архив и убедитесь, что он распаковывается без ошибки. Проверьте наличие входного файла сайта, каталогов загрузок, конфигурации и скрытых файлов. Сравните общий размер с тем, что показывал файловый менеджер.
Откройте SQL-дамп текстовым редактором только для просмотра и убедитесь, что он не пустой и содержит ожидаемые названия таблиц. Не изменяйте кодировку и не сохраняйте его поверх исходного файла.
Лучшая проверка — тестовое восстановление на отдельной площадке или локальном стенде. Если такой возможности нет, хотя бы ведите короткий текстовый файл с описанием: какой архив относится к какой дате, какая база ему соответствует и какая версия PHP использовалась.
Как часто делать резервные копии
Частота зависит не от типа сайта, а от того, сколько данных вы готовы потерять. Если сайт меняется раз в месяц, ежедневная ручная копия может быть избыточной. Если магазин получает десятки заказов в день, копия недельной давности уже мало помогает.
Хорошая схема сочетает автоматические копии хостинга и периодическую независимую выгрузку наружу. Но автоматический бэкап нельзя считать гарантированным, пока вы не знаете срок хранения, состав и способ восстановления.
Как понять, что резервная копия действительно готова
- Архив сайта скачан на компьютер и успешно открывается.
- В нём есть весь webroot, пользовательские загрузки и необходимые скрытые файлы.
- Для динамического сайта есть отдельный непустой дамп базы MySQL.
- Конфигурация и секреты сохранены, но не опубликованы в открытом доступе.
- Зафиксированы PHP, cron и DNS, если они нужны для переноса.
- Есть хотя бы ещё одна независимая копия важных данных.
- Вы понимаете, как именно будете восстанавливать этот комплект.
Когда лучше остановиться и не экспериментировать
Не удаляйте старый сайт, если ещё не скачана база и вы не проверили архив. Не импортируйте дамп поверх рабочей базы без свежей копии. Не меняйте config.php, .htaccess и DNS одновременно без фиксации исходных значений.
Не ставьте права 777 ради скачивания и не отключайте проверку SSL. Если панель не даёт скачать нужный каталог или база слишком велика для phpMyAdmin, запросите штатный бэкап у хостера вместо обхода ограничений.
Частые вопросы
Достаточно ли скачать public_html?
Только для сайта, который действительно не использует внешнюю базу и другие данные. Для большинства CMS нужны и файлы, и база.
wp-config.php нужно сохранять?
Да, он важен для восстановления WordPress, но содержит чувствительные данные. Храните его вместе с резервной копией безопасно и не публикуйте отдельно.
Можно ли считать резервной копией архив, который лежит на том же хостинге?
Это лучше, чем ничего, но такая копия не защищает от потери всего аккаунта или сервера. Важный бэкап нужно выгрузить наружу.
Почему после переноса сайт может открываться то на старом, то на новом сервере?
DNS обновляется постепенно. Разные сети могут некоторое время использовать разные закешированные значения, поэтому старую площадку держат доступной на переходный период.
Читайте также:
Вывод
Рабочий бэкап сайта — это комплект для восстановления, а не просто ZIP с public_html. Для динамического проекта нужны файлы, база, конфигурация и понимание серверных настроек; для переноса дополнительно полезно сохранить DNS, PHP и cron. После скачивания обязательно проверьте архив и SQL-дамп и держите копию вне исходного хостинга. CompMaster может подготовить резервную копию, проверить её полноту и выполнить перенос, если на сайте есть заказы, заявки или другие данные, которые нельзя потерять.