Комментарии 26
Ого! Российский разработчик бэкапа на Хабре..да еще и с советами и ноу-хау...это позитивно. Хотя бы бэкап свой у нас, похоже, есть. )
Судя по всему, нужно закладывать "соломку" заранее. Большая часть советов - изначальная настройка. Потом, я так понимаю, особо уже не оптимизировать.
Смотрю на интерфейс, и вот прям хочется спросить не Nakivo под низом у вас с темой, которая очень сильно похожа?
У меня домашняя лаба из 5 ESXi ноутов и пара серверов в дата центре.
Использую более простые продукты для бэкапа.
Посчитал на вашем сайте и получилось что при цене каждого ESXi 64к х 7машин = 448к для среды.
Пожадничал. Буду дальше бэкапить набором из жизни и палок. :)
Кстати, у КП сайта дискриминация по региональному признаку?
При попытке зайти на сайт:
И для их размещения лучше всего использовать файловую систему с максимальным размером кластера. Такой подход уменьшает фрагментацию данных в файловой системе и приводит к тому, что при работе с резервной копией дисковая подсистема может выполнить большее количество последовательных операций чтения или записи.
Откуда возьмется большая фрагментация на файловой системе, куда складывают большие файлы и удаляют большие файлы?
Отличная картинка с тортиком. :) А что там у вас за шаманство с инкрементным бэкапом? Возникает чувство, что вы нам что-то недорассказали...
раскрывает потенциал работы специального формата резервных копий “Киберпротекта” и в результате дает одновременно эффективную дедупликацию и сжатие, а также высокие скорости восстановления даже при длине цепочки 100+ точек.
Наш формат архива .tibx одна из изюминок продукта. Во многих сценариях мы рекомендуем использовать схему "Всегда инкремент" из-за ее высокой производительности и надежности. Я понимаю что практически все привыкли, что "полная копия" это самое лучшее что придумало человечество, а длинные цепочки это медленно и опасно. У нас на этот счет немного другое мнение. Ну и под капотом этого формата очень много фишек, которые позволяют нам говорить о скорости и надежности при работе даже с длинными цепочками. Но по этой теме я думаю мы сделаем отдельную статью.
Не увидел в статье заветного слова ReFS
Многопоточное чтение крупных каталогов с автоматическим разбиением на потоки присутствует?
4. Использовать резервное копирование на уровне гипервизора
По моему опыту (это был Veeam и VMWare лет пять назад) — палка о двух концах (может быть). Возможная проблема в том, что бэкап по факту делается со снимка виртуального диска VM, сделанного средствами гипервизора, а потом этот снимок надо удалить, т.е. слить с ним все накопленные изменения на разностном виртуальном диске, который в процессе бэкапа играет роль основного.
Если железо возрастное (а у меня оно было как раз возрастное) то операция слияния удаленного снимка с разностным диском может быть небыстрой. Более того, в процессе слияния есть момент, когда VM приостанавливается на время переключения с разностного основного диска на слитый. И если с железом напряжно, то приостановка, по моему опыту, запросто может затянуться на минуту, из-за чего возникают уже таймауты в сетевых протоколах (на, а про выходящий при этом из себя мониторинг я и не говорю).
Так что этот совет я бы применял с осторожностью, особенно если речь идет об ускорении.
PS Ну, а ещё он по очевидным причинам не подходит для бэкапа распределенной БД, вроде БД MS Exchange в DAG — если софт бэкапа специально не заточен под такую БД.
Все верно, снимок на уровне гипервизора нагружает датасторы при удалении снимка и тут самое критичное это создание полной копии, потому что инкременты будут делаться быстро (CBT) и диски разницы не успеют сильно набрать вес. Но если гипевизор все же держит удар, то безагентное резервное копирование выполняется значительно быстрее чем агентом внутри гостевой ОС.
Таймауты заморозки на создание и удаление снимка у VMware сейчас значительно меньше описанных Вами.
БД можно спокойно забирать из гостевой ОС если создается снимок с поддержкой приложений (БД у которых есть свой врайтеры VSS).
PS А про БД было про распределенную и там не все так просто.Например в упомянутом Exchange надо забирать только одну копию базы в DAG (и желательно, ту, которая пассивную).
Про VMware vSphere 6 ничего плохого сказать не могу.
А работа с пассивной копией БД нужна только при резервном копировании базы агентом. Если мы говорим про резервное копирование на уровне гипервизора, то тут всю подготовку обеспечивает app-consistent снимок ВМ. А мы уже забираем в бэкап всю машину, в которой уже консистентные базы. Из такой резервной копии мы можем вернуть всю машину, отдельно базы и почтовые ящики.
А работа с пассивной копией БД нужна только при резервном копировании базы агентом.
Если пытаться копировать без агента — будет еще хуже.
Потому что речь идет о распределенной БД. Для которой вожна согласованность копий между разными VM. Exchange тут чисто для примера, как нечто старое и хорошо известное, как с ним работать. Сейчас распределенные БД достаточно широко встречаются. И правила работы с ними могут быть самые разные, т.к. архитектура у них тоже разная. А потому и вряд ли получится сделать универсальное решение для их копирования.
Спасибо за советы!
У вас на сайте написано, что вы бекапите SWAP. Расскажите, пожалуйста, как вы это делаете, и зачем это может понадобиться?
Какие алгоритмы у вас используются для дедупликации?
Включаем турбо-режим: 9 способов ускорить резервное копирование