Данный способ работает и в остальных версиях Xen и даже подпиливается к венценосному CitrixXen.
что имеем — файловая система XEN DomU на LVM
сервер стоечный с двумя Xeon® E5520 (например)
и необходимость бекапа средствами хотя бы отдаленно похожими на автоматические.
Поскольку никто кроме компании phdvirtual.com так ничего не выпустил для автоматизированного бекапа XEN, все бекапят в силу своей изощренности и глубины знаний.
В основном все варианты из гугла сводятся с получению snapshot указанного LVM и сохранение его на диск.
Вообщем-то это практически единственный и самый продуктивный вариант, поcкольку слепок получается без остановки виртуальной машины.
Парк виртуальных машин на моих серверах подбирается к 20 (на небольшой компании), бекап необходим почти для всех, поэтому данные я архивирую. Использую для этого 7zip в мультипроцессорном режиме.
Так же стоит отметить что машины с db и др. требовательными к потере информации сервисами стоит подготовить перед запуском lvm snapshot. Разный взгляд на эту проблему можно найти в каментариях к этой статье ниже :)
Итак команды для бекапа отдельно взятого тома:
первая строчка — получаем слепок lvm c именем 2003-mssql2-b
вторая строчка — с помощью команды dd копируем образ в файл, архивируя через 7 зип использующий все процессоры системы на полную
третья команда удаляет lvm слепок из системы.
Восстановить образ системы можно следующей командой:
А теперь все это нужно автоматизировать и поставить в работу по cron
Разделим эту задачу на два скрипта — первый со списком lvm томов и их размером и удалением образов созданных более чем 128 дней назад, второй с функционалом самого бекапа описанным выше.
Первый файл — backup-lv.sh
Второй файл alt.sh
В итоге в директории /backup/xen/ которая является примонтированным хранилищем NAS, у нас располагаются бекапы за последние 128 дней.
Теперь достаточно задать время выполнения в cron ( в нашем случае каждую субботу)
зыЖ для большей корректности изложения, сменил имя lvm тома с mssql на hdd. Потому как пример действительно был не корректный.
что имеем — файловая система XEN DomU на LVM
сервер стоечный с двумя Xeon® E5520 (например)
и необходимость бекапа средствами хотя бы отдаленно похожими на автоматические.
Поскольку никто кроме компании phdvirtual.com так ничего не выпустил для автоматизированного бекапа XEN, все бекапят в силу своей изощренности и глубины знаний.
В основном все варианты из гугла сводятся с получению snapshot указанного LVM и сохранение его на диск.
Вообщем-то это практически единственный и самый продуктивный вариант, поcкольку слепок получается без остановки виртуальной машины.
Парк виртуальных машин на моих серверах подбирается к 20 (на небольшой компании), бекап необходим почти для всех, поэтому данные я архивирую. Использую для этого 7zip в мультипроцессорном режиме.
Так же стоит отметить что машины с db и др. требовательными к потере информации сервисами стоит подготовить перед запуском lvm snapshot. Разный взгляд на эту проблему можно найти в каментариях к этой статье ниже :)
Итак команды для бекапа отдельно взятого тома:
lvcreate -L20G -s -n 2003-mssql2-b /dev/vg/hdd
dd if=/dev/vg/hdd-b bs=1024000 | 7z a -tbzip2 -mmt=on -si /backup/xen/hdd.tar.bz
lvremove /dev/vg/hdd-b
первая строчка — получаем слепок lvm c именем 2003-mssql2-b
вторая строчка — с помощью команды dd копируем образ в файл, архивируя через 7 зип использующий все процессоры системы на полную
третья команда удаляет lvm слепок из системы.
Восстановить образ системы можно следующей командой:
7z e -tbzip2 -mmt=on -so /backup/xen/hdd.tar.bz | dd of=/dev/vg/hdd bs=1024000
А теперь все это нужно автоматизировать и поставить в работу по cron
Разделим эту задачу на два скрипта — первый со списком lvm томов и их размером и удалением образов созданных более чем 128 дней назад, второй с функционалом самого бекапа описанным выше.
Первый файл — backup-lv.sh
#!/bin/bash
DIR=/root/bin
BACKUP_CMD=alt.sh
BACKUP_ROOT=/backup/xen/
#VG=/dev/vg
LV[0]=atlassian-disk
LV[1]=hdd-disk
LV_SIZE[0]=10
LV_SIZE[1]=10
cd $DIR
COUNT=0
CAT_STR=""
while [ $COUNT -lt ${#LV[@]} ]
do
./$BACKUP_CMD -b ${LV[$COUNT]} -s ${LV_SIZE[$COUNT]}
COUNT=$(( $COUNT+1 ))
done
# delete backups older than 128 days
find $BACKUP_ROOT -type f -mtime +128 -exec rm {} \; 2>/dev/null
Второй файл alt.sh
#!/bin/bash
script=`basename $0`
USAGE="Usage: $script -b <lv_device> -s <lvm_size>"
MAX_TRIES=5
#variables
DATE=`date +%Y%m%d_%H_%M`
VG=/dev/vg
set -- `getopt b:s: $* 2>/dev/null`
if [ $# -eq 1 ]; then
echo $USAGE; exit 1
fi
for opt in $*
do
case "$opt" in
-b) BLOCK_DEVICE=$2; export BLOCK_DEVICE
shift 2;;
-s) SIZE=$2; export SIZE
shift 2;;
--) shift; break;;
esac
done
if [ $# -ne 0 ]; then
echo $USAGE; exit 1
fi
echo $SIZE
echo $VG
echo $BLOCK_DEVICE
echo
#LVM backup process
/sbin/lvcreate -L${SIZE}G -s -n $VG/$BLOCK_DEVICE-snap $VG/$BLOCK_DEVICE
/bin/dd if=$VG/$BLOCK_DEVICE-snap bs=1024000 | 7z a -tbzip2 -mmt=on -si /backup/xen/$BLOCK_DEVICE-$DATE.tar.bz;
/sbin/lvremove $VG/$BLOCK_DEVICE-snap -f
В итоге в директории /backup/xen/ которая является примонтированным хранилищем NAS, у нас располагаются бекапы за последние 128 дней.
Теперь достаточно задать время выполнения в cron ( в нашем случае каждую субботу)
10 23 * * 6 /root/bin/backup-lv.sh &> /root/bin/log.txt
зыЖ для большей корректности изложения, сменил имя lvm тома с mssql на hdd. Потому как пример действительно был не корректный.