Эта статья содержит один из древнейших методов, предложенный NIX Craft в 2006 году. Статья, на мой взгляд, ценна тем, что содержит как бы базовое направление мысли, в котором может следовать начинающий или «случайный» (вынужденный заниматься администрированием баз данных в дополнение к другим задачам) сисадмин.
На мой взгляд, понимание базовых принципов, изложенных в этой статье, сродни пониманию принципов изготовления плова. Можно экспериментировать с пловом в достаточно широких пределах; главное — не разварить рис в клейкую кашу и не сунуть в плов вместо жирного мягкого мяса непонятно что. Точно так же и стратегия бэкапа баз данных MySQL может варьироваться в очень широких пределах, но основы — сочетание полного резервного копирования с инкрементальным, установление периодичности выполнения отдельных задач и контроль за их правильным выполнением — остаются неизменными вне зависимости от используемого инструментария.
Оригинал статьи взят здесь: http://www.cyberciti.biz/tips/how-to-backup-mysql-databases-web-server-files-to-a-ftp-server-automatically.html. Далее идёт сам текст перевода.
* * *
Здесь приводится простое решение для резервного копирования, предназначенное для тех администраторов, которые обслуживают собственные веб-серверы и системы управления базами данных (СУБД) MySQL на выделенных или VPS-серверах. Большинство специализированных хостинг-провайдеров предоставляют пользователю услуги резервного копирования в выделенное сетевое хранилище (NAS) или на сервер FTP. Эти провайдеры привязывают пользователя к своим избыточно функциональным массивам хранения данных через частную виртуальную сеть. Поскольку мне довелось управлять множеством серверных проектов, я готов предложить вместо этого собственное автоматизированное решение. If you just want a shell script, go here (you just need to provided appropriate input and it will generate FTP backup script for you on fly, you can also grab my php script generator code).
Инкрементальный бэкап с помощью утилиты tar
Вы можете создавать резервные копии на магнитной ленте или стриммере (или работать с любым файлом как со стриммером или лентой). Но в наше время это решение утрачивает функциональность. Утилита GNU tar позволяет вам создавать инкрементальные резервные копии с помощью ключевого параметра -g. В нижеследующем примере команда tar создаст инкрементальные копии каталогов /var/www/html, /home, and /etc. Выполните её в консоли:
# tar -g /var/log/tar-incremental.log -zcvf /backup/today.tar.gz /var/www/html /home /etc
Здесь ключ -g создаёт/выводит/извлекает новую (инкрементальную) информацию из резервной копии и помещает её в файл /var/log/tar-incremental.log.
Создание резервных копий баз данных MySQL
Клиентское приложение mysqldump предназначено для дампа или резервного копирования баз данных (БД), таблиц и отдельных данных MySQL. Например, следующая команда покажет список баз данных в конкретной СУБД:
$ mysql -u root -h localhost -p -Bse 'show databases'
Результат вывода (приведён для примера):
brutelog
cake
faqs
mysql
phpads
snews
test
tmp
van
wp
Теперь можно создать резервную копию каждой из БД с помощью команды mysqldump; например, для базы данных faqs команда может иметь следующий вид:
$ mysqldump -u root -h localhost -pmypassword faqs | gzip -9 > faqs-db.sql.gz
Создание простой схемы резервного копирования для вашего проекта
Принципиальное преимущество использования удалённого сетевого хранилища (FTP или NAS) для хранения резервных копий заключается в дополнительной защите от потери данных. Для пересылки резервных копий вы можете использовать несколько протоколов:
- FTP
- SSH
- RSYNC
- Разнообразные коммерческие решения
Я хочу описать здесь только решение, предназначенное для резервного копирования по FTP. Идея стратегии бэкапа, лежащая в основе этого решения, такова:
- Создание полной резервной копии нашей базы данных около полуночи каждого воскресенья (то есть, по воскресеньям воссоздаётся резервная копия всего содержимого СУБД);
- В течение недели резервному копированию подвергаются только изменённые данные (инкрементальное копирование).
- Цикл резервного копирования повторяется каждые 7 дней.
Параметры нашей тестовой конфигурации
Наш сервер ===> ftp/nas server
IP:202.54.1.10 ===> 208.111.2.5
Предположим для теста следующую детальную информацию о нашем аккаунте FTP:
- IP-адрес сервера FTP: 208.111.2.5
- Имя аккаунта FTP: nixcraft
- Пароль к аккаунту FTP: somepassword
- Каталог FTP: /home/nixcraft (или /)
Места, куда мы будем размещать резервные копии:
=> /home/nixcraft/full/dd-mm-yy/files — полные;
=> /home/nixcraft/incremental/dd-mm-yy/files — инкрементальные.
Здесь dd-mm-yy — даты создания резервных копий.
Автоматическое резервное копирование с использованием утилиты tar
Теперь вы знаете, как создавать резервные копии файлов и баз данных MySQL с помощью команд tar и mysqldump. Самое время автоматизировать раз навсегда всю процедуру, связав эти команды в единый скрипт.
- Для начала наш скрипт собирает все данные как с сервера MySQL, так и из файловой системы, во временный каталог под названием /backup. Для этого используется команда tar.
- Далее скрипт подключается к вашему серверу хранения данных через FTP и создаёт структуру каталогов, о которой было рассказано выше.
- Скрипт сбрасывает файлы из каталога /backup на сервер FTP.
- Из каталога /backup убираются врменные файлы.
- Если резервное копирование на FTP по каким-либо причинам прервано или оказывается неуспешным, скрипт уведомляет вас об этом по E-mail.
Для корректного использования скрипта у вас должны быть установлены следующие пакеты (в качестве FTP-клиента используется утилита ncftp):
- ncftp
- mysqldump
- GNU tar
Листинг нашего примера, названного ftpbackup.sh, приведён ниже:
#!/bin/sh
# System + MySQL backup script
# Full backup day — Sun (rest of the day do incremental backup)
# Copyright © 2005-2006 nixCraft <www.cyberciti.biz/fb>
# This script is licensed under GNU GPL version 2.0 or above
# Automatically generated by bash.cyberciti.biz/backup/wizard-ftp-script.php
### System Setup ###
DIRS="/home /etc /var/www"
BACKUP=/tmp/backup.$$
NOW=$(date +"%d-%m-%Y")
INCFILE="/root/tar-inc-backup.dat"
DAY=$(date +"%a")
FULLBACKUP=«Sun»
### MySQL Setup ###
MUSER=«admin»
MPASS=«mysqladminpassword»
MHOST=«localhost»
MYSQL="$(which mysql)"
MYSQLDUMP="$(which mysqldump)"
GZIP="$(which gzip)"
### FTP server Setup ###
FTPD="/home/vivek/incremental"
FTPU=«vivek»
FTPP=«ftppassword»
FTPS=«208.111.11.2»
NCFTP="$(which ncftpput)"
### Other stuff ###
EMAILID=«admin@theos.in»
### Start Backup for file system ###
[! -d $BACKUP ] && mkdir -p $BACKUP ||:
### See if we want to make a full backup ###
if [ "$DAY" == "$FULLBACKUP" ]; then
FTPD="/home/vivek/full"
FILE=«fs-full-$NOW.tar.gz»
tar -zcvf $BACKUP/$FILE $DIRS
else
i=$(date +"%Hh%Mm%Ss")
FILE=«fs-i-$NOW-$i.tar.gz»
tar -g $INCFILE -zcvf $BACKUP/$FILE $DIRS
fi
### Start MySQL Backup ###
# Get all databases name
DBS="$($MYSQL -u $MUSER -h $MHOST -p$MPASS -Bse 'show databases')"
for db in $DBS
do
FILE=$BACKUP/mysql-$db.$NOW-$(date +"%T").gz
$MYSQLDUMP -u $MUSER -h $MHOST -p$MPASS $db | $GZIP -9 > $FILE
done
### Dump backup using FTP ###
#Start FTP backup using ncftp
ncftp -u"$FTPU" -p"$FTPP" $FTPS<<EOF
mkdir $FTPD
mkdir $FTPD/$NOW
cd $FTPD/$NOW
lcd $BACKUP
mput *
quit
EOF
### Find out if ftp backup failed or not ###
if [ "$?" == «0» ]; then
rm -f $BACKUP/*
else
T=/tmp/backup.fail
echo «Date: $(date)»>$T
echo «Hostname: $(hostname)» >>$T
echo «Backup failed» >>$T
mail -s «BACKUP FAILED» "$EMAILID" <$T
rm -f $T
fi
Как установить автоматическое периодическое выполнение скрипта резервного копирования с помощью утилиты cron?
Просто добавьте задачу cron с требуемыми вам параметрами времени и периодичности:
13 0 * * * /home/admin/bin/ftpbackup.sh >/dev/null 2>&1
В качестве небольшого послесловия от переводчика.
Так как задачи бэкапа данных принадлежат к числу наиболее часто беспокоящих системного администратора проблем, то применимость удачного скрипта в этой области, даже без переделок и изменений, может оказаться весьма высокой в течение 5, 10 или 20 лет. В частности, скрипт, похожий на описанный в статье, только сделанный изначально под Windows, работал несколько лет на одном из серверов нашего института, пока мы не заменили его более современной и совершенной программой с GUI.
Понятное дело, что серьёзные администраторы способны создавать такие скрипты самостоятельно, без особых усилий. Я же преследовал цель – показать логику, на которой мы, учёные, вынужденные в силу известных экономических причин работать ещё и с компьютерными базами данных, учились строить задачи взаимодействия с ОС и СУБД на уровне командного языка. Таким пользователям, только осваивающим скрипты и администрирование БД, подобные примеры могут оказаться в высшей степени полезными.
Это соображения, так сказать, идеологического порядка. Чужой скрипт можно довольно точно сравнить с шахматным этюдом, показательно решающим ту или иную задачу. Классические решения, наподобие приведённого, могут стать проверенным во времени полем для самостоятельных экспериментов, показать логику и направление мысли для тех, кто не удовлетворён функциональностью продуктов с GUI и хочет попробовать вызвать к жизни всю мощь пакетных команд. Поэтому для меня здесь важна не столько давность или, наоборот, эффективность предложенного решения, сколько его внутренняя логичность и объяснимость каждого из пунктов. Приняв его за базу, можно легко создать свой собственный «этюд» для другой СУБД или другого диапазона задач; общая логика мышления, заданная один раз, станет в будущем ценным дополнением к арсеналу администратора или разработчика.
Простота понимания, выполнение заявленных базовых условий (о которых говорилось в начале статьи) и небольшие размеры этого скрипта позволяют мне рекомендовать его как базу для различных экспериментов с резервным копированием данных MySQL. Ну, а если этот «этюд» устарел окончательно – что ж, возможно и такое. Будет интересно сравнить его с теми решениями, которые предлагают сейчас для той же задачи современные программисты и системные администраторы. Добро пожаловать в комментарии со своими собственными скриптами, способными заткнуть за пояс вышеописанное изделие.
