Автоматический бекап сайта по SSH
2015-12-10 08:12:47

   Не стоит пугаться: большинство современных хостингов имеют поддержку доступа на сервер по SSH. Хоть за классику и принято полагать FTP в этом вопросе, я сейчас объясню чем SSH удобнее.

   Для начала, определимся с вводными: у тебя есть свой сайт и доступ к хостингу по SSH (посмотри в панели управления хостингом, если даже его и нет, то, как правило, можно включить). У меня авторизация проходит по RSA-ключу, без пароля, что удобно, но можно и с паролем сделать — никаких проблем в этом нет.

   Почему неудобен FTP? Ну, во-первых, он медленный. Реально, очень медленный. Дело в том, что FTP относится к семейству древних текстовых протоколов, они хороши тем, что их поддерживает каждый утюг в современном мире, но из-за текстовой их природы страдает скорость. Как правило, сегодня всегда есть бинарная альтернатива текстовым протоколам и она завсегда быстрее. А во-вторых?

   А, во-вторых, бекап сайта — это не только ценный мех бекап файлов, но и бекап базы данных. А как по FTP забекапить базу данных сайта? Напрямую — никак. Поэтому я, покумекав, решил что стоит создать скриптик, который на стороне сервера сначала сделает дамп БД в файл, а затем все это добро заархивирует вместе с остальными файлами сайта. В идеале, этот же скриптик мог бы сам скопировать бекап куда-нибудь на удаленный сервер, но тут есть небольшая проблемка: не у каждого есть собственный сервер, доступный из глобального интернета (хотя у меня есть :-р и я, даже, научу и тебя как и зачем заиметь такой практически нахаляву).

   Так вот, если у тебя личного сервера нет, то можно обойтись и без него, просто разделив задачу на клиентскую и серверную часть. Модель видится такая: с некоторой периодичностью на клиентской машине (скажем, домашний ПК) запускается скрипт-клиент, он по SSH заходит на сервер и дергает серверный скрипт, на предмет создать архив с базой данных и файлами, серверный скрипт такой архив создает, а клиентский по SSH же забирает его на клиентскую машину. Это, если в двух словах. Теперь, посмотрим мою реализацию и послушаем пару моих советов по оптимизации

   Серверная часть:

#!/bin/sh

   # скрипт для выполнения резервного копирования сайта jmule.ru

   # адрес каталога для бекапа BACKUP_DIR=~/jmuleru/www

   # реквизиты для доступа к БД DB_HOST=XXXXXXXXX DB_NAME=XXXXXXXXX DB_USER=XXXXXXXXX DB_PASSWORD=XXXXXXXXX

   #####################################################

   # проверим, существует ли сегодняшний бекап DATE=`date +%d-%m-%Y` if [ ! -f $BACKUP_DIR/backup.$DATE.tar.gz ] then # файла бекапа не существует — создадим новый # а перед этим удалим все старые rm -f $BACKUP_DIR/*.tar.gz # построим дамп БД mysqldump -u $DB_USER -p$DB_PASSWORD $DB_NAME -h $DB_HOST > $BACKUP_DIR/db_backup.sql

    # теперь все заорхивируем вместе с дампом базы tar -zcvf $BACKUP_DIR/backup.$DATE.tar.gz $BACKUP_DIR fi

   Разберем сей скрипт по полочкам:

   Первая часть, до строки с решеточками, это, понятно, часть в которой определяются переменные, специфичные для хостинга, затем, алгоритм следующий: проверяем, существует ли архив, подписанный сегодняшней датой, и, если да, то завершаем выполнение скрипта, ибо, сегодня бекап уже делали, а делать его несколько раз за день — значит понапрасну грузить сервер. Ведь единственная задача серверной части скрипта — создать архив, содержащий дамп БД и все файлы сайта.

   Ежели так случилось, что сегодня архив еще не делали — нужно сделать, не забыв при этом удалить вчерашний, чтоб зря не засорял тут нам хостинг. Создание сегодняшнего архива состоит из двух частей — дампа базы данных (с перезаписью вчерашнего файла с дампом) и архивированием всех файлов сайта, включая файл дампа БД. Все: как видишь, серверная часть системы бекапа — очень простая, однако в результате мы получаем файл, который содержит все необходимое, чтоб воссоздать сайт, в случае чего.

   Теперь дело за малым: нужно этот файл уволочь с сервера и спрятать в надежном месте. Тут на сцену выходит вторая часть системы бекапа сайта — клиентская.

   

