Какие возможности появились у утилиты rdiff-backup благодаря миграции на Python 3

Автор оригинала: Patrik Dufresne
  • Перевод
В процессе миграции на Python 3 разработчики утилиты rdiff-backup усовершенствовали её, добавив много новых фич.



В марте 2020 года вышел второй крупный релиз утилиты rdiff-backup. Второй — за 11 лет. Во многом, это объясняется прекращением поддержки Python 2. Разработчики решили совместить приятное с полезным и доработали функционал утилиты.

Около 20 лет она верой и правдой служит Linux-сообществу — помогает делать бэкапы на локальных и удалённых машинах, скажем так… без лишней головной боли. Секрет прост: утилита позволяет делать бэкап только тех файлов, которые изменились с прошлого резервного копирования. Для более краткого обозначения этого процесса существует термин «инкрементальное резервное копирование».

Второе рождение rdiff-backup пережила благодаря команде энтузиастов, которую возглавили Эрик Зольф и Патрик Дюфресне из IKUS Software, а также Отто Кекяляйнен из Seravo.


Новые фичи


Проект переехал в новый репозиторий и предлагает всем желающим стать контрибьюторами. Команда внесла в новый релиз все полезные доработки, которые появлялись в течение прошедших 11 лет. Среди них — поддержка разрежённых файлов и баг-фиксы для жёстких ссылок.

Автоматизация на базе Travis CI


Другое важнейшее улучшение — это конвейер CI/CD на базе распределённого веб-сервиса Travis CI. Теперь пользователи смогут запускать rdiff-backup в различных тестовых средах без риска сломать работающий проект. Конвейер CI/CD позволит выполнять автоматизированную сборку и доставку для всех основных платформ.

Простая установка с помощью yum и apt


Новая версия работает на большинстве ОС семейства Linux — Fedora, Red Hat, Elementary, Debian и многих других. Разработчики постарались подготовить все необходимые открытые репозитории для лёгкого доступа к утилите. Установить rdiff-backup можно с помощью менеджера пакетов или пошаговой инструкции на GitHub-странице проекта.

Новый дом


Сайт проекта переехал с Savannah на GitHub Pages (rdiff-backup.net), разработчики обновили контент и дизайн сайта.

Как работать с rdiff-backup


Если вы познакомились с rdiff-backup только сейчас, вы удивитесь, насколько он прост в использовании. Разработчики позаботились о том, чтобы вы чувствовали себя комфортно: по их мнению, подобные утилиты не должны отвлекать своей сложностью от таких важных процессов, как подготовка бэкапа или планирование восстановления данных.

Бэкап


Чтобы запустить бэкап на локальном диске (например, USB), введите команду rdiff-backup, затем имя источника (откуда будете копировать файлы) и путь к каталогу, в который вы планируете сохранить их.

Например, чтобы сделать бэкап на локальном диске с именем my_backup_drive, введите:

$ rdiff-backup /home/tux/ /run/media/tux/my_backup_drive/

Для сохранения файлов во внешнем хранилище введите путь к удалённому серверу вместе со знаком «::»

$ rdiff-backup /home/tux/ tux@example.com::/my_backup_drive/

Вероятно, ещё вам потребуются SSH ключи для доступа на сервер.

Восстановление файлов из бэкапа


Бэкапы делают потому, что иногда какие-то файлы имеют обыкновение, скажем так… теряться. Утилита позволяет достаточно просто восстанавливать файлы из бэкапа. Но всё-таки по щелчку пальцем это сделать не получится.

Тут нам на помощь придут команды копирования — cp для локального диска и scp для удалённого сервера.

Для локального диска нужно написать, например, такое:

$ cp /run/media/tux/my_backup_drive/Documents/example.txt ~/Documents

Для удалённого сервера:

$ scp tux@example.com::/my_backup_drive/Documents/example.txt ~/Documents

У команды rdiff-backup есть опции, которые позволяют настроить параметры копирования. Например, --restore-as-of даёт возможность указать, какую версию файла нужно восстановить.

Допустим, вы хотите восстановить файл в том состоянии, в котором он был 4 дня назад:

$ rdiff-backup --restore-as-of 4D /run/media/tux/foo.txt ~/foo_4D.txt

Или, может быть, вам нужна последняя версия:

$ rdiff-backup --restore-as-of now /run/media/tux/foo.txt ~/foo_4D.txt

Вы видите, что работать с rdiff-backup достаточно легко. У этой утилиты много настроек и возможностей. Например, вы можете исключать отдельные файлы из списка для бэкапа, делать резервное копирование с одного удалённого сервера на другой и так далее. С описанием всех её возможностей вы можете ознакомиться на странице с документацией.



На правах рекламы


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

VDSina.ru
Серверы в Москве и Амстердаме

Комментарии 7

    +1
    Возможно, стоит отметить отличие rdiff-backup от rsync: в то время как rsync каждый раз обходит всё дерево каталогов на источнике и получателе, сравнивая размеры и даты изменения каждого файла, rdiff-backup каждый раз пересчитывает sha1-суммы всех (?) файлов на источнике, сравнивая их с локально сохраненной базой данных. У обоих способов есть свои плюсы и минусы. Источник
      0

      А зато у вас негров линчуют rsync передает только изменившиеся части файлов.
      Не представляю, кому оно может помочь (разве что при бэкапах DBF-файлов), но тем не менее.

        0

        при бэкапе образа виртуалки разве не помогает?

          0

          Вот не знаю, честно говоря.
          По идее должен. На практике среди себя мне не приходилось засекать время и объем.

            0

            Для образов rdiff-backup ИМХО не лучшее решение. Он заточен на работу с россыпью файлов, некоторые из которых периодически частично или полностью меняются. В некотором смысле он похож на git (хотя я лично не понимаю людей, которые делают бекапы гитом).

          0
          rdiff-backup каждый раз пересчитывает sha1-суммы всех (?) файлов на источнике

          Это определённо не так. Как и у rsync, у rdiff-backup можно включить такое поведение, но по умолчанию сравнение идёт по метаданным. Конечно, при начальном копировании и каждый раз, когда файл меняется rdiff-backup пересчитывает и сохраняет контрольную сумму, чтобы можно было выполнить --verify-at

          +1

          Благодаря миграции на python 3 строго говоря rdiff-backup ничегошеньки не приобрёл. Только потерял бинарную совместимость протокола между старыми (2) и новыми (3) версиями, а поскольку собрать свежий rdiff-backup под древний линукс или вообще под termux для шестого андроида — то ещё приключение, то лично я не очень рад этой миграции.


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

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

          Самое читаемое