Linux backup по сети

Организация 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 и не только (UrBackup)

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

Для начала начал искать решение для резервного копирования файлов, очевидным решением было простая настройка скриптов на Linux по cron, но это не очень удобное и надежное решение, если серверов более одного(а у меня их около 50-ти) и структура достаточно динамична. Тем более если инфраструктура смешанная, Linux + Windows. Хотелось что-нибудь простое в дальнейшем обслуживании и извлечении самих копий, например, переложить восстановление пользовательских файлов на группу поддержки. Порывшись пару часов в интернете, я наткнулся на интересный проект UrBackup, он удовлетворял всем моим условиям.

Как операционную систему я выбрал CentOS 6 в конфигурации minimal, взять можно тут. Подробно на установке и первичной настройке останавливаться не будут, т.к. манулов по этой процедуре уже достаточно на Хабре. Перейдем к установке виновника топика UrBackup.

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

Тут мы подключаем репозиторий и устанавливаем собственно сервер. Далее, чтобы мы могли подключится к серверу из вне, нам необходимо поправить iptables:

Так же для серверов внутри сети отключаем selinux:

Отключаем selinux без перезагрузки:

Устанавливаем сервис в автозагрузку и запускаем:

Готово. Можно подключаться и настраивать.

Заходим по адресу. При желании выбираем язык и идем в настройки:

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

Для начала нам необходимо установить клиент на сервер, который мы хотим копировать. Клиент для Windows систем можно скачать с сайта разработчиков, но так как мы в данный момент рассматриваем linux-системы, рассмотрим установку на тот же CentOS 6:

Добавляем правила в iptables:

Не забываем отключить selinux, если, конечно, в нем нет необходимости. И можно добавлять клиента на сервер. Возвращаемся на сервер. Идем в раздел «статус»:

Вбиваем в поле «Имя/IP» IP-адрес сервера, с которого мы хотим бекапить данные, и нажимаем добавить. Ждем пару минут, пока клиент появится в списке.

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

Идем в настройки:

Выбираем наш сервер из списка и настраиваем «каталоги по умолчанию для бекапа».

Готово. Сервер настроен и работает. Во время работы мы видим нечто подобное:

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

Это минимальная настройка сервера, при желании можно настроить авторизацию, архивацию, создание образов систем (Windows), резервное копирование через интернет и т.д. В дальнейших статьях планирую рассказать, как на этот же сервер настроить резервное копирование MSSQL и Exchange, если это, конечно, будет интересно читателям.

Источник

Как настроить кросс-платформенный сервер резервного копирования на Linux с BackupPC

В этом сообщение я представлю вам BackupPC, программный кросс-платформенный бэкап сервер, который через сеть может вытянуть резервное копирование клиентов Linux, Windows и MacOS. В BackupPC добавлено ряд функций, которые делают резервное копированиче чуть ли не приятной вещью.

Особенности BackupPC

BackupPC поставляется с надёжным веб-интерфейсом, который позволяет вам собирать и управлять централизованным образом резервными копированиями других удалённых хостов. Используя веб-интерфейс, вы можете изучить файлы журналов и конфигурационные файлы, запустить/отменить/настроить расписания резервных копирований удалённых хостов и визуализировать текущий статус задач резервного копирования. Вы также можете просматривать архивные файлы и очень просто восстанавливать отдельные файлы или всё полностью из архивов бэкапов. Для восстановления индивидуальных отдельных файлов, вы можете загружать их из предыдущих бэкапов прямо в веб-интерфейсе. Если этого недостаточно, не требуется специальной программы на стороне клиента для клиентских хостов. На Windows клиентах используется родной протокол SMB, в то время как на *nix клиентах вы будете использовать rsync или tar через SSH, RSH или NFS.

Установка BackupPC

На Debian, Ubuntu, Mint и их производных запустите следующую команду.

На Fedora используйте команду yum command. Обратите внимание, что имя пакета регистрозависимое.

На CentOS/RHEL 6 сначала включите репозиторий EPEL. На CentOS/RHEL 7 включите вместо репозиторий Nux Dextop. Затем продолжайте с командой yum:

Далее команды на разных дистрибутивах Linux идентичны, пользователи Debian, Ubuntu, Mint и их производных не забывайте ставить sudo перед каждой командой.

