le087 25.08.2012 11:24
Я рекомендую — Организация инкрементальных бекапов за 5 минут
Все мы делаем бекапы, ну может собираемся их делать. Системные администраторы знают множество различных рецептов для выполнения этого запретного и таинственного действия. Вот один из них.Для организации простого инкрементального бекапа я хочу предложить использовать утилиту rdiff-backup. Эта штука написана на python и использует в качестве основы rsync.
Создание бекапов
Найти в репозиториях своего дистрибутива, думаю, не составит труда.
В создании бекапов также проста как rsync:
1 |
|
В результате в /destination/path будет создано зеркало каталога /source/path.
Если мы внесем какие-либо изменения в /source/path, а потом выполним команду бекапа повторно, утилита определит, что именно изменилась и добавить копию только изменившихся файлов, а может даже только изменившуюся часть этих файлов, хотя фиг знает. В любом случае появится новый слепок каталога.
Посмотреть наличие слепков можно командой:
Утилита делает инкремент только в том случае, если были внесены какие-то изменения в файлы и каталоги со времени последнего выполнения бекапа. Благодаря этому мы получаем ряд полезных плюшек:
- Возможность экономить дисковое пространство. Если я не ошибаюсь, инкременты делаются до тех пор, пока их суммарный объем не превысит половины объема от последнего полного бекапа. Когда это случается, делается снова полный бекап
- Возможность вернуться не просто к последнему бекапу, а бекапу за определенное число
- Управлять всем этим хозяйством чертовски просто
Что бы получить краткую сводку после выполненного бекапа, достаточно в команду внести опцию --print-statistic
Восстановление данных
Что бы восстановить данные, необходимо выполнить команду вида:
1 |
|
В результате мы восстановим данные из последнего выполненного бекапа в каталог /local/path.
Поскольку в /destination/path хранится полное дерево того, что мы бекапим, то можно указать для восстановления только определенный файл или каталог, например так:
1 |
|
Чувствую пятой точкой, как минимум глоббинг здесь так же должен работать, но не проверял.
Что бы восстановить файлы 5 дневной давности, можно воспользоваться такой командой:
1 |
|
Можно восстановить и по определенной дате:
1 |
|
1 |
|
Удаляем старое
Естественно, что хранить кучу устарвешего файла 5 лет нет смысла. Rdiff-backup умеет и прибирать за собой. Давайте удалим бекапы старше, чем 16 недель:
1 |
|
Удаление старых бекапов происходит таким образом, что если в тот день имеется только инкремент полного бекапа, то останется все предыдущие до момента создания этого инкремента бекапы вплоть до предыдущего полного бекапа. Таким образом гарантируется, что удаление старых бекапов не приведет к неработоспособности оставшихся инкрементов.
Немного сладкого напоследок
Поскольку rdiff используется для работы rsync, то естественно он умеет делать бекапы на удаленный хост. Команда для создания бекапов в этом случае выглядит примерно так:
1 |
|
- настроить ssh-авторизацию по ключу
- навоять простенький скрипт
- добавить задание в cron
Вот небольшой мини скрипт бекапа, написанный мною на скорую руку:

+ 0 -
Уже несколько месяцев бекапы своего сервера и ноутбука делаю через rdiff-backup. В принципе доволен. Хотя с одно стороны бекап хома длиться до часа (большое число вложений, даже при том что я отключаю файлы больше 10Мб и каталоги музыки, и видео). Нагрузки почти не создает. за статью спасибо узнал пару новых вещей. Хотя у rdiff-backup и критики много, но и она в сторону старых версий программы
На работе у меня rdiff-backup используется почти для всего, что нужно бекапить. Для хранения данных пользователей у нас имеется пара десятков террабайт дискового пространства, из которого 60% уже заняты. Бекапы делаются ежедневно. Возможно это не самый быстрый способ, но поскольку есть реальный пример использования, то делюсь именно им.
У меня на работе еще не разу не использовали rdiff-backup, потому что свои сценарии резервного копирования настраиваются только на нагруженных и очень важных серверах. Используется rsync, потому что там не до экспериментов.
Учитывая то, что он все равно использует тот же самый rsync можно сказать, что rdiff-backup тоже самое, только с оберткой, написанной на питоне. У меня очень положительный, пока что по крайне мере, опыт использования этой штуки. Rsync чаще всего мне приходиться использовать для копирования данных и синхронизации каталогов, а сабж вот для организации бекапов удобен.
Да я с Вами согласен, это вполне нормально, что его не везде получиться использовать.
Да я с Вами согласен, это вполне нормально, что его не везде получиться использовать.
Лично я испытываю его до того момента пока не придется реально заняться восстановлением. Так сказать боевые условия. Какой у Вас опыт в восстановлении данных через rdiff-backup. Часто восстанавливали и были проблемы?
Да постоянно приходится восстанавливать, каждый день почти, такова специфика организации.
Ну если верить описанию программы на главной странице проекта: "rdiff-backup also preserves subdirectories, hard links, dev files, permissions, uid/gid ownership, modification times, extended attributes, acls, and resource forks."; то оно должно хорошо справлятся и с хардлинками.
Может я не правильно понял вопрос и имеется в виду, будет ли делаться бекап того файла, хардлинк которой бекапиться? Насколько мне известно hardlink не выйдет сделать на какой-либо каталог, а вот на файлы их можно делать. Хард линк указывает на inode файла, соответственно пока есть хотя бы один хардлинк на файл, он не будет удален из файловой системы. Отсюда можно сделать вывод, хардлинки и файлы на которые они ведут так же должны бекапиться. Лучший способ - проверить на практике. На своей памяти я не помню проблем с хардлинками при использовании rdiff-backup.
Может я не правильно понял вопрос и имеется в виду, будет ли делаться бекап того файла, хардлинк которой бекапиться? Насколько мне известно hardlink не выйдет сделать на какой-либо каталог, а вот на файлы их можно делать. Хард линк указывает на inode файла, соответственно пока есть хотя бы один хардлинк на файл, он не будет удален из файловой системы. Отсюда можно сделать вывод, хардлинки и файлы на которые они ведут так же должны бекапиться. Лучший способ - проверить на практике. На своей памяти я не помню проблем с хардлинками при использовании rdiff-backup.
Нет, я не имел ввиду бэкап жёстких ссылок, я имел ввиду бэкап на основе жёстких ссылок. То есть каждый раз, когда делаем новый бэкап, делается полный бэкап, но если файл не изменялся, то вместо него создаётся жёсткий линк на уже забэкапленный. Если обновился - то кладётся новая версия. В результате только микроскопический оверхед на директории и сами ссылки, в плюсе - отсутствие необходимости в полном бэкапе, т.к. любой бэкап всегда имеет полную версию данных.
Я не уверен, что оно работает так. Насколько я знаю, оно рботает немного по-другому.
Сначала делается полный бекап. После этого, предположим, мы внесли несколько изменений в содержимое каталога, которое бекапим. Следующий бекап сделает инкремент, который будет содержать только разницу между предыдущим и текущем состояниями каталога. Еще одно резервное копирование создасть инкремент, который будет содержать разницу между предыдущем бекапом и предыдущем инкрементом и текущем состоянием каталога и так далее. При извлечение данных из резервной копии сначала берется полный бекап, а затем на него накатываются накопившиеся до нужного нам момента инкременты, после чего отдается уже пользователю на растерзание. В этом случае, наверно, нет необходимости создавать жесткие ссылки, но должна появится некая копилка информации о каждом слепке, которая знает состояние зарезервированного каталога в каждый раз из сделанных бекапов.
Сначала делается полный бекап. После этого, предположим, мы внесли несколько изменений в содержимое каталога, которое бекапим. Следующий бекап сделает инкремент, который будет содержать только разницу между предыдущим и текущем состояниями каталога. Еще одно резервное копирование создасть инкремент, который будет содержать разницу между предыдущем бекапом и предыдущем инкрементом и текущем состоянием каталога и так далее. При извлечение данных из резервной копии сначала берется полный бекап, а затем на него накатываются накопившиеся до нужного нам момента инкременты, после чего отдается уже пользователю на растерзание. В этом случае, наверно, нет необходимости создавать жесткие ссылки, но должна появится некая копилка информации о каждом слепке, которая знает состояние зарезервированного каталога в каждый раз из сделанных бекапов.
Отлично! Будет классно, если Вы напишите небольшую заметку о том, что используете. Если честно, о bontmia я слышу впервые =)
Большое спасибо. Надеюсь, этого мне хватит, чтобы перестать собираться, и таки начать делать. :)))
Хорошая статья. Я бы только в последнем скрипте между созданием бекапа и удалением старых поставил бы проверку успешности первой строки. А то, скажем, новые бэкапы перестали создаваться из-за какой-нибудь проблемы, а старые потихонечку исчезаааааают...
distanation -> destination :)
TIMESHTAMP -> TIMESTAMP