Добавить информацию об исправлении ошибок в поток tar, передаваемый по каналу

Добавить информацию об исправлении ошибок в поток tar, передаваемый по каналу

Я использую Amazon S3 Glacier Deep Archive для хранения резервных копий на моей машине Ubuntu. Мой рабочий процесс в основном сводится к следующему:

tar cf - $FILES | gzip -3 --stdout | aws s3 cp - $TARGET

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

Я посмотрел на PAR2, который, кажется, делает то, что мне нужно, с одной оговоркой: он не может принимать канал в качестве входных данных. Это потребовало бы от меня создания всего архива на диске,затемпропустите его через PAR2 и затем загрузите все. С архивами более 1 ТБ это не всегда осуществимо с точки зрения доступного дискового пространства, не говоря уже о том, что это значительно замедляет процесс.

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

решение1

Инструмент:redupe

Я нашел инструмент для этого: redupe. Читайте об этом:Redupe: прямое исправление ошибок.

В этой статье представлен redupe[…] инструмент для обеспечения прямого исправления ошибок в потоках данных. […] redupe, создан по образцу инструментов сжатия, таких как gzipили bzip2, но добавляет избыточность, а не устраняет ее. redupeработает с данными напрямую, преобразуя их в избыточное состояние путем добавления избыточной информации в исходные данные.

Дополнительная команда — reundupeэто на самом деле всего лишь один инструмент, и название, которым вы его называете, определяет, что он делает.

Вы можете получитьredupe из GitHub.

Мне удалось скомпилировать и протестировать redupeв моем Debian 12. Подробности смотрите ниже.


Компиляция

Примечание: некоторые описанные здесь проблемы могли возникнуть из-за отсутствия у меня опыта программирования и компиляции или из-за того, что я не все настроил правильно заранее (или вообще не настроил).

Моя ОС — Debian 12. Вот что я сделал:

  1. Я загрузилredupe-master.zip из GitHub, распаковал и поместил себя в только что созданный redupe-master/.

  2. Методом проб и ошибок я обнаружил, что мне нужны следующие пакеты: automake, make, gcc, libpopt-dev, libtool*.

    sudo apt-get update
    sudo apt-get install automake make gcc libpopt-dev libtool
    

    * По крайней мере, я попробовал именно эти пакеты, и все они показались мне важными.

  3. autoreconf -ivf
    
  4. ./configure && make && sudo make install
    
  5. Мне удалось запустить redupe, но инструмент не смог найти libredupe.so.0. Я обнаружил, что соответствующие библиотеки находятся в /usr/local/lib/. С strace redupeЯ обнаружил, что инструмент проверяет несколько мест (например /usr/lib/), но не /usr/local/lib/. Я переместил все, что связано с redupeиз /usr/local/lib/в `/usr/lib/:

    sudo mv /usr/local/lib/libredupe.* /usr/lib/
    
  6. Я также обнаружил, что недавно установленные /usr/local/bin/redupeи /usr/local/bin/reundupeидентичные обычные файлы. Достаточно одного обычного файла, другое имя может быть символической ссылкой:

    (cd /usr/local/bin/ && sudo rm reundupe && sudo ln -s redupe reundupe)
    

Мой тест

  1. Я переслал 1 ГиБ из /dev/urandomв обычный файл original.
  2. Я просмотрел originalи redupeсохранил результат как original.rd.
  3. Я выполнил команду конвейера original.rd, tr ab xyчтобы изменить некоторые байты, сохранил результат как modified.rd.
  4. Я убедился, что original.rdи modified.rdотличаются (можно использовать cmpили или такие). Очень, очень маловероятно , что в 1 ГиБ случайных данных md5sumнет aи нет , так что этот шаг на самом деле не нужен.b
  5. Я просмотрел modified.rdи reundupeсохранил результат как result.
  6. Я проверил (с помощью cmp), идентичны ли originalи .result

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

</dev/urandom head -c 1G >original \
&& <original redupe | tr ab xy | reundupe | cmp - original

Успешно cmp(без ошибок, код выхода 0) означает, redupeчто работает. У меня работает.

Я также протестировал без tr( … | redupe | reundupe | …), чтобы увидеть, все ли в порядке, когда нет вообще никаких повреждений. Так и есть.


Заключение, примечания

  • redupeработает, но это не панацея. Продолжайте читать.

  • Вызовите redupe --help, обратите внимание на опцию -o/ --overhead.

  • Если данные слишком повреждены для reundupeисправления, инструмент выведет на печать error reading input; будьте осторожны, это немного вводит в заблуждение.

  • Мне удалось найти (относительно небольшой) файл случайных данных, который после применения redupe -o 1(слабой избыточности), изменения (относительно сильной) и применения reundupeдал мне другой файл без какой-либо ошибки из reundupe. Я на самом деле не подозреваю об ошибке, по чистой случайности мне, вероятно, удалось создать файл, который казался допустимым для reundupe. С другой стороны, случайные перевороты бит были исправлены нормально.

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

  • Вы написали: «Я беспокоюсь, что если мой ПК где-то испортится». Если ваш ПК испортится раньше, redupeто redupeон будет работать с испорченным потоком и добросовестно его обработает. Мусор на входе, мусор на выходе; reundupeвоссоздаст исходный испорченный поток. Если ваш ПК (или что-то еще)Действительноесли после redupeэтого что-то пойдет не так, то, скорее всего, инструмент вам тоже не поможет, поскольку он обрабатывает только перевороты бит.

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

  • Вы хотите поставить redupeмежду gzipи aws, а не перед gzip. Тогда при извлечении из резервной копии reundupeбудет перед gunzip. Делать это наоборот (т.е. redupeперед gzip, gunzipперед reundupe) неправильно, потому что:

    • (практическая причина) немного перевернут приведет к gunzipсбою (он проверяет CRC) и данные даже не будут reundupeисправлены; но даже если бы вы могли gunzipпродолжить, есть другая причина; которая заключается в…

    • (теоретическая причина) сжатие работает путем обнаружения шаблонов, сходств, поэтому оно уменьшает избыточность; вы не хотите добавлять избыточность и сразу же ее удалять; вы хотите уменьшить избыточность ваших фактических данных, а затем добавить некоторую преднамеренную избыточность иОставь это.

  • На данный момент мне кажется, что redupe+ reundupeправильно и надежно работает, когда нет повреждений; он может исправить незначительные повреждения (измененные байты). Повреждение, которое, по-видимому, «превышает избыточность», может быть обнаружено или не обнаружено reundupe(в вашем случае необнаруженное повреждение, вероятно, приведет к gunzipсбою). Другими словами, инструмент не портит хорошие данные и дает вам некоторые шансы восстановить хорошие данные из поврежденных данных. По моему мнению, чистая ценность инструмента определенно положительная.

  • Проведите собственные испытания и решите, redupeподходит ли это вам, чего --overheadвы хотите и приемлемы ли результаты.

Связанный контент