Comments 26
А технические подробности по дедупликации можно?
К примеру фиксированные блоки или скользящие? Какой хэш используете для сравнения блоков?
К примеру фиксированные блоки или скользящие? Какой хэш используете для сравнения блоков?
Вы можете выбрать, какой размер блока использовать при дедупликации: 4,8,16 или 32 Килобайта. На последней картинке видно, как размер блока влияет на эффективность дедупликации и потребность в быстрой памяти (оперативной или SSD).
В предыдущих версиях программы резервного копирования Arcserve UDP по умолчанию предлагали использовать блок данных в 4 Килобайта. Теперь стали рекомендовать 16 Килобайт.
Используемый хэш — SHA1.
В предыдущих версиях программы резервного копирования Arcserve UDP по умолчанию предлагали использовать блок данных в 4 Килобайта. Теперь стали рекомендовать 16 Килобайт.
Используемый хэш — SHA1.
Ну я имею ввиду блоки строго от начала файла идут или скользят по всему файлу, т.е. если в файл добавить в начало один байт, то будет замечено, что отличие всего в одном байте, а остальное дубликаты?
И насчет sha1, коллизии не попадались на больших объемах?
И насчет sha1, коллизии не попадались на больших объемах?
Образ диска разбивается на блоки условленного размера, и позиция этих блоков не меняется, то есть они не скользят. Это не мешает, однако, получать высокий процент дедупликации на реальных данных при минимальных вычислительных затратах.
А уж если бы коллизия SHA-1 кому-то попалась (необязательно нам), то такая новость сразу бы наводнила Интернет, и мы тут же увидели бы её на Хабре, да и во всяких википедиях тоже.
А уж если бы коллизия SHA-1 кому-то попалась (необязательно нам), то такая новость сразу бы наводнила Интернет, и мы тут же увидели бы её на Хабре, да и во всяких википедиях тоже.
Не, ну в интернете напишут, если эту коллизию можно относительно легко находить (хотя в принципе их можно находить, потому собственно все SSL сертификаты на sha2 переходят). Но это больше касается криптографической стойкости.
В случае дедупликации и инкрементального бэкапа (блочного) возможно случайное появление коллизий, так как понятное дело при «ужатии» 4-16 КБ блока до 20 байт так или иначе коллизии будут, попадутся они или нет зависит от везения в принципе. И в случае если будет коллизия в блоках, то «попортятся» файлы.
В случае дедупликации и инкрементального бэкапа (блочного) возможно случайное появление коллизий, так как понятное дело при «ужатии» 4-16 КБ блока до 20 байт так или иначе коллизии будут, попадутся они или нет зависит от везения в принципе. И в случае если будет коллизия в блоках, то «попортятся» файлы.
«Государь Гелон!
Есть люди, думающие, что число песчинок бесконечно. Я не говорю о песке в окрестности Сиракуз и других местах Сицилии, но о всём его количестве как в странах населённых, так и необитаемых.»
Архимед. Исчисление песчинок в пространстве равном шару неподвижных звёзд (Псаммит).
А, есть люди, которые считают, что 1/2^80 (вероятность коллизии SHA-1) – это обычное такое число, ничего особенного. И что встретить коллизию SHA-1 – обычное дело.
Сравнить же с этим числом можно (если не ошибаюсь) количество элементарных частиц в нашей галактике. А это куда больше, чем количество песчинок, подсчитанных Архимедом (2^80 против 10^63 – тысячи мириад чисел «восьмых»).
И вероятность коллизии меньше, чем вероятность того, что данные на жёстком диске случайно переманитятся, но CRC останется прежним! Представляете? Было «Я к вам пишу — чего же боле?» а стало «А теперь Горбатый! Я сказал – Горбатый!» только за счёт случайного перемагничивания.
Когда вероятность коллизии столь мала, что непонятно, увидим ли мы её когда-нибудь за всю историю существования человечества, то как-то трудно считать это ненадёжным решением. Возможно, серверы нашего тысячелетия расыпятся в прах, а коллизию мы так и не встретим. А может быть, натолкнёмся на коллизию уже завтра – со случайными величинами ни в чём быть уверенным нельзя.
В общем, всё зависит от вашего доверия/недоверия к тому, может ли возникнуть событие с ничтожно низкой вероятностью. И «ничтожно» — это куда меньше, чем найти две одинаковых песчинки не просто в окрестностях Сиракуз, но и во всей нашей галактике.
Есть люди, думающие, что число песчинок бесконечно. Я не говорю о песке в окрестности Сиракуз и других местах Сицилии, но о всём его количестве как в странах населённых, так и необитаемых.»
Архимед. Исчисление песчинок в пространстве равном шару неподвижных звёзд (Псаммит).
А, есть люди, которые считают, что 1/2^80 (вероятность коллизии SHA-1) – это обычное такое число, ничего особенного. И что встретить коллизию SHA-1 – обычное дело.
Сравнить же с этим числом можно (если не ошибаюсь) количество элементарных частиц в нашей галактике. А это куда больше, чем количество песчинок, подсчитанных Архимедом (2^80 против 10^63 – тысячи мириад чисел «восьмых»).
И вероятность коллизии меньше, чем вероятность того, что данные на жёстком диске случайно переманитятся, но CRC останется прежним! Представляете? Было «Я к вам пишу — чего же боле?» а стало «А теперь Горбатый! Я сказал – Горбатый!» только за счёт случайного перемагничивания.
Когда вероятность коллизии столь мала, что непонятно, увидим ли мы её когда-нибудь за всю историю существования человечества, то как-то трудно считать это ненадёжным решением. Возможно, серверы нашего тысячелетия расыпятся в прах, а коллизию мы так и не встретим. А может быть, натолкнёмся на коллизию уже завтра – со случайными величинами ни в чём быть уверенным нельзя.
В общем, всё зависит от вашего доверия/недоверия к тому, может ли возникнуть событие с ничтожно низкой вероятностью. И «ничтожно» — это куда меньше, чем найти две одинаковых песчинки не просто в окрестностях Сиракуз, но и во всей нашей галактике.
Или вот такое (мрачное) сопоставление.
В практикуме по страхованию жизни (легко ищется в интернете) можно прочитать, что вероятность прожить ещё один год для взрослого человека составляет около 0.99
Допустим, в вашем ИТ-департаменте работает 10 человек
Вероятность того, что в течение года все они дружно переплывут через реку Стикс, составляет
(1-0.99)^10 ~= 1/(2^7)^10 ~= 2^-70
То есть встретить коллизию SHA-1 вероятность гораздо меньше, чем всему департаменту ломануться на вечеринку к Одину.
Не кажется ли вам, что настолько маловероятное событие не заслуживает беспокойства о нём?
В практикуме по страхованию жизни (легко ищется в интернете) можно прочитать, что вероятность прожить ещё один год для взрослого человека составляет около 0.99
Допустим, в вашем ИТ-департаменте работает 10 человек
Вероятность того, что в течение года все они дружно переплывут через реку Стикс, составляет
(1-0.99)^10 ~= 1/(2^7)^10 ~= 2^-70
То есть встретить коллизию SHA-1 вероятность гораздо меньше, чем всему департаменту ломануться на вечеринку к Одину.
Не кажется ли вам, что настолько маловероятное событие не заслуживает беспокойства о нём?
Я же не спорю, что вероятность маленькая, только вот она не нулевая.
2^80 это не вероятность коллизии, это вероятная криптостойкость к различным атакам, которая в данном случае не важна (так как не рассматривается злонамеренная подделка блоков бэкапа), так что можно считать 2^160 вариантов. Но теперь посчитайте теоретическое количество вариаций блоков размером 4КБ или 16КБ. Для блока 4 КБ это 2^32768 и уже число 2^160 не выглядит таким большим.
Ок, допустим, а почему к примеру тогда не выбрали md5 у него вероятность тоже гораздо меньше «чем всему департаменту ломануться на вечеринку к Одину», а считается этот хэш быстрее и места в памяти меньше занимает, чем sha-1.
2^80 это не вероятность коллизии, это вероятная криптостойкость к различным атакам, которая в данном случае не важна (так как не рассматривается злонамеренная подделка блоков бэкапа), так что можно считать 2^160 вариантов. Но теперь посчитайте теоретическое количество вариаций блоков размером 4КБ или 16КБ. Для блока 4 КБ это 2^32768 и уже число 2^160 не выглядит таким большим.
То есть встретить коллизию SHA-1 вероятность гораздо меньше, чем всему департаменту ломануться на вечеринку к Одину.
Не кажется ли вам, что настолько маловероятное событие не заслуживает беспокойства о нём?
Ок, допустим, а почему к примеру тогда не выбрали md5 у него вероятность тоже гораздо меньше «чем всему департаменту ломануться на вечеринку к Одину», а считается этот хэш быстрее и места в памяти меньше занимает, чем sha-1.
Я это всё к чему, что зачастую используют комбинацию из двух хэшей, так как вероятность поймать коллизию на двух хэшах значительно ниже.
Вы правы вероятность получить коллизию хэша очень маленькая, просто ничтожная
И о ней не стоит беспокоиться.
Никому.
Кроме разумеется тех, чей софт делает более миллиарда хэшей ежедневно.
Поэтому если вы не работаете с системами предназначенными для дедупликации террабайтов бэкапов и архивов, то вам боятся нечего.
И о ней не стоит беспокоиться.
Никому.
Кроме разумеется тех, чей софт делает более миллиарда хэшей ежедневно.
Поэтому если вы не работаете с системами предназначенными для дедупликации террабайтов бэкапов и архивов, то вам боятся нечего.
1. Дедупликация в таком виде используется во многих продуктах известных производителей программного и аппаратного обеспечения. Не кажется ли Вам, что если бы коллизия хэшей имела бы коль сколько-нибудь серьёзную вероятность возникновения, давно бы появилась обоснованная критика этого метода со стороны серьёзных специалистов, а не только дискуссии на форумах?
2. В вконце концов, дедупликация — это инструмент, который вы можете использовать, а можете и не использовать. Всё зависит от вашей собственной оценки рисков. Вы когда-нибудь ездили на автомобиле? Вы знаете, что погибнуть в автокатастрофе отлична от нуля и вовсе не ничтожна? Например, в России вероятность погибнуть в ДТП в течение года составляет около 0.00019.
Но вы всё-равно ездите. Оцениваете риск, но удобства от езды на автомобиле перевешивают опасность.
Так же и при дедупликации. Разница только в том, что риск автомобильной аварии осязаем, а риск коллизии миллиарда хешей ежедневно — ничтожен.
3. Что значит «ничтожен»? Выше я уже приводил примеры крайне маловероятных событий, вероятность которых выше, чем вероятность возникновения коллизии.
Но известно ли Вам, что вероятность того, что ошибочно будет произведён пуск ядерной ракеты также отлична от нуля? Это Вас не беспокоит? Вы просто уверены, что вероятность такого события ничтожна, хотя последствия чудовищны. А ничтожна — это насколько мала? когда для Вас число будет столь малым, что не будет вызывать беспокойства? 2^-80 достаточна? А 2^-160? А какая достаточна? Давайте выберем такой размер хеша, который будет соответствовать Вашим понятиям ничтожной вероятности.
Просто до нас уже кто-то прикинул вероятность коллизии для SHA-1 и решил, что это весьма небольшая вероятность, позволяющая использовать основанную на ней дедупликацию в промышленных системах.
2. В вконце концов, дедупликация — это инструмент, который вы можете использовать, а можете и не использовать. Всё зависит от вашей собственной оценки рисков. Вы когда-нибудь ездили на автомобиле? Вы знаете, что погибнуть в автокатастрофе отлична от нуля и вовсе не ничтожна? Например, в России вероятность погибнуть в ДТП в течение года составляет около 0.00019.
Но вы всё-равно ездите. Оцениваете риск, но удобства от езды на автомобиле перевешивают опасность.
Так же и при дедупликации. Разница только в том, что риск автомобильной аварии осязаем, а риск коллизии миллиарда хешей ежедневно — ничтожен.
3. Что значит «ничтожен»? Выше я уже приводил примеры крайне маловероятных событий, вероятность которых выше, чем вероятность возникновения коллизии.
Но известно ли Вам, что вероятность того, что ошибочно будет произведён пуск ядерной ракеты также отлична от нуля? Это Вас не беспокоит? Вы просто уверены, что вероятность такого события ничтожна, хотя последствия чудовищны. А ничтожна — это насколько мала? когда для Вас число будет столь малым, что не будет вызывать беспокойства? 2^-80 достаточна? А 2^-160? А какая достаточна? Давайте выберем такой размер хеша, который будет соответствовать Вашим понятиям ничтожной вероятности.
Просто до нас уже кто-то прикинул вероятность коллизии для SHA-1 и решил, что это весьма небольшая вероятность, позволяющая использовать основанную на ней дедупликацию в промышленных системах.
Выше я уже приводил примеры крайне маловероятных событий
Вы забыли такую вещь, как закон Мерфи или закон подлости: если какая-то гадость может случиться, то она обязательно случится :)
В случае с ядерными ракетами, пример не корректный, так как там не проверяют миллиард раз в день сработает защита или нет.
Я другой пример приведу, америкосовскую лотерею Powerball, вероятность выиграша в неё 1/2^28. Теперь прикинем какова вероятность, что выиграют 2 человека одновременно. Вероятности насколько помню умножаются (степени складываются), т.е. получается 1/2^56. А для трех человек 1/2^84 ничтожная вероятность по вашему, тем не менее в январе этого года 3 человека никак не связанные между собой сорвали джекпот в 1,5 млрд.
Просто до нас уже кто-то прикинул вероятность коллизии для SHA-1 и решил, что это весьма небольшая вероятность
Ну почему насколько знаю многие системы с дедупликацией используют SHA-256, та же ZFS для дедупликации использует SHA-256 (хотя вроде для файловой системы лучше более быстрый хеш использовать).
Т.е. на вашей практике, еще на сталкивались с какими-то проблемами из-за sha-1 коллизий, насколько я понял.
| Т.е. на вашей практике, еще на сталкивались с какими-то проблемами из-за sha-1 коллизий, насколько я понял.
Верно, не сталкивались.
Тут бы мне тихо и мирно закончить дебаты, но всё-таки не могу оставить без комментариев некоторые Ваши утверждения:
1. «В случае с ядерными ракетами, пример не корректный, так как там не проверяют миллиард раз в день сработает защита или нет.»
Я не ставил задачу сравнить вероятности. Очень надеюсь, что они несравнимы. Я лишь хотел указать, что вероятность сбоя, в принципе, отлична от нуля, и нельзя безапелляционно утверждать, что если вероятность сбоя (или коллизии в нашем случае) отлична от нуля, то доверия такой системе нет.
2. По поволу лотереи Powerball.
Думаю, что в расчет вероятности выигрыша джекпота вкралась ошибка.
Действительно, вероятность совпадения выигрышных чисел ДЛЯ ОДНОГО КОНКРЕТНОГО ЧЕЛОВЕКА равна 1/2^28 ( точнее, говорят, 1 к 292 201 338).
Но если купили миллион билетов, то вероятность выигрыша для одного человека не изменится, а вот вероятность того, что джекпот в принципе случится, станет больше в миллион раз, то есть будет равна… 1/292
То есть вероятность того, что я, мой сосед и мой племянник (то есть конкретные три человека) выиграют джекпот, действительно супер-низкая: 1/2^84, как Вы и сказали.
Но то, что джекпот выиграют три ПРОИЗВОЛЬНЫХ человека из миллиона купивших билеты, всего лишь 1/292^3.
Если куплено больше билетов, то вероятность ещё выше.
Верно, не сталкивались.
Тут бы мне тихо и мирно закончить дебаты, но всё-таки не могу оставить без комментариев некоторые Ваши утверждения:
1. «В случае с ядерными ракетами, пример не корректный, так как там не проверяют миллиард раз в день сработает защита или нет.»
Я не ставил задачу сравнить вероятности. Очень надеюсь, что они несравнимы. Я лишь хотел указать, что вероятность сбоя, в принципе, отлична от нуля, и нельзя безапелляционно утверждать, что если вероятность сбоя (или коллизии в нашем случае) отлична от нуля, то доверия такой системе нет.
2. По поволу лотереи Powerball.
Думаю, что в расчет вероятности выигрыша джекпота вкралась ошибка.
Действительно, вероятность совпадения выигрышных чисел ДЛЯ ОДНОГО КОНКРЕТНОГО ЧЕЛОВЕКА равна 1/2^28 ( точнее, говорят, 1 к 292 201 338).
Но если купили миллион билетов, то вероятность выигрыша для одного человека не изменится, а вот вероятность того, что джекпот в принципе случится, станет больше в миллион раз, то есть будет равна… 1/292
То есть вероятность того, что я, мой сосед и мой племянник (то есть конкретные три человека) выиграют джекпот, действительно супер-низкая: 1/2^84, как Вы и сказали.
Но то, что джекпот выиграют три ПРОИЗВОЛЬНЫХ человека из миллиона купивших билеты, всего лишь 1/292^3.
Если куплено больше билетов, то вероятность ещё выше.
Но если купили миллион билетов, то вероятность выигрыша для одного человека не изменится, а вот вероятность того, что джекпот в принципе случится, станет больше в миллион раз, то есть будет равна… 1/292
Интересно, как это у вас так получилось, миллион билетов снизили вероятность, а то что у вас в 35 ГБ данных 9 млн блоков по 4 КБ вероятность не снижают, а если бекапить несколько терабайт то там 500 млн блоков, а теперь посчитайте сколько всего блоков у пользователей вашей программы :) Собственно к этому я и вел, что в масштабах всех клиентов фирмы делающей систему дедупликации вполне можно поймать коллизии.
Конечно, Вы правы. В 500 миллионах блоков вероятность коллизии значительно выше, но всё равно остаётся в пределах допустимого риска по мнению производителя. Я попробую запросить расчётные значения у разработчиков.
В VBR, насколько мне известно, MD5. Сведений о замеченных коллизиях лично ко мне пока не поступало :).
Насчет хешей и коллизий пару лет назад была аналогичная дискуссия (куда ж без этого) на форуме Veeam, резюме по сути то же, что привел и автор поста. Так что производители тут, можно сказать, солидарны :)
Насчет хешей и коллизий пару лет назад была аналогичная дискуссия (куда ж без этого) на форуме Veeam, резюме по сути то же, что привел и автор поста. Так что производители тут, можно сказать, солидарны :)
Не хватает краткого описания преимуществ по сравнению со встроенной в ОС (начиная с Server 2012) дедупликацией.
1. Принципиальное отличие в том, что встроенная в ОС дедупликация выполняется в офлайне.
То есть:
— Оставляйте свои данные, мы ими займёмся.
— А когда будут готовы?
— Мы вам позвоним.
Вы (а) не можете предсказать, когда занятое место на диске уменьшится, (б) успеет ли оно уменьшится к тому моменту, когда нужно будет делать следующую копию, следующую за следующей…, (в) не можете предсказать заранее, НАСКОЛЬКО уменьшится занятое место.
В то же время онлайн-дедупликация в Arcserve UDP сразу же выдаёт данные в дедуплицированном виде. Правда, цена за это — повышенные требования к быстрой памяти (оперативной или SSD), где должна помещаться вся таблица хэшей.
2. Дедупликация в Arcserve UDP производится на источнике, то есть ещё перед передачей по сети. Вы не только ужимаете полную копию на, например, 91%, но и сокращаете сетевой трафик на 91% (за вычетом служебных данных Ethernet/TCP/IP).
То есть:
— Оставляйте свои данные, мы ими займёмся.
— А когда будут готовы?
— Мы вам позвоним.
Вы (а) не можете предсказать, когда занятое место на диске уменьшится, (б) успеет ли оно уменьшится к тому моменту, когда нужно будет делать следующую копию, следующую за следующей…, (в) не можете предсказать заранее, НАСКОЛЬКО уменьшится занятое место.
В то же время онлайн-дедупликация в Arcserve UDP сразу же выдаёт данные в дедуплицированном виде. Правда, цена за это — повышенные требования к быстрой памяти (оперативной или SSD), где должна помещаться вся таблица хэшей.
2. Дедупликация в Arcserve UDP производится на источнике, то есть ещё перед передачей по сети. Вы не только ужимаете полную копию на, например, 91%, но и сокращаете сетевой трафик на 91% (за вычетом служебных данных Ethernet/TCP/IP).
UFO just landed and posted this here
— Максимально использовать инкрементные копии. Проверку на повторяемость будут проходить не все блоки диска, а только те, что помечены, как изменённые.
— Если сервер виртуальный, то копировать его без установки агента (брать снапшот с гипервизора) и проводить дедупликацию на машине, установленной рядом.
— «Душить» скорость копирования (network throttling) встроенными средствами, «размазывая» нагрузку на процессор по времени.
Но необходимость в этом возникает нечасто. В реальной жизни инкрементные копии на уровне блоков могут проскакивать за считанные минуты глубокой ночью.
— Если сервер виртуальный, то копировать его без установки агента (брать снапшот с гипервизора) и проводить дедупликацию на машине, установленной рядом.
— «Душить» скорость копирования (network throttling) встроенными средствами, «размазывая» нагрузку на процессор по времени.
Но необходимость в этом возникает нечасто. В реальной жизни инкрементные копии на уровне блоков могут проскакивать за считанные минуты глубокой ночью.
(удалено, промахнулся)
Меня сильно смущает дедупликация в контексте резервного копирования. Фактически повредив один блок в результирующей копии мы потеряем их все. Как-то опасно…
Любая технология резервного копирования подразумевает, что должна проводиться периодическая проверка восстановимости. И дело не только в дедупликации.
Лично мне приходилось сталкиваться с такими двумя случаями:
1. Копирование на ленточный привод годами проходило без ошибок. Ленты подписывались и складывались в шкафчик. Когда возникла необходимость восстановить данные, оказалось что ленты пусты. Ни разу никто не проверил, действительно ли на лентах что-то записано или нет.
2. Снова лента. Долгое время проводилось ежедневное резервное копирование сервера с базой данных Oracle. Операционная система стояла на диске C:, база данных — на диске D:. Когда сервер рухнул, оказалось, что копировался только бесполезный диск C:, про диск D: забыли при создании задания на резервное копирование.
Что я хочу этим сказать? Если бы люди хоть раз провели бы тестовое восстановление, то ошибки всплыли бы.
Точно также и с дедупликацией. Если есть регламент проверки восстановимости, то можно положиться на такую систему.
Для пущей уверенности держать несколько серверов хранения резервных копий и периодически переливать хранилище на отчуждаемый носитель (магнитную ленту).
Лично мне приходилось сталкиваться с такими двумя случаями:
1. Копирование на ленточный привод годами проходило без ошибок. Ленты подписывались и складывались в шкафчик. Когда возникла необходимость восстановить данные, оказалось что ленты пусты. Ни разу никто не проверил, действительно ли на лентах что-то записано или нет.
2. Снова лента. Долгое время проводилось ежедневное резервное копирование сервера с базой данных Oracle. Операционная система стояла на диске C:, база данных — на диске D:. Когда сервер рухнул, оказалось, что копировался только бесполезный диск C:, про диск D: забыли при создании задания на резервное копирование.
Что я хочу этим сказать? Если бы люди хоть раз провели бы тестовое восстановление, то ошибки всплыли бы.
Точно также и с дедупликацией. Если есть регламент проверки восстановимости, то можно положиться на такую систему.
Для пущей уверенности держать несколько серверов хранения резервных копий и периодически переливать хранилище на отчуждаемый носитель (магнитную ленту).
Sign up to leave a comment.
Примеряем дедупликацию и компрессию к резервным копиям