Настроить автоматический бэкап linux

Организация backup-сервера. Linux, ZFS и rsync

TL;DR:
Статья о настройке бекапа линуксовых серверов. В качестве хранилища используется раздел ZFS с включенными дедубликацией и компрессией. Ежедневно делаются снапшоты, которые сохраняются в течение недели (7 штук). Ежемесячные снапшоты хранятся в течение года (еще 12 штук). В качестве транспорта выступает rsync: на сервере он запущен демоном, на клиентах он запускается из crontab.

Так получилось, что у меня есть пара серверов, на которых под KVM живут виртуальные машины. Хотелось бекапить образы этих машин в сеть, но так, чтобы выполнялись условия:

• Хранить все бекапы за последнюю неделю.
• Хранить в течении года ежемесячные бекапы.
• Никаких сторонних бекап-агентов. На клиентах только стандартное и проверенное поколениями админов ПО.
• Экономно расходовать место в хранилище. Желательна компрессия и дедубликация данных.
• Все файлы должны быть доступны без дополнительных инструментов и оболочек. Идеальный вариант: каждый бекап в отдельном каталоге.

Можно ли всё это совместить? Да, и очень просто.

Все компьютеры, о которых идет речь в этой статье, являются серверами. Но как-то глупо и длинно делить их на “сервер, который хранит бекапы” и “сервер, бекапы которого хранит сервер, который хранит бекапы”. Поэтому первый я буду называть просто сервером, а второй уже начал называть клиентом.

1. ZFS с компрессией и дедубликацией

Наиболее привычная для меня ОС – Linux. Всё то же самое без особых изменений должно подойти и к Solaris, и к FreeBSD, в которых ZFS есть давно и что называется “из коробки”. Но Linux мне ближе и роднее, а проект по портированию на него ZFS выглядит уже достаточно зрелым. За год экспериментов у меня не было с ним заметных проблем. Поэтому поставил на сервер Debian Wheezy, подключил официальный репозитарий проекта и установил нужные пакеты.

Создал пул, указав что zfs у меня будет на /dev/md1 и что монтировать эту файловую систему я хочу к каталогу /mnt/backup:

По имени устройства /dev/md1 можно заметить, что я использую линуксовый software raid. Да, я знаю, что у ZFS есть свой способ создавать зеркала. Но поскольку на этой машине уже есть одно зеркало (для корневого раздела) и оно сделано штатным mdadm, то и для второго зеркала я предпочту использовать его же.

Включил дедубликацию и компрессию, сделал видимым каталог со снапшотами:

Положил в /usr/local/bin скрипт для создания снапшотов:

Этот скрипт добавил в crontab для ежедневного запуска. Чтобы содержимое снапшота соответствовало его дате, скрипт лучше запускать ближе к концу суток. Например, в 23:55.

Четвертое число месяца выбрано почти случайно. Запускал я всё этого третьего августа и хотелось поскорее сделать бекап, который будет храниться год. Следующий день был четвертым.

Снапшоты будут сохраняться в каталоге /mnt/backup/.zfs/snapshot. Каждый снапшот – отдельный каталог с именем в виде даты на момент создания этого снапшота. Внутри снапшота полная копия каталога /mnt/backup в том виде, в котором он был в этот момент.

2. Rsync на сервере

Традиционно rsync настраивают для работы поверх ssh. На клиентах настраивается авторизация по ключам (и без пароля), а эти ключи складываются на бекап-сервер. Сервер ходит по ssh на клиентов и забирает с них файлы. Преимущество этого подхода – шифрование трафика. Но мне не нравится идея с беспарольным входом по ssh (особенно в свете последних уязвимостей в bash). Так же мне не нравится идея инициировать бекап со стороны сервера: иногда перед бекапом на клиенте хочется выполнить какой-нибудь скрипт (например, сбросить дамп mysql), и только после завершения этого скрипта начинать бекап. Поэтому мой выбор – rsync, запущенный демоном на сервере и запускаемый из crontab на клиентах.

Поставил на сервер rsync (штатный, из репозитария), и чтобы он запускался при старте системы, написал в /etc/default/rsync:

