Backup проекта, часть 2
Немного ранее, был представлен SHELL скрипт резервного сохранения данных проекта. При наличии нескольких проектов хочется каким-то образом систематизировать этот процесс, для облегчения подключения новых проектов к резервному копированию, кроме как плодить файлы с дублированием кода, учитывая тот факт, что со временем может измениться логика выполняемых действий или настройки подключения к БД/FTP серверу.
Вынесем общую логику в отдельный скрипт, а индивидуальные данные проекта, такие как имя БД и загружаемые файлы в конфигурационный файл для каждого проекта.
Для получения дампа БД, если проекты на сервере используют один сервер, но различные базы удобно создать отдельного пользователя для нашего скрипта и дать ему права на чтение и блокировку таблиц необходимых БД:
GRANT SELECT, LOCK TABLES ON svdev.* TO backup@localhost;
Далее немного модифицируем скрипт из предыдущей части для подключения настроек. Так же проект может не использовать БД или использовать совместно с другим проектом, в этом случае достаточно сохранить её один раз – такая возможность так же реализована. Вот что получилось в итоге:
#Данные для подключения к БД
DBUSER="backup"
DBPASS="dbpassword"
# FTP для сохранения данных
FTPUSER='ftpuser'
FTPHOST='ftphost'
FTPPASS='ftppassword'
# Путь на FTP где хранятся бэкапы, общая директория,
# в которой для каждого проекта есть поддиректория,
# путь от домашней директории пользователя FTP
FTPPATH="./"
# Дата, для именования файла бэкапа в формате YYYY.MM.DD
DT=`date '+%Y.%m.%d'`
# Временная директория для хранения файлов
TEMPDIR="/tmp/backup-"$DT"/"
SQLFILE="dump.sql"
# Файл архива
DESTFILE=$DT".tar"
mkdir $TEMPDIR
cd $TEMPDIR
echo "Начало резервного копирования: "`date '+%F %T'`
# Если все проекты находятся в директории /var/www то для каждого, который
# необходимо сохранить должен быть файл backup.conf
for CONFIG in `find /var/www -mindepth 2 -maxdepth 2 -name backup.conf`
do
. $CONFIG
# Если в конфиге установлено имя БД, до делаем её дамп
# и добавляем в архив
if [ ! -z $DBNAME ]; then
mysqldump --user=$DBUSER --password=$DBPASS $DBNAME > $SQLFILE
TARFILES=$TARFILES" -C "$TEMPDIR" "$SQLFILE
fi
tar -cf $DESTFILE $TARFILES
gzip -9 $DESTFILE
# Отправляем полученный архив на FTP; не забываем
# включить бинарный режим передачи, иначе архивы побъются
ftp -n $FTPHOST <<EOF
quote USER $FTPUSER
quote PASS $FTPPASS
binary
cd $FTPPATH$PROJECTNAME
put $DESTFILE".gz"
quit
EOF
echo " - "`date '+%F %T'`" проект "$PROJECTNAME" сохранен, размер архива "`stat -c %s $DESTFILE'.gz'`" байт;"
# Удаляем за собой все файлы
for TFILE in $TEMPDIR"/*"
do
rm -rf $TFILE
done
done
# Удаляем за собой временную директорию
rm -rf $TEMPDIR
Полученный файл назовем sites-backup и положим его в /etc/cron.daily/ таким образом он будет запускаться один раз в сутки, вместе с остальными служебными скриптами, такими как ротация логов и другие. Для пущей надежности права на файл лучше дать 700 и сделать владельцем рута:
sudo chmod 0700 /etc/cron.daily/sites-backup
Осталось только для каждого проекта создать файл конфига. К примеру для проекта svdev, получаем следующий конфиг /var/www/svdev.ru/backup.conf:
DBNAME="svdev"
PROJECTNAME="svdev.ru"
TARFILES=" -C /var/www/svdev.ru/htdocs wp-config.php -C /var/www/svdev.ru/htdocs/wp-content uploads"
Если БД не используется, то необходимо указать пустую строку в качестве имени БД:
DBNAME=""
PROJECTNAME="svdev.ru"
TARFILES=" -C /var/www/svdev.ru/htdocs wp-config.php -C /var/www/svdev.ru/htdocs/wp-content uploads"
Теперь для создания бэкапов нового проекта необходимо дать права пользователю скрипта на БД, создать на удаленном FTP директорию куда будут складываться архивы и добавить конфиг из 3х строчек.
Главное не забывать вовремя чистить FTP.
Декабрь 23rd, 2009 at 12:09
Чтобы не вспоминать вовремя чистить FTP, можно сделать
DT=`date ‘+%d’` # тогда получится закос под ротацию длиной в месяц
или
DT=`date ‘+%u’` # ротация длиной в неделю
Дату создания бэкапа смотреть в листинге.
Декабрь 23rd, 2009 at 12:19
Это будет следующим шагом – скрипт для чистки FTP.
Данные думаю хранить не просто за последний месяц или неделю, а к примеру:
- по одному за последние 3 дня;
- за последний месяц по одному на неделю;
- за последние полгода по одному на месяц;
Так есть возможность восстановить случайно убитые данные, если сразу не спохватиться. Сталкивался уже с таким.
А если вариант попроще, то да – просто манипулировать с датой в имени бэкапа