Резервное копирование Acronis Infoprotect

Основное отличие состоит в том, что агент для рабочих станций не позволяет проводить создание согласованных резервных копий с учетом состояния приложений и согласно лицензионной политики не может быть установлен на серверную ОС.

Управление процессом резервного копирования происходит в пользовательской web-портала самообслуживания Acronis.

У клиента есть возможность выбрать преднастроенную политику или осуществлять управление политиками резервного копирования в web-портале самообслуживания.

#CloudMTS не несет ответственность за работоспособность Acronis Agent на площадке Клиента. В зону ответственности #CloudMTS входит только взаимодействие с Acronis в рамках договорных отношений, время устранения неисправности находится в зоне ответственности вендора.

Основное отличие данных сценариев использования заключается только методах управления, т.к. общая стоимость в обоих вариантах рассчитывается исходя из количества Виртуальных Машин. В случае резервного копирования на уровне гипервизора, с использованием поддерживаемой решением платформы необходимо скачать и запустить соответствующий агент, после чего централизовано настроить резервное копирование требуемых Виртуальных Машин, развернутых на данном хосте. В противном случае необходимо устанавливать агент отдельно в гостевую ОС и настраивать резервирование для каждой Виртуальной Машины. В данном сценарии используются серверные агенты для Windows/Linux в зависимости от ОС. При установке Acronis самостоятельно определяет, что агент используется для резервного копирования Виртуальной Машины.

Когда нет доступа к хосту виртуализации. Например, провайдер услуги держит на хосте несколько своих клиентов, которые имеют доступ только к рабочим столам своих машин; Когда есть доступ к хосту Hyper-V, но необходимо использовать application-aware backup, т.е. сценарий, когда один и тот же бекап-файл может быть использован не только для восстановления машины целиком или же отдельного файла, находящегося внутри неё, но и элементов приложений в этой машине — ящика или письма из Microsoft Exchange, в случае использования Exchange-сервера, или же базы Microsoft SQL, в случае SQL-сервера; Когда хост виртуализации не поддерживается Acronis для безагентного бекапа – в настоящий момент без использования агента можно резервировать только машины VMware, Hyper-V и Virtuozzo. Для остальных платформ используется сценарий резервного копирования данных с помощью агентов Acronis для Windows и Linux servers. Если у заказчика, например, KVM или Xen Server, в любом случае придётся ставить агент внутрь гостевой ОС.

Безусловно. Когда встает вопрос о консолидации вычислительных ресурсов и сокращения расходов на обслуживание парка оборудования, то необходимо принимать меры. С использованием Acronis данный процесс не займет много времени и сил – нужно просто сделать резервную копию физического сервера, а после выбрать данный бэкап для восстановления, указав местом восстановления виртуальную машину на хочет. В случае VMware и Hyper-V все происходит автоматически - создаётся виртуальная машина и для нее добавляется диски нужного размера. В процессе восстановления Acronis также подменяет драйвера внутри восстанавливаемой операционной системы, так что она остается загрузочной и в виртуальной среде. В случае других сред виртуализации Виртуальную Машину нужно будет создать вручную, подготовить ios образ для восстановления – возможность загрузки будет также обеспечиваться автоматически.

Данный сценарий аналогичен описанному в предыдущем пункте, только вместо физического сервера изначальная машина виртуальная. В данном случае также необходимо сделать бекап после чего восстановить его на другой гипервизор (например, VMware на Hyper-V). Возможность загрузки в данном случае также сохраняется.

Процесс создания резервных копий более гибкий и надежнее снимков сразу по нескольким причинам:

• Создание моментальных снимков обычно является ручным процессом. Бекапы же делаются регулярно, (хоть раз в неделю, хоть раз в 10 минут).
  
• Большое количество моментальных снимков разрастается в дерево, которым трудно управлять (например, удаление старых снимков довольно затратно по времени), повреждение внутри цепочки снапшотов, разрушает всю цепочку.
  
• Обилие снимков в конечном итоге ухудшает производительность самой виртуальной машины (поскольку содержимое её дисков становится размазанным по многим файлам на стороне гипервизора).
  
• Снимки хранятся там же, где и сами диски виртуальных машин, тем самым нивелируя саму идею резервного копирования (хранить копию исходных данных подальше от них самих).
  
• Бекапы Acronis занимают меньше места по сравнению со снимками, поскольку хранят только те блоки файловой системы, которые действительно заняты данными; снимки же фиксируют диск целиком — потенциально со всем мусором давно удалённых данных.
  

Да, причем не важно, будет ли эта резервная копия физической или виртуальной машины. Развертывание возможно на гипервизорах VMware и Hyper-V. В этом случае также создается виртуальная машина, но вместо восстановления необходимо осуществить подключение бекапа к ней напрямую, как если бы он был её дисками. Поскольку бекап может располагаться далеко, такая машина может работать медленнее обычного, но главное, что непрерывность бизнеса достигнута, и время простоя будет минимальным.

У клиента есть возможность зашифровать свою информации попадающую в резервную копию собственным ключом. Настройка доступна на портале самообслуживания или напрямую в агенте.

Все бэкапы передаются/ восстанавливаются по SSL.

Облачный стородж хранит резервные копии в виде объектов, с жесткой привязкой к соответствующей организации заказчика.

Решение развернуто на базе конфигурации с резервирование 3+2+1 на уровне узла кластера, к примеру, кластер состоит из 6 узлов, каждый узел имеет 48 дисков, конфигурация такова, что мы готовы потерять 3 узла кластера, без потери информации, 1 узел кластера без потери производительности или готовы потерять 144 диска без потери данных или 48 дисков без потери производительности.

Каждый узел кластера является физическим сервером, с независимой между нодами дисковой и вычислительной подсистемой.

Сервера физически расположены в отдельных стойках, с двукратной избыточностью по питанию, каналам связи.

Сервера расположены в изолированном сетевом сегменте. Физический доступ к хранилищу резервных копий регламентируется нормами Tier3. Удаленный доступ к хранилищу присутствует у строго ограниченного списка лиц (два выделенных архитектора и руководитель отдела).

Портал расположен на гео-распределенных ресурсах компании Acronis.

Доступы к порталу организован over SSL. По умолчанию заказчику предоставлена возможность ограничения списка IP адресов, с которых возможно управление резервным копированием и восстановлением.

НЕТ. Клиенту доступен функционал пофайлового либо массового скачивания содержимого резервной копии по средствам специализированного интерфейса.

Да, но объем доступны для хранения локально равен объему купленному в облачном хранилище.