Создал на сервере /etc/rsyncd.conf такого содержания:

192.168.xxx.xxx и 192.168.xxx.yyy – это адреса тех серверов, которые будут бекапиться. Зовут их kvm01 и kvm02. Их файлы будут лежать в /mnt/backup/kvm01 и /mnt/backup/kvm02. Поэтому:

3. Rsync на клиентах

Минимально необходимый скрипт для копирования файлов с клиента kvm02 на сервер с адресом 192.168.xxx.zzz будет выглядеть примерно так:

Разумется, если речь идет о бекапе виртуальных машин, то этот скрипт стоит пополнить командами создания и удаления LVM-снапшота, монтирования и отмонтирования его содержимого и так далее. Но эта тема уже выходит за рамки данной статьи.

4. Восстановление

Для восстановления файлов из бекапа клиента KVM01 за 4 августа 2014 года достаточно будет на сервере перейти в каталог /mnt/backup/.zfs/snapshot/2014-08-04/kvm01/ и скопировать оттуда файлы любым привычным способом. Каждый конкретный бекап выглядит как обычный каталог, доступный только для чтения. Для поиска определенного файла в этом бекапе можно использовать стандартные утилиты, такие как find или grep.

5. Заключение

Сейчас на сервере 9 снапшотов: 7 ежедневных и 2 ежемесячных. Плюс сегодняшний бекап, снапшот с которого снимется вечером. Размер раздела с бекапами составляет 1.8T. Общий объем файлов — 3.06T. Физически занимают на диске они 318G. Суммарный объем сегодняшнего бекапа — 319G. Да, 10 бекапов на ZFS с компрессией и дедубликацией занимают места меньше, чем один бекап занимал бы на файловой системе без этих полезных свойств.

Поскольку сам rsync не занимается шифрованием передаваемых данных, высовывать такую схему без изменений в интернет небезопасно. Добавить шифрование можно, пустив трафик через ipsec или stunnel, например.

Выше я написал, что заметных проблем с ZFS у меня не было. На самом деле, одна проблема была. Однажды ночью, когда оба клиента активно бекапились, сервер дважды сообщил в dmesg, что task rsync blocked for more than 120 seconds. При этом оба бекапа успешно завершились, ничего не зависло, данные не потерялись. Подозреваю, что это проявление знаменитого бага 12309. Разнес бекапы по времени, с тех пор проблема не повторялась.

Источник

Настройка резервного копирования Linux-сервера за 5 минут

Передо мной возникла необходимость настроить резервное копирование на новом Linux-сервере, задачка эта оочень важная, но уж больно скучная: нужно написать и отладить скрипты, которые будут архивировать нужные папки (причем желательно делать инкрементальные архивы), базы данных, хранилища subversion, а затем переносить эти архивы на удаленный сервер. По этому я попробовал нагуглить готовое решение для этой задачки и в результате наткнулся на backup-manager — замечательный опенсорсный набор bash-скриптов, позволяющих:

• архивировать любые папки, в том числе и создавать инкрементальные архивы. В конфиге просто указывается список директорий, которые должны быть скопированы, а также «черный список» файлов, которые копироваться не будут.
• делать резервное копирование баз данных MySQL. В конфиге указываются логин и пароль mysql-юзера, имеющего доступ к базам, а всю остальную работу backup-manager делает сам.
• делать резервное копирование svn-репозиториев, причем бэкап делается не копированием папки с хранилищем, а с помощью команды svnadmin dump.
• шифровать архивы.
• копировать созданные архивы на удаленные сервера по FTP, SSH или (это самая важная для меня фича) в хранилище Amazon S3, а также записывать их на DVD.

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

Скачать можно отсюда: www.backup-manager.org/downloads, либо просто можно установить пакет backup-manager (пример для Debian):

aptitude install backup-manager

Кроме того, нужно учесть, что для копирования данных в хранилище Amazon S3 в системе должны быть установлены пакеты libnet-amazon-s3-perl и libfile-slurp-perl:

aptitude install libnet-amazon-s3-perl libfile-slurp-perl

Теперь остается только настроить запуск backup-manager по крону и можно спать спокойно.

