Нам не нужно их «теснить», мы и так уже в несколько раз их больше. Просто рынок новый для нас и тесный, всяких китайских шаровар на нём вагон и тележка, так что с бесплатным тулом — это самый правильный заход. Получим правильный feedback, наберём market share — а монетизировать всегда успеем (причем не за счёт консьюмеров).
Расцениваете 2GB памяти как требование поддерживаемых нами версий Microsoft Windows. Здесь не имеется ввиду, что 2GB потребляется тулом «сверху». Ну а LocalDB вообще грешно ставить в один ряд с обычным полновесным SQL сервером (который мы используем в Veeam Backup & Replication, например).
Это мы починим тогда в грядущем апдейте. Start-VBRZip будет работать в бесплатной версии, так что сможете шедулить VeeamZIP бакапы с использованием Windows Task Scheduler. Спасибо за фидбэк!
Откуда Ваша информация про SnapRestore VMware VM? Моя непосредственно из NetApp R&D и Product Management, с которыми я напрямую работал последний год, пока мы разрабатывали интеграцию выше. И конкретно со SnapRestore они мне всю плешь проели, в смысле чтобы мы именно через него свой Instant VM Recovery заимплементили. Примерно раз в квартал эта тема разными людьми поднималась, и заканчивалась всегда именно моим аргументом, что мы будем делать по-другому, так как нам нужен общий движок и для NFS, и для блокового стораджа.
Речь в комментируемом Вами посте идёт про VMware, на котором SnapRestore VM возможен только на NFS, так что никуда меня не понесло. А минусов у NFS не меньше, чем плюсов, и это долгий религиозный спор… вот только намекать на то, что добрая половина клиентов NetApp с VMware является странными неудомками по меньшей мере странно с Вашей стороны.
1. SnapRestore требует NFS, на блочном сторадже (около 50% для NetApp + VMware) не работает.
2. Как бы экономно не использовали, но используют. Причём используют дорогущий production FAS, а не больно какой копеечный JBOD забитый толстыми SATA… речь об этом.
3. Согласен, нужны пояснения, что здесь имелось ввиду.
4. Большие преимущества Ferrari перед Газелькой очевидны и бесспорны, пока не нужно отвезти холодильник на дачу. Именно в такой, безусловно очень редкий, момент, все плюсы перестают что-либо значить. Поэтому при всей своей корявости, родственник с Газелькой никому ещё не помешал :) а так-то Ferrari ругать никто здесь и не думал.
Да, успели воткнуть в последний момент. Теперь будем детектить изменения конфигурации дисков, и резетить CBT автоматически. Но уже побитое CBT этот функционал не исправит, поэтому в целях профилактики рекомендуем скриптом зарезетить CBT на всех существующих VM однократно перед установкой v8 (если, конечно, этого уже не было сделано ранее).
В-общем, с многократными увеличениями понятнее не стало. Взяли на 175GB диск, увеличили на 45GB — нормально. Ещё на 45GB увеличили — CBT сломался (хотя в сумме всего на 90GB в два присеста было увеличение). В общем, без поллитры сорс кода не разобраться, а закономерности корраптов выводить исходя из тестов — дело не благодарное в такой точной науке, как бакап. Поэтому мы пишем патч, который будет резетить CBT после любого увеличения диска.
Также тесты подтвердили, что резет CBT достаточен, то есть полный бакап не нужен (по крайней мере в случае с Veeam B&R). Бакапы пролечиваются на первом проходе сами по себе, благодаря тому, что джоба физически весь сорсовый диск обсчитывает в отсутствии CBT, и довозит инкрементом всё, что возилось из-за косяка.
Привет всем. Мы продолжаем исследовать данную багу. Эмпирическим способом выяснили, что начальный и конечный размер диска значения не имеет. Важен размер увеличения диска: проблема только если диск увеличивается больше, чем на 128GB. Так что можно поправить пост ещё раз.
Для понятности пара примеров реальных тестов: при увеличении 200GB > 300GB проблемы нет, при увеличении 200GB > 350GB проблема есть.
Увеличение 15 раз по 10GB ещё пока не успели проверить, но сегодня уже должен быть результат.
Привет, я автор сей новостной рассылки Veeam, взорвавшей сегодня мир судя по Twitter :)
Спешу сообщить, что перевод KB в посту выше неверен. Под риском находятся только те VM, у которых после включения CBT был увеличен размер диска, и этот процесс увеличения заставил размер диска «перешагнуть» 128GB. То есть не так всё плохо. Увеличением диска чаще балуются мелкие клиенты, так как у большинства крупных используются стандартизированные типоразмеры дисков.
Комментировать более сегодня не смогу, так как в самолётах до вечера. Спасибо за внимание!
Мы его специально тестировали много, и чинили его специфические баги.
2. Как бы экономно не использовали, но используют. Причём используют дорогущий production FAS, а не больно какой копеечный JBOD забитый толстыми SATA… речь об этом.
3. Согласен, нужны пояснения, что здесь имелось ввиду.
4. Большие преимущества Ferrari перед Газелькой очевидны и бесспорны, пока не нужно отвезти холодильник на дачу. Именно в такой, безусловно очень редкий, момент, все плюсы перестают что-либо значить. Поэтому при всей своей корявости, родственник с Газелькой никому ещё не помешал :) а так-то Ferrari ругать никто здесь и не думал.
поллитрысорс кода не разобраться, а закономерности корраптов выводить исходя из тестов — дело не благодарное в такой точной науке, как бакап. Поэтому мы пишем патч, который будет резетить CBT после любого увеличения диска.Также тесты подтвердили, что резет CBT достаточен, то есть полный бакап не нужен (по крайней мере в случае с Veeam B&R). Бакапы пролечиваются на первом проходе сами по себе, благодаря тому, что джоба физически весь сорсовый диск обсчитывает в отсутствии CBT, и довозит инкрементом всё, что возилось из-за косяка.
Для понятности пара примеров реальных тестов: при увеличении 200GB > 300GB проблемы нет, при увеличении 200GB > 350GB проблема есть.
Увеличение 15 раз по 10GB ещё пока не успели проверить, но сегодня уже должен быть результат.
Так что «никогда не говори никогда» :)
Спешу сообщить, что перевод KB в посту выше неверен. Под риском находятся только те VM, у которых после включения CBT был увеличен размер диска, и этот процесс увеличения заставил размер диска «перешагнуть» 128GB. То есть не так всё плохо. Увеличением диска чаще балуются мелкие клиенты, так как у большинства крупных используются стандартизированные типоразмеры дисков.
Комментировать более сегодня не смогу, так как в самолётах до вечера. Спасибо за внимание!