Любое обновление или изменение компонентов сайта на WordPress (ядро, темы, плагины и обновлениями серверных компонентов) может привести к сбою всего сайта. Резервная копия WordPress поможет вам в любой момент восстановить сайт в его былое состояние.
WordPress рекомендует делать резервную копию вашего сайта до того, как вы будете обновлять его компоненты, и есть даже некоторые популярные плагины, которые сделают это за вас. Например, вы можете использовать популярный UpdraftPlus или аналогичный, но я считаю, что в них также есть место для ошибок.
Альтернативой может быть создание собственных сценариев резервного копирования, которые выполняются по расписанию cron. Мы увидим, как это сделать для сайтов WordPress, работающих на Linux-машине.
Создание резервного скрипта
Есть два основных компонента, которые необходимо резервировать в случае сбоя:
- Вам необходимо сделать резервную копию файлов WordPress, которые могут включать в себя плагины, темы и загрузки,
- Данные, которые находятся в вашей базе данных.
Создайте следующий скрипт backup.sh где-нибудь на вашем сервере:
#!/bin/bash
TODAY=`date '+%Y%m%d'`
TEMP_DIR=/home/nraboy/backups/temp
BACKUP_NAME="blog"
DB_NAME="DATABASE_NAME_HERE"
DB_USER="DATABASE_USERNAME_HERE"
DB_PASS="DATABASE_PASSWORD_HERE"
SITE_PATH=/var/www
echo "Starting Backup..."
mkdir $TEMP_DIR
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME > $TEMP_DIR/database.sql
tar --exclude="updraft" -zcf $TEMP_DIR/files.tar.gz $SITE_PATH
tar -zcf $BACKUP_NAME-$TODAY.tar.gz -C $TEMP_DIR .
rm -Rf $TEMP_DIR
echo "Backup Complete [$(du -sh $BACKUP_NAME-$TODAY.tar.gz | awk '{print $1}')]"
Так что же происходит в приведенном выше сценарии?
Сначала мы получаем дату, которая будет использоваться при именовании наших резервных копий. В моем сценарии я никогда не планировал делать больше одной резервной копии в день. Нам также необходимо определить временный каталог, который будет содержать каждый из компонентов резервного копирования.
В следующем разделе мы определим имя резервной копии, которое вы можете использовать для ее идентификации. Конечным результатом будет файл с именем что-то вроде blog-20161230.tar.gz , основанный на том, что у меня есть в сценарии.
SITE_PATH: Должно быть место , где ваш WordPress сайт находится на сервере. Распространенным местом является каталог /var/www. Если вы не уверены, в пути должен быть файл wp-config.php, который содержит информацию о базе данных.
Все до сих пор было инициализацией.
При запуске сценария будет создан временный каталог, а база данных MySQL будет выгружена в файл SQL. Этот дамп содержит структуру таблицы и данные. Как только база данных выгружена, все файлы WordPress архивируются в tar-файл, за исключением каталогов, которые мы определяем. Исключенные каталоги могут быть другими каталогами резервного копирования, каталогами кэша и т. д.
Имея два файла в нашем временном каталоге, мы можем создать из них наш единственный и окончательный архив tar.
Теперь, когда у вас есть сценарий, который будет создавать и связывать резервную копию файла и базы данных, вам необходимо настроить его для запуска по расписанию с помощью crontab .
Выполните crontab e на своем сервере и добавьте следующую строку:
0 2 * * * /path/to/backup.sh
Приведенная выше строка будет выполнять наш скрипт резервного копирования каждый день в 2:00. В результате у вас будет резервная копия в текущем рабочем каталоге, если вы не укажете выходной каталог в нашем скрипте, чего мы не сделали.
Мы могли бы легко сделать что-то подобное в нашем скрипте:
tar -zcf /home/nraboy/$BACKUP_NAME-$TODAY.tar.gz -C $TEMP_DIR .
Если случится что-то плохое и вам нужно восстановить блог WordPress из этой резервной копии, вы можете извлечь файлы и заменить то, что у вас есть, а затем импортировать файл SQL в MySQL. Это полный снимок, а не инкрементная резервная копия.
Заключение
В то время как существует множество бесплатных и платных плагинов для резервного копирования WordPress, иногда требуется старый добрый скрипт Linux, чтобы вы чувствовали себя непринужденно на своем сайте или блоге. Лично я делаю резервные копии только на еженедельной или ежемесячной основе, но ваши потребности могут отличаться от моих. Просто обратите внимание, что, поскольку они не являются инкрементными, они могут занимать немного места на вашем жестком диске.