В один прекрасный день вам захочется перенести сайт на другой хостинг. Или вы решите регулярно делать резервные копии сайта и хранить их у себя на компьютере. А может быть, вы создадите сайт сами, на своем компьютере, и потом решите перенести его на облачный хостинг, чтобы сайт стал доступен всем. Все эти ситуации крутятся вокруг одной темы — так называемого бэкапа сайта. Давайте подробнее разберем, о чем идет речь.
Что такое резервная копия
Бэкап — это слово хоть и на слуху, но все же не самое очевидное по своему смыслу. В отличие от резервной копии сайта. Здесь можно подробно не объяснять, и так понятно. Бэкап — это и есть резервная копия. Это такой it-сленг. Резервная копия — копия сайта, сделанная в определенное время. Нужна, в первую очередь, для своего спокойствия. Когда знаешь, что она есть, жить становится проще.
Какой бы ни был сайт стабильный, оптимизированный и защищенный, но сделать его копию и положить в укромное место всегда будет кстати. Здорово, если копия и не понадобится, но лучше пусть она будет. На этой оптимистической ноте и начнем основной рассказ.
Как создать бэкап
Есть несколько способов создания копий сайта. Рассмотрим основные.
Автоматическое резервное копирование на хостинге
На большинстве хостингов эта функция подключается автоматически, и раз в сутки (или раз в несколько дней) создается резервная копия вашего сайта.
Здесь надо быть внимательными, потому что на каких-то хостингах одновременно в разделе резервных копий может быть не больше трех-пяти созданных бэкапов. И здесь кроется очень важная деталь. Допустим, на каком-то сайте сегодня случился взлом и заражение. Администратор сайта этого не заметил (по разным причинам). Может, уехал в отпуск далеко-далеко, подальше от Интернета и мобильной связи.
На следующий день на хостинге создается очередная резервная копия (обычно все это делается темной ночью). При этом вновь созданная копия будет уже с зараженными файлами. Проходит еще день, и хостинг автоматически создает новую копию. И если на вашем хостинге можно создать только три бэкапа, то четвертая созданная копия автоматически удалит первую. Чтобы не занимать место, как минимум. А пятая копия потом удалит вторую.
В итоге получим ситуацию, когда все автоматически созданные копии окажутся зараженными. В этой ситуации такой бэкап оказывается практически бесполезным. Конечно, в большинстве случаев можно «вылечить» сайт, удалить все вредоносные скрипты и вернуть сайт в прежнее состояние. Но сколько на это уйдет времени, денег и нервов, сказать трудно.
Автоматическое резервное копирование с помощью плагина
На сайте активируется плагин, который по заданному расписанию делает копию сайта и сохраняет ее на вашем облачном диске. Количество бэкапов в этом случае зависит от объема вашего диска. Если размер вашего сайта в архиве будет 100 мегабайт, это одно. А если ваш сайт большой и его архив будет весить уже 1 гигабайт, то это совсем другое дело. Нужно учитывать этот момент. Таких плагинов в каталоге WordPress достаточно, по ним можно сделать отдельный обзор.
Создание резервных копий вручную
Скачиваем и активируем плагин Duplicator. Он бесплатный, регулярно обновляется, совместим с последней на сегодня версией WordPress 5.8, и у него более 1 миллиона активных установок.
Вообще, изначально (и это видно из названия) плагин ориентирован на перенос сайта. А функция бэкапа вторична. Но только в названии. В функционале все очень хорошо, удобно и понятно. Поэтому давайте посмотрим, как работать с плагином.
Обзор плагина Duplicator
После активации в консоли сайта появится новый пункт Duplicator. Внутри него будет подпункт «Пакеты», куда и заходим. Настройки плагина можно не трогать, все и так работает замечательно.
Пакет в данном случае и есть каждый созданный бэкап. Каждый пакет будет включать в себя всего два файла. Это сам архив сайта, включая базу данных, и установочный файл, чтобы в новом месте запустить распаковку и установку сайта.
Нажимаем «Создать новый». В этом окне можно изменить имя пакета, если хотите. В другие подпункты можно не заходить.
Жмем «Далее», и в новом окне появляются результаты сканирования.
Здесь смотрим на размер файлов самого сайта и размер базы данных. Если ваш сайт будет совсем уж неподъемным, плагин вас об этом предупредит. Тогда нужно будет раскрыть строку «Проверки размеров» и настроить там фильтры.
Например, исключить из создания резервной копии папку /wp-content/uploads — ведь именно она и будет самой тяжелой. В ней хранятся все загруженные картинки, документы и другие файлы. Тогда нужно зайти на хостинг и вручную скопировать эту папку себе на компьютер.
Когда здесь все готово, внизу ставим галочку для продолжения и внизу нажимаем «Создание». Начнется процесс архивации, после которого появится новое окно. В идеале оно будет таким:
Скачиваем оба файла: установщик и архив. Это все, теперь на вашем компьютере есть резервная копия вашего сайта. Такие пакеты можете создавать хоть каждый день. Или раз в месяц. Или перед большим обновлением сайта. А может, после создания нового раздела и загрузки на сайт важной информации. Как видите, поводов много и все они разные. Ведь и сайты у всех разные. Выбирайте под свой случай.
Восстановление сайта из пакета
Теперь обратная ситуация: нужно восстановить сайт из резервной копии, а именно — из пакета. Будет чуть сложнее, так что морально подготовьтесь, глубоко вдохните и поехали. Исходим из ситуации, когда вам нужно восстановить сайт из архива на вашем действующем хостинге. Это вполне может быть ситуация, когда восстановить сайт быстрее, чем лечить его от вирусов или исправлять какую-то ошибку.
Заходим в папку сайта, затем в папку public_html (или www). Сейчас нам нужно узнать данные для подключения к базе данных. Для этого открываем файл wp-config.php и находим там эти строки:
Находим и копируем все, что в скобках, — DB_NAME, DB_USER (обычно совпадает с предыдущим пунктом), DB_PASSWORD. Также обращаем внимание, что написано в DB_HOST. Бывает, что там вместо localhost указан IP-адрес. Если так, то копируем и этот адрес.
Теперь удаляем все внутри папки public_html и загружаем сюда те два файла пакета, которые недавно создал Duplicator — архив сайта и installer.php. Полпути позади, сверимся. На этом этапе ваш сайт (прежняя его версия) уже не открывается, выдается просто белый экран с ошибкой. Если так, то все нормально, идем дальше.
Теперь в адресной строке пишем адрес сайта вот в таком формате: www.your-site.ru/installer.php. То есть в конце добавляем путь к файлу установки, который запустит процесс распаковки. После этого откроется такое окно:
Ставим галочку и нажимаем кнопку Next. Второй шаг — это подключение к базе данных. Выглядит это так:
Здесь заполняем строки по очереди:
- в поле хоста оставляем localhost или меняем на IP-адрес, который мы взяли в файле wp-config.php;
- где Database — вставляем имя базы данных (DB_NAME из предыдущего шага);
- где User — данные из строки DB_USER;
- пароль берем из DB_PASSWORD.
Как заполнили эти строки, нажимаем внизу зеленую кнопку Test Database. На скриншоте она уже неактивная, потом что я ее уже нажал. Этой кнопкой плагин проверяет подключение к базе данных, и если все хорошо, то активируется кнопка Next. Ее и нажимаем и во всплывающем окне подтверждаем запуск установщика.
Третий шаг — обновление данных сайта.
Здесь главное, все проверить, можно ничего не менять. Идем дальше, Next. И финальный шаг — все готово и можно зайти в консоль.
Здесь ничего не трогаем и сразу нажимаем кнопку Admin Login, которая переведет вас на страницу авторизации. Это все, вы получаете новый значок опыта и +100 к уверенности. Здесь я описал идеальную ситуацию переноса, когда значки горят зеленым и все хорошо. Бывают и другие случаи, но они сугубо индивидуальны и каждый нужно рассматривать отдельно.
Что в итоге
А в итоге у вас теперь есть схема, по которой можно архивировать сайт вручную и при случае восстанавливать его. А это уже независимость вашего сайта от хостинга и его методов резервного копирования. По такой схеме можно раз в месяц делать копию сайта и хранить у себя. И пусть она вам лучше не понадобится. А уж если понадобится, она у вас будет.