Comments 16
Сообщите пожалуйста точную модель HDD, которая выбрана для бекапа.
Захватывающая история бэкапа )
Для простых случаев сравнения в 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 есть несколько вопросов:
Если мне хочется проигнорировать директорию с сериалами, которые я вообще не бэкапирую и которые занимают половину диска? А если список для игнорирования состоит из трёх десятков пунктов? Лично в моём случае так и есть для rsync — передаю их параметрами в скрипте резервирования.
Что если мне нужно продолжить с прерванного места?
Что в плане обновлений через месяц, например, чтобы актуализировать все изменения после бэкапа? Перерасчёт с нуля всех 25Tb?
Вопросы не праздные — я в них упёрся в тот момент, когда сам продумывал решение и хотел нагородить проверку контрольных сумм на bash скриптах и системных утилитах. Думал, что ничего сложного нет.
там суммы считаются/проверяются во все потоки
Каким алгоритмом рассчитываются суммы? Это алгоритм с поддержкой многопоточности или под многопоточностью подразумевается обращение к диску в несколько потоков для чтения файлов? Просто интересуюсь.
Каким алгоритмом рассчитываются суммы?
sha256. Это унаследованное по цепочке обработки с тех времён, когда 256 был быстрее чем 512. Применительно к велосипеду с квадратными колёсами - там "поровну", так как в роли bottleneck выступает SSD.
В шелловском alias легко заменить 256 на 512. Ну и 256-е в терминале смотрятся эстетичнее из-за лаконичности )
Моё личное наблюдение — sha512sum работает быстрее, чем sha256sum
Кстати, это не обязательно везде так, в разных процах с аппаратным ускорением этих алгоритмов дела обстоят по-разному.
Вопросы не праздные — я в них упёрся в тот момент, когда сам продумывал решение и хотел нагородить проверку контрольных сумм на bash скриптах и системных утилитах.
Вопросы очевидно не подпадают под определение "простых случаев" для которых приводился шельный alias из исходного комментария. Вряд ли возможно в пару-тройку коротких строк "утолкать" универсальный ответ на все вопросы бэкапа с помощью узкоспецифичных утилит.
В моих случаях alias используется для расчёта сумм файлов для временного контроля целостности или проверки "покрытия" файлов с какого ни будь из носителей, где годами накапливались дубликаты разных pdf'ов, архивов, фотографий и видеозаписей. Делается список сумм файлов с носителя/директории, который затем используется для ответа на вопрос что уже обрабатывалось, а что новое.
Я правильно понимаю, что если бы в rsync опция -c работала с поддержкой прерывания и продолжения с того же места, то статьи бы не было?
Перед ответом я тщательно подумал над Вашим так точно заданным вопросом! И да, совершенно верно, была бы опция прерывания, — не было бы статьи, не было бы и моего личного опыта в борьбе с несовершенством цифровой реальности.
Но! На самом деле я рад этому опыту! Есть такой термин, часто используемый в разработке: Test Oracle — тестовый Оракул. Это некая независимая сущность, призываемая для проверки результата.
Ещё тогда, когда я уже начал использовать rsync для рабочих нужд, не до конца понимая всех нюансов его работы, я интуитивно чувствовал, что использовании единственного инструмента может таить угрозу. И потом, внезапно потеряв кусок важного дампа БД в DRC банка я в этом убедился воочию. Пришлось вникать в нюансы и строить процедуры периодического восстановления из бэкапов на архитектуре DRC. Это было чертовски сложно и долго, но действительно гарантировало восстановление работы на резервных ресурсах в случае проблем с основным DC. Это и был тот самый Оракул, который проверял результат.
precizer в данном случае тоже является оракулом, связанным с основным инструментом синхронизации, только через данные. Простым, но от этого не менее эффективным.
Угрозы могут идти не только от rsync. ПО или железо. Развалившийся RAID, проблемы с бэдблоками на дисках в более простых решениях, сбои на сетевом уровне, баги в ПО: как внутри rsync, так и в любом другом. Всё это несёт реальную угрозу рассинхронизации.
После наступания на «грабли» я теперь осознаю важность тестового Оракула. Не precizer, так какой-то другой инструмент. Поэтому все мои текущие и будущие решения в обязательном порядке будут построены на этом принципе.
Давно забытый слог. Читал с каким-то упоением что ли. Напомнило движуху времён диал-апа (но уже после фидо). Про гелий не задумывался, купил пару на 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 копии в разных местах можно организовать, если у вас настолько серьезные данные и забыть о многонедельных попытках восстановления.
надо ставить nvme сразу
Сейчас да, я полностью соглашусь. Тогда, когда я только пробовал свою первую Raspberry Pi, задача стояла не в том ключе, чтобы разориться на покупку nvme, а попробовать вообще подойдёт малинка для тогдашних моих нужд или нет. Возможно да, это бы решило проблему UBOOT и расширило бы выбор OS, но сейчас меня итак устраивает и без лишних трат. Малинка прекрасно работает как backup-платформа, на которой можно даже что-то запустить с минимумом энергозатрат.
проделано многонедельные работы, но зачем?
Ради результата. Сейчас у меня два ёмких диска на двух сторонах и я ничем не ограничен в своих желаниях хранить любой объём интересующих меня данных; синхронизация с проверкой и полная уверенность в идентичности данных; прямой доступ к данным через обе железки — к обеим точкам я могу за считанные секунды подключиться через интернет и добраться до любого файла.
Несомненно, HDD не конкуренты NVME дискам. И вообще магнитная технология заведомо обречена на увядание. Однако обещания Samsung выпустить четыре года назад NVME диски пользовательского уровня ёмкостью 100Tb пока так и остаются обещаниями. Учитывая ≅6 кратную разницу в стоимости хранения одного мегабайта продолжаем жить с HDD и жать светлого будущего.
забыть о многонедельных попытках восстановления
NVME точно так же НЕ гарантируют 100% сохранности и доступности данных как и HDD. Рано или поздно, но и с любыми solid state возникнут проблемы. Даже солидных брендов. Технология увы, не совершенна. Это не просто слова, это неоднократный личный опыт.
“Решил я как то проверить, что будет если энтропия в системе будет нарастать бесконечно…”
*** Длинный текст с описанием эволюции вселенной.
Почему rsync ≠ гарантия целостности данных. Как я проверяю бэкапы и нахожу расхождения