Comments 15
Тема бекапов актуальна, спасибо за пост. Но я не смог осилить вашу первую картинку-инфорграфику.
Можно ли 8-ю версию поставить на отдельный сервер и для тестов делать бэкапы существующих ESXi, с которыми уже трудится Veeam 7?
Да, именно так и рекомендуем.
C ESXi это, скорее всего, нормально сработает. Главное — разнести джобы по времени, дергать их исключительно по очереди, чтобы не было «драки» за снятие/удаление снэпшотов с машин и т.д.
А вот с Hyper-V мы не рекомендуем так делать из-за архитектурных особенностей в реализации работы со снапшотами томов с виртуальными машинами.
А вот с Hyper-V мы не рекомендуем так делать из-за архитектурных особенностей в реализации работы со снапшотами томов с виртуальными машинами.
А то будем мучаться от багов ломанной veComLic.dll и писать про вас всякое :-P
Гранд мерси, теперь по ссылке дают ключ для восьмёрки!
> процедура восстановления из аппаратного снапшота не гранулярна (при необходимости восстановить отдельный файл на хранилище, в результате восстановления диска из аппаратного снимка, все хранилище целиком “перемещается в прошлое” и последние изменения на диске теряются),
Это не так в общем случае. Это так, только при восстановлении с помощью SnapRestore, или подобного механизма. Но в общем случае в снэпшоте файлы остаются доступны для восстановления сами по себе, и гранулярность равна отдельному файлу.
> аппаратные снапшоты используют полезную емкость оригинального диска
Да, но крайне экономно. А вот вынесенные наружу они начинают использовать огромный объем, пусть и вторичного хранилища для резервных копий, но — огромный, так как становятся не differential, а full copy/
> может замедлять или даже приводить к сбоям в работе некоторых приложений
Это не проблема «аппаратных снэпшотов», а проблема этих «некоторых приложений», не так ли? Каких, кстати?
> снапшоты не могут рассматриваться как надежный способ защиты данных от сбоев, прежде всего потому, что снапшоты располагаются на том же СХД
Не «прежде всего», а «только лишь потому, что».
Зато у них есть большие преимущества, прежде всего то, что восстановление с них происходит быстро, быстрее любого другого варианта резервной копии. Кроме того, они лежат на хранилище с очень высокой надежностью его самого по себе, вдобавок, они занимают на primary storage минимально возможное место, и, наконец, мы не зависим от сторонних решений при восстановлении, от отказов вторичного стораджа, канала передачи данных до него, багов ПО Veeam, и так далее.
Видите, сколько плюсов на один «минус»?
Это не так в общем случае. Это так, только при восстановлении с помощью SnapRestore, или подобного механизма. Но в общем случае в снэпшоте файлы остаются доступны для восстановления сами по себе, и гранулярность равна отдельному файлу.
> аппаратные снапшоты используют полезную емкость оригинального диска
Да, но крайне экономно. А вот вынесенные наружу они начинают использовать огромный объем, пусть и вторичного хранилища для резервных копий, но — огромный, так как становятся не differential, а full copy/
> может замедлять или даже приводить к сбоям в работе некоторых приложений
Это не проблема «аппаратных снэпшотов», а проблема этих «некоторых приложений», не так ли? Каких, кстати?
> снапшоты не могут рассматриваться как надежный способ защиты данных от сбоев, прежде всего потому, что снапшоты располагаются на том же СХД
Не «прежде всего», а «только лишь потому, что».
Зато у них есть большие преимущества, прежде всего то, что восстановление с них происходит быстро, быстрее любого другого варианта резервной копии. Кроме того, они лежат на хранилище с очень высокой надежностью его самого по себе, вдобавок, они занимают на primary storage минимально возможное место, и, наконец, мы не зависим от сторонних решений при восстановлении, от отказов вторичного стораджа, канала передачи данных до него, багов ПО Veeam, и так далее.
Видите, сколько плюсов на один «минус»?
1. SnapRestore требует NFS, на блочном сторадже (около 50% для NetApp + VMware) не работает.
2. Как бы экономно не использовали, но используют. Причём используют дорогущий production FAS, а не больно какой копеечный JBOD забитый толстыми SATA… речь об этом.
3. Согласен, нужны пояснения, что здесь имелось ввиду.
4. Большие преимущества Ferrari перед Газелькой очевидны и бесспорны, пока не нужно отвезти холодильник на дачу. Именно в такой, безусловно очень редкий, момент, все плюсы перестают что-либо значить. Поэтому при всей своей корявости, родственник с Газелькой никому ещё не помешал :) а так-то Ferrari ругать никто здесь и не думал.
2. Как бы экономно не использовали, но используют. Причём используют дорогущий production FAS, а не больно какой копеечный JBOD забитый толстыми SATA… речь об этом.
3. Согласен, нужны пояснения, что здесь имелось ввиду.
4. Большие преимущества Ferrari перед Газелькой очевидны и бесспорны, пока не нужно отвезти холодильник на дачу. Именно в такой, безусловно очень редкий, момент, все плюсы перестают что-либо значить. Поэтому при всей своей корявости, родственник с Газелькой никому ещё не помешал :) а так-то Ferrari ругать никто здесь и не думал.
> SnapRestore требует NFS, на блочном сторадже (около 50% для NetApp + VMware) не работает.
Э-э… Что-то вас понесло, и понесло не туда. Вообще-то SnapRestore это функция WAFL и никакого отношения к NFS и вообще любым протоколам не имеет.
Он может не быть включенным, например если не куплена на него лицензия, но снэпшоты и восстановление из них простым копированием все равно есть и всегда будут, просто как свойство внутренней файловой системы стораджа.
Тема про странных людей, использующих блочные протоколы при возможности использовать NFS на том же сторадже, со всеми его плюсами, оставлю сейчас за скобками темы.
Э-э… Что-то вас понесло, и понесло не туда. Вообще-то SnapRestore это функция WAFL и никакого отношения к NFS и вообще любым протоколам не имеет.
Он может не быть включенным, например если не куплена на него лицензия, но снэпшоты и восстановление из них простым копированием все равно есть и всегда будут, просто как свойство внутренней файловой системы стораджа.
Тема про странных людей, использующих блочные протоколы при возможности использовать NFS на том же сторадже, со всеми его плюсами, оставлю сейчас за скобками темы.
Речь в комментируемом Вами посте идёт про VMware, на котором SnapRestore VM возможен только на NFS, так что никуда меня не понесло. А минусов у NFS не меньше, чем плюсов, и это долгий религиозный спор… вот только намекать на то, что добрая половина клиентов NetApp с VMware является странными неудомками по меньшей мере странно с Вашей стороны.
> на котором SnapRestore VM возможен только на NFS
Это не так. Все что я могу вам по этому поводу сказать. Не упорствуйте в грехе, лучше пойдите почитайте документацию (исправьте, если это написано у Veeam)
> является странными неудомками по меньшей мере странно с Вашей стороны.
Не приписывайте мне то, что я не говорил, это ваши фантазии и ваши слова.
Это не так. Все что я могу вам по этому поводу сказать. Не упорствуйте в грехе, лучше пойдите почитайте документацию (исправьте, если это написано у Veeam)
> является странными неудомками по меньшей мере странно с Вашей стороны.
Не приписывайте мне то, что я не говорил, это ваши фантазии и ваши слова.
Откуда Ваша информация про SnapRestore VMware VM? Моя непосредственно из NetApp R&D и Product Management, с которыми я напрямую работал последний год, пока мы разрабатывали интеграцию выше. И конкретно со SnapRestore они мне всю плешь проели, в смысле чтобы мы именно через него свой Instant VM Recovery заимплементили. Примерно раз в квартал эта тема разными людьми поднималась, и заканчивалась всегда именно моим аргументом, что мы будем делать по-другому, так как нам нужен общий движок и для NFS, и для блокового стораджа.
Коллеги, мне кажется, у вас тут небольшое недопонимание произошло на почве SnapRestore.
Snaprestore — это технология восстановления из снэпшота средствами массива. Она работает на всех протоколах доступа.
Но на файловом уровне можно восстановить любой файл (например, vmdk диск), а на блочном — только LUN целиком.
netto прав в том, что snaprestore работает всегда и везде, но восстановить конкретную ВМ его средствами, как верно подметил TheRealGostev, возможно только на nfs.
Snaprestore — это технология восстановления из снэпшота средствами массива. Она работает на всех протоколах доступа.
Но на файловом уровне можно восстановить любой файл (например, vmdk диск), а на блочном — только LUN целиком.
netto прав в том, что snaprestore работает всегда и везде, но восстановить конкретную ВМ его средствами, как верно подметил TheRealGostev, возможно только на nfs.
Sign up to leave a comment.
Вышла новая версия Veeam Backup & Replication v8 (платная и бесплатная редакции)