Резервное копирование линукс серверов

Настройка резервного копирования 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″

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

Источник

Организация 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 сервера

Резервное копирование Linux сервера

Введение

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

Из статьи вы узнаете как я подхожу к этому вопросу и защищаю бэкапы всех своих ресурсов надежно и безопасно в системах Linux.

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

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

Основа безопасности бэкапов

Правильность и безопасность бэкапов включает в себя несколько простых правил:

1. Хранение бэкапов за продолжительный период времени. Вариантов почему лучше хранить бэкапы долго множество. Например, удалили какой то материал, но решили восстановить спустя некоторое время или необходимо найти ошибку когда появилась проблема которую обнаружили не сразу.
2. Забарать бэкапы сторонним сервером. В идеале лучше использовать под резервные копии специальный сервер использующийся только для бэкапов. В случае если копии бэкапов отправляются с самого сервера где делаются бэкапы это опасно, так как в случае взлома или вируса вы можете потерять все копии.
3. Мониторинг как создание бэкапа так и аналитика его размеров. Как бы вы не пытались отслеживать периодически сами как делаются бэкапы по закону подлости, когда они потребуются, обнаружите что они или не делаются или испорчены.

Ниже я по порядку опишу все свои действия которые использую на практике. Будут использованы стандартные программы используемые во всех версиях Linux.

Создание бэкапов на сервере

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

Структура папок для бэкапов

Создавать папки можно где угодно. Например, мне больше нравится создавать их в корне папку backup и держать там всё что связанно с резервными копиями.

Создадим необходимые папки куда будем класть бэкапы

В итоге мы получили следующие папки:

• /backup — папка где будет находиться всё что связано с резервными копиями;
• /backup/bin — папка где будут находиться скрипты запускаемые по расписанию;
• /backup/infoit.com.ua/day — папка где будут лежать ежедневные бэкапы;
• /backup/infoit.com.ua/month — папка где будут лежать ежемесячные бэкапы;
• /backup/infoit.com.ua/source — папка в которой я храню копии которые были начальными. Например, в случае когда ресурс переносится с другого сервера или возвращается в жизнь после продолжительного перерыва в работе.

Backup и его периодичность

Всегда сложно выбрать какой необходим период хранения и интервал резервного копирования. Для меня удобней организовать резервное копирование по следующей схеме:

• Дневные копии — хранить 30 дней,
• Месячные копии — хранить год.

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

Создание скриптов для бэкапов

Создадим два скрипта для ежедневного и ежемесячного бэкапа.

Создадим скрипт который будем ежедневно запускать по расписанию:

Для ежемесячных бэкапов создадим такой скрипт:

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

После создания скриптов сделаем их исполнительными выполнив необходимую команду:

Добавление заданий в cron

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

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

В случае если создается резервная копия для разных ресурсов выставляйте время с учетом времини которое необходимо для создания бэкапа.

Открываем необходимый файл и добавляем нужный код:

Согласно команде каждый день в 1:20 бедет выполнятся скрипт для создания ежедневного бэкапа и ежемесячно первого числа в 1:25 будет создаваться ежемесячная резервная копия.

Перезагрузим cron в системе CentOS для применения изменений:

Проверка создания бэкапов

Убедится что все работает правильно можно только запустив скрипт у посмотреть результат его работы.

Мне больше нравится брать код непосредственно из файла crontab, так как это последнее место которое выявит ошибки связаные с правильностью написания пути к скрипту.

Из вывода видно какие файлы забекапились и что база данных тоже успешно зарезервиловалась.

Осталось дождаться времени выполнения и проверить как отрабатывает команду cron.

Посмотреть результат работы cron можно заглянув в файл:

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

Создание копии backups используя rsync

В моем случае под всевозможные бэкапы используется специальный сервер настроенный только для бэкапов.

Подключается к серверу с которого надо забирать бэкапы будем по сертификату. Для копирования будем использовать утилиту rsync.

Именно на этом сервере производится мониторинг правильности создания бэкапов и их размеры средствами программы для мониторинга Zabbix.

Узнать как работать со свободным программным комплексом для мониторинга вы можете из раздела Мониторинг Zabbix.

