Комментарии 35
Спасибо за статью, она очень познавательна. Но про Iometr вы зря так. Ровно все то же самое, что вы описали для FIO можно реализовать и на нем. B он тоже кроссплатформенный если что :), в том числе из исходников можно собрать под нужную OS. Тут вопрос в том, кто и с чем лучше разобрался :). Ну и в 2006 году вышла не последняя версия Iometr, т.к. после компании Intel его развитием занимались другие люди. Последние версии доступны тут www.iometer.org.
НЛО прилетело и опубликовало эту надпись здесь
> … показывает, что вы крайне плохо и мало знаете эту тему.
Значит пишу глупости и не надо их читать.
> Нет, только не понимающие тему
А аргументировать?
> Какое это отношение имеет к БЭКАПУ?
Бэкап не информация и хранить её нигде не надо. Вот ещё глупости!
> Файлы в бэкапе не должны изменяться. Вообще. Никогда. На то они и БЭКАП.
Эм, а сам бекап это, простите, что?
> Какие Enterprise-class NAS автор вообще видел
В Enterprise-class автор видит только SAN, а на остальное смотрит с недоумением
> Ерунда снова какая-то.
А вы в нутаниксе точно работаете? Прямо за деньги?
Вас тема насов ну совсем как то задела. Неконструктивный диалог получается…
Значит пишу глупости и не надо их читать.
> Нет, только не понимающие тему
А аргументировать?
> Какое это отношение имеет к БЭКАПУ?
Бэкап не информация и хранить её нигде не надо. Вот ещё глупости!
> Файлы в бэкапе не должны изменяться. Вообще. Никогда. На то они и БЭКАП.
Эм, а сам бекап это, простите, что?
> Какие Enterprise-class NAS автор вообще видел
В Enterprise-class автор видит только SAN, а на остальное смотрит с недоумением
> Ерунда снова какая-то.
А вы в нутаниксе точно работаете? Прямо за деньги?
Вас тема насов ну совсем как то задела. Неконструктивный диалог получается…
>> Даже для самых банальных действий файл надо скачать, изменить и залить обратно.
>Файлы в бэкапе не должны изменяться. Вообще. Никогда. На то они и БЭКАП.
Автор, очевидно, имел в виду ситуацию, что, начиная с прошлогодней версии 8, Veeam Backup & Replication использует по умолчанию метод Forward Incremental Forever, который как раз файл полного бэкапа постоянно обновляет (после каждого инкремента), «инжектируя» в него данные самого старого инкремента («самый старый» определяется согласно установленной retention policy). Аналогично метод Synthetic Full Copy, который существует уже давно, также постоянно обновляет файл синтетической полной копии.
>Файлы в бэкапе не должны изменяться. Вообще. Никогда. На то они и БЭКАП.
Автор, очевидно, имел в виду ситуацию, что, начиная с прошлогодней версии 8, Veeam Backup & Replication использует по умолчанию метод Forward Incremental Forever, который как раз файл полного бэкапа постоянно обновляет (после каждого инкремента), «инжектируя» в него данные самого старого инкремента («самый старый» определяется согласно установленной retention policy). Аналогично метод Synthetic Full Copy, который существует уже давно, также постоянно обновляет файл синтетической полной копии.
Время работы установлено 10 минут, эмулировали прогон reverse increment и в итоге мы имеем 60 iops со средней пропускной способностью в 31051 KB/s. Не забываем разделить на три, перевести KB/s в MB/s и получаем эффективную скорость создания бэкапа 10,35 MB/s.
Если не ошибаюсь, в обзоре этого метода мне сказали что очистка запускается уже после копирования очередного инкремента. В этом случае окно бекапа не увеличивается, а лишь откладывается завершение задачи и I/O можно принебречь — пусть хоть весь день лопатит данные, главное чтобы успел до следующего окна.
Абсолютно верное наблюдение! — просто фокус статьи был именно на операциях I/O на хранилище данных. Если бы анализ затрагивал еще и операции I/O на исходной (резервируемой) машине, то мы бы действительно увидели, что она освободилась от нагрузки, связанной с операциями бэкапа гораздо раньше, чем хранилище.
Но без анализа возможностей исходной машины можно сделать неверные выводы! Как раз у нас похожие вопросы есть с ESXi хостами. И то, как делает бекапы Veeam, не позволяет (?) сделать их быстрее 30 Мб/сек! Возможности целевого хранилища не при чем.
Вы можете описать вашу ситуацию более подробно? Можно в личку.
За редким исключением скорость создания бекапа зависит от трёх вещей: скорость чтения с хранилища хоста, скорость записи в репозиторий бекапов и линия связи между компонентами т.е. виртуалка на этот процесс может влиять только косвенно, например, сильно загружая продакшн сторейдж.
Эта статья именно про сторейдж бекапов и как его не сделать узким местом всей системы.
Veeam старательно выжимает максимум из доступных ресурсов и даже иногда слишком хорошо, поэтому мы включили функцию искусственного снижения производительности. Писал про это здесь.
За редким исключением скорость создания бекапа зависит от трёх вещей: скорость чтения с хранилища хоста, скорость записи в репозиторий бекапов и линия связи между компонентами т.е. виртуалка на этот процесс может влиять только косвенно, например, сильно загружая продакшн сторейдж.
Эта статья именно про сторейдж бекапов и как его не сделать узким местом всей системы.
Veeam старательно выжимает максимум из доступных ресурсов и даже иногда слишком хорошо, поэтому мы включили функцию искусственного снижения производительности. Писал про это здесь.
вопрос к экспертам veeam backup: выбираем бюджетный способ хранения второй (offsite) копии бeкапов. имеем десяток виртуалок и планируем использовать veeam backup, позже возможен рост числа виртуалок. один из рассматриваемых вариантов — windows 2012 сервер на четыре диска (типа hp microserver). также планируем дедуплицировать бeкапы при помощи Windows 2012. будет ли верным решением использовать raid10? или просто оставить четыре отдельных диска? как найти баланс между скорострельностью, надежностью и эффективным использованием дисковой ёмкости? :) вроде вторая копия, надежность менее важна, дисковая ёмкость важнее…
Дедуплицировать бэкапы уже дедуплицированые в Veeam не лучшая идея. Примерно как пытаться ужать в архив сотню jpg и потом удивляться почему место не только не сэкономилось, а архив стал занимать еще больше чем файлы до этого. А в остальном вполне себе вариант. Вот только если рэйд, то лучше софтовый, что бы в случае чего не искать второй такой же микросервер или аналогичный Raid контроллер. Ну и тут все может еще упереться в пропускную способность канала между площадками.
P.s. Я не эксперт по Veeam, но по работе сталкивался с ним. Мое мнение — это только мое мнение и все :).
P.s. Я не эксперт по Veeam, но по работе сталкивался с ним. Мое мнение — это только мое мнение и все :).
Да, включать дополнительную дедупликацию на уровне системы не лучшая затея. Даже крайне не рекомендованная.
Будет неплохая скорость записи, но всем операциям чтения будет предшествовать регидрация данных и общая производительность будет на крайне низком уровне. А выигрыш по месту будет копеечным.
И я лично плохо отношусь к raid10 из 4-х дисков т.к. надежность этой конструкции больше кажется, чем есть на самом деле.
Просто диски тоже можно оставить, создать на каждом свой репозиторий и бекапить разные машины. Тут вопрос исключительно в том, насколько критично потерять информацию на офсайте.
Будет неплохая скорость записи, но всем операциям чтения будет предшествовать регидрация данных и общая производительность будет на крайне низком уровне. А выигрыш по месту будет копеечным.
И я лично плохо отношусь к raid10 из 4-х дисков т.к. надежность этой конструкции больше кажется, чем есть на самом деле.
Просто диски тоже можно оставить, создать на каждом свой репозиторий и бекапить разные машины. Тут вопрос исключительно в том, насколько критично потерять информацию на офсайте.
спасибо за советы. я рассчитывал задействовать дедупликацию Windows 2012 после прочтения вот этой статьи:
www.veeam.com/blog/how-to-get-unbelievable-deduplication-results-with-windows-server-2012-and-veeam-backup-replication.html
вроде бы deduplication friendly compression и дедупликация Windows 2012 server показывают сказочные результаты :) статья устарела?
www.veeam.com/blog/how-to-get-unbelievable-deduplication-results-with-windows-server-2012-and-veeam-backup-replication.html
вроде бы deduplication friendly compression и дедупликация Windows 2012 server показывают сказочные результаты :) статья устарела?
Классический сферический маркетинг в вакууме. Теоретически показывает на право, практически на лево, а в вас может показать вперёд )
В любом случае лучший выход — прогнать несколько раз тестовое задание и всё станет понятно.
Если переносить на офсайт будете через backup copy job, то не забудьте изменить настройки первичного бекапа иначе смысл пропадает.
В любом случае лучший выход — прогнать несколько раз тестовое задание и всё станет понятно.
Если переносить на офсайт будете через backup copy job, то не забудьте изменить настройки первичного бекапа иначе смысл пропадает.
Раз пошла пьянка про дедупликацию томов средствами Windows Server 2012 R2 на которых хранятся архивы сделанные Veeam B&R 8, я пожалуй, выскажу свой практический опыт:
Вот прямо сейчас — от 9 до 35 процентов.
от 9% на томах куда бэкапится Exchange+AD DC.
~35% на томах куда бэкапятся разносортные виртулаки с sql, файлопомойками, терминальниками и etc.
Статистика с отдельного сервера для горячих бэкапов. Тома в массе своей на основе RAID5 из 1 или 2TB обычных sata винтов. Ночью бэкапит, днем дедуплицирует. По быстродействию претензий нет, если прокурить и оптимизировать WeeklyScrubbing у дедупликации
Вот прямо сейчас — от 9 до 35 процентов.
от 9% на томах куда бэкапится Exchange+AD DC.
~35% на томах куда бэкапятся разносортные виртулаки с sql, файлопомойками, терминальниками и etc.
Статистика с отдельного сервера для горячих бэкапов. Тома в массе своей на основе RAID5 из 1 или 2TB обычных sata винтов. Ночью бэкапит, днем дедуплицирует. По быстродействию претензий нет, если прокурить и оптимизировать WeeklyScrubbing у дедупликации
Чем больше в задании схожих виртуалок, а ещё лучше если они созданы из одного шаблона, тем лучше будет рейт дедупликации. В таких средах дедуп рейт под 400% нормальное явление.
спасибо, интересно. у вас даже RAID5 справляется с нагрузкой. я думал в сторону RAID10 именно из-за скорострельности.
«Скорострельность» в первую очередь зависит от количества шпинделей, а тип Raid только вносит свои коррективы. Если утрировать, то Raid5 из 9 дисков будет быстрее, чем Raid10 из 4-рех.
мы планируем hp microserver на четыре диска (см мой коммент выше).
Я видел то, что выше. И конкретно про ваш случай с hp microserver я бы собирал два софтовых Raid1 средствами самой OS. И использовал их как два отдельных репозитория для Veeam. Что бы исключить зависимость от испарвности/неисправности встроенного Raid-контроллера, который все равно «ненастоящий», а такой же полусофтовый (использующий ресурсы CPU). В этом случае, при необходимости, винты можно перекинуть в любой другой сервер/компьютер и более-менее спокойно забрать с них данные.
P.s. Но опять же в данном случае мое мнение не претендует на истинность :).
P.s. Но опять же в данном случае мое мнение не претендует на истинность :).
Не совсем понял, что значат 9% и 35%. Это объем исходных данных после дедупликаци?
Если да то какой дедупликации?
Используется Veeam. Задания настроены с использованием встроенной дедупликации. После этого на полученных дедуплицированных архивах применяется постпроцесная Windows дедупликация и объем архивов уменьшается до 9%-35% от исходного объема архивов? Или уменьшается еще на 9%-35% от исходного объема архивов?
Можно подробнее рассказать? :)
Если да то какой дедупликации?
Используется Veeam. Задания настроены с использованием встроенной дедупликации. После этого на полученных дедуплицированных архивах применяется постпроцесная Windows дедупликация и объем архивов уменьшается до 9%-35% от исходного объема архивов? Или уменьшается еще на 9%-35% от исходного объема архивов?
Можно подробнее рассказать? :)
Подробности 
Я думаю оснастка Windows Server привычна и понятна.
Я думаю оснастка Windows Server привычна и понятна.
Да это немного проясняет картину. Но вы так и не ответили. Встроенная дедупликация Veeam в заданиях бэкапа при этом используется или нет?
Мы рекомендуем в Veeam выставлять dedup friendly при использовании дедупликации на уровне хранилища.
Нажал «Опубликовать» раньше чем выразил мысль полноценно :/ а время на редактирование ограничено
Veeam берет виртуалку, жмет её и кладёт в файловое хранилище. После этого сверху Windows Server дедуплицирует.
Поскольку в логах выполнения задачи у Veeam стоит почти везде deduplication x1.0, то я полагаю, что Veeam не дедуплицирует, а просто жмет. BackupProxy руки развернуть еще не дошли, хотя инженеры Veeam предлагали помочь с развертыванием. У нас Veeam закрывает не весь цикл резервного копирования в виду его фришной версии, а нишевую часть с тяжелыми виртуальными машинами, которые VDP не бэкапит в приемлемые сроки. Поэтому я не могу сейчас сказать точно на предмет «не дедупликации в самом Veeam» из-за отсутствия BackupProxy или из-за того что редакция Free.
Veeam берет виртуалку, жмет её и кладёт в файловое хранилище. После этого сверху Windows Server дедуплицирует.
Поскольку в логах выполнения задачи у Veeam стоит почти везде deduplication x1.0, то я полагаю, что Veeam не дедуплицирует, а просто жмет. BackupProxy руки развернуть еще не дошли, хотя инженеры Veeam предлагали помочь с развертыванием. У нас Veeam закрывает не весь цикл резервного копирования в виду его фришной версии, а нишевую часть с тяжелыми виртуальными машинами, которые VDP не бэкапит в приемлемые сроки. Поэтому я не могу сейчас сказать точно на предмет «не дедупликации в самом Veeam» из-за отсутствия BackupProxy или из-за того что редакция Free.
Прокси автоматом ставится на той же машине, что и консоль вима т.к. это обязательная часть.
Если в репорте deduplication x1.0, значит в рамках бекапного файла достойно дедуплицировать не получилось и применилось только дефолтовое сжатие.
Если есть возможность, попробуйте восстановить из бекапа тяжелый файл на пару гигабайт. Интересно с какой скоростью пойдёт рестор.
Если в репорте deduplication x1.0, значит в рамках бекапного файла достойно дедуплицировать не получилось и применилось только дефолтовое сжатие.
Если есть возможность, попробуйте восстановить из бекапа тяжелый файл на пару гигабайт. Интересно с какой скоростью пойдёт рестор.
Если честно, не вижу проблем с скоростью, но в конфигурации:
Виртуалка-файлсервер с включенной дедупликацией (Deduplication Rate = 38%) на разделе с файлопомойкой, заархивированная (Optimal, Compression x1.1) Veeam B&R8 и аккуратно положенная на локальный массив RAID5 на бэкап сервере, после чего раздел с архивом продедуплицирован еще раз поверх — на выходе выдает скорость восстановления 1GB файла архива почты PST на другой массив RAID1 этого же бэкап сервера со скоростью ~70 мегабайт в секунду (если просто копировать файлы с RAID5 на RAID1, то там ~160мб/сек). Добраться до файла по менюшкам труда тоже не составило, зависаний нет.
Восстанавливать в виртуалку не побывал, но не думаю, что результат будет сильно отличаться, потому что при бэкапе бутылочным горлышком выступает источник примерно на 60-80 мегабайт в секунду.
Виртуалка-файлсервер с включенной дедупликацией (Deduplication Rate = 38%) на разделе с файлопомойкой, заархивированная (Optimal, Compression x1.1) Veeam B&R8 и аккуратно положенная на локальный массив RAID5 на бэкап сервере, после чего раздел с архивом продедуплицирован еще раз поверх — на выходе выдает скорость восстановления 1GB файла архива почты PST на другой массив RAID1 этого же бэкап сервера со скоростью ~70 мегабайт в секунду (если просто копировать файлы с RAID5 на RAID1, то там ~160мб/сек). Добраться до файла по менюшкам труда тоже не составило, зависаний нет.
Восстанавливать в виртуалку не побывал, но не думаю, что результат будет сильно отличаться, потому что при бэкапе бутылочным горлышком выступает источник примерно на 60-80 мегабайт в секунду.
Я Free версию Veeam не использовал. Потому хочется докопаться до истины.
В недрах настроек Job-а в резделе Storage=>Advanced=>вкладка Storage стоит чекбокс «Enable inline data deduplication (recomended)»? Поле «Compression level» настроено?
Если посмотреть отчет (Report) по завершенному Job, то что то подобное есть?
Просто хочется для себя понять. Действительно ли встроенная дедупликация Windows может приносить дополнительную выгоду в дополнение к средствам Veeam? Или все таки нет? :)
В общем если у вас и Veeam дедуплицирует и выполняет компрессию данных. А затем Windows еще добавляет компактности хранимым данным от себя, то это крайне интересные факт :).
В недрах настроек Job-а в резделе Storage=>Advanced=>вкладка Storage стоит чекбокс «Enable inline data deduplication (recomended)»? Поле «Compression level» настроено?
Если посмотреть отчет (Report) по завершенному Job, то что то подобное есть?
Просто хочется для себя понять. Действительно ли встроенная дедупликация Windows может приносить дополнительную выгоду в дополнение к средствам Veeam? Или все таки нет? :)
В общем если у вас и Veeam дедуплицирует и выполняет компрессию данных. А затем Windows еще добавляет компактности хранимым данным от себя, то это крайне интересные факт :).
У меня к вам ещё вопрос, про полный интерфейс в VB&R FREE. Все ли функции полного интерфейса сохраняются навсегда? (free forewer) Или часть функционала пропадает через N дней?
Будет неприятно, настроил кучу всего… например, репозитории а они через 30 испытательных дней превратятся в тыкву?
Будет неприятно, настроил кучу всего… например, репозитории а они через 30 испытательных дней превратятся в тыкву?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Грамотно подбираем и тестируем хранилище своих бекапов