Живой бэкап сайта
Традиционный подход к резервному копированию сайта состоит в регулярном копировании на другой сервер дампа базы данных и архива файлов сайта. Недостаток метода в том, что backup выполняется вслепую без проведения теста на возможность его восстановления. В настоящей статье мы предлагаем автоматически восстанавливать backup на резервном сервере с поддержанием рабочей резервной копии сайта.
Предлагаем следующий алгоритм действий:
- Ежедневно в 5 утра, cron на сервере www запускает скрипт ~/backup.pl, который выполняет следующий ряд действий:
- Создает дамп базы и архив каталога htdocs.
- Копирует дамп и архив на backup-сервер.
- Запускает на backup-сервере скрипт ~/store_backup.pl, который выполняет следующие дествия:
- Удаляет каталог htdocs и пересоздает пустую базу данных.
- Разархивирует архив файлов и восстанавливает базу данных из дампа.
- Добавляет информацию в .htaccess для того, чтобы backup-версия была доступна только по паролю.
- Совершает иные действия, требуемые для работоспособности перенесенного сайта.
- Создает каталог с именем, совпадающим с текущей датой и в него переносит новые backup-файлы.
- Удаляет старые backup-файлы (сохраняются последние 20).
В результате живого бэкапа, на резервном сервере всегда будет работоспособная версия сайта. Заказчик сможет проверять, что backup действительно существует и работает и это придаст ему спокойствие и уверенность в качестве услуг. По датам сообщений на сайте будет видно, что резервная копия сделана сегодня в 5 утра.
Пример
В качестве примера рассмотрим бэкап сайта webew.ru.
Пусть у нас есть два сервера: основной (www) и резервный (backup). На каждом сервере настроен apache, на первом на адрес webew.ru, на втором на адрес backup.webew.ru. На каждом сервере есть пользователь webew, база данных webew, а корневой каталог сайта — каталог htdocs в домашнем каталоге пользователя webew. Пусть также пользователь webew@www может подключаться по ssh к серверу backup без пароля (с использованием ключа, если эта тема интересна — напишу отдельную статью). Кроме того, для удобства поместим имя и пароль для доступа к базе данных в файл .my.cnf в домашнем каталоге пользователя на каждом из серверов.
crontab на www:
0 5 * * * ~/backup.pl
Скрипт ~/backup.pl на сервере www (прошу прощения за ломаный перл):
$dbname = 'webew';
print "Start backup.\nmysqldump...";
print `mysqldump -R $dbname > $dbname.sql`;
print "bzip2...";
print `rm $dbname.sql.bz2`;
print `bzip2 $dbname.sql`;
print "done\ntar...";
print `tar cfj $dbname.tbz2 htdocs`;
print "done\nscp...";
print `scp $dbname.tbz2 $dbname.sql.bz2 webew\@backup.webew.ru:`;
print "done\nstore backup...\n";
print `ssh webew\@backup.webew.ru "./store_backup.pl"`;
print "fin";
Скрипт ~/store_backup.pl на сервере backup:
$dirbase = "backup";
$dbname = "webew";
if( (!-f "$dbname.tbz2") || (!-f "$dbname.sql.bz2") ) {
print "No new backup found\n";
exit;
}
print "Start storing backup\n";
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime time;
$mon++;
if($mon<10) { $mon = "0$mon"; }
if($mday<10) { $mday= "0$mday"; }
$year=$year-100;
if($year<10) { $year = "0$year"; }
$dirname = $dirbase . "/" . $year . $mon . $mday;
print `mkdir -p $dirname`;
print "$dirname/ \n";
print "untar...";
print `rm -rf htdocs`;
print `tar xfj $dbname.tbz2`;
print `cat .htaccess.add >> htdocs/.htaccess`;
print "done\nmysql...";
print `echo "DROP DATABASE IF EXISTS $dbname" | mysql test`;
print `echo "CREATE DATABASE $dbname CHARSET UTF8" | mysql test`;
print "cleared...";
print `bunzip2 -c $dbname.sql.bz2 | mysql $dbname`;
print "done\n";
print `mv $dbname.tbz2 $dbname.sql.bz2 $dirname/`;
print "remove old...";
$count = 20; # keep this number of backups
print `LANG=C cd $dirbase && ls -t | awk '{i=i+1;if(i>$count) print \$1}' | xargs rm -rf`;
print "done\n";
print "\nfin\n";
~/.htaccess_add на backup:
AuthName webew
AuthUserFile /home/webew/.htpasswd
require valid-user
Файл ~/.my.cnf на обоих серверах:
user=webewdbuser
password=webewdbpassword
Файл .htpasswd создан shell-командой:
Если вы опасаетесь взлома основного сервера, то процедуру можно обратить: скрипт ./store_backup на backup-сервере будет подключаться к основному серверу, создавать на нем копию данных и копировать ее себе. В таком случае злоумышленник, получивший доступ к основному серверу не сможет получить ssh-доступ к резервному.
Заключение
Живой бэкап позволяет заказчику быть уверенным, что резервная копия действительно есть. Кроме живого бэкапа, не забывайте сохранять копии проектов на локальной машине и на сменных физических носителях.
© Все права на данную статью принадлежат порталу webew.ru. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в печатных изданиях допускается только с разрешения редакции.
