Резервное копирование linux rsync

Организация 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. Разнес бекапы по времени, с тех пор проблема не повторялась.

Источник

Скрипт резервного копирования через rsync

Возникла необходимость как-то и куда-то бэкапится. Причём чтобы процессоры не грузились и место не занималось, а бэкапы ротэйтились и удобно доставались. Раньше всегда пользовался fsbackup, но захотелось отказаться от архивирования. Для решения задачи была использована rsync и механизм жёстких ссылок (так называемых хардлинков) файловой системы.

Архитектура: есть отдельно стоящий сервер с большим винтом — на нём и работает скрипт. Есть много разных серверов с доступом по ssh, на которых в

/.ssh/authorized_keys добавлен публичный ключ пользователя, под которым работает скрипт резервного копирования.

Логика работы: в определённое время скрипт по ssh синхронизирует содержимое папки на удалённом сервере с папкой domain.com/latest, а потом копирует её в папку с сегодняшней датой, создавая при этом жёсткие ссылки на файлы, затем удаляет папки, дата создания которых старше 7 дней. Т.к. синхронизируется только содержимое каталога, дампить базу по крону нужно на клиентской машине перед тем, как rsync заберёт файлы.

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

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

Источник

Как сделать резервную копию всей системы Linux с помощью Rsync

Сделать бэкап Linux системы можно с помощью Rsync командой всего в одну строку. Хотя у rsync есть много параметров для резервного копирования, но нам данной строки достаточно для полного копирования системы. Кроме того, этот метод намного лучше, чем клонирование диска с помощью команды dd. Потому что, для rsync неважно, имеет ли ваш HDD другой размер или использует другую файловую систему. Этот метод будет работать практически на всех Linux-системах, в которых установлен rsync. В этом кратком how-to я расскажу, как создать полную резервную копию системы Linux с помощью утилиты Rsync.

Для начала, нам нужен резервный носитель (USB-флешка или внешний жесткий диск). Далее нужно узнать имя диска, используя команду «fdisk -l». В моем случае диск определился как /dev/sdb1. Теперь примонтируем наш резервный накопитель в любое удобное место, я выбрал /mnt.

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

Эта команда создаст резервную копию всей корневой директории (/), исключая директории /dev, /proc, /sys, /tmp, /run, /mnt, /media, lost + found в папке / mnt.

Давайте разберём вышеуказанную команду и узнаем, для чего каждый параметр.

• rsync — быстрая, универсальная, локальная и удаленная утилита копирования файлов.
• -aAXv — файлы передаются в режиме «архив», что гарантирует сохранение символических ссылок, устройств, разрешений, владельцев, времени модификации, списков ACL и расширенных атрибутов.
• / — Исходный каталог.
• —exclude — исключает заданные каталоги из резервной копии.
• /mnt — это папка назначения резервного копирования.

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

Чтобы восстановить систему из резервной копии, просто измените исходные и целевые пути в приведенной выше команде.

Помните, что это подходит только для локальных и автономных систем. Если ваша система активно используется некоторыми другими системами в сети, то это не лучшее решение. Потому что содержимое этих систем может постоянно обновляться каждую минуту, а некоторые файлы могут меняться в процессе rsync. Например, когда rsync достигнет файла 2, содержимое предыдущего файла (Файл 1) может быть изменено. Это приведет к ошибке с зависимостями, когда вам понадобится использовать эту резервную копию. В таких случаях резервное копирование на основе снимков является лучшим подходом. Поскольку система будет «заморожена» до того, как процесс резервного копирования запустится и будет «разморожен», когда процесс резервного копирования завершится, поэтому все файлы будут согласованы.

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

Источник

Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования

Данной статьей продолжается

1. Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий
2. Резервное копирование, часть 2: Обзор и тестирование rsync-based средст резервного копирования
3. Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati
4. Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup
5. Резервное копирование, часть 5: Тестирование Bacula и Veeam Backup for Linux
6. Резервное копирование, часть 6: Сравнение средств резервного копирования
7. Резервное копирование, часть 7: Выводы

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

Из тех, что больше всего подходят под наши условия, я буду рассматривать 3: rdiff-backup, rsnapshot и burp.

Тестовые наборы файлов

Наборы файлов для тестирования будут одинаковыми для всех кандидатов, включая будущие статьи.

