Этой заметкой я решил подвести логический итог тому что начал в статьях: Как сделать BackUp базы данных MySQL при помощи консоли Linux и
Пакуем «всё нажитое непосильным трудом» в чемоданы. Потому команды описанные в них я снова описывать не буду, а просто ими воспользуюсь. Итак к делу.
В результате автоматизация процесса резервного копирования или просто сохранения сайтов (вместе с их базами данных) на Linux-сервере провайдера, у меня получился вот такой командный файл:
#!/bin/bash
data=$(date +%F)
TarFileName1=./backup/site1.ru.$data.tar.gz
TarFileName2=./backup/site2.ru.$data.tar.gzrm ./backup/* &>/dev/null
#BackUp www.site1.ru
mysqldump -u user_site1_db -pMyPassword site1_db > ./backup/base.site1.ru.$data.sql
tar czf $TarFileName1 site1#BackUp www.site2.ru
mysqldump -u user_site2_db -pMyPassword site2_db > ./backup/base.site2.ru.$data.sql
tar czf $TarFileName2 site2
Немного опишу диспозицию на сервере, чтобы стали понятны некоторые явки/пароли использованные мною в данном командном файле. У меня (в корне моего аккаунта) есть два каталога: site1 и site2 (по доменным именам site1.ru и site2.ru соответственно) в которых лежат движки сайтов со всеми их файлами настроек и прочей «шелухой». Был создан каталок backup (всё так же в корне аккаунта) для складирования файлов получившихся в результате описываемой процедуры. Существуют две базы данных на движке MySQL с именами site1_db и site2_db которые относятся соответственно к site1 и site2. Для доступа к каждой из этих баз данных существует свой пользователь user_site1_db и user_site2_db тоже соответственно. Пользователи имеют один и тот же пароль — MyPassword. Ну вот недостающие детали описал, теперь перейду к разбору самого файла.
В самой первой его строке стоит набор загадочных символов: #!/bin/bash. Это не что иное как объяснение системе, что это командный файл оболочки bash и перенаправление её к интерпретатору этой самой командной оболочки bash. В общем эта загадочная штука обязательна и должна быть написана ровно так (с точностью до символа) и ровно в этом месте (первая строка командного файла).
Идём дальше. А дальше у нас надпись data=$(date +%F). На самом деле тут тоже ничего страшного нет, а эта строка создаёт переменную data и присваивает ей значение текущей даты в формате YYYY-MM-DD, где Y — цифра года, M — цифра месяца, а D — цифра дня (числа). В общем эта переменная содержит дату выполнения данного файла где сначала идёт год, потом месяц и наконец число месяца, и разделены они при помощи знака «-«. Эта переменная потребуется нам в дальнейшем для формирования имён файлов.
Строка TarFileName1=./backup/site1.ru.$data.tar.gz — это не что иное как присвоение переменной TarFileName1 полного пути и имени файла архива в который будет закован один из наших сайтов (в данном случае это site1). Здесь мы уже видим как используется переменная data, о которой я только что рассказал. А знак «$» означает, что идёт обращение к переменной (в данном случае переменной data).
Следующая строка абсолютно аналогична только что описанной, потому не буду на ней заострять внимание.
Далее видим надпись: rm ./backup/* &>/dev/null. Эта загадочная строка означает очистку каталога backup в полностью молчаливом режиме. Команда rm — говорит о том что нужно удалить файлы, путь ./backup/* — говорит «всё содержимое каталога backup», а &>/dev/null — говорит, что весь вывод команды (просто сообщения и сообщения об ошибках) нужно отправить на нулевое устройство, а не на экран и не на почту админа аккаунта. Тут наверное нужно сказать что же такое /dev/null — это некое нулевое устройство, если человеческим языком то это «нигде» и перенаправление вывода на него означает перенаправление вывода «в никуда». Другими словами это приказ команде сделать своё дело, но молча. Можно не употреблять такой конструкции, но тогда вам на почту (как админу аккаунта) будут сыпаться письма содержащие различные сообщения выполнения этой команды. Ничего, поверьте, интересного в них нет, потому я и рекомендую сделать именно так. Если уж интересен весь этот хлам то можете вместо /dev/null написать имя файла и всё это будет сваливаться туда, а потом можно будет посмотреть.
Ну а дальше я думаю всё уже очень узнаваемо из тех двух статей которые я упомянул в начале заметки. Там просто идет сначала сохранения базы данных сайта, потом каталога самого сайта и так для их обоих.
Теперь для завершения автоматизации осталось лишь сохранить созданный скрипт в корень аккаунта и включить его выполнение в планировщик заданий.
Важно: я не зря написал в «корень аккаунта», потому что все файловые пути описанные в статье завязаны на это.
Важно: нужно поставить на данный файл атрибуты «выполнения» иначе он просто не будет запускаться.
В результате работы этого скрипта мы получим каталог backup содержащий резервные копии всех наших сайтов (в описанном мною случае это два сайта: site1.ru и site2.ru). Каждая копия содержит два файла-слепка: базы данных и каталога сайта, которых достаточно чтобы восстановить наш сайт при крахе или другой неприятности, либо развернуть его на другой площадке (в этом случае нужно будет исправить файл настроек и восстановить всё из копии (как это сделать описано в статьях упомянутых выше)). Вот собственно и всё.