Существует ли решение с обратным инкрементным резервным копированием со встроенной избыточностью (например, пар2)?

Question

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

Полное еженедельное резервное копирование не вариант из-за размера данных. Вместо этого я смотрю по принципу инкрементного резервного копирования. Однако я знаю, что одно повреждение в наборе инкрементных резервных копий делает всю серию (за пределами точки) невосстановимой. Таким образом, простые инкрементные резервные копии не подходят.

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

• Инкремент в обратном порядке (для экономии места на диске и определения приоритетов для самой последней резервной копии)
• История файлов (вид более широкой категории, включая обратный инкремент)
• данные четности Par2 для приращений и данные резервного копирования
• Сохранить метаданные
• Эффективно с пропускной способностью (экономия пропускной способности; не нужно копировать весь каталог для каждого приращения). Большинство решений для инкрементного резервного копирования должны работать таким образом.

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

• Bacula - Простые нормальные инкрементные резервные копии
• bup - инкрементно и реализует пар2, но не инкрементно инкрементно и не сохраняет метаданные
• duplicity - инкрементный, сжатый и зашифрованный, но не обратный инкрементный
• дар - инкрементный и пар2 легко добавить, но не обратный инкрементный и нет истории файлов?
• rdiff-backup - почти идеально подходит для того, что мне нужно, но у него нет поддержки par2

Пока что я думаю, что rdiff-backup кажется лучшим компромиссом, но он не поддерживает par2. Я думаю, что могу добавить поддержку par2 к приращениям резервных копий достаточно легко, так как они не изменяют каждую резервную копию, но как насчет остальных файлов? Я мог бы создать файлы par2 рекурсивно для всех файлов в резервной копии, но это было бы медленно и неэффективно, и мне пришлось бы беспокоиться о повреждении во время резервного копирования и старых файлах par2. В частности, я не мог определить разницу между измененным файлом и поврежденным файлом, и я не знаю, как проверить наличие таких ошибок или как они повлияют на историю резервного копирования. Кто-нибудь знает какое-нибудь лучшее решение? Есть ли лучший подход к проблеме?

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

Answer 1

http://www.timedicer.co.uk/index

В качестве двигателя используется rdiff-backup. Я смотрел на это, но для этого мне нужно настроить «сервер» с помощью Linux или виртуальной машины.

Лично я использую WinRAR для создания псевдоинкрементных резервных копий (фактически, он создает полную резервную копию последних файлов), выполняемых ежедневно по запланированной задаче. Это также «резервное копирование».

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

RAR имеет свою собственную запись четности или восстановления, которую вы можете установить в размере или в процентах. Я использую 1% (один процент).

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

Может быть эффективным, так как сжимает файлы.

Тогда все, что мне нужно сделать, это отправить файл в мою резервную копию. Я скопировал его на другой диск и на другой компьютер в сети. Нет необходимости в настоящем сервере, просто доля. Вы не можете сделать это для слишком большого количества компьютеров, так как рабочие станции Windows имеют ограничение на 10 соединений.

Поэтому для моих целей, которые могут соответствовать вашим, ежедневно выполняется резервное копирование моих файлов для файлов, которые были обновлены за последние 7 дней. Затем у меня есть другая запланированная резервная копия, которая создает резервные копии файлов, которые были обновлены за последние 90 дней, один раз в месяц или каждые 30 дней.

Но я использую Windows, поэтому, если вы на самом деле настраиваете сервер Linux, вы можете проверить Time Dicer.

Answer 2

Поскольку никто не смог ответить на мой вопрос, я напишу несколько возможных решений, которые я нашел при исследовании темы. Короче говоря, я считаю, что лучшим решением является rdiff-backup для файловой системы ZFS. И вот почему:

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

Лично я не использую это решение, так как ZFS немного сложно начать работать в Linux. Btrfs выглядит многообещающе, но не доказал свою стабильность с годами использования. Вместо этого я использую более дешевый вариант простой проверки данных SMART на жестком диске. Жесткие диски должны самостоятельно выполнять проверку / исправление ошибок, и, отслеживая эти данные, я вижу, работает ли этот процесс правильно. Это не так хорошо, как дополнительная четность файловой системы, но лучше, чем ничего.

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

• par2, похоже, устарел и глючит софт. zfec кажется намного более быстрой современной альтернативой Обсуждение в bup произошло некоторое время назад: https://groups.google.com/group/bup-list/browse_thread/thread/a61748557087ca07
• Безопаснее вычислять данные четности еще до записи на диск. не записывать на диск, читать его, а затем вычислять данные о четности. Сделайте это от оперативной памяти, и сравните с оригиналом для дополнительной надежности. Это может быть возможно только с zfec, так как par2 слишком медленный.