#!/bin/sh

   # скрипт для выполнения резервного копирования сайта jmule.ru # на клиентской стороне

   # для установки # crontab 0 * * * * /var/www/html/tools/backup_site_client_side.sh

   # адрес каталога для бекапа BACKUP_DIR=~/jmuleru_backups

   # реквизиты для доступа к хостингу SSH_USER=XXXXXXXXX SSH_HOST=XXXXXXXXX SSH_PORT=XXXXXXXXX SITE_PATH=XXXXXXXXX

   #####################################################

   # проверим существует ли папочка для бекапов if [ ! -d $BACKUP_DIR ] then mkdir $BACKUP_DIR fi

   # теперь проверим есть ли там сегодняшний бекап DATE=`date +%d-%m-%Y`

   if [ ! -f $BACKUP_DIR/jmuleru_backup.$DATE.tar.gz ] then # сегодня бекап еще не делали — делаем # сперва удаленно запустим скрипт, который забекпит базу и создаст архив # со всеми файлами сайта, в случае, если сегодня такого не делали ssh -p $SSH_PORT $SSH_USER@$SSH_HOST $SITE_PATH/tools/backup_site.sh # скопируем полученный бекап к себе scp -P $SSH_PORT $SSH_USER@$SSH_HOST:$SITE_PATH/backup.$DATE.tar.gz $BACKUP_DIR/jmuleru_backup.$DATE.tar.gz # и удалим очень старые бекапы find $BACKUP_DIR/ -type f -mtime +30 -exec rm -f {} \; fi

   Сей скрипт мы тоже последовательно разберем. В первой части, как водится, настройки. Далее, снова как водится же, проверка, а не делали ли мы сегодня бекап раньше? Ну, то есть, если сегодня бекап уже делали — то сразу отбой и не гоношимся.

   Если же выясняется что сегодня еще есть работа, тогда дергаем по SSH серверную часть системы, на предмет создать нам файлик с бекапом для копирования. Серверная часть нам его либо создает, либо он уже там сегодня был сделан, в любом случае, нужный нам файл оказывается на своем месте. Мы его оттуда дергаем с помощью SCP и кладем у себя, подписывая нужной датой и, напоследок, удаляем самые старые бекапы, из тех, что хранятся локально. В этом случае те, что старше 30 дней. Всегда нужно так далать, ибо, если так не далать, то периодический скрипт, рано или поздно заполнит все свободное пространство в любой системе.

   Все. Осталось только организовать периодическое выполнение клиентской части системы на любом компьютере, который имеет доступ в интернет и умеет выполнять bash-скрипты. А это почти любая linux-машина и даже windows-машина подойдет, если ее доработать напильником.

   Преимущество предложенной мной системы в том, что клиентских машин может быть любое количество и сколько бы их не было, это почти никак не отразится на производительности хостинга потому что, во-первых, резервное копирование сайта на хостинге выполняется в любом случае один раз в сутки, а каждая из клиентских машин будет запрашивать бекап не более одного раза в сутки.

   От така система. Всем пинга.

Эта статья является частью цикла статей Unix Way
  • ВасяПупкин 2016-10-19 01:03:06
    Круто! Спасибо!!!
  • bo 2016-10-27 10:09:53
    Пожалуйста. Приятно, что кому-то пригодилось.
Чтоб доказать что Вы не робот причините вред человеку или своим бездействием допустите, чтоб ему был причинен вред решите сложнейший пример:
8 + 2 =
Регистрация