Полезна ли проверка целостности данных с помощью хешей для моего сценария?
У меня есть NAS в качестве производственной системы (в основном видеоматериалы и файлы проектов) и резервное копирование 1: 1. Мне нужно получить резервную копию данных только в экстренных случаях. Такого случая еще не было.
В последнее время я обеспокоен тем, что данные в резервной копии могут быть повреждены незамеченными. Поэтому я подумал о хешировании всех файлов в обеих системах, чтобы проверить, есть ли какие-либо неожиданные различия.
Я не нашел подходящего инструмента, который бы вписался в мой общий процесс, но я могу написать свой собственный скрипт на Python для этого цель. Это займет у меня несколько недель, поэтому я хотел бы спросить, имеет ли это смысл в любом случае.
Я спрашиваю, потому что резервное копирование выполняется каждый день (диски активны, и внутреннее исправление ошибок может вступить в силу, однако резервное копирование программное обеспечение не хэширует), и уже существует уровень исправления ошибок в сетевом транспорте (и, возможно, ОС Windows и файловая система NTFS).
Можно ли применить дополнительный уровень безопасности, выполняющий хеширование SHA512 для всех файлов, или можно ли уже полагаться на существующие исправления ошибок?
Спасибо!
Зависит от данных ... Для наших резервных копий базы данных мы хэшируем их перед передачей и после тестирования в первую очередь. Затем мы помещаем новый хеш в начало файла, чтобы его могли прочитать другие системы, чтобы сравнить их хеши с проверенным хешем и убедиться, что они получили копию файла.
Если файлы вашего проекта важны, да, сделайте это. вероятно, не стоит вашего времени ...
bash может быть быстрее ... Вы можете просто выполнить цикл for через файлы, выполняя openssl, или, если вас не заботит совершенство и скорость, используйте md5sum.
, поэтому либо md5sum $ file >> log.out или sha11sum >> log.out. Вы можете добавить к нему даты и прочее и т. Д., А затем вы можете wc -l строки файла и использовать diff для сравнения и убедиться, что они одинаковые, а затем запустить хэши на второй копии и посмотреть, одинаковы ли они .
Надеюсь, это каким-то образом поможет ... Извини, я должен был спать несколько часов назад.
Вы должны быть очень осторожны с контрольной суммой пользовательских данных! Например, включение контрольной суммы для ReFS превращает ее в файловую систему с полной лог-структурой, в которой изменены все шаблоны ввода-вывода.
https://www.starwindsoftware.com/blog/log-structured-file-systems-microsoft- refs-v2-research-part-1
Вашему приложению базы данных это точно не понравится, поскольку БД используют журнал перед «плоским» хранилищем для ускорения записи, а с ReFS вы получите вход в систему. log, и это ужасная идея с точки зрения производительности.
https://www.usenix.org/system/files/conference/inflow14/inflow14-yang.pdf
Я думаю, вы можете безопасно полагаться на свою резервную копию выбор обработки данных проверяет целостность данных за вас. Сколько времени простоя вы можете себе позволить?
Решите, хотите ли вы реализовать защиту на уровне тома, уровне файла или на обоих уровнях. Под объемом я имею в виду файловые системы, которые могут контрольные суммы данных и восстановление, например ReFS или ZFS. Под уровнем файла я имею в виду проверку файлов с помощью программного обеспечения для резервного копирования или эту специальную контрольную сумму, которую вы рассматриваете.
В общем, позаботьтесь о том, чтобы ваши резервные копии холодные, иначе говоря, офлайн, на разных носителях и, самое главное, протестированы . Это система восстановления , а не система резервного копирования. Если какое-то вредоносное ПО захватит ваше хранилище и зашифрует основное и резервные копии на одном NAS, это очень плохо. Внешний носитель данных, который вы оставляете отключенным, но протестировали путем копирования полезных файлов, спасет вас даже в этом сценарии.