Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 867 сообщений
Cообщения с меткой

резервное копирование - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[recovery mode] “А шо эта ваш бэкап такой уставший?”*

Пятница, 22 Июля 2016 г. 13:23 (ссылка)

* А что это ваш бэкап такой несвежий? (Одесск.)







Даже самые дорогие системы, выполняющие периодическое резервное копирование (например, каждую ночь), обладают одним существенным ограничением: всё, что было сделано на компьютере после последнего резервного копирования, никак не защищено, и будет безвозвратно потеряно, если компьютер выйдет из строя.



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



Бороться с такими ситуациями призвана технология непрерывного резервного копирования (Continuous Data Protection, CDP). Всё, что записывается на диск, одновременно отправляется в резервную копию.



Рассмотрим подробнее, как это делается в продукте Arcserve RHA (Replication and High Availability) на реальных примерах в средах Windows и Linux.



Содержание



Введение

1. Архитектура

2. Установка программного обеспечения

2.1. Установка управляющих компонентов

2.2. Установка управляемых компонентов

3. Эксперименты по восстановлению данных

3.1. Восстановление файлов на заданный момент времени

3.2. Восстановление базы данных MS SQL на заданный момент времени

4. Заключение и реклама





Введение



Пусть мы имеем два сервера.



Боевой сервер (Master) содержит постоянно обновляющиеся данные. Мы следим за изменениями и ведём ведомость (журнал) изменений в виде «было -> стало», например:

















Время Содержимое файла «мытьё» Журнал изменений
10:30:51 МАМА МЫЛА РАМУ
10:30:52 МАМА МЫЛА ПАПУ Файл «мытьё», смещение 10, «РАМ» -> «ПАП»


Журнал изменений постоянно пересылается на резервный сервер (Replica) и применяется к его файлам. Таким образом файлы боевого и резервного серверов становятся идентичными.



Некоторые детали:


  • Изменения отслеживаются на уровне байтов, то есть при изменении одного байта журнал будет содержать информацию только об этом байте, а не о всём блоке данных;

  • Журнал изменений пересылается по обычной IP-сети, то есть разнести боевой и резервный серверы можно на значительные расстояния, в том числе, в разные города;

  • При разрыве соединения данные накапливаются в буфере и, как только связь восстановится, будут переданы и применены к резервному серверу;

  • История изменений (в заданном объёме, например, последние 500 Мегабайт) сохраняется на резервной машине и может быть применена в обратной последовательности, вернув содержимое файлов в состояние на определённый момент времени.





1. Архитектура







Для того, чтобы описанная выше схема заработала, нам потребуется установить на машины Master и Replica компонент, именуемый Engine, который берёт на себя основную работу по отслеживанию изменений в файлах и репликации данных с одной машины на другую.



Для того, чтобы сконфигурировать работу этих двух Engine, установим на ещё одну машину (Manager) сервис управления (Control Service). Эта машина требуется только для конфигурации, получения отчётов и запуска отдельных действий на управляемых машинах. Она не должна быть постоянно включенной.



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





2. Установка программного обеспечения



Скачаем Arcserve RHA (iso или zip) с сайта разработчика (как указано на странице arcserve.zendesk.com/hc/en-us/articles/205009209-RHA-R16-5-SP5-ARCSERVE-RHA-16-5-SP5 ):



Продукт работает 30 дней без лицензионных ключей.





2.1. Установка управляющих компонентов



Начнём с того, что установим Control Service на управляющую машину (Manager).



Для его работы требуется .NET Framework 3.5.



В Windows 2012R2 .NET Framework 3.5 устанавливается так.
В Server Manager выбираем Manage -> Add Roles and Features. Отмечаем галочкой “.NET Framework 3.5 Features”.







Важно! Нужно явно указать, где на дистрибутиве Windows находится этот компонент. Для этого на следующем экране нажать “Specify an alternate source path”:







В моём случае путь выглядит вот так (D: — DVD c дистрибутивом Windows):









Теперь запускаем Setup.exe с дистрибутива Arcserve RHA и выбираем “Install Components”:







На следующем экране выбираем “Install Arcserve RHA Control Service”. (Особенность: на слова “Install Arcserve RHA …” кликнуть не получается, а на “… Control Service” – получается):







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







Будем запускать сервис от имени Local System:







Следующий экран касается возможности иметь две управляющих машины для повышения отказоустойчивости. Мы для целей тестирования ограничимся одной:







После завершения установки соединимся интернет-браузером с машиной Manager на порту 8088. Войти можно под пользователем, у которого есть права локального администратора на машине Manager:







Мы получим доступ к странице, на которой будет публиковаться статистика работы различных машин. Но для реального управления нам потребуется скачать с этого сайта и запустить windows-утилиту “Arcserve RHA Manager”. Её можно запускать уже не на сервере, а на рабочей станции (например, Windows 7 или 10). Для скачивания нажмём на ссылку “Scenario Management”:







После предупреждений безопасности должна запуститься программа “Arcserve RHA Manager”:







Эта программа и в дальнейшем будет запускаться только с веб-страницы.





2.2. Установка управляемых компонентов



На машины Master и Replica установим рабочие компоненты – Engine.



Можно установить их локально с дистрибутива, а можно – удалённо. Для удалённой установки на сервер требуется, чтобы у сервера была установлена роль “File Server”:







Если роль “File Server” установлена на машинах master и replica, то на машине Manager мы можем обратиться к “\\master\C$” и “\\replica\C$”.



Из утилиты Arcserve RHA Manager, о которой шла речь в предыдущем разделе, запустим удалённую установку через меню “Tools -> Launch Remote Installer”.







На следующем экране нажимаем кнопку “Start host discovery” (1) и получаем список машин из кэша Active Directory.



Выделяем машины master и replica и добавляем их в список кандидатов на установку Engine при помощи кнопки “Add” (3)







На следующем экране введём пользователя (администратора домена), под которым будет выполняться удалённая установка:







Далее убеждаемся, что оба сервера (master и replica) позволяют выполнить удалённую установку и помечены галочками:







На следующем экране введём пользователя, под которым будет запускаться служба Engine.



Для целей непрерывного резервного копирования достаточно пользователя с правами локального администратора (Local System). А вот если мы хотим использовать функционал High Availability, когда резервная машина сможет изображать из себя вышедшую из строя основную машину, то нам нужно запускать сервис под доменным администратором. Описанный ниже пример из раздела () требует именно таких полномочий:







