Hetzner - DokuWiki

Backup2l/ru

Inhaltsverzeichnis

Предисловие

Данное решение, вероятно, не является наилучшим, поэтому сотрудничество в улучшении приветствуется  :)
Я заявляю, что не несу никакой ответственности за возможный причинённый вред! Лучшее, что можно сделать, это хорошо понять изложенные факты! Данная инструкция не привязана к определённому дистрибутиву. У меня работает Debian 3.1. Адоптация данной инструкции к другим дистрибутивам должна быть возможной.

Инструкция

Установка backup2l

Пакет входит в большинство дистрибутивов, а также доступен на http://backup2l.sourceforge.net

В Debian устанавливается с помощью

$> apt-get install backup2l

Читайте документацию

Не пугайтесь, документация не очень длинная, но очень важно её прочитать, чтобы понимать работу утилиты и научиться выполнять восстановление. Документация открывается с помощью команды man.

$> man backup2l

Настройка backup2l

Теперь нам нужно применить знания, добытые по инструкции во втором шаге для настройки утилиты backup2l. Итак, мы открываем /etc/backup2l, конфигурационный файл утилиты. Открыть его можно, например, с помощью pico:

$> pico /etc/backup2l.conf

Здесь мы убеждаемся в полезности шага 2, в том, что если его пропустить, то параметры, указываемые в конфигурационном файле, могут быть непонятны. Все параметры также хорошо прокомментированы в самом конфигурационном файле, и опытный пользователь должен знать, что с ними делать дальше в текстовом редакторе. Однако, укажу некоторые указанные мной параметры, а также причины, по которым я их выбрал:

SRCLIST=(/etc /root /home /var/backup.d/premilinary /var/www/domains)

Я делаю резервное копирование файлов настройки из /etc, пользовательских файлов из /home и /root. Более того, я делаю копию директории /var/backup.d/preliminary. В ней я храню «горячие» копии баз данных MySQL и PostgreSQL, а также репозитории SVN. Ниже мы увидим, как это настраивается.

SKIPCOND=(-path "/var/www/domains/*/logs/*")

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

BACKUP_DIR="/var/backup.d/final"

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

MAX_LEVEL=1
MAX_PER_LEVEL=9
MAX_FULL=1
GENERATIONS=1
CREATE_CHECK_FILE=1

Эти настройки подходят мне. Таким образом, я всегда имею полную резервную копию и девять инкрементных резервных копий. Если следующее инкрементное копирование должно быть сделано на следующей неделе, то max_per_level следует задать значение 6. Полная резервная копия и, затем, инкрементные копии, всегда необходимы для восстановления.

PRE_BACKUP ()
{
  echo "start pre backup scripts"

  cd /root/backup

  sh hotcopy-mysql.sh
  sh hotcopy-svn.sh
  sh hotcopy-cyrus.sh
  sh hotcopy-postfix.sh
  sh hotcopy-postgresql.sh

  sh dump-dpkg-selections.sh

  chmod -R u=rw,go-rwx /var/backup.d/preliminary/*

  echo "pre backup scripts completed"

}
POST_BACKUP ()
{
  echo "Executing post backup actions."

  cd /root/backup
  chown -R root:backup /var/backup.d/final
  chmod -R u=rw,g=r /var/backup.d/final/*

  echo "The backup has been completed."
  echo "----------------------------------------------"

  sh sendemail.sh
}

Эти команды выполняются перед и/или после выполнения резервного копирования. Ниже мы рассмотрим их подробнее.

Наконец, немаловажно, на данном шаге мы настраиваем директорию /var/backup.d/final, куда будет выполняться резервное копирование.

Создание «горячих» копий

Некоторые файлы просто невозможно скопировать, так как они постоянно используются. Такими файлами являются файлы репозиториев систем контроля версий, баз данных MySQL и PostgreSQL, директории Cyrus IMAP и каталог очередей почтового сервера Postfix в /var/spool/. С такими файлами необходимо разобраться отдельно.

Нам нужно либо использовать доступные инструменты для создания так называемых «горячих» копий - копий данных, сделанных на ходу, с работающей программы, либо нам нужно использовать кое-какие хитрости. Так как необходимы нам для этого команды не очень тривиальны, и мы не желаем перегружать ими конфигурационный файл, мы переносим отдельные шаги в shell-скрипты и сохраняем их в директории /root/backup.

Давайте коротко взглянем на эти скрипты.

Горячие копии MySQL

Здесь мы просто используем утилиту mysqldump для создания резервных копий наших баз данных MySQL.

#!/bin/sh

# Этот скрипт создаёт горячую копию файлов mysql.
echo "creating mysql dump"

echo "   removing old dumps and creating directory"
mkdir -p /var/backup.d/preliminary/mysql
rm /var/backup.d/preliminary/mysql/all.dump

echo "   executing mysqldump"
mysqldump -A --add-locks -u root --password=miro4711 > /var/backup.d/preliminary/mysql/all.dump

echo "mysql dump created"

Горячие копии PostgreSQL

Здесь мы также используем утилиту, входящую в пакет сервера баз данных: pg_dumpall. Выполняем pg_dumpall от имени пользователя postgres, так как это даёт нам полный доступ ко всем стандартно установленным базам данных, в то время, как это невозможно сделать от имени пользователя root.

#!/bin/sh

USER=postgres
COMMAND="pg_dumpall --clean --column-inserts"
TARGET_DIR=/var/backup.d/preliminary/postgres
TARGET_FILE=pg_dumpall.sql

echo "creating PostgreSQL backup"

if [ ! -d $TARGET_DIR ]
  echo "  create $TARGET_DIR"
  then mkdir $TARGET_DIR
fi

echo "  executing pg_dumpall"
sudo -u postgres pg_dumpall > ${TARGET_DIR}/${TARGET_FILE}

Горячие копии систем контроля версий

Системы контроля версий также имеют программу для создания резервных копий. Мы вызываем svnadmin с помощью команды hotcopy.

#!/bin/sh

# Этот скрипт создаёт горячую копию всех репозиториев SVN в директории
# /var/svn.

echo "creating Subversion repository hotcopies"

echo "   removing old subversion hotcopies"
rm -rf /var/backup.d/preliminary/svn
mkdir -p /var/backup.d/preliminary/svn

pushd /var/svn > /dev/null

for repository in `ls`
do
  if [ -d $repository ]
  then
    echo "   creating hotcopy of ${repository}"
    svnadmin hotcopy $repository "/var/backup.d/preliminary/svn/${repository}"
  fi
done

popd > /dev/null

Резервные копии Cyrus

Насколько мне известно, у Cyrus нет инструмента для создания копий. Разработчики Cyrus рекомендуют выполнять резервное копирование на уровне файйловой системы, с помощью LVM илиrsync. Мы воспользуемся вторым вариантом. Сначала сделаем копии данных Cyrus с помощью rsync. Затем мы останавливаем сервер и копируем данные вновь, с помощью rsync. rsync копирует только изменения в файлах. Затем мы запускаем сервер вновь. Это сокращает время недоступности сервера.

#!/bin/sh

# Этот скрипт создаёт горячую копию файлов данных cyrus.

# Мы используем фокус, заимствованный с cyrus wiki. Сначала, используем rsync 
# для копирования каталога очередей (spool) и баз данных cyrus в директорию 
# предварительных резервных копий. Затем мы оставливаем cyrus, делаем rsync 
# ещё раз и запускаем cyrus вновь. Таким образом мы сокращаем недоступность 
# сервера cyrus до минимума.

echo "creating Cyrus backup"

echo "   creating directories"
rm -rf /var/backup.d/preliminary/cyrus
rm -rf /var/backup.d/preliminary/sieve
mkdir -p /var/backup.d/preliminary/cyrus/lib
mkdir -p /var/backup.d/preliminary/cyrus/spool
mkdir -p /var/backup.d/preliminary/sieve/spool

echo "   first rsync pass"

rsync -r /var/lib/cyrus /var/backup.d/preliminary/cyrus/lib
rsync -r /var/spool/cyrus /var/backup.d/preliminary/cyrus/spool
rsync -r /var/spool/sieve /var/backup.d/preliminary/sieve/spool

echo "   halting cyrus"
/etc/init.d/cyrus21 stop

echo "   second rsync pass"
rsync -r /var/lib/cyrus /var/backup.d/preliminary/cyrus/lib
rsync -r /var/spool/cyrus /var/backup.d/preliminary/cyrus/spool
rsync -r /var/spool/sieve /var/backup.d/preliminary/sieve/spool

echo "   starting cyrus again"
/etc/init.d/cyrus21 start

Резервные копии Postfix

Здесь мы используем фокус, похожий на то, что мы делаем с файлами Cyrus.

#!/bin/sh

# Используем тот же фокус, что и с cyrus: rsync, shutdown, снова rsync и
# надеемся, что резервное копирование получилось.

echo "creating Postfix backup"

echo "   creating backup directories"
rm -rf /var/backup.d/preliminary/postfix
mkdir -p /var/backup.d/preliminary/postfix

echo "   first rsync pass"
rsync /var/spool/postfix /var/backup.d/preliminary/postfix

#echo "   stop postfix"
postfix stop

#echo "   second rsync pass"
rsync /var/spool/postfix /var/backup.d/preliminary/postfix

#echo "   start postfix again"
postfix start

Настройка Cronjob

Настраиваем cronjob. Для этого мы создаём файл /etc/cron.daily/zz-backup2l со следующим содержимым (файл может уже и существовать в результате установки backup2l).

#!/bin/bash

# Следующая команда вызывает 'backup2l' с конфигурации по умолчанию
# файл (/etc/backup2l.conf).
#
# Удалите его, или весь этот скрипт в случае, если вам не нужно автоматическое 
# создание резервных копий.
#
# Перенаправьте вывод, если вы не хотите автоматической отправки e-mail после 
# каждого выполнения резервирования.

! which backup2l > /dev/null || nice -n 19 backup2l -b

Передача файлов

Вообще, существуют два варианта передачи файлов на сервер резервного копирования (при возможности, на сервер с RAID, такой, как один из серверов резервного копирования от Hetzner). Первый и самый очевидный вариант заключается в копировании с сервера на котором сделаны копии на целевой сервер (сервер хранения резервных копий): 'Push Data. Это можно сделать с помощью, например, утилиты scp. Второй вариант, с сервера хранения резервных копий сделать с помощью scp: Pull Data. На мой взгляд, второй вариант предпочтительней, так как серверы хранения резервных копий хорошо защищены.

Для обоих вариантов я рекомендую использование scp, так как сервер хранения резервных копий скорее всего имеет SSH доступ, а производительность утилиты вполне позволяет одно копирование за вечер. Более того, передача данных шифруется. Также можно использовать FTP-клиент (как ncftp) или rsync.

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

Push Data

Здесь кратко опишем наш подход: создать SSH ключ и прописать его на сервере резервного копирования в файл ~/.ssh/authorized_keys. Затем удалить закрытый ключ на сервере:

$> ssh-keygen -t rsa
# Прописать ~/.ssh/id_rsa.pub на сервере
# в файл ~/.ssh/authorized_keys
# Удалить закрытый ключ - он нам больше не нужен.
$> rm ~/.ssh/id_rsa

Затем мы создаём небольшой скрипт в /root/backup и вызываем его в POST_BACKUP() (v.s.). Следующее должно довольно хорошо работать:

#!/bin/bash

SOURCE_DIRECTORY=/var/backup.d/final
TARGET_USER=backup_user
TARGET_DIRECTORY=/home/user/backup
TARGET_SERVER=backupXYZ.your-server.de

scp ${SOURCE_DIRECTORY}/* ${TARGET_USER}@${TARGET_SERVER}:${TARGET_DIRECTORY}

Альтернативы Backup2l

В качестве альтернативы, также рекомендуется rdiff-backup.

Утилита умеет почти всё то, что и backup2l, но обладает улучшеным алгоритмом rsync и более гибким, чем в backup2l, управлением жизненного цикла.

За подробной информацией обращайтесь на страницы:



© 2018. Hetzner Online GmbH. Alle Rechte vorbehalten.