Как обычно, обе системы управления пакетами будут заботиться об автоматическом разрешении зависимостей. В дополнение как часть установочного процесса, вас могут спросить настроить почтовый сервер, настроить или перенастроить веб-сервер, который будет использован для графического пользовательского интерфейса. Я не стал ничего настраивать в почтовом сервере (чтобы не удлинять инструкцию). Следующие скриншоты из системы Debian:

Сделайте ваш выбор нажав на пробел и затем перейдите к Ок, используя кнопку [Tab], и нажмите [Enter].

Вам будет представлена следующий экран, информирующий вас, что администраторский пользовательский аккаунт ‘backuppc’ с соответствующим ему паролем (который, по желанию, может быть изменён), был создан для управления BackupPC. Обратите внимание, что пользовательский аккаунт HTTP и обычный Linux аккаунт с одинаковым именем ‘backuppc’ будут созданы с идентичным паролем. Первый нужен для получения доступа в защищённый веб-интерфейс BackupPC, в то время как второй нужен для выполнения резервного копирования используя rsync через SSH.

Вы можете изменить пароль по умолчанию для HTTP пользователя ‘backuppc’ следующей командой:

Для изменения обычного ‘backuppc’ пользовательского аккаунта Linux, используйте команду passwd.

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

Запуск BackupPC и настройка Backups

Чтобы начать, откройте окно браузера по адресу http:// /backuppc/. Когда появится окно запроса, введите данные HTTP пользователя, которые были предоставлены вам ранее. Если авторизация успешна, вас перекинет на главную страницу веб-интерфейса.

Наиболее вероятно, первое, что вам нужно сделать, это добавить хосты клиентов для резервного копирования. Перейдите в «Edit Hosts» (редактирвоание хостов) в панеле задач. Мы добавим два клиентских хоста:

• Host #1: CentOS 7 [IP 192.168.0.17]
• Host #2: Windows 7 [IP 192.168.0.103]

Мы будем делать резервное копирование CentOS, используя rsync через SSH, и хоста Windows, используя SMB. До выполнения резервного копирования, нам нужно настроить основанную на ключе аутентификацию на наш хост CentOS и сделать доступной по сети (расшарить) каталог на Windows машине.

Вот инструкция для настройки аутентификации, основанной на ключе, для удалённого хоста CentOS. Мы создаём пользователю ‘backuppc’ пару ключей RSA и переносим публичный ключ в аккаунт рута хоста CentOS.

Когда спросят, напечатайте yes и введите пароль рута для 192.168.0.17.

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

Когда хосты CentOS и Windows готовы, добавьте их в BackupPC используя веб-интерфейс:

Следующий шаг состоит из изменения настроек резервного копирования каждого хоста:

Следующее изображение показывает настройку для резервного копирования на Windows машине:

А следующий скриншот показывает настройку резервного копирования для CentOS:

Запуск резервного копирования

Для запуска каждого резервного копирования, перейдите к настройкам каждого хоста, а затем кликните «Start Full Backup»:

В любое время, вы можете просмотреть статус процесса, кликнув на home хоста, как показано в изображении выше. Если это по каким-либо причинам не получилось, также появится ссылка на страницу с сообщением ошибки (ошибок) в меню хоста. Когда резервное копирвоание завершено успешно, на сервере создаётся каталог с названием хоста или IP адресом в /var/lib/backuppc/pc:

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

Восстановление резервных копий

Для просмотра сохранённых файлов, переходите в раздел «Browse backups», что находится в главном меню хоста. Вы можете визуализировать каталоги и файлы с первого взгляда и выбрать те, которые вы хотите восстановить. Как вариант, вы можете кликнуть по файлу и открыть его, используя программу по умолчанию, или кликните правой кнопкой и выберете Сохранить ссылку, для его загрузки на машину, где вы работаете в данный момент:

Если хотите, то можете загрузить файлы zip или tar, заключающие содержание резеврных копий или просто восстановите файл (файлы) на прежнее место:

Заключение

Говорят «Чем проще — тем лучше», и именно это предлагает BackupPC. В BackupPC вы найдёте не только инструмент для резервного копирования, но также разносторонний интерфейс для управления вашими резервными копиями нескольких операционных систем без необходимости приложения на стороне клиента. Я уверен, что более чем достаточная причина, чтобы хотя бы попробовать.

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

Источник