Нажимаем всякие Next -> Install -> Yes и ждём завершения установки:









3. Эксперименты по восстановлению данных





3.1. Восстановление файлов на заданный момент времени





Создадим на машине Master каталог “C:\Ax-уехала-жена\” и положим туда файлы:



Таня.jpg



Лена.jpg



Джоконда.jpg



Создадим сценарий репликации этого каталога на машину Replica. В меню “Arcserve RHA Manager” выберем Scenario -> New

Первый экран мастера создания сценариев оставляем без изменений:







На втором экране также ничего не меняем – там должен быть выбран сценарий репликации файлов (File Server):







Выберем в качестве основной машины сервер Master, а в качестве резервной – Replica:







На следующем экране видим подтверждение того, что служба Engine установлена на обеих машинах. Если мы не установили её ранее, то можем сделать это удалённо отсюда.



На следующем экране выберем исходный каталог “C:\Ax-уехала-жена\” на машине Master:







На следующем экране нам предложат реплицировать этот каталог в каталог с таким же именем на машине Replica. Согласимся:







На следующем экране ничего не меняем:







А вот здесь нам нужно выставить параметр “Data Rewind” в “On”, чтобы иметь возможность восстанавливать данные на произвольный момент времени в прошлом:







Наконец, нам скажут, что сценарий не содержит ошибок:







Запустим сценарий, нажав кнопку “Run Now”:







На главном экране мы увидим, как работает сценарий. Заданный каталог быстро синхронизируется (станет одинаковым на основной и резервной машине), и теперь любое изменение в каталоге на машине Master приведёт к аналогичному изменению его копии на машине Replica.







Выполним три действия на машине Master:

1. Изменим файл Джоконда.jpg







2. Сотрём файл Таня.jpg



3. Добавим файл Маша.jpg



Убедимся, что на машине Replica с файлами произошло то же самое.



Теперь мы хотели бы вернуть Джоконде прежний облик. Для этого отмотаем время назад на машине Replica, воспользовавшись инструментом Data Recovery.



Сначала мы должны остановить сценарий (меню Tools -> Stop)



Затем щёлкнуть мышью на машине Replica и вызвать меню Tools -> Data Recovery:







Нажав в следующем окне кнопку “Select Recovery Point”, попадаем вот в такое окно, где нужно:



(1) Установить просмотр всех временных точек, на которые возможен откат по времени

(2) Нажать кнопку Apply

(3) Выделить самую первую точку, когда Джоконда ещё не была повреждена

(4) Нажать на кнопку “OK”







Затем нажимаем кнопку “Run”:







Проверяем, что произошло с файлами на машине Replica.



— Джоконда.jpg снова вернулась в начальное состояние

— Маша.jpg исчезла

— Лена.jpg появилась



Именно для того, чтобы не потерять Машу.jpg, мы не стали восстанавливать данные на обеих машинах. Теперь достаточно переписать файл “Джоконда.jpg” на машину Master, и мы снова получим в работу неиспорченный файл, не затрагивая все остальные.





3.2. Восстановление базы данных MS SQL на заданный момент времени



Предположим, что MS SQL установлен на машине Master. На машину Replica можно MS SQL не ставить, тогда она будет служить лишь хранилищем копии каталога DATA:







Сценарий репликации MS SQL похож на сценарий репликации файлов, но добавляются две вещи, которые облегчают нам жизнь:



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





2. при восстановлении данных на основную машину (Master) сервисы MS SQL будут автоматически потушены и переведены в режим ручного запуска. После восстановления всё вернётся на место:





Предположим, что кто-то забыл написать “where” в команде “update”:



begin transaction;
update dbo.Table_1 set name='Сидоров';
commit;


(кто сам такое делал – поймёт глубину падения).



Так же, как и в предыдущем случае, останавливаем сценарий репликации, запускаем “Tools->Data Recovery”, но выбираем восстановление не только на резервную машину, но и на основную:







Остаётся только выбрать точку во времени, предшествующую моменту порчи данных, и провести восстановление:









4. Заключение и реклама



В этой статье мы рассмотрели только основные возможности продукта Arcserve RHA, направленные на восстановление данных на заданный момент времени в прошлом. То есть, расшифровали только половину названия “Replication and High Availability”. В следующей статье вы увидите, как реализуется вторая часть названия – High Availability. Мы посмотрим, как вышедшая из строя машина (физическая или виртуальная) будет подменятся резервной машиной, содержащей актуальную копию данных.



[Реклама] В настоящее время, до конца сентября 2016 года, вы можете бесплатно получить продукт Arcserve RHA, приобретая продукт Arcserve UDP Premium Plus по цене Arcserve UDP Premium.

Подробнее можете узнать у партнеров компании Arcserve.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306194/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Знакомство с Veeam Agent for Linux

Среда, 20 Июля 2016 г. 14:44 (ссылка)

Как вы, возможно, уже знаете, в недалеком будущем увидит свет наш новый продукт — Veeam Agent for Linux. И уже сейчас все желающие могут оценить это решение в ходе анонсированной программы бета-тестирования. Чтобы получить доступ к бета-версии, нужно зарегистрироваться здесь, и вы получите на email ссылку для скачивания. Обратите внимание, что период бета-тестирования закончится 1 сентября 2016 года – затем вы сможете установить уже релизную версию.



Итак, что же умеет бета? За ответом добро пожаловать под кат.







Veeam Agent for Linux — это наше новое бесплатное решение для резервного копирования машин под управлением Linux. Его основные характеристики:


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

  • Работает с машинами семейств Debian и RedHat. Доступен в виде пакетов RPM и DEB.

  • Поддерживаются версии ядра Linux, начиная с 2.6.32 (т е. даже если у вас очень старенькая инсталляция, то и она будет поддержана при условии, что у вас стоит официальное ядро для данного дистрибутива).

  • Работает с 32-битной и 64-битной архитектурой.









Решение включает в себя следующие компоненты:


  • Veeam Agent for Linux Service – компонент, отвечающий за работу со всеми задачами и необходимыми ресурсами. Регистрируется как обычный сервис, автоматически стартует при старте ОС и работает в фоновом режиме.

  • Veeam Agent for Linux Job Manager – процесс, который запускается вышеназванным сервисом для каждой сессии задания резервного копирования и отвечает за ее работу.

  • Veeam Agent – это, собственно, рабочая лошадка, которая выполняет операции передачи данных: во время бэкапа копирует их в репозиторий, а во время восстановления – наоборот, а также выполняет дедупликацию, компрессию, и т.д.

  • Veeam Agent for Linux Driver – модуль ядра Linux, который отвечает за создание снапшотов томов вашей машины.

  • SQLite database engine — используется для хранения конфигурации; если у вас его нет – то поставится в процессе установки продукта.



Veeam Agent for Linux умеет выполнять резервное копирование на уровне образа, работая внутри гостевой ОС, причем можно делать бэкапы на уровне томов и файлов. Для создания инкрементальных резервных копий нами был разработан специальный драйвер, который отслеживает измененные блоки (его модуль динамически подгружается в ядро).



Читателей, вероятно, порадует, что этот модуль поставляется в виде исходного кода. Поскольку версий ядра великое множество, то мы решили не пытаться написать и скомпилировать бинарную версию модуля для каждой из них – в итоге вполне могло оказаться, что на какой-то из версий что-то не поддерживается, и соответствующая часть пользователей не сможет использовать решение. Поэтому мы решили пойти по традиционному для Linux-сообщества пути – поставлять исходный код и компилировать модуль в процессе установки продукта, уже конкретно для той версии ядра, с которой ему предстоит работать. Пользователю не придется ничего компилировать вручную – все необходимые операции выполнит менеджер пакетов вашего дистрибутива: проверит наличие необходимых зависимостей, выдаст список недостающих, чтобы вы могли все поправить, и в ходе инсталляции автоматически скомпилирует и установит наш модуль.



Выполняем установку



Для работы решения необходимо наличие пакета Dynamic Kernel Module Support (DKMS), который требуется для компиляции модуля ядра, а также пакета LVM2, который требуется для поддержки операции с томами LVM. Если их нет на машине, то установите их – к примеру, DKMS на CentOS можно поставить из дополнительного репозитория EPEL.







После того, как прошла установка первого компонента, можно переходить к установке собственно Veeam Agent for Linux (для установки понадобятся права root):







Агент Veeam Agent for Linux устанавливается в виде сервиса, с которым затем можно работать, применяя команду veeamconfig. Для просмотра списка ее опций после команды veeamconfig введите --help. Ну и затем можно переходить уже непосредственно к работе – а там уже практически все понятно и без подсказок, но мы все же вкратце рассмотрим сначала процесс бэкапа.



Приступаем к резервному копированию



Поскольку среди пользователей Linux есть как продвинутые, так и начинающие, то мы в дополнение к командной строке предлагаем простенький графический интерфейс. Для его запуска используется командная строка – в ней вводим команду veeam. На экране появится GUI с приветственным сообщением и кнопками меню:







Чтобы создать новое задание резервного копирования, нажимаем C (Configure). Проходим по шагам мастера:


  1. Вводим имя, которое хотим дать заданию.

  2. На шаге Backup mode выбираем, хотим ли мы бэкапить всю машину (Entire machine), какой-либо том (Volume level backup) или отдельные файлы и папки (File level backup):

  3. Затем указываем тип репозитория (Destination Location), куда будут сохраняться резервные копии. Если репозитория у нас еще нет, то мастер попросит его создать. В качестве репозитория поддерживаются:


    • устройства с прямым подключением (USB, eSATA, FС и т.п.)

    • сетевые файловые системы NFS, SMB (CIFS)

    • локальное устройство хранения (не рекомендуется)



    В данном примере в качестве репозитория выбирается папка NFS с общим доступом:








  4. Тут же можно указать, сколько точек восстановления (Restore points) должно храниться в репозитории – по умолчанию 14.

  5. Затем можно настроить расписание (Schedule) для нашего задания, указав, с какой периодичностью оно будет запускаться.



После того, как все настройки сделаны, мастер предложит вам запустить задание сразу же. Если вы еще раз хотите пройтись по настройкам и, возможно, что-то поменять, можно либо вернуться к предыдущему шагу, нажав Prev, либо, если вы уже нажали Finish и вернулись в главное меню, нажать C. Для запуска задания из главного меню нажмите S. Если же вы захотите запустить задание в какой-то момент по требованию, то к вашим услугам соответствующая команда:

veeamconfig job start --name "BackupJob1"



В ходе выполнения задания по нажатию Enter можно посмотреть, что как идет и что пишется в лог:







Наше задание успешно отработало, и на экране появилась соответствующая информация в поле Status:







В репозитории на NFS-сервере теперь лежат файлы резервной копии (.VBK и .VBM), поименованные согласно названию задания и времени создания:







Имея резервную копию, можно посмотреть, как Veeam Agent for Linux умеет выполнять восстановление Linux-сервера на уровне файла, тома, или же вообще «на голое железо» — но об этом в следующем посте.



Полезные ссылки



Регистрация для участия в бета-тестировании

Комментарии и пожелания можно оставлять на нашем форуме
Original source: habrahabr.ru.

https://habrahabr.ru/post/306032/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Altaro VM Backup: резервное копирование виртуальных машин Hyper-V и VMware

Среда, 06 Июля 2016 г. 17:43 (ссылка)

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





До сих пор бытует мнение, что при всех своих преимуществах виртуализация существенно осложняет резервное копирование. Возможно, это одна из причин игнорирования компаниями потребности в защите виртуальной среды: по информации зарубежных аналитических агентств, процедуры резервного копирования охватывают менее 70% виртуальных серверов.



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



Процесс восстановления в виртуальной среде имеет свою специфику. Вместо восстановления всего образа ВМ большинство продуктов резервного копирования позволяют восстановить один файл или группу файлов ВМ. А сама резервная копия может храниться и в облаке, в удаленном ЦОД. Такой способ становится все более популярным. В этом случае данные обычно копируются локально, а затем реплицируются в облако (Cloud Backup). Резервирование в облаке не решает все проблемы локальной защиты и обеспечения высокой готовности, но защищает от аварий (DR).



Новые возможности продуктов резервного копирования помогают надежнее и быстрее восстанавливать виртуальные машины, приложения и данные в случае отказа, найти необходимый баланс между допустимым временем восстановления информации (Recovery Time Objective, RTO), допустимой потерей информации (Recovery Point Objective, RPO) и стоимостью решения. Ниже пойдет речь об одном из таких решений.