Первый набор: 10 Гб медиафайлов, и примерно 50 мб — исходный код сайта на php, размеры файлов от нескольких килобайт для исходного кода, до десятков мегабайт для медиафайлов. Цель — имитация сайта с статикой.

Второй набор: получается из первого при переименовании подкаталога с медиафайлами размером 5 гб. Цель — изучение поведения системы резервного копирования на переименование каталога.

Третий набор: получается из первого удалением 3гб медиафайлов и добавлением новых 3 гб медиафайлов. Цель — изучение поведения системы резервного копирования при типовой операции обновления сайта.

Получение результатов

Любое резервное копирование выполняется минимум 3 раза и сопровождается сбросом кэшей файловой системы командами sync и echo 3 > /proc/sys/vm/drop_caches как на стороне тестового сервера, так и сервера хранения резервных копий.

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

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

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

Оперативная память, чтение.

Диск на сервере-источнике данных

Диск на сервере хранения резервных копий

Скорость сети между серверами

Методика тестирования

Ожидаемые результаты

Так как все 3 кандидата основаны на одной и той же технологии (rsync), ожидается, что результаты будут близки к обычному rsync, включая все его преимущества, а именно:

1. Файлы в репозитории будут храниться «как есть».
2. Размер репозитория будет расти только включая разницу между резервными копиями.
3. Будет сравнительно большая нагрузка на сеть при передаче данных, а также небольшая нагрузка на процессор.

Тестовый прогон обычного rsync будет применяться в качестве эталона, его результаты

Узкое место было на сервере хранения резервных данных в виде диска на основе HDD, что достаточно четко видно на графиках в виде пилы.

Данные были скопированы за 4 минуты и 15 секунд.

Тестирование rdiff-backup

Первый кандидат — rdiff-backup, скрипт на python, который выполняет резервное копирование одного каталога в другой. При этом текущая резервная копия хранится «как есть», а резервные копии, сделанные ранее, складываются в специальный подкаталог инкрементально, и таким образом, экономится место.

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

Время работы каждого тестового запуска:

Первый запуск	Второй запуск	Третий запуск
Первый набор	16m32s	16m26s	16m19s
Второй набор	2h5m	2h10m	2h8m
Третий набор	2h9m	2h10m	2h10m

Rdiff-backup весьма болезненно реагирует на любое большое изменение данных, также не до конца утилизирует сеть.

Тестирование rsnapshot

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

Также инвертирована логика процесса резервного копирования: сервер активно «ходит» сам по своим клиентам и забирает данные.

Первый запуск	Второй запуск	Третий запуск
Первый набор	4m22s	4m19s	4m16s
Второй набор	2m6s	2m10s	2m6s
Третий набор	1m18s	1m10s	1m10s

Отработал весьма и весьма быстро, гораздо быстрее rdiff-backup и очень близко к чистому rsync.

Тестирование burp

Еще один вариант — реализация на C поверх librsync — burp, имеет клиент-серверную архитектуру включая авторизацию клиентов, а также наличие web-интерфейса (не входит в базовую поставку). Еще одна интересная особенность — резервное копирование без права восстановления у клиентов.

Давайте посмотрим на

Первый запуск	Второй запуск	Третий запуск
Первый набор	11m21s	11m10s	10m56s
Второй набор	5m37s	5m40s	5m35s
Третий набор	3m33s	3m24s	3m40s

Отработал в 2 раза медленнее, чем rsnapshot, однако тоже достаточно быстро, и уж точно быстрее rdiff-backup. Графики немного пилообразны — производительность опять же упирается в дисковую подсистему сервера хранения резервных копий, хотя это и не так выражено, как у rsnapshot.

Результаты

Размер репозиториев у всех кандидатов был примерно одинаковым, т. е. сначала рост до 10 гб, потом рост до 15 гб, потом рост до 18 гб и т.д., что связано с особенностью работы rsync. Также стоит отметить однопоточность всех кандидатов (загрузка по процессору около 50% при двухядерной машине). Все 3 кандидата предоставляли возможность восстановления последней резервной копии «как есть», то есть можно было восстанавливать файлы без применения каких-либо сторонних программ включая те, которые применялись для создания репозиториев. Это также «родовое наследие» rsync.

Выводы

Чем сложнее система резервного копирования и чем больше у нее различных возможностей — тем медленнее она будет работать, но для не сильно требовательных проектов подойдет любая из них, кроме, возможно, rdiff-backup.

Анонс

Данная заметка продолжает цикл о резервном копировании

Источник