Возможности Zabbix удовлетворят любые потребности для осуществления любых параметров практически любой системы.

Подключение по сертификату

Более подробно о том как настраивать механизм подключения по сертификаты можете найти в статье RSA или авторизация SSH по ключу.

Скопируем на подключаемый ресурс необходимую часть ключа:

После успешного выполнения пробуем подключиться:

В случае успеха идём дальше.

Для безопасности можно создать пользователя на ресурсе откуда забираете данные и ограничить его только в папке откуда забираем резервные копии.

Создание скрипта для выполнения rsync

Создадим необходимый скрипт:

Скрипт задокументирован и выберите параметры исходя из ваших требований.

Расшифрую параметры указанные в коде:

• a — режиме архива;
• v — увеличение детализации;
• z — сжатие данных файла во время передачи;
• h — вывод чисел в удобочитаемом формате;
• e — используем ssh подключение.

После создания скриптов сделаем их исполнительными выполнив необходимую команду:

Добавление задания в cron

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

В случае если создается резервная копия для разных ресурсов выставляйте время с учетом времени которое необходимо для создания бэкапа.

Открываем необходимый файл и добавляем нужный код:

Согласно команде каждый день в 6:30 бедет выполнятся скрипт который будет забирать резервные копии согласно вашим пожеланиям.

Дальнейшие проверки аналогичны действиям указаным в разделе выше.

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

Смотрите правильность указания всех путей и параметров или выполните в консоли команду rsync —help и разбирайте в параметрах команды.

Использование Yndex.Disk для backups

При регистрации домена мне нравится переводить его управление на Yandex. Для бэкапов создаю отдельный почтовый ящик на домене и туда копирую бэкапы сайта. Удобно передовать заказчику управление доменом и резервные копии в одном месте.

Yandex.Disk дает возможность подключится с помощью WebDav. Необходимо добавить пакет davfs2 для работы по WebDav.

К сожалению на данный момент невозможно передавать данные большого размера по WebDav на Yandex.

Вы можете установить на систему консольный клиент от Yandex и проводить резервное копирование с помощью его.

Официальная страница руководства пользователя имеет понятное описание по установке и использованию на разных системах.

Более подробно с описанием сервиса Yandex Disk вы можете ознакомиться перейдя в раздел техподдержки Яндекса.

Установка Davfs2

Рассмотрим настройку на примере системы CentOS 7.

Подключим репозиторий Еpel:

Установим пакет davfs2:

Настройка WebDav для Yandex.Disk

Создадим папку куда будем монтировать:

Чтобы не путаться в конце я указываю логин почты на котором находиться диск.

Смонтируем Yandex.Disk в необходимую папку:

Диск смонтировался в указанную папку.

Отмантировать диск можно командой:

Введение вручную данных при монтировании не всегда удобно и для удобства мы автоматизируем этот процесс.

Отредактируем файл /etc/davfs2/secrets, добавив в конец строку с данными для авторизации:

Так мы можем задать любое количество строчек с необходимыми ресурсами Yandex.Disk.

В случае если вы хотите чтобы диск монтировался при перезагрузке системы то в etc/fstab необходимо добавить строчку:

Теперь при перезагрузке сервера диск автоматически монтируется.

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

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

Создание скрипта для работы с Yandex.Disk

Создалим скрипт для выполнения копирования резервных копий на Yandex.Disk:

Скрипт выполнит следующие действия:

1. Сомнтирует удаленый Yandex.Disk;
2. Сделает зеркало с папки /backup/infoit.com.ua/day;
3. Отмонтирует Yandex.Disk;
4. Очистит кэш создаваемый при работе davfs2.

Очищать кэш созданный при работе davfs2 надо обязательно иначе место на диске быстро закончиться.

После создания скриптов дадим необходимые права для всех файлов в папке backup:

Добавление задания в cron

Откроем для редактирования /etc/crontab файл откуда выполнятся задания:

Перезагрузим cron в системе CentOS 7 для применения изминений:

Проверки осуществляем по аналогии с предыдущими главами.

Заключение

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

Источник