Upd.
Все настройки хранятся в файле /etc/backup-manager.conf, вот основные его параметры:

# Папка, в которой архивы будут складываться локально
export BM_REPOSITORY_ROOT=»/var/archives»

# Используемые методы резервного копирования
export BM_ARCHIVE_METHOD=»tarball-incremental mysql svn»

# Далее для каждого из выбранных выше методов резервного копирования задаем настройки
# Список папок, содержимое которых будем бэкапить
BM_TARBALL_TARGETS[0]=»/etc»
BM_TARBALL_TARGETS[1]=»/boot»
BM_TARBALL_TARGETS[2]=»/var/www»
export BM_TARBALL_TARGETS

# Список исключений, то есть файлов в перечисленных выше папках, которые бэкапить не нужно
export BM_TARBALL_BLACKLIST=»/dev /sys /proc /tmp *imagecache*»

# Теперь указываем как часто делать мастер-бэкап и инкрементный бэкап
export BM_TARBALLINC_MASTERDATETYPE=»weekly»
export BM_TARBALLINC_MASTERDATEVALUE=»1″

# Для бэкапа MySQL баз данных указываем какие базы бэкапить и параметры mysql-юзера
export BM_MYSQL_DATABASES=»__ALL__»
export BM_MYSQL_ADMINLOGIN=»user»
export BM_MYSQL_ADMINPASS=»1234″

# Для бэкапа subversion-репозитория указываем путь к хранилищу
export BM_SVN_REPOSITORIES=»/var/repositories»

# Выбираем метод аплоада созданного бэкапа а удаленный сервер
# (еще есть варианты ftp, ssh, ssh-gpg, rsync)
export BM_UPLOAD_METHOD=»s3″

# Для копирования копий на Amazon S3 задаем имя корзины, access key и secret key
export BM_UPLOAD_S3_DESTINATION=»basket-name»
export BM_UPLOAD_S3_ACCESS_KEY=»ABC123″
export BM_UPLOAD_S3_SECRET_KEY=»DEF456″

Это самые основные настройки, в самом конфиге есть еще пара десятков параметров, все они подробно прокомментированы.

Источник

Настройка резервного копирования в Ubuntu

Для работы над проектами использую svn, который находится на удаленном виртуальном выделенном хосте, под управлением ubuntu 8.04. Со временем объемы данных выросли, как и критичность этих данных. Потеря чего-то снилась в кошмарах. Время от времени копировал репозитории на локальный компьютер. Недавно мне это надоело. И я стал искать возможности автоматизировать это дело. Не буду говорить о поисках и вариантах, расскажу о результатах.

Итак, мы имеем удаленный хост под управлением ubuntu, с некоторым массивом довольно критичных данных. Довольно логичным было бы настроить бэкап прямо на удаленном хосте, с помощью tar по крону, rsyns и т.д. Но, т.к. место на виртуальном выделенном хостинге довольно дорого и использовать его лучше по делу, идеально было бы, чтобы данные автоматически копировались на какую нибудь локальную машину, место на которой хоть отбавляй. В моем случае это файловый сервис в офисе, под управлением все той же Ubuntu.

Подготовка

Данные будем переливать с помощью SSH, поэтому давайте сначала настроим public и private ключи для локального и удаленного серверов. Делаем это для того, чтобы программа, которая будет переливать данные могла заходить по SSH без пароля.

$ ssh-keygen -t dsa

Оставьте папку по-умолчанию, а пароль сделайте пустым.
Эта команда должна создать в папке

/.ssh(по умолчанию) два файла — private и public key. private предназначается для локальной машины, pub отправляется на удаленный.

Теперь копируем private key в папку /root/.ssh, чтобы пользователь root так мог пользоваться им

/.ssh
$ sudo mkdir /root/.ssh
$ sudo cp id_dsa /root/.ssh

Теперь надо скопировать public key на удаленную машину, с которой мы хотим копировать данные. Предварительно создайте пользователя backup на удаленной машине(команда adduser). Не забудьте дать этому пользователю права на чтение каталогов, которые вы хотите копировать.