Резервное копирование – это просто



Altaro VM Backup — простое в использовании решение для резервного копирования с интуитивно понятным интерфейсом и несложной настройкой. Более 30 тыс. компаний применяют его для надежного хранения и восстановления виртуальных машин Hyper-V и VMware. Как свидетельствуют отзывы пользователей, Altaro VM Backup устанавливается в разы быстрее конкурентных решений и отличается очень удобным и понятным интерфейсом. Это ПО поддерживает резервное копирование и восстановление ВМ между разными серверами и разные типы хранилищ для резервных копий – локальные (DAS), внешние (NAS/SAN) и облачные (Cloud Backup).



Нацелено программное обеспечение  Altaro, известное ранее под названием Altaro Hyper-V Backup, на компании сегмента SMB. Именно поэтому разработчики постарались сделать его максимально простым и интуитивно понятным, но при этом обладающим всеми необходимыми малому и среднему бизнесу средствами. Выпущенная в прошлом году шестая версия продукта поддерживает резервное копирования ВМ и в среде Microsoft Hyper-V, и в среде VMware vSphere, поэтому и называется он теперь Altaro VM Backup.

Перечислим его основные особенности:




  • Поддержка Hyper-V в Windows Server 2008 R2 и старше.


  • Поддержка VMware vSphere 5,6 и старше.


  • Резервирование Exchange Server на уровне элементов.


  • Технология инкрементного резервного копирования ReverseDelta.


  • Репликация резервных копий на другую площадку.


  • Сжатие данных, уменьшающее объем резервных копий примерно на 25%.


  • Шифрование резервных копий.


  • Мгновенное восстановление на уровне файлов.


  • Восстановление в «песочницу» Sandbox Restore для проверки целостности резервной копии и самой возможности восстановить ее.


  • Поддержка Microsoft Exchange и SQL.


  • Полная поддержка Microsoft Cluster Shared Volumes.


  • Возможность восстановления ВМ на разных системах.


  • Индивидуальные, задаваемые для отдельных ВМ, политики резервирования и хранения.




Нередко системные администраторы недолюбливают средства резервного копирования, многие из которых имеют сложный пользовательский интерфейс с множеством никогда не применяемых опций, либо просто не работают и генерируют ошибки. Altaro VM Backup к таковым не относится: немногие продукты столь просты в установке и в работе. Все задачи выполняются посредством удобных процедур. Да и цена у Altaro VM Backup вполне привлекательная. В течение 30 дней Altaro VM Backup можно протестировать бесплатно. Предлагается также не ограниченная по времени бесплатная версия, но поддерживает она только две ВМ на хост-систему.



Что нового в Altaro VM Backup 6.0?



Кроме поддержки VMware версия 6.0 предлагает следующие новые средства:




  1. Централизованное конфигурирование и управление несколькими хост-системами.

    Пользовательский интерфейс позволяет настраивать конфигурацию заданий резервного копирования/восстановления для нескольких хостов и управлять всеми этими заданиями. Контроль над всеми ВМ осуществляется с одной консоли.




  2. Параллельная работа с хост-системами для ускорения резервного копирования.

    Задания резервного копирования можно запускать на нескольких хостах одновременно, что существенно сокращает время копирования.




  3. Автоматическая выгрузка отчетов об ошибках.

    Отчеты генерируются автоматически и отправляются службе поддержки для устранения проблем.




  4. В Altaro Console встроен LiveChat.

    Пообщаться со службой поддержки Altaro можно прямо из приложения в чате.








Варианты общения со службой поддержки



Что включает в себя Altaro VM Backup?



В состав Altaro VM Backup входит четыре ключевых компонента:




  • Основное приложение Altaro VM Backup.


  • Программный агент Hyper-V Host Agent


  • Инструменты удаленного управления Altaro Remote Management Tools.


  • Утилита Altaro Offsite Server для копирования на другую площадку.




Процесс инсталляции



Инсталлировать Altaro VM Backup не просто, а очень просто. Достаточно запустить установщик, пару раз нажать «Далее», и все. Никаких дополнительных компонентов инсталлировать не требуется. После завершения процесса и запуска Altaro VM Backup устанавливается соединение с экземпляром программы на одном из серверов, например, localhost. Нужный для этого порт (35107) в интерфейсе уже прописан.  

Следующий шаг – соединение с




  • Хостом Hyper-V или отказоустойчивым кластером.


  • Хостом ESXi (если недоступен vCenter Server)


  • vCenter Server








Выберем для примера хост ESXi. Для соединения потребуется имя, имя хоста, аккаунт и пароль. Порты 443 и 902 (vSphere VDDK) должны быть открыты. После того как соединение с хостом установлено, нужно выбрать место для резервирования данных – локальное (USB, eSATA, iSCSI) или сетевое устройство.  Конечно, для надежности предпочтительнее хранить резервные копии на съемном носителе или на другой площадке, например, настроить репликацию по глобальной сети. Хранимые данные ВМ шифруются.







Места хранения резервных копий







Консоль мониторинга показывает информацию по заданиям резервного копирования, резервированию на сторонней площадке и хранилищу резервных копий.



Для более чёткого понимания опишем процесс инсталляции и запуска продукта по шагам.




  1. Скачиваем и устанавливаем Altaro VM Backup на компьютере с Windows одной из нижеперечисленных версий. Это может быть и хост Hyper-V, тогда шаг 2 пропускаем.








  2. Добавляем хосты (из нижеперечисленных) к консоли Altaro.








  3. Выбираем место для хранения резервной копии. Это может быть внешний накопитель USB или eSATA, сетевой диск или устройство SAN/NAS.




  4. Опционально для удаленного управления Altaro подключаемся через RDP к серверу, где установлен продукт, либо инсталлируем Altaro Remote Management Tools.




  5. Опционально устанавливаем на машине вне локальной сети Altaro Offsite Server и отправляем туда резервные копии по WAN/VPN/интернет. Это на случай аварийного восстановления при крупных неприятностях.






Вот, собственно, и всё. От начала инсталляции до запуска процесса резервирования обычно проходит минут десять.

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





Добавление нового правила хранения резервной копии.



