
Комментарии 13
Сообщите пожалуйста точную модель 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 работала с поддержкой прерывания и продолжения с того же места, то статьи бы не было?
Давно забытый слог. Читал с каким-то упоением что ли. Напомнило движуху времён диал-апа (но уже после фидо). Про гелий не задумывался, купил пару на 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 копии в разных местах можно организовать, если у вас настолько серьезные данные и забыть о многонедельных попытках восстановления.
Почему rsync ≠ гарантия целостности данных. Как я проверяю бэкапы и нахожу расхождения