/.ssh/id_dsa.pub | ssh backup@remotehost.ru «cat >>

Теперь можем попробывать зайти через ssh на удаленную машину:

В случае, если все сделано правильно, нас впустит без пароля.
На удаленной машине ставим нормальные права на чтение публичного ключа:

remotehostru$ chmod 700 .ssh
remotehostru$ chmod 400 .ssh/authorized_keys2
remotehostru$ exit

Настройка rsnapshot

rsnapshot — утилита для создания копий состояния файловых систем на базе rsync. Она упрощает создание периодических копий с локальной и удаленных машин по ssh. Она использует, по возможности, жесткие связи, что позволяет существенно уменьшить объем необходимого дискового пространства. (цитата отсюда)

Установка

$ sudo apt-get install rsnapshot

Если вы используете не debian-подобный дистрибутив, rsnapshot наверняка тоже есть в репозиториях вашего дистрибутива. Для CentOS, при включенных RPMForge это делается, например, так:

# yum install rsnapshot

Теперь нам нужно создать директорию, где мы собираемся хранить наши «снимки»:

$ sudo mkdir /var/snapshots

Настройка

Теперь можно перейти к настройке, собственно, rsnapshot:

$ sudo nano /etc/rsnapshot.conf

Вместо nano вы можете использовать любой другой редактор, например vi, или gedit, если работаете в GNOME.
Настроить нужно следующие параметры:

snapshot_root — директория, в которую вы хотите сохранять «снимки».

interval xxx yy — ххх — название интервала(например hourly, daily), yy — количество снимков для каждого. Например:
interval hourly 6
interval daily 7

Означает, что мы хотим хранить 6 ежечасных копий и 7 ежемесячных. Если уже доступно указанное количество копий, rsnapshot будет заменить старую более новой.

Расскомментируйте cmd_cp. cmd_ssh расскоментируйте и измените на

Настройка бэкапа осуществляется командой backup :

#Добавляем папку /etc/ с локальной машины в папку localhost/
backup /etc/ local/
#Добавляем папку /var/svn с удаленной машины в папку remotehost/
backup backup@remotehost.ru:/var/svn/ remotehost/

Помните, что в конфигурационном файле недопустимы пробелы — используйте только табы.

Пробный запуск

Запустим rsnapshot:
$ rsnapshot hourly

Второй параметр означает интервал, который мы задали в конфигурационном файле.
Команда может выполняется продолжительное время. После выполнения, смотрим, что она создала:
$ ls -l /var/snapshots

Пока что в директории должен быть один каталог: hourly.0. При следующем запуске rsnapshot будет создавать каталоги hourly.1, hourly.2 и т.д., пока не упрется в максимум, указанный нами в конфигурационном файле.

Настройка cron

В Ubuntu автоматически создается файл /etc/cron.d/rsnapshot со следующим содержанием:
0 */4 * * * root /usr/bin/rsnapshot hourly
30 3 * * * root /usr/bin/rsnapshot daily
0 3 * * 1 root /usr/bin/rsnapshot weekly
30 2 1 * * root /usr/bin/rsnapshot monthly

Вот и все. Теперь у вас 6 раз в сутки должен автоматически создаваться снимок данных с вашего удаленного сервера. Данные в сохранности, да еще и географически распределены.

Кстати, 6 раз в сутки не означает, что размер будет в 6 раз больше, чем если копировать всего 1 раз в сутки. Если в промежутки между копированиями не будет изменений в файлах, то общий размер копий почти не изменится.

Дополнительная информация

С помощью параметра backup_script можно также настроить резервное копирование баз данных MySQL, да и вообще всего, чего угодно. Я не описывал сей процесс, т.к. у меня он не используется и ничего конкретного сказать не могу.
Подробнее можно почитать в гугле. По запросу rsnapshot вылезает куча релевантных ссылок, правда на английском языке.

Прошу особо не ругать, на гуру администрирования(да и linux) я не похож, но довольно долго искал, как просто автоматизировать резервное копирование — нашел способ, решил поделиться.
Но конструктивной критике и предложениям буду, конечно, рад.
UPD: Эта же статья в моем блоге

Источник