Comments 15
протестировали китайскую Aishu на энтерпрайз задачах
При тестировании восстановления, например, SAP HANA пиковая скорость была высокой и соответствовала скорости системы хранения базы.
Протестировали так протестировали!
В ходе тестирования мы столкнулись с тем, что с одной из популярных библиотек AnyBackup не работает.
Можно уточнить, каким образом может быть бекапный софт несовместим с конкретной ленточной библиотекой? Нестандартный драйвер робота вместо системного, или что?
В плане же интеграции, например, с такими базами данными как SAP HANA, Sybase, Oracle и Postgress в AnyBackup этот процесс значительно упрощен сравнивая с другими enterprise решениями СРК.
С какими? В чем упрощение?
AnyBackup — более тяжелая система РК по сравнению с тем же Vinchin, предназначенная для решения более масштабных задач
А если сравнить с чем-то, что кто-то реально использовал? Commvault, NetBackup, Avamar/Networker, Veeam?
По библиотеке у нас не виделся робот в консоли, хотя драйвы отображались. Поддержка ответила, что в листе совместимости такой модели нет, сделать ничего нельзя. Хотя я уверен, что под конкретного заказчика поправят.
По упрощению в первую очередь то, что настройки все делаются через консоль, все по максимуму упрощено. Нет необходимости пилить внешние скрипты как у того же Веритаса.
По сравнению с реальными софтами я бы сказал, что по сложности сопоставимо с хорошей инсталляцией NetBackup/Commvault/Networker/TSM со своими особенностями архитектуры и потребностью почитать документацию. А вот Винчин больше похож на Вим, но у него и ориентир в первую очередь на бэкап виртуализации.
Нет не единого калькулятора цены что Aishu, что Vinchin
Вариант обращаться в Крок совсем не вариант, общались по датацентру, было все в стиле у нас нет фикс таксы, давайте торговаться о цене, можем все, при том приходили с четкой задачей
Не освещен вопрос гранулированного восстановления того же Exchange и SharePoint. Точнее отсутствие этого самого гранулированного восстановления.
Насчёт эффективности дедупа: хотелось бы какого-нибудь сравнения с тем же StoreOnce и DataDomain, тем более что есть ограниченно работающие бесплатные эплаинсы. В том числе интересно и сравнение в скорости чтения. Также можно было бы упомянуть, что нет возможности выбора где будет производится сжатие и дедуп - на клиенте или на серверах хранения.
Что такое OFS - ликбез также не помешал бы.
Нет информации про репликацию.
Короче маловато будет! :-)
Думаю, что по мере накопления опыта я еще поделюсь информацией :)
По гранулярке Exchange проверяли: восстанавливаются только базы данных целиком.
По дедупу нужно посмотреть и сравнить в лабе, займемся этим. Но в целом алгоритм правильный и полноценный, дедупликация глобальная, пока сюрпризов не было замечено.
OFS - стандартный том для хранения бэкапов, в документации мне не встречалась расшифровка.
По модулям мы пока полностью изучили и оттестировали модуль бэкапа и это заняло достаточно много времени, по остальным возможностям конечно же поделимся результатами.
Документации по настройке открытой нет…а по запросу она присылается часто на китайском языке.
Вот одного этого достаточно, чтобы не рассматривать. Это не системы из разряда «мышкой везде потыкаю, пока не заработает как надо». Разбирать фокусы автоперевода в сфере, где важна надежность и предсказуемость — самое то.
Основные все документы уже на английском и вендор их продолжает выпускать. По специфичным интеграциям типа Sybase документы скорее всего так и будут на китайском. Сюрпризы бывают (я привел их в статье), но в целом качество машинного перевода на английский очень хорошее. Я бы точно не рассматривал вопрос документации как стоп-фактор.
Мы провели достаточно большое количество интеграций и нигде не возникло сложностей с документацией.
А как такие системы делают резервные копии БД? Просто переиспользуют инструменты, предоставляемые разработчиками БД? Или у них свой подход? Если свой, то как обстоят дела с консистентностью и целостностью данных в резервных копиях?
Если по-правильному, то конечно же через интеграцию с API и утилитами от производителя СУБД. В этом случае данные забираются в понятном и консистентном формате напрямую в систему резервного копирования и также восстанавливаются. В случае с AISHU или Vinchin так и реализовано.
Но на рынке встречаются решения и без такой интеграции, в этом случае по факту выполняется скрипт, выполняющий локальный дамп БД средствами СУБД, а потом файлы с дампом забираются в СРК. Восстановление наоборот: копируем дамп обратно на клиента, средствами СУБД подтягиваем из него данные. Минусы очевидны: доп. место при бэкапе и восстановлении, более долгое выполнение бэкапа, скорее всего невозможность делать какие-либо виды копий, кроме как полные.
Бэкап в тяжелом весе: протестировали китайскую Aishu на энтерпрайз задачах