Тут нет ничего удивительного. Эта компания в свое время передала нам код, на базе которого мы строим свое решение. Многие модули очень сильно «захардкожены», но мы стараемся в первую очередь уделять время развитию и оптимизации, вместо переименования.
Это актуально только для агента. На этой версии на собирается модуль SnapAPI, который делает снимки дисков. Файловый бэкап работает. В грядущей версии 16.5 постараемся поддержать ядра до 6.4.
2) Для базовой установки нужен только RPM пакет. kernel-* пакеты нужны как раз для SnapAPI. Иначе не будет снимков дисков (блочное резервное копирование). Тут все по документации.
java-1.8.0-openjdk-headless.x86_64 запрашивается только для сервера управления, но это рудимент. Игнорируем при установке, в новой версии запрашиваться не будет.
3) При хранении данных на узле хранения нужна учетка root, все верно. Но есть обходные пути решения, не самые элегантные, но есть. Написали по этому поводу статью в базе знаний. При хранении данных на smb/nfs данной проблемы нет. Планируем в будущих версиях уйти от необходимости использовать учетную запись суперпользователя при резервном копировании.
4) По поводу снимков SpaceVM, тут нужно уточнение какие именно файлы блокируются? Снимок ВМ или резервная копия? Сейчас в 16-й версии мы не видим массовых обращений по этим проблемам. Если есть сценарий воспроизведения, приходите, будем тестировать и решать.
В плане резервного копирования, для каждой ВМ архив один. Верно. Все хеши и мета хранятся в самом архиве. По этому агентам не нужно ничем обмениваться. Агент просто начинает резервное копирование и из самого архива берет все необходимое.
1) Самый большой архив который видел в заявках клиентов был чуть больше 30 ТБ. Проблем с ним не было, просто видел его в логах. Но уверен что есть и поболее. 2) Привязка архива для ВМ идет по ID этой ВМ и ID плана. По этому в момент начала резервного копирования происходит балансировка по агентам (кому удобнее и проще), а потом агент продолжает созданный ранее архив. К агенту тут архив не привязывается. 3) Дедуп в данном случае будет в рамках последней цепочки (полная копия и ее дифы + инкременты).
Про VMware vSphere 6 ничего плохого сказать не могу. А работа с пассивной копией БД нужна только при резервном копировании базы агентом. Если мы говорим про резервное копирование на уровне гипервизора, то тут всю подготовку обеспечивает app-consistent снимок ВМ. А мы уже забираем в бэкап всю машину, в которой уже консистентные базы. Из такой резервной копии мы можем вернуть всю машину, отдельно базы и почтовые ящики.
Все верно, снимок на уровне гипервизора нагружает датасторы при удалении снимка и тут самое критичное это создание полной копии, потому что инкременты будут делаться быстро (CBT) и диски разницы не успеют сильно набрать вес. Но если гипевизор все же держит удар, то безагентное резервное копирование выполняется значительно быстрее чем агентом внутри гостевой ОС. Таймауты заморозки на создание и удаление снимка у VMware сейчас значительно меньше описанных Вами. БД можно спокойно забирать из гостевой ОС если создается снимок с поддержкой приложений (БД у которых есть свой врайтеры VSS).
Наш формат архива .tibx одна из изюминок продукта. Во многих сценариях мы рекомендуем использовать схему "Всегда инкремент" из-за ее высокой производительности и надежности. Я понимаю что практически все привыкли, что "полная копия" это самое лучшее что придумало человечество, а длинные цепочки это медленно и опасно. У нас на этот счет немного другое мнение. Ну и под капотом этого формата очень много фишек, которые позволяют нам говорить о скорости и надежности при работе даже с длинными цепочками. Но по этой теме я думаю мы сделаем отдельную статью.
Сценарий простой - многопоточная запись больших файлов на один том. Запись на диск идет по очереди от каждого потока. Если одновременно записывать 10-20 потоков, то были случаи достижения ограничения файловой системы уже на 300 ГБ размере файла архива.
Тут нет ничего удивительного. Эта компания в свое время передала нам код, на базе которого мы строим свое решение. Многие модули очень сильно «захардкожены», но мы стараемся в первую очередь уделять время развитию и оптимизации, вместо переименования.
Приветствую Вас. Давайте разберем все отдельно.
1) Linux 6.*** не поддерживаются.
Это актуально только для агента. На этой версии на собирается модуль SnapAPI, который делает снимки дисков. Файловый бэкап работает. В грядущей версии 16.5 постараемся поддержать ядра до 6.4.
2) Для базовой установки нужен только RPM пакет. kernel-* пакеты нужны как раз для SnapAPI. Иначе не будет снимков дисков (блочное резервное копирование). Тут все по документации.
java-1.8.0-openjdk-headless.x86_64 запрашивается только для сервера управления, но это рудимент. Игнорируем при установке, в новой версии запрашиваться не будет.
3) При хранении данных на узле хранения нужна учетка root, все верно. Но есть обходные пути решения, не самые элегантные, но есть. Написали по этому поводу статью в базе знаний. При хранении данных на smb/nfs данной проблемы нет. Планируем в будущих версиях уйти от необходимости использовать учетную запись суперпользователя при резервном копировании.
4) По поводу снимков SpaceVM, тут нужно уточнение какие именно файлы блокируются? Снимок ВМ или резервная копия? Сейчас в 16-й версии мы не видим массовых обращений по этим проблемам. Если есть сценарий воспроизведения, приходите, будем тестировать и решать.
В плане резервного копирования, для каждой ВМ архив один. Верно.
Все хеши и мета хранятся в самом архиве. По этому агентам не нужно ничем обмениваться. Агент просто начинает резервное копирование и из самого архива берет все необходимое.
1) Самый большой архив который видел в заявках клиентов был чуть больше 30 ТБ. Проблем с ним не было, просто видел его в логах. Но уверен что есть и поболее.
2) Привязка архива для ВМ идет по ID этой ВМ и ID плана. По этому в момент начала резервного копирования происходит балансировка по агентам (кому удобнее и проще), а потом агент продолжает созданный ранее архив. К агенту тут архив не привязывается.
3) Дедуп в данном случае будет в рамках последней цепочки (полная копия и ее дифы + инкременты).
Про VMware vSphere 6 ничего плохого сказать не могу.
А работа с пассивной копией БД нужна только при резервном копировании базы агентом. Если мы говорим про резервное копирование на уровне гипервизора, то тут всю подготовку обеспечивает app-consistent снимок ВМ. А мы уже забираем в бэкап всю машину, в которой уже консистентные базы. Из такой резервной копии мы можем вернуть всю машину, отдельно базы и почтовые ящики.
Все верно, снимок на уровне гипервизора нагружает датасторы при удалении снимка и тут самое критичное это создание полной копии, потому что инкременты будут делаться быстро (CBT) и диски разницы не успеют сильно набрать вес. Но если гипевизор все же держит удар, то безагентное резервное копирование выполняется значительно быстрее чем агентом внутри гостевой ОС.
Таймауты заморозки на создание и удаление снимка у VMware сейчас значительно меньше описанных Вами.
БД можно спокойно забирать из гостевой ОС если создается снимок с поддержкой приложений (БД у которых есть свой врайтеры VSS).
Наш формат архива .tibx одна из изюминок продукта. Во многих сценариях мы рекомендуем использовать схему "Всегда инкремент" из-за ее высокой производительности и надежности. Я понимаю что практически все привыкли, что "полная копия" это самое лучшее что придумало человечество, а длинные цепочки это медленно и опасно. У нас на этот счет немного другое мнение. Ну и под капотом этого формата очень много фишек, которые позволяют нам говорить о скорости и надежности при работе даже с длинными цепочками. Но по этой теме я думаю мы сделаем отдельную статью.
Сценарий простой - многопоточная запись больших файлов на один том. Запись на диск идет по очереди от каждого потока. Если одновременно записывать 10-20 потоков, то были случаи достижения ограничения файловой системы уже на 300 ГБ размере файла архива.