Далее нужно назначить для ВМ место хранения. Это делается простым перетаскиванием ВМ в графическом интерфейсе на целевое хранилище и нажатием кнопки «Сохранить изменения». Осталось создать резервную копию. Выберите ВМ и нажмите «Резервировать». Теперь можно настроить расписание копирования.



Создание консистентных копий приложений



Altaro поддерживает создание консистентных копий приложений, используя технологию Microsoft VSS. Это означает, что после восстановления ВМ приложение с поддержкой VSS не окажется «испорченным».  Для работы с логами приложений типа Exchange Server или SQL нужно установить Altaro VM Tools. Это можно сделать удаленно с помощью консоли управления.



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



Как убедиться в том, что из резервной копии можно будет действительно восстановиться? Об этом нередко просто забывают. В Altaro VM Backup предлагается два метода верификации – по контрольным суммам и путем фактического восстановления ВМ. Первый, Backup Verification,  позволяет просто убедиться в целостности данных на носителе. Второй, Sandbox Restore, позволит вам спать спокойно. Оба варианта можно планировать для автоматизации данного процесса.







Окно отчетов показывает статус резервной копии, результат верификации и  заданий восстановления







Настройка и планирование Sandbox Restore



Sandbox Restore восстанавливает ВМ под временным именем. Администратор может запустить ее и убедиться, что она загружается. На работу других ВМ это не повлияет.



Восстановление файлов



Восстанавливать файлы можно тремя способами:




  1. Восстановлением всей ВМ на той же или на другой хост-системе.


  2. Путем восстановления на файловом уровне.


  3. Восстановлением на уровне элементов Exchange.








Восстановление из Exchange на уровне элементов



Второй способ очень прост и выполняется по шагам. Выбирается ВМ, виртуальный жесткий диск и файлы для восстановления. Altaro VM Backup восстанавливает файлы в специальную папку, после чего остается скопировать их в ВМ.







Непосредственно с консоли Altaro можно выполнять гранулярное восстановление, например, восстановить файл или почтовый ящик







Панель управления Altaro VM Backup в наглядной форме показывает всю необходимую информацию







Планирование резервного копирования



Выводы



Какую технологию или продукт резервного копирования ВМ, какой подход лучше всего использовать в конкретных обстоятельствах? На что следует обращать внимание в первую очередь? На этот вопрос нет однозначного ответа – все зависит от корпоративной политики, процедур и требований бизнеса, размера компании и других факторов. Altaro VM Backup, определенно, заслуживает того, чтобы познакомиться с ним поближе. Попробуйте!



Загрузить бесплатную полнофункциональную версию (демо, 30 дней) можно здесь:

www.altaro.com/vm-backup/download.php






Пост 1 — GFI LanGuard — виртуальный консультант по безопасности >>

Пост 2 — GFI Archiver: хранилище для почты >>

Пост 3 — GFI MailEssentials: почта под защитой >>
Original source: habrahabr.ru.

https://habrahabr.ru/post/304278/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Тенденции резервного копирования — «золотой век» дискет и современный взгляд на сетевой бэкап

Вторник, 05 Июля 2016 г. 10:35 (ссылка)



Плёночный архив, почти современность



Проблема резервного копирования данных начала остро вставать, пожалуй, только в последние века. Конечно, в Египте, Древней Греции, в отдельных древних государствах на территории современного Китая были бумажные или папирусные библиотеки, но как таковой индустрии бэкапа не существовало. Резервное копирование понадобилось индустриально уже в самом начале двадцатого века, когда появились реально очень большие накопленные данные.



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



Естественно, с появлением возможности оцифровывать документы поменялось почти всё и сразу. И я бы хотел рассказать о том ярком периоде — с начала 90-х по настоящее время, когда технологии менялись довольно сильно. А начнём мы, пожалуй, с того, что практически все цифровые носители крайне недолговечны и ненадёжны.



Первыми массовыми носителями информации стали гибкие диски: сначала восьмидюймовые (мало кто из старожилов помнит эти здоровенные конверты с односторонними дискетами), потом — куда более компактные пятидюймовые (5,25).







Напомню, дискета представляла собой конверт с антифрикционными прокладками, внутри которого находился пластиковый диск с магнитным покрытием. Фактически развитие технологии магнитной плёнки, но только с заменой, собственно, плёнки на диск. Считывалась дискета с помощью головки дисковода, фактически скользящей по поверхности диска. Дискеты по мере использования могли резко уйти в отказ из-за физического износа. Чем больше вы читаете или пишете, тем больше царапин остаётся на диске от плохо откалиброванной головки дисковода, от того, что диск пошёл волной после хранения или транспортировки и начал натыкаться на головку, просто от того, что он крутится внутри конверта. Любая пылинка, попадающая внутрь конверта, становилась источником царапин, не критичных для данных, но всё же неприятных. Вторая проблема была в хранении — дискеты размагничивались. Некоторые могли выдержать и десятилетия, но гораздо чаще отказывали за 2-3 года.



До появления жёстких дисков с дискет грузились, на них работали как на основном системном диске, и нормальной практикой было размещение в системном блоке двух дисководов: одного для дискеты с ОС, второго — для рабочих данных. Если софт был большой, то приходилось играть во «вставьте диск 2». Например, забегая вперёд, наша система резервного восстановления помещалась на 4 дискетах формата 3,5 дюйма, по 1,44 мегабайта, надо было вставлять их по очереди по мере загрузки.



Важный культурный момент. Обратите внимание, в том же «домашнем» DOS у файла было четыре атрибута: скрытый, только для чтения, системный и архивный. Read-only понятно для чего, скрытый — чтобы пользователь случайно не наткнулся, системный — это связка RO и скрытого плюс особые предупреждения от ОС при действиях с файлом, а архивный — это флаг того, что файл был забэкаплен. При изменении файла атрибут снимался, и файл снова подлежал копированию на дискету в конце недели.







Обычная ёмкость 5,25-дискеты составляла сначала 180 килобайт, потом «народные» 360 килобайт, а потом — 1,2 мегабайта. При этом сам диск позволял по факту записать больше: например, на 360-килобайтной дискете была возможность хранить больше 500 килобайт. Народный «лайфхак» выглядел так: берёте 360-килобайтную дискету и форматируете её под 1,2 мегабайта. Потом тщательно проверяете тем же «Скандиском» или «Диск Дестроером Доктором». Получается чуть больше места для записи. Записываете, несёте другу по флоппонету, быстро копируете — и вот удалось сделать, что хотелось, за один поход.



Потом появилась довольно удачная для бэкапа пара из небольшого жёсткого диска и дискет. 20 и 50-мегабайтные HDD, распространённые в серии 386-х персональных компьютеров, казались тогда просто бесконечностью. Целиком забэкапить их на дискеты было довольно сложно, поэтому сохранялись только ключевые данные.



Чуть раньше этого периода широкое распространение получил бэкап больших некритичных данных на видеоплёнку, то есть на обычные видеокассеты. Использовалось специальное устройство, способное писать на магнитную плёнку и корректировать ошибки. Поскольку процент ошибок чтения просто потрясал, использовался довольно высокий уровень избыточности. Собственно, именно на аналоговых технологиях хранения отрабатывались алгоритмы восстановления данных. Самый распространённый способ — писать данные неким развитием кода Хэмминга в N частей, где по любому N-1 (при повреждении одного любого из сегментов) можно восстановить остальное. Технология, наверняка прекрасно знакомая вам по RAID-массивам.



С появлением дискет формата 3,5 дюйма (это гибкие диски с жёстким корпусом) появилась возможность хоть как-то не беспокоиться за то, что при хранении (не чтении-записи, а именно хранении или транспортировке) данные никуда не денутся. Физический корпус хорошо защищал диск от случайных повреждений. Интересно, что долгую жизнь этому носителю в России обеспечила налоговая: они крайне долго принимали отчёты в цифровом виде именно и только на таких дискетах. Возможно, где-то ещё до сих пор так делают. Поэтому они продавались даже в переходах и задорого.



В этот же примерно период получили широкое распространение в домашнем сегменте программы вроде Double Space (он же DrvSpace позже) — то, что мы бы сегодня назвали драйвером для работы с жёстким диском с возможностью записи данных. Все данные, которые поступали на запись, сначала сжимались, все данные чтения сначала разархивировались. Всё это делалось прозрачно для пользователя. Получалось, что из 50-мегабайтного HDD можно было получить 70-мегабайтный. Пользователям нравилось. Естественной проблемой было то, что при повреждении диска убивалось нередко вообще всё, а не только один участок. Наверное, в плане бэкапа важных данных, именно тут произошло важное изменение в сознании обычных пользователей.



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



Предполагалось, что технология магнитной записи будет развиваться и дальше. Появились ZIP-дискеты. Люди их немного пугались: вроде дискета, а вроде можно записать хоть 100 мегабайт. К сожалению (или к счастью), долго они не протянули —японцы в это время уверенно решали задачу записи своей любимой классической музыки в плеер, и магнитные носители не подходили. Появились первые компакт-диски.

Счастливые обладатели первых приводов очень быстро обнаружили в них баг: читать они могли, а вот писать — нет. С появлением пишущих CD-драйвов резко изменилось вообще всё представление о бэкапе. Когда в музыкальные хиты пробился рок-альбом «CD-R» группы «750 мегабайт», бэкап делался достаточно просто. 15 минут в неделю, чтобы забрать реально большие данные — это было круто. У многих были целые библиотеки таких дисков.



К сожалению, они тоже оказались недолговечными. R-болванки (для однократной записи) держались дольше, а RW-диски (многократные), особенно ширпотребные, не очень хорошего качества, «стирались» за 2-3 года лежания в сухом прохладном месте. Поэтому для бэкапа они не годились, и в дата-центрах продолжала использоваться старая добрая магнитная плёнка.



Распространение получили зеркальные RAID’ы.



Где-то в этот момент HDD настолько подешевели, что хранилища стало можно делать на них. Понятно, что технологии, подходы, методология и основные алгоритмы были отработаны давно, но именно в момент поиска новых средств хранения (ставили на оптические носители, flash-память, фантазировали о бионосителях) потребовалось делать надёжные и долговечные вещи на ненадёжном материале. Вся история человечества так и устроена, кстати говоря.



Отсюда массовое использование идей кода Хэмминга, хранилища с многократным дублированием дисковых подсистем, распределение данных между ними. Подтянулись старые добрые архиваторы с возможностью защиты данных, переиспользовались патенты на передачу данных в шумных каналах — и вот мы имеем то, что имеем сегодня. В большинство современных хранилок hi-end в дата-центрах можно с размаху воткнуть лом, и данные, скорее всего, сохранятся в полном объёме.



Появление и массовое распространение flash-памяти наконец-то изменило сознание — больше никто не рассматривал носители как нечто постоянное. Речь шла о постоянном «трогании» данных, обновлении и перезаписи.



Мы в целом двигались до этого периода по очень понятной парадигме. Первое, что мы начали продавать, — продукт, который имел дружелюбный GUI (редкость для системных утилит в начале 2000-х) и позволял обычному конечному пользователю (не админу) делать бэкап быстро, уметь просто восстанавливаться из него и прививать привычку копировать важные данные. Требовались технологии снепшотов, было много работы с диском на почти физическом уровне, много особенностей ОС. Бэкап делался на внешние носители или соседние жёсткие диски, и в целом всё было предсказуемо. Вот тут есть чуть больше деталей от одного из наших первых сотрудников.



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



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



Очевидно, следующая идея, которая прямо проистекает из современных тенденций виртуализации и распределения данных — это отвязка данных от терминалов домашних пользователей. Уже сейчас они прекрасно знакомы с тем, как бэкап с телефона можно накатить на новую «трубку» (и всё будет точно таким же), видят свои файлы из командировки при доступе к бэкапу через веб-агента, пользуются тем же «Яндекс.Диском» или «Дропбоксом», и в целом готовы отдавать данные в сеть относительно свободно. Каналы тоже уже доросли, если не считать прыгающую через спутник Камчатку, у нас в России с интернетом почти везде почти порядок. И благодаря распространению 3G и LTE нормальный канал есть почти везде на планете.



Понятно, что и в парадигмах развития хранения данных, и в истории бэкапов можно копаться ещё долго. Если вам интересно, скажите, и я продолжу чуть позже. Пока же самая важная тенденция: из скучной, но важной гигиенической процедуры бэкап превратился в нечто автоматическое (пришёл домой с планшетом — всё сохранилось) и само собой разумеющееся. И всё идёт к тому, что скоро бэкапа как такого не останется, не будет нужна отдельная резервная копия как инстанс, скорее всего, обычное хранение данных будет на низком уровне поддерживать достаточное количество избыточности, чтобы не разделять в сознании пользователя его данные и какую-то их копию.



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



Если интересно
То заглядывайте в Beta Acronis True Image 2017

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304438/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] Примеряем дедупликацию и компрессию к резервным копиям

Четверг, 16 Июня 2016 г. 05:09 (ссылка)



Заморские купцы говаривали, что дедупликация может существенно сэкономить место, необходимое для хранения резервных копий. Что есть в заморских землях такие, кто годовую историю резервных копий хранят в том же объёме, что занят на рабочих серверах. Вроде как копируешь 10 Терабайт данных изо дня в день цельный год, а на устройстве хранения резервных копий те же 10 Терабайт и заняты. Брешут, наверное.



Однако, есть хороший способ проверить, как же данные многочисленных резервных копий конкретно наших серверов могут быть упакованы в хранилище с дедупликацией и компрессией. При этом не нужно разворачивать целую систему резервного копирования, а достаточно скачать одну маленькую (4 Мегабайта) утилиту, которая выдаст нам не только картину того, как можно пожать данные прямо сейчас, но и построит прогноз того, сколько памяти нам потребуется в будущем.







Для начала – качаем утилиту вот отсюда:



http://downloads.arcserve.com/tools/RPSPlanning/unsupported/DeduplicationPlanningTool/V1.0/ArcserveUDPDataStoreCapacityPlanningTool.zip



Хоть архив и небольшой, но утилита требовательная:


  • для работы нужна 64-битная система Windows (желательно, серверная. У меня на Windows 7 отработала нормально, всё посчитала и нарисовала, но при выходе свалилась).

  • каждые 100 Гигабайт сканированных данных могут потребовать при обработке статистики до 1 Гигабайта оперативной памяти на компьютере, где мы запускаем утилиту (это можно обойти, если использовать SSD вместо оперативной памяти).

  • должны быть открыты порты 10000 и 135 (какие — не уточняется, предположу, что TCP)

  • запускать её нужно из-под администратора





Если всё необходимое у нас есть, разворачиваем архив куда угодно и запускаем ArcserveDeduplicationAssessment.exe



Затем добавляем интересующие нас сервера в список обследуемых, нажав на кнопку “Add Node”:







После этого на указанный нами сервер будет удалённо установлена программа-пробник, которую можно увидеть в списке сервисов:







Кстати, по завершению работы с утилитой программу-пробник предложат удалить:







А пока запустим сбор статистики, нажав на кнопку “Scan Nodes”.



Кстати, сколько ресурсов у рабочего сервера отъедает сбор статистики?
В документации приведён пример, согласно которому сервер с процессором i7-4790, 3601 МГц, 4 ядра был загружен на 25-30% в течение 22 минут для обработки данных с диска в 199 Гигабайт.



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



Это можно изменить, если сбор статистики слишком затягивается.





На экране отображается процент выполненных работ на каждом из исследуемых серверов:







По завершению сбора статистики переходим на закладку 2 и строим отчёт. Имеет смысл отметить галочками все даты, когда была собрана статистика. Это позволит увидеть данные в динамике:







Теперь на закладке 3 мы можем воспользоваться полученными данными и, поиграв параметрами, определить потребность в объёмах хранилища резервных копий и конфигурацию сервера хранения резервных копий Arcserve UDP.



На примере ниже мы видим следующее:


  • Полные резервные копии двух исследуемых машин занимают 35,54 Гигабайта

  • Мы хотим хранить историю из 31 резервной копии

  • Каждая новая резервная копия отличается от предыдущей на 17%

  • Размер блока данных при дедупликации выбираем 4 Килобайта

  • Используем стандартную компрессию (без фанатизма, дли минимизации загрузки процессора)





На выходе получаем, что для хранения 31 резервной копии этих машин нам потребуется 76,85 Гигабайт памяти, что означает экономию в 94%:



(Также можно увидеть, какие требования будут к оперативной памяти сервера хранения резервных копий Arcserve UDP. В данном случае будет необходимо 1,19 Гб опративной памяти либо 0,06 Гб оперативной памяти в сочетании с 1,19Гб места на SSD-диске).







Нажав на “Show Details” увидим более подробную информацию.



Если мы делаем только полные резервные копии (“Full Always”), то дедупликация сократит их общий объём (1282,99 Гигабайт) на 91% до 118,90 Гигабайт.



Компрессия сократит этот объём ещё на 35%, то есть до 78,85 Гигабайт.







Если мы используем резервное копирование в режиме “Incremental Forever” (только инкрементные копии вслед за одной полной), то требуемое место для хранения резервных копий не изменится и также составит 78,85 Гигабайт. Просто нам придётся выполнить меньше вычислений для дедупликации, а следовательно, меньше будут загружены рабочие серверы:







Теперь посмотрим на закладку с графиками.



Выберем тип графика “Disk and Memory Usage Trend”.



Хорошо видно, что добавив к первой резервной копии в 35 Гигабайт вторую (тоже 35 Гигабайт), мы нуждаемся в 70 Гигабайтах памяти, как показано слева синим графиком.



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



На правом графике видно, как растёт потребность в оперативной памяти (или оперативной памяти в сочетании с SSD-диском) на сервере хранения резервных копий Arcserve UDP.







Если мы выберем тип графика “Disk and Memory Usage”, то увидим, как влияет на потребность в памяти размер блока, применяемый при дедупликации. Видно, что увеличение размера блока несколько снижает эффективность дедупликации, но также уменьшает требования к быстрой памяти (оперативной или SSD) на сервере хранения резервных копий Arcserve UDP:







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



Описанная утилита включена в дистрибутив продукта Arcserve UDP, устанавливается вместе с ним в каталог “…\Program Files\Arcserve\Unified Data Protection\Engine\BIN\Tools\RPS Planning”, но может быть загружена и сама по себе, как указано выше.



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



Больше узнать о продуктах Arcserve вы сможете, почитывая наш блог, и посетив ссылки, приведённые в правой колонке,
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303404/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] 20 самых заметных событий в истории резервирования и восстановления

Четверг, 09 Июня 2016 г. 05:04 (ссылка)





1539 год. Генрих VIII, король Англии, для того чтобы решить, на ком жениться в следующий раз, послал художника Ганса Гольбейна сделать достоверную копию…



Впрочем, начнём с самого начала.



13.7 миллиардов лет до нашей эры – Вселенная возникла из сингулярности; те, кто верят в теорию «большого взрыва», предсказывают грядущую катастрофу…



3.8 миллиарда лет до нашей эры – Начало жизни на Земле. Считается, что первая клетка возникла из само-реплицирующейся РНК, позднее развившейся в ДНК. ДНК – это хранилище биологических данных, генетическая информация, которая позволяет всем современных живым существам функционировать, расти и воспроизводить себя. Или по-другому, мы – резервная копия наших родителей. Привет терапевту от меня.



65 миллионов лет до нашей эры – Динозавры, резервная копия не была сделана.







3200 лет до нашей эры – Изобретение письменности. Чтобы не забывать разные вещи, древние шумеры начали их записывать. Книги дают хороший показатель точки восстановления [RPO] (если у вас хороший летописец), но время восстановления [RTO] ужасно: средний взрослый человек читает со скоростью 300 слов в минуту, слишком медленно.



552 лет до нашей эры – Кир Великий помнил имена всех солдат своей армии, около 10 000 персов. Впечатляющее достижение для человеческой памяти, но и горький урок о единой-точке-отказа. Он был убит в 530 году до нашей эры, и информация исчезла вместе с ним.







48 лет до нашей эры – Пожар в Александрийской библиотеке. Среди прочих книг из «списка 10 самых примечательных утерянных книг за все времена», превратился в дым второй том поэтики Аристотеля, и человечество заподозрило существенный просчёт в своём хитром плане резервного копирования: бумага весьма легко воспламеняема.



1347 – Первый известный нам страховой контракт был подписан в итальянской Генуе. Это было здорово для тех, кто покупал и продавал товары, а также владел собственностью. Но трудно измерить ценность информации, большинство людей предпочло бы вернуть свои данные вместо того, чтобы получить компенсацию за их утрату.



1436 – Иоганн Гутенберг, бывший ювелир, создал первый печатный станок в Германии. Он воспользовался своими навыками в металлообработке для изготовления букв из металла, смачивал их в чернилах и создавал копию на бумаге. Это существенно ускорило создание копий, серьёзный шаг к восстановимости данных.



1539 – Копирование на основе образов, первые шаги. Генрих VIII, король Англии, для того чтобы решить, на ком жениться в следующий раз, послал художника Ганса Гольбейна сделать достоверную копию того, как выглядят европейские принцессы из его списка. На основе полученных образов Генри сделал выбор и предложил замужество Анне Клевской, но увидев её лично, понял, что представлял её совсем по-другому. Недостоверная / испорченная копия.







1937 – Изобретение фотокопировальной машины. Успешно и точно копирует документы с начала 20 столетия. Эй, что это за серые пятна на бумаге? И как насчет аварийного восстановления тропических лесов?



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







1964 – Компьютеры выходят на массовый рынок. На Всемирной Ярмарке в Нью-Йорке публике был продемонстрирован компьютер «Programma 101». Один из таких компьютеров использовался на «Аполлон 11», и был, по сути… калькулятором. «Один маленький шаг...» (в то время!)



1972 – Мейнфреймы делают приложения и быструю обработку данных доступными сотням людей, встроенная аппаратная избыточность обеспечивает выдающиеся показатели восстановления (RPO и RTO). Древним Шумерам это бы дико понравилось.



1990 – Arcserve 1.0 выпущен компанией Cheyenne software. Эпоха распределённых вычислений находится на подъёме, главное – не забывать про резервное копирование на эти маленькие прямоугольные штучки, именуемые «ленты».



1998 – компания VMware основана в городе Пало Альто, штат Калифорния. Хотя концепция гипервизоров берёт начало из 1960-х, именно VMware вывела виртуализацию на массовый рынок. Виртуализация перевернёт резервное копирование и аварийное восстановление.







2006 – Технология WANsync компании XOsoft интегрирована в Arcserve. Впервые на рынке для средних компаний появилось единое решение для резервного копирования и мгновенного переключения на резервную систему.



2008 – Microsoft выпускает продукт, конкурирующий с VMware, и называет его Hyper-V. Если вы ещё не были виртуализованы, то сейчас будете. Специфическое программное обеспечение для резервного копирования виртуальных систем существует, но слабо интегрировано с физическими серверами, копированием на ленту и не является кроссплатформенным для Microsoft/Linux.







2014 – Продукт Unified Data Protection (UDP) выпущен компанией Arcserve. Он был специально разработан для виртуальных сред, VMware, Hyper V и Xen, оставаясь удобным и функциональным и на физических серверах. UDP предоставляет возможность копировать образы дисков и файлы, выполнять репликацию данных приложений и горячую замену на резервный сервер. UDP предоставляет расширенную функциональность при работе с лентами; совместим с Windows и Linux, физическими и виртуальными; копирует и выполняет аварийное восстановление с дисков, лент и из облака при помощи единой консоли; RPO = 0. RTO = 0.



2015 – Arcserve UDP завоёвывает три награды на VMWorld 2015, включая «золотую награду за аварийное восстановление и резервное копирование в виртуализованных средах », “лучший проект аварийного восстановления” и “лучшие на шоу”.







2016 – Вы находитесь здесь.



Марсоход NASA «Кьюриосити» находит подтверждение существования древней цивилизации на Марсе:







Зарегистрируйтесь здесь, чтобы увидеть демонстрацию работы продукта Arcserve UDP.



Или скачайте Arcserve UDP здесь.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/302952/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
ОГОЛЬ

Урок: "Резервное копирование в 1 клик (видео)"

Пятница, 27 Мая 2016 г. 16:50 (ссылка)

Это цитата сообщения EFACHKA Оригинальное сообщение

Урок: "Резервное копирование в 1 клик (видео)"




3424885_ (684x433, 61Kb)



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



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



Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Конструкция и принципы работы Arcserve UDP – программного продукта для резервного копирования и восстановления данных

Четверг, 26 Мая 2016 г. 15:52 (ссылка)




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



Читать дальше →

https://habrahabr.ru/post/301854/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<резервное копирование - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda