Обновить

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

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

Toshiba MG06ACA10TE 10Tb был заменён на Seagate ST28000NM000C-3WM103 25TB Добавлю, пожалуй, эти данные в статью, чтобы расставить все точки над «ё».

Захватывающая история бэкапа )

Для простых случаев сравнения в bash использую:

alias rs='find . -type f -exec sha256sum -b \{\} \;'
использование под сравнение:
rs | sort > sums1..N
и сравнение:
diff sums1 sums2

Для сложных случаев есть свой собственный велосипед с квадратными колёсами на Джаве -там суммы считаются/проверяются во все потоки, которые даёт проц и всё упирается в производительность SSD/HDD.

Кстати, есть старый диск WD Green 800GB у которого через несколько лет эксплуатации появились бэд-блоки в начале диска. После вычисления "битого" диапазона, сделал раздел, начинающийся после оного. С тех пор уже 10 лет работает холодным бэкапом одного из "хранилищ" с периодическим (раз-два в месяц) дополнением и проверкой контрольных сумм.

Сейчас подыскиваю диски для долгосрочного хранения важной информации (4-6 ТБ) и кучи не особо важной всячины (где-то 15-20 ТБ). Сомневаюсь насчёт гелия. Но других вариантов особо не наблюдается.

find . -type f -exec sha256sum

Моё личное наблюдение — sha512sum работает быстрее, чем sha256sum

К предложенной схеме с find/rs/sort/diff есть несколько вопросов:

  1. Если мне хочется проигнорировать директорию с сериалами, которые я вообще не бэкапирую и которые занимают половину диска? А если список для игнорирования состоит из трёх десятков пунктов? Лично в моём случае так и есть для rsync — передаю их параметрами в скрипте резервирования.

  2. Что если мне нужно продолжить с прерванного места?

  3. Что в плане обновлений через месяц, например, чтобы актуализировать все изменения после бэкапа? Перерасчёт с нуля всех 25Tb?

Вопросы не праздные — я в них упёрся в тот момент, когда сам продумывал решение и хотел нагородить проверку контрольных сумм на bash скриптах и системных утилитах. Думал, что ничего сложного нет.

там суммы считаются/проверяются во все потоки

Каким алгоритмом рассчитываются суммы? Это алгоритм с поддержкой многопоточности или под многопоточностью подразумевается обращение к диску в несколько потоков для чтения файлов? Просто интересуюсь.

Каким алгоритмом рассчитываются суммы?

sha256. Это унаследованное по цепочке обработки с тех времён, когда 256 был быстрее чем 512. Применительно к велосипеду с квадратными колёсами - там "поровну", так как в роли bottleneck выступает SSD.

В шелловском alias легко заменить 256 на 512. Ну и 256-е в терминале смотрятся эстетичнее из-за лаконичности )

Моё личное наблюдение — sha512sum работает быстрее, чем sha256sum

Кстати, это не обязательно везде так, в разных процах с аппаратным ускорением этих алгоритмов дела обстоят по-разному.

Мой опыт ограничивается только замерами на паре вариантов несильно старых x86_64 CPU, поэтому да, возможно мои выводы были поспешны. Спасибо за точку зрения!

Вопросы не праздные — я в них упёрся в тот момент, когда сам продумывал решение и хотел нагородить проверку контрольных сумм на bash скриптах и системных утилитах.

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

В моих случаях alias используется для расчёта сумм файлов для временного контроля целостности или проверки "покрытия" файлов с какого ни будь из носителей, где годами накапливались дубликаты разных pdf'ов, архивов, фотографий и видеозаписей. Делается список сумм файлов с носителя/директории, который затем используется для ответа на вопрос что уже обрабатывалось, а что новое.

Я правильно понимаю, что если бы в rsync опция -c работала с поддержкой прерывания и продолжения с того же места, то статьи бы не было?

Давно забытый слог. Читал с каким-то упоением что ли. Напомнило движуху времён диал-апа (но уже после фидо). Про гелий не задумывался, купил пару на 20000 ГБ полгода назад. Как оказалось это - инвестиция, так как стоимость поднялась уже более чем в 2 раза с момента покупки. А почему не syncthing, которая как минимум два в одном - и опенсурс и может p2p работать?

Конкретно у меня Syncthing не смог завершить синхронизацию 18Tb из Windows на Android TV приставку.

Resilio Sync (тоже бесплатный) - смог, и уже год прекрасно работает.

Читал с каким-то упоением что ли

От души благодарю. Значит не зря старался! Думаю, в будущем больше никто так не будет писать не потому, что весь мой айтишный опыт — продукт того самого диалапа, времён абсолютной свободы фидо, субкультуры udaff и padonkaf, а потому, что все ленятся и получается юридически выверенный, стерильный текст, выс…ый AI. Ну хорошо, может не ленятся, но экономят личный невозобновляемый ресурс — время.

Меня когда то сильно впечатлил стиль текстов Andy Weir: добрый, умный, сложный и с циничным юмором. Наверно, это теперь неосознанно отражается в том, к чему сам стремлюсь.

Сейчас вспоминаю и с удивлением осознаю, что раньше можно было писать обо всём и на любую тему, и за это тебе ничего не было (кроме злобных модераторов, которые могли кенсельнуть пост, конечно! :)

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

Хоть сейчас трава за моим окном и зеленее, чем была раньше за моим другим окном в прошлой жизни, но всё равно, поразительные и удивительные были времена! :-D

syncthing

Моё первое знакомство с этим решением состоялось несколько лет назад, когда я пытался отправить родственнику через полпланеты огромный архив со словарями Goldendict и их индексацией. Тогда это казалось восхитительной идеей: и тебе торрент-протокол, и шифрование, и контрольные суммы и докачка. По-факту промучались неделю с нулевым результатом и пришлось искать альтернативные пути. Это при том что между нами нет ни каких DPI или какой-либо другой дряни, которая могла бы потенциально помешать передаче.

Потом была ещё одна попытка завернуть трафик syncthing в туннель или любой VPN и тоже безуспешно — эксперименты остановились на стадии исследования. Цель полностью недостижима архитектурно, несмотря на заверения нескольких источников в обратном.

Идеи заложены правильные, но тратить время на это кривое поделие я больше не хочу. Может быть, когда-нибудь, напишут на хорошем языке программирования что-то в таком же стиле, но действительно работающее. Но это будет уже не syncthing.

rsync не идеален, но он работает. Он полностью надёжен и предсказуем. Не вижу смысла менять что-то архитектурно, что уже проверено годами. Улучшить — да, можно. И статья именно об этом.

Очень круто написано и проделано многонедельные работы, но зачем? Цель какая была всего этого изначально? Начиная с того, что на малинке надо ставить nvme сразу и забыть про флешку и далее далее далее....
veeam просто существует.
Более мелкие диски, не на 100500Тб - тоже. 2 копии в разных местах можно организовать, если у вас настолько серьезные данные и забыть о многонедельных попытках восстановления.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации