Эта статья написана для тех, кто хочет познакомиться, а возможно и попробовать в действии современный продукт для резервного копирования и восстановления данных Arcserve Unified Data Protection, или коротко, Arcserve UDP. Продукт можно без проблем загрузить с сайта разработчика – www.arcserve.com и спокойно гонять в течение месяца без всяких лицензионных ключей. Но не всё в нём лежит на поверхности, поэтому позвольте мне разъяснить некоторые тонкости архитектуры и функционирования Arcserve UDP.


Первым делом отмечу, что в основе продукта лежит идеология копирования образов дисков. Диск условно делится на блоки (от 4 до 32 Килобайт), и далее вся работа производится именно с блоками данных.
Такой подход, по сравнению с копированием файлов, обладает рядом преимуществ.

Несмотря на то, что копируем мы образ диска, восстанавливать мы можем как диск целиком, так и отдельные его элементы: файлы, каталоги, атрибуты Active Directory, отдельные базы данных MS SQL, документы Exchange, SharePoint и некоторые другие.

Три главные составляющие части Arcserve UDP – это агент, консоль и сервер хранения резервных копий.

Агент

Прежде всего отмечу, что теоретически, для резервного копирования достаточно одного лишь агента. Агент – основная тягловая сила, боевая единица. Агент устанавливается на машину, для которой нужно выполнять резервное копирование, обладает собственным веб-интерфейсом, планировщиком запуска заданий, способен складывать резервные копии на указанные диски (локальные или сетевые), поддерживать нужную «глубину» резервного копирования, то есть удалять устаревшие резервные копии.

Если у вас всего один компьютер, то вам может хватить и одного агента. Смотрите вот эту статью, например.

В обязанности агента также входит контроль изменений блоков данных на диске. Ведь для того, чтобы понять, какие блоки данных необходимо отправить в инкрементную резервную копию, мы должны знать, кто из них изменился, а кто – нет с момента последнего копирования. И если у файлов такую информацию мы можем получить в операционной системе (архивный бит в Windows, timestamp в других системах), то блоки данных таких атрибутов не имеют (за исключением, пожалуй, механизма Change Block Tracking в vSphere). Поэтому агент сам, установив «change tracking» драйвер в операционной системе, ведёт ведомость изменений, побитовую карту диска, где каждому блоку данных соответствует один бит. В дальнейшем эта ведомость используется при создании инкрементных резервных копий.


Агент может складывать резервные копии на любой диск, например, дополнительный внутренний диск, внешний диск, сетевую папку. Кроме того, агент может складывать резервные копии на сервер хранения резервных копий (Recovery Point Server, RPS).



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

Сервер хранения резервных копий

Сервер хранения резервных копий – это программный компонент, установленный на сервере с операционной системой Windows.
Зачем он нам нужен, если агент может складывать резервные копии куда угодно. Для чего что-то городить?

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

Практически это означает, что резервные копии машин с похожими операционными системами будут иметь много идентичных блоков, которые сохранятся только один раз. И то, что повторные полные резервные копии будут по объёму походить на инкрементные.
Дедупликация производится на лету, то есть во время и со скоростью резервного копирования, что недостижимо при, например, дедупликации NTFS, когда занятое место на диске может уменьшиться только на следующий день.

И дедупликация начинается ещё на агенте (source-side deduplication). То есть мы экономим не только место для хранения резервных копий, но и сетевой трафик. А сетевой трафик (как вам скажет любой администратор), это то, что больше всего влияет на время резервного копирования, и больше всего доставляет головной боли. Ниже проиллюстрировано, как повторяющиеся блоки данных отбрасываются ещё до передачи их по сети, а передаются только новые, уникальные:



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

Это самый простой способ защитить свои резервные копии от потери. Создайте второй сервер и держите его в другом помещении, здании, городе.



При этом глубина хранения на разных серверах может быть разной. На первом – храним только оперативные копии за последние дни, на втором – держим их уже в течение года.

Также можно выстроить цепочку из серверов, когда резервные копии, лежащие на сервере в основном вычислительном центре, будут реплицироваться на сервер в резервном вычислительном центре, а оттуда – на сервер в облаке, например.



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



Также легко организовать консолидацию резервных копий из серверов филиалов на сервер в центральном вычислительном центре.

Замечу, что при репликации с одного сервера хранения резервных копий на другой также работает дедупликация. То есть происходит такая же экономия сетевого трафика, как и при общении между агентом и сервером хранения резервных копий.

Наконец, сервер хранения резервных копий разгружает агента, беря на себя функции поддержания заданного количества резервных копий, удаляя старые. При этом, если копия, следующая за той, что мы удаляем, является инкрементной, то она будет превращена в полную путём дописывания в неё недостающих блоков данных из удаляемой копии.

Кроме того, сервер хранения резервных копий берёт на себя составление каталога файлов в образе диска, также освобождая агента от такой работы.

Консоль

Консоль служит для централизованного управления процессом резервного копирования. Когда у вас много агентов, то управлять каждым из них по отдельности неудобно. На консоли создаются правила резервного копирования, и затем доносятся до агентов. После чего агенты воплощают эти правила в жизнь, самостоятельно отслеживая время запуска и выполняя необходимые операции.

Отмечу, что консоль не пропускает через себя потоки данных резервных копий. И поэтому мы не называем её «сервером» резервного копирования. Более того, если консоль выключить во время резервного копирования, то это никак не повлияет на результат. Тем не менее, консоль полезна и при копировании – для оперативного сбора журналов агентов и построения отчетности.

Консоль работает через веб-интерфейс.

Модуль работы с магнитными лентами

По желанию мы можем установить модуль работы с магнитными лентами. Фактически – это продукт Arcserve Backup, который в минимальной комплектации, позволяющей переливать данные Arcserve UDP на ленту, включен в состав Arcserve UDP, даже в простейшей лицензии «Standard». Тем не менее, конфигурировать копирование на ленту мы можем из единой консоли Arcserve UDP.

Запись на магнитную ленту – это всегда дополнение к резервному копированию на диск, второй шаг. Мы обязательно должны сначала выполнить копирование на диск, а потом уже переносить данные на ленту.

Если необходимо копировать данные непосредственно на ленту, минуя диск, то можно воспользоваться полнофункциональным продуктом Arcserve Backup, входящим в состав комплектаций Premium и Premium Plus продукта Arcserve UDP.

Виртуальная машина, как способ быстрого восстановления

(подробнее смотрите вот эту статью)

Мы можем превращать резервные копии (в том числе физических серверов) в виртуальные машины сразу после их получения. Такой процесс называется Virtual Standby и его также производит агент. Этот же или другой агент может осуществлять мониторинг работоспособности скопированного сервера, и запускать его виртуальную копию, если окажется, что основной сервер недоступен.

При этом виртуальная машина-копия может содержать несколько снапшотов, соответствующих нескольким последним резервным копиям. И мы, при необходимости, можем запустить виртуальную машину по состоянию на момент одной из предыдущих резервных копий, а не только на момент последней копии.



Можно также запускать виртуальную машину прямо из резервной копии, не переписывая заранее файлы на хранилище гипервизора. Необходимые для запуска виртуальной машины файлы (*.vmdk, *.vhdx) создаются «на лету» и предоставляются гипервизору по сети. Такой процесс называется «Instant VM» и также выполняется агентом.



***
Arcserve UDP – современное средство, которое позволяет эффективно организовать резервное копирование и восстановление данных, используя самые передовые технологии. Благодаря Arcserve UDP вы сможете в рамках своего бюджета достичь заданных целей:

• времени восстановления данных
• глубины истории хранения резервных копий
• соблюдения ограничений объёма для хранения резервных копий
• соблюдения ограничений объёма сетевого трафика и окон резервного копирования
• резервного копирования в распределённой среде (центральный офис и филиалы)

Для желающих самим попробовать продукт Arcserve UDP ниже приведена ссылка для скачивания (требует заполнения формы):
arcserve.com/free-backup-software-trial/?src=RU/AR//MMitroshin

Больше информации о продуктах Arcserve на русском языке вы всегда можете найти на сайте arcserve.su