Victor_VG
Tracker Mod | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору secretDV С использованием внутренней избыточности как у FreeArc/RAR - нет, алгоритмы 7-Zip такой возможности не предоставляют, но средства контроля целостности контейнера в них есть. С использованием внешних средств резервирования вероятность успешного восстановления повреждённых данных будет определятся их свойствами. Из них самое простое в реализации, но имеющее высокую избыточность это распределённое мажоритарное резервирование. Идея проста - мы создаём несколько, не менее трёх независимых копий хранящихся на географически распределённых удалённых узлах поскольку вероятность повреждения всех распределённых копий стремится к нулю, а при восстановлении из резервной копии производим мажоритарное сравнение M из N, M <= N. При этом в случае повреждения M копий из N сравнение покажет несовпадение повреждённых и целых копий между собой и далее проверяем целостность контейнера исходя из его свойства "повреждённый контейнер не проходит проверку на целостность" после чего отбрасываем заведомо повреждённые копии. По уровню избыточности и затратам времени на получение N копий данный способ очень не эффективен, а по уровню надёжности хранения один из самых надёжных. Возможным решением задачи "резервирование с восстановлением на произвольный момент времени" может стать использование хранилища Git поскольку он имеет возможность отката на произвольную точку фиксации истории локальных данных и обеспечивает достаточно высокий уровень их безопасности и скорость доступа при использовании протокола SSH. Для локального хранилища стоит использовать RAID5 с независимым RAID процессором что в отличии от программных "RAID 0,1,3,5,10" встроенных в большинство чипсетов и имитирующих реализацию спецификаций RAID уровней 3 и 5 обычно путём использования зеркалирования средствами драйвера более низких уровней RAID, обеспечивает восстановление данных в случае отказа одного из накопителей, но для RAID5 их должно быть не менее 4-х на массив. Относительно предлагаемых вами настроек сжатия - для снижения расхода памяти при упаковке и распаковке архива и уменьшения длительности операций я бы воспользовался уровнем сжатия MAXIMUM, а при частом обновлении отказался бы и от SOLID (непрерывного) формата архива предусматривающего помещение всех данных в один блок, что требует его полной перепаковки при обновлении, но повышает сжатие. Выигрыш в сжатии для уровня ULTRA по сравнению с MAXIMUM не столь велик по сравнению с многократным проигрышем в размере необходимого для работы алгоритмов сжатия 7-Zip объёма непрерывного участка ОЗУ, что при его отсутствии в момент выполнения операции сжатия сделает её невозможной. При это в машине памяти может быть во много раз больше, но на момент выполнения операции подходящего по размеру непрерывного фрагмента ОЗУ для размещения словарей сжатия из-за накопления фрагментации ОЗУ не будет и вы получит ошибку "Не достаточно памяти для выполнения операции.". Для уровня ULTRA вероятность такого сообщения при увеличении времени с момента запуска ОС резко возрастает, задача использующая уровень сжатия MAXIMUM успешно выполняется практически всегда.
---------- Жив курилка! (Р. Ролан, "Кола Брюньон") Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti |
| Всего записей: 34084 | Зарегистр. 31-07-2002 | Отправлено: 04:22 19-03-2018 | Исправлено: Victor_VG, 04:37 19-03-2018 |
|