Патч очень большой двоичный файл через медленное соединение

771
mcandril

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

tail -c 1000000000 myfile.img|md5sum # and head -c 1000000000 myfile.img|md5sum

совпадают, поэтому начало и конец файла идентичны.

Так как мой нисходящий поток намного быстрее, я снова загрузил полный образ и набрал md5 суммы за все это, и они НЕ совпадают. Так что, видимо, где-то в этих 1,5 ТБ есть хотя бы один бит, который отличается.

Есть ли способ, чтобы сгенерировать «патч» из двух загруженных мной файлов, а затем применить его к удаленному файлу, чтобы снова передавались только неправильные блоки?

Пожалуйста, обратите внимание: я НЕ имею права удаленно выполнять код или использовать возможности rsync, которые требуют удаленного запуска rsync. Я думаю, что я все еще мог бы использовать rsync, и он работает в порядке величины моей скорости загрузки, но мне интересно, есть ли лучший способ использовать тот факт, что у меня есть обе версии локально. Вероятно, было бы не так сложно что-то написать, но я бы предпочел использовать что-то проверенное и сохранить работу.

0
Я только что увидел ответ, который предложил bsdiff. Я не могу видеть это больше. Я на самом деле посмотрел на это и говорит, что он работает с O ((n + m) log n). Поскольку мои файлы имеют одинаковый размер и, очевидно, большие части одинаковы, я чувствую, что это должно быть возможно в O (n) -> Выполнить один раз над первым файлом, посмотреть соответствующий бит в другом и записать, если хотите изменить это и на что. mcandril 7 лет назад 0
Теперь о bsdiff: 200-МГц Pentium Pro, упомянутый на их странице, потребует 9375h для моих 1,5 ТБ. Моя система не такая медленная, но и не современный Core i7. Так что я бы, вероятно, все еще попал в область времени при повторной загрузке, чего я также должен достичь с помощью rsync, используя этот https://blog.christophersmart.com/2014/01/15/force-rsync- в использовании дельта-передачи к FIX-коррумпированной-удаленного файла / комментарий-страничный-1 /. Другой предложил один, который я не могу вспомнить. mcandril 7 лет назад 0

2 ответа на вопрос

1
meuh

(при условии Linux), если вы считаете, что поврежден только один блок данных или около того, но размер блока не изменился, вы можете использовать cmp -l. Он сравнивает побайтово и -lдает смещение любых различий. Если у вас есть смутное представление о том, с чего начать в файлах, вы можете начать с самого начала -i. Если у вас есть смещения по ошибке, вы можете использовать их dd skip=...для удаления исходного файла и dd seek=... conv=notruncвставки его в поврежденный файл. (Сначала протестируйте копию)

Круто, именно то, что я ищу! mcandril 7 лет назад 0
0
billc.cn

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

Чтобы заставить его работать в приватной обстановке:

  1. Отключите DHT на локальных и удаленных бит-торрент-клиентах.
  2. Откройте локальные бит-торрент-порты на брандмауэре или настройте переадресацию портов SSH.
  3. Создайте начальный файл на стороне источника. Не используйте трекер. Убедитесь, что клиент также начал заполнять файл.
  4. Сделайте резервную копию файла на удаленной стороне.
  5. Скопируйте начальный файл на удаленную сторону и откройте его с помощью клиента.
  6. Укажите местоположение загрузки для поврежденного файла и выберите опцию, чтобы не начать загрузку ! Также отключите параметры для подключения к DHT, обмена пирами и т. Д., Если avaialbe.
  7. Попросите клиента перепроверить загруженный файл. Следует сообщить процент загрузки, который почти завершен.
  8. Добавьте локальный клиент в качестве пира к загрузке
  9. Начать загрузку
Спасибо, но, как я уже сказал, я не могу запустить код удаленно. Это также означает, что не может быть удаленного битторрент-клиента. Единственное, что у меня есть, это такие протоколы, как SCP (но НЕ SSH, я даже не могу рассчитать контрольную сумму на удаленной стороне), SFTP, CIFS, WebDAV. Потенциально испортить вещи не является большой проблемой, поскольку удаленное хранилище поддерживает моментальные снимки. mcandril 7 лет назад 0
Если у вас есть доступ к SCP / CIFS / WebDAV, вы можете подключить их как локальные файловые системы и использовать BitTorrent, как указано выше. Это было бы очень медленно, хотя ... Промежуточным решением было бы сделать это с компьютера с быстрым подключением к удаленной стороне. Например, AWS / VPS-почасовой провайдер близок к удаленному серверу. billc.cn 7 лет назад 0
Да, но в этом случае я не вижу, как rsync будет намного проще. У меня действительно есть сервер с быстрым доступом к этому хранилищу, но тогда я все равно буду использовать rsync. Надо было подумать об этом для первоначальной передачи. В любом случае, предложение meuh - именно то, чего я хочу, и я не могу представить, как оно могло бы работать быстрее. Это O (n) локально, и тогда только передает неправильные байты. mcandril 7 лет назад 0

Похожие вопросы