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


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

восстановление данных - Самое интересное в блогах

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

Как восстановить данные с жесткого диска.

Четверг, 25 Августа 2016 г. 21:36 (ссылка)

Это цитата сообщения Владимир_Шильников Оригинальное сообщение

Как восстановить данные с жесткого диска.

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

Читать далее



http://faqpc.ru/kak-vosstanovit-dannye-s-zhestkogo-diska/
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Artconn

hadow Defender 1.4.0.650 Rus - Восстановление данных, hadow Defender, защита системы

Понедельник, 22 Августа 2016 г. 12:44 (ссылка)
sweet.org.ua/program/1934-hadow.html

Атаки червей, скачивание spyware, удаление Ваших любимых фотографий и т.п... всё будет возвращено назад после очередной перезагрузки компьютера.
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] Как защита от Microsoft удалила код на серверах. Байка о Defender

Понедельник, 16 Августа 2016 г. 02:01 (ссылка)

Сегодня на календаре 16 Августа 2016.

Windows Defender удалил рабочий код с хоста. Как это было:



Обсуждая с коллегой новости о череде проблем у Microsoft, которые пестрят в новостях. Там зависло, там пропало, там еще что-то — видимо накаркал себе проблем.

Работая на виртуальном сервере с кодом под IIS вдруг получаю предупреждение о том что Windows Defender обнаружил Worm внутри многих ASP файлов на хосте и настоятельно рекомендует удалить.



Вся прелесть в том что вариантов не предлагает Defender. Файлы уже пустые и залоченные. До вчера этой проблемы не существовало. Любая попытка восстановить с репозитория файлы — вызывает возмущение у Defender, с последующим удалением файлов.

Проверка настроек показала что Windows Defender обновился 8/15/16 до версии 1.225.3982.0.

Сканер настойчиво видел Worm:VBS/VBSWGbased.gen в ASP (VBScript ) файлах.

Проверка одного из файлов на virustotal.com показала теже результаты. Из 53х тестовых проверок — только Microsoft Defender находит Worm:VBS/VBSWGbased.gen.







Далее идет много часовая попытка понять, что именно заставило найти вирус и удалить код. Перебирая варианты строк и проверяя сканером каждую строчку — удалось удалить все и получить минимальный тестовый файл который вызывает безумие у Defender.

Function SafeSQLLogin()
Execute(SafeSQLLogin())
End Function
Function Stream_StringToBinary(Text)
Set BinaryStream = CreateObject("ADODB.Stream")
BinaryStream.Type = adTypeText
BinaryStream.CharSet = "us-ascii"
BinaryStream.Open
BinaryStream.WriteText Text
BinaryStream.Position = 0
BinaryStream.Type = adTypeBinary
BinaryStream.Position = 0
Stream_StringToBinary = BinaryStream.Read
Set BinaryStream = Nothing
End Function
Function strCrypt()
For i = 1 To Len(Text)
End Function


Код странный только потому что я удалил максимально все что смог, пока сканер все еще видел Червя. Этот текст минимальный, любое изменение или удаление одной из строк — перестает сводить с ума Defender.



Update:

более свежая версия текста для принятия его за вирус:

Function S
Execute S
End Function
For i To Len T




Сохранив текст в файл как test.txt и отправив на virustotal.com все еще выдает потверждение о Черве, несмотря на то что Defender уже получил несколько новых обновлений.

Вот результат от virustital.com

Result



Попытка связаться с Tech центром от Microsoft в режиме чата, слегка подняло настроение. Девушка+специалист настойчиво пыталась помочь мне восстановить систему и RestorePoint выдавая команды типа SCN и др. Все попытки пояснить что проблему не у меня с компьютером, вели вокруг настойчивой попытки решить мою проблему с моим компьютером. Поняв что сообщить о проблеме с Defender не получится, я связался с Администраторами хостов с предупреждением, что у нас могут возникнуть проблемы на всех серверах.

Администраторы как обычно не доступны. Надеюсь что они отзовутся не как обычно, когда уже что-то рухнуло. (сарказм)



Анализ «вредоносного» когда, не дает понимания никакой логики. Все ведет к случайному набору каких то совпадений. Любое изменение в тексте, ведет к тому что Червь перестает находиться. Но вся хитрость состоит в том, что текст идет не подряд!!! Этот код очищен от всего остального и это только часть строк, между этими строками были сотни строк другого кода. Нахождение Червя срабатывало только при существовании этих строк среди других строк кода весом на 80kb. Значит это не шаблон, а скорее по регулярке нахождение какого-то кол-ва определенных слов или фраз. Другой логики я не увидел.



Ничего против Microsoft не имею, но чтото в последнее время их ошибки чреваты огромными последствиями. У Администраторов существует жесткое правило — Никаких обновлений на серверах!!! Сначала долгие тесты на тестовых машинах. Понимаю что это звучит не ново — но исправления от Microsoft должны исправлять и защищать а не убивать и создавать новые проблемы, еще более страшные.



P.S. Defender получил очередную порцию обновлений, v1.225.4025.0 — но он все еще настойчиво блокирует и удаляет файлы на тестовом PC, на остальных машинах он везде отключен.
Original source: habrahabr.ru.

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

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

Восстановление из резервной копии с помощью Veeam Agent for Linux

Понедельник, 15 Августа 2016 г. 12:55 (ссылка)

Конечная цель создания резервной копии – обеспечить возможность восстановления данных в случае сбоя, и сегодня я вкратце расскажу, как с этим способен справиться новый Veeam Agent for Linux. Возьмем в качестве «подопытного кролика» тот же бэкап, создание которого было описано в предыдущем посте, и посмотрим, как из него можно восстановиться. За сим добро пожаловать под кат.







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



Как вы помните, Veeam Agent for Linux успешно сохранил бэкап на сервер NFS. Запустим уже знакомый нам UI, введя команду

veeam

Сверим часы, то есть данные о последней сессии задания резервного копирования:





Внизу, в списке команд теперь появилась команда R (Recover Files) – восстановить файлы. По ней будет выведена информация о имеющихся в наличии резервных копиях: какой хост был в работе, какое задание создало бэкап, сколько получилось точек восстановления (в нашем случае – одна) и в какое время.





Дважды нажимаем Enter, и выбранный бэкап монтируется на файловую систему нашего хоста в папку /mnt/backup:





Почему мы решили ограничиться этой операцией? Просто подумали, что у пользователей обычно есть свои предпочтения в работе с файлами, и ни к чему изобретать велосипед. Так что после того, как прошло монтирование, вы можете задействовать привычный для вас способ – например, командную строку или популярный Midnight Commander (mc):





Восстановление тома



Теперь рассмотрим, как выполняется восстановление тома целиком. Для начала выполняем загрузку машины с использованием Veeam Recovery Media (скачивается вместе с установочным пакетом решения Veeam Agent for Linux). Он запускается, используя файл ISO.



Veeam Recovery Media открывает нам графический интерфейс с вот таким набором команд:





Здесь есть возможность восстановления томов (Restore volumes), восстановления файлов (Restore files), настроек сети (Configure network), перехода к командной строке (Switch to command line), а также перезагрузки (Reboot) и выключения (Shutdown).

Если, как в нашем примере (и как рекомендовано!), бэкап хранится вовсе не на локальной машине, а на сетевой СХД, то нужно до начала процедуры восстановления убедиться в наличии доступа к месту хранения бэкапа, а в ходе самой процедуры — выполнить настройку параметров сети. Можно задать настройки вручную. Для этого:




  1. В данном меню выбираем пункт Configure network, затем выбираем в списке нужный сетевой адаптер, который будет использоваться для соединения с СХД, и жмем Enter.




  2. В диалоге Configure adapter (настроить адаптер) выбираем Manual (ручная настройка) и жмем Enter.




  3. В диалоге Adapter settings (параметры адаптера) указываем требуемое: IP-адрес, маску подсети, шлюз по умолчанию, сервер DNS




  4. Кликаем Apply (применить) и жмём Enter.





    Если вы работаете с сервером DHCP, то нужные настройки Veeam Agent for Linux сделает автоматически – если в диалоге Configure adapter выбрать Auto.




  5. Продолжаем восстанавливать том: выбираем соответствующую операцию из списка команд — это Restore volumes.




  6. Далее на шаге Select Backup Location нужно указать местонахождение нашего бэкапа. Для нашего примера нужно выбрать опцию добавления шары Add shared folder…




  7. Затем на шаге Mount Shared Folder указываем, что у нас это NFS:






  8. В поле Server/Directory вводим имя сетевой шары, в которой лежат файлы бэкапа. Veeam Agent for Linux смонтирует ее в папку /media на файловой системе нашего recovery image и отобразит содержимое смонтированного тома. На шаге Browse for Backup Files вы сможете выбрать нужную точку восстановления, чтобы импортировать ее:





    Полезно: Если ваши бэкапы хранятся на одном из локальных устройств, то на шаге Select Backup Location вы, естественно, выберете опцию Mount local disk. При этом можно будет выполнять монтирование многократно — для нескольких устройств, на которых живут файлы резервных копий. Для этого нужно вернуться на шаг выбора местонахождения бэкапа Select Backup Location и опять выбрать опцию Mount local disk.




  9. На шаге Backup выбираем нужный бэкап и в нём — точку восстановления.




  10. Затем на шаге Disk Mapping можно просмотреть, какие тома имеются у машины в продакшене (то есть у локального хоста – Current System) и в бэкапе. Veeam Agent for Linux отобразит для выбранного тома подробную информацию, включая тип раздела, файловую систему, местоположение точки монтирования, размер тома, а также выведет список доступных команд:




    • Restore volume from (восстановить том) – восстановить данный том из бэкапа.




    • Delete partition (удалить раздел) — позволяет переразметить диск перед восстановлением тома. После удаления раздела можно будет создать новый и замапить на него том из бэкапа.




    • [для восстановления томов LVM] Create LVM physical volume (создать физический том LVM)— создать физический том LVM на выбранном разделе и добавить его в уже существующую группу томов (volume group, VG), либо создать новую группу. Это позволит восстановить логические тома LVM или группы томов в выбранную VG.




    • Close (закрыть) — закрыть диалог и выбрать другой том.



    Здесь мы выбираем Restore volume from и жмем Enter.




  11. В панели Current system в поле Restore напротив выбранного тома появится имя того, с которого будем восстанавливаться:






  12. Подтверждаем выбор (будьте внимательны, оплошность может дорого обойтись, поскольку данные будут перезаписаны теми, что в бэкапе!), нажимаем (Start restore).




  13. Cмотрим краткую сводку, подтверждаем выбор ещё раз и наблюдаем за прогрессом:








После завершения процесса мы заканчиваем работу с Veeam Recovery Media:




  1. Нажимаем Esc для возврата в главное меню.

  2. Отключаем носитель с recovery image.

  3. В главном меню выбираем Reboot и жмем Enter.

  4. Ждем старта ОС.



Вот, в общем-то, и весь рассказ о том, как происходит восстановление с помощью Veeam Agent for Linux.



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




Original source: habrahabr.ru.

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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
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)КомментироватьВ цитатник или сообщество
Гриола

Как восстановить данные на компьютере, смартфоне, планшете и карте памяти.

Четверг, 21 Июля 2016 г. 21:26 (ссылка)



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



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

NetApp ONTAP: SnapMirror for SVM

Четверг, 14 Июля 2016 г. 11:12 (ссылка)

Начиная с версии 8.3.1 в Data ONTAP был презентован новый функционал под названием SnapMirror for SVM. SnapMirror for SVM это возможность отреплицировать все данные на СХД и все настройки или только часть данных или настроек.



Чтобы мочь запустить все ваши сервисы на резервной системе, логично чтобы основная и запасная системы были более-менее одинаковые по производительности. Если же на резервной площадке система стоит слабее, стоит заранее задаться вопросом, какие самые критичные сервисы необходимо будет запустить, а какие будут не запущены. Можно реплицировать как весь SVM со всеми его вольюмами, так и исключить из реплики часть вольюмов и сетевых интерфейсов (начиная с ONTAP 9).



Существует два режима работы SnapMirror for SVM: Identity Preserve и Identity Discard.







Что такое NetApp SVM?



SVM это что-то на подобии виртуальных машин на серверах, но предназначены для СХД. Пускай эта аналогия не введет вас в заблуждение, на СХД не получится запускать ваши виртуальные машины с Windows, Linux и так далее. SVM это виртуальная машина (очень часто одна единственная, но при желании можно развернуть много) в кластере СХД. Кластер СХД с софтом (прошивкой) ONTAP может состоять из одной или более нод, на данный момент максимум 24 ноды в кластере. Каждая SVM «логически» это одна сущность, видна администратору как одна сущность, которая живёт сразу на всём кластере, но физически, на самом деле, «под капотом» СХД, это набор виртуальных машин, по одной машине на каждой ноде всего кластера, которые объединены специальным образом и представляются администратору как одна сущность.

Смысл SVM в кластере ONTAP, с одной стороны, в том, что для администратора СХД он видит кластер, как одну сущность, управляет её ресурсами из одной консоли, при необходимости мигрирует объекты кластера (вольюмы, луны), сетевые адреса, по нодам кластера без какой-либо специальной настройки кластера, SVM берет всю заботу по миграции на себя.

С другой стороны смысл SVM также в том, чтобы обманывать хосты, чтобы 2, 4,8, или даже 24 ноды кластера были видны для конечного хоста, как единое устройство, а при миграции данных из одной ноды на другую, хосты этого вообще не замечали.

Все эти возможности SVM в кластере называют «Single Namespace».



Identity Preserve для NAS



С сохранением сетевых настроек и адресов, может использоваться в двух режимах: когда имеется растянутый L2 домен между площадками и когда между сайтами есть L3 связность (маршрутизация). В режиме Identity Preserve можно также не реплицировать настройки сетевых IP адресов, тогда их нужно будет настраивать вручную после переключения на резервную площадку.





L2 домен для NAS


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



L3 домен для NAS


Так как при отсутствии растянутой L2 сети между основной и резервной площадками, понадобится наличие двух разных IP подсетей и маршрутизации. Если бы данные были доступны по старым адресам, на DR площадке, то приложения не смогли бы к ним получить доступ, ведь на резервной площадке другие подсети. В этом случае также приходит на помощь функция Identity Preserve с сохранением сетевых адресов — ведь вы можете заранее указать новые сетевые IP адреса для DR площадки (которые поднимутся на DR площадке в момент переключения на вторичную СХД), по которым будут доступны данные на резервной СХД. Если просто мигрировать хосты, то их сетевые адреса тоже потребуется перенастроить: вручную или при помощи скриптов на резервной площадке, чтобы они увидели свои данные, со своих новых IP адресов подключаясь, опять таки, на новые IP адреса СХД. Этот режим работы будет больше интересен не большим компаниям, которые могут себе позволить более длительное время переключения в случае катастрофы или аварии при этом, не тратясь на дорогостоящее оборудование и каналы.



Identity Discard для SAN или NAS



Иногда есть необходимость полностью отказаться от старых настроек, при переключении на резервную площадку, к примеру отказаться от настроек NFS экспорта, настроек CIFS сервера, DNS и т.д. Также бывает необходимо обеспечить возможность чтения данных на удаленной площадке или когда есть необходимость реплицировать луны для SAN окружения. Во всех таких ситуациях приходит на помощь функция Identity Discard (Identity Preserve = False).

Как и в случае с Identity Preserve L3 конфигурацией, на удалённом сайте, после переключения необходимо будет перенастроить сетевые IP или FC адреса (и другие настройки, которые небыли были реплицированны, согласно режима Identity Discard), по которым будут доступны старые данные на вторичной СХД. Если просто мигрировать хосты, то их сетевые адреса тоже потребуется перенастроить: вручную или при помощи скриптов на резервной площадке, чтобы они увидели свои данные. Этот режим работы будет больше интересен для заказчиков которым необходимо иметь возможность реплицировать LUN'ы для SAN инфраструктуры или для тех кто хочет выполнять чтение данных на резервной площадке (к примеру каталогизация). Также этот режим будет интересен для проверки резервной копии на возможность к ней восстановится, а также для разнообразных тестироващиков и разработчиков.





SnapMirror Toolkit



Clustered Data ONTAP SnapMirror Toolkit — это бесплатный набор Perl скриптов, которые позволят ускорить и наладить процесс автоматизации проверки, подготовки, настройки, инициализации, обновления, переключения на резервную площадку и обратно репликации SnapMirror.

Скачать SnapMirror Toolkit.



NetApp-PowerShell Commandlets



Для Windows машин доступен NetApp PowerShell Toolkit, который позволит создавать скрипты управления NetApp.



Workflow Automation



Workflow Automation — это бесплатная графическая утилита позволяющая создавать наборы или связки задач, для автоматизации процессов управления ONTAP. К примеру через неё можно настроить создание новых разрешений для файловых шар или iGroup, добавить в неё отреплицированные вольюмы и новых хостов-инициаторов с DR площадки, поднять новые LIF интерфейсы и многое другое (создать Broadcast Domain, создать Failover Groups, Firewall Policies, Routes, DNS, и т.д.). Всё это можно автоматизировать так, чтобы это было выполнено сразуже, после выполнения разрыва репликации, практически по одному клику мыши. Workflow Automation будет более полезен для режимов Identity Preserve L3 и Identity Discard, так как в этих режимах после переключения на резервную площадку необходимо будет выполнить дополнительную настройку СХД и серверов. Также Workflow Automation будет крайне полезен для тестировщиков и разработчиков, которые могут клонировать огромные наборы данных средствами СХД за секунды и автоматизировать их подготовку для своей работы.



Snap-to-Cloud



Репликация данных может быть выполнена как на физическую FAS платформу, так и на их виртуальных братьев: Data ONTAP Edge, ONTAP Select или Cloud ONTAP в публичное облако. Последний вариант получил название Snap-to-Cloud. Если быть более точным то Snap-to-Cloud это набор (бандл) определенных моделей FAS платформ + Cloud ONTAP с установленными лицензиями репликации для бэкапа в облако.





Disaster Recovery не High Avalability



Чтобы обеспечить 0 время переключения, понадобится ещё большие затраты на каналы и больше и дороже оборудование. По-этому часто более целесообразно использовать DR, а не HA. В случае DR простой при переключении на резервную площадку неизбежен, RPO и RTO не равняются 0, как в случае с HA.



Исключение вольюма из DR реплики



Чтобы исключить вольюм/лун из DR реплики всего SVM, необходимо на источнике выполнить:

source_cluster::> volume modify -vserver vs1 -volume test_vol1 -vserver-dr-protection unprotected




Вторым применением SnapMirror может служить Test/Dev



Использование запасной площадки как среды разработки при помощи тонкого клонирования (Data Protection вольюма) снижает нагрузку на основную СХД, при этом тестировщики и разработчики могут иметь достаточно более новую информацию (по сравнению с традиционным подходом FullBackup) для своей работы, отреплицированную из основной СХД. Для тонкого клонирования понадобится лицензия FlexClone на соответствующей площадке.



Традиционный бекап vs Snap*



Cнепшоты NetApp вообще никак не виляют на производительность всей системы так устроено архитектурно. Благодаря чему снепшоты удобно использовать для репликации — передавать только изменения. Это более эффективно по сравнению с Full Backup/Restore так как при операциях резервного копирования читаются/пишутся только эти изменения, а не каждый раз всё по-новой. Использовать аппаратную репликацию более эффективно ещё и потому, что CPU хоста и его сетевые порты не задействуются во время бекапа. Это позволяет более часто выполнять резервное копирование, а возможность моментально снимать снепшоты позволит снимать их прямо посреди рабочего дня.

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



Выводы



Технология SnapMirror позволяет тонко реплицировать и восстанавливать данные, используя снепшоты. Это позволяет уменьшить нагрузку на сеть и дисковую подсистему по сравнению с Full Backup/Restore. Функционал SnapMirror for SVM обеспечивает удобный способ создания DR схемы восстановления всей СХД. Кроме DR второй сайт может быть использован для Test/Dev, что снимает нагрузку с основной СХД.



Здесь могут содержаться ссылки на Habra-статьи, которые будут опубликованы позже.

Сообщения по ошибкам в тексте прошу направлять в ЛС.

Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/279911/

Комментарии (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

ETERNUS Snapshot Manager – эффективный инструмент для обеспечения высокой доступности данных

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



Постоянный рост объемов данных, накопленных в ИТ-инфраструктуре современного предприятия, и ужесточающийся требования к непрерывности бизнес-приложений значительно усложняют обеспечение высокой доступности критически-важной информации. Сегодня мы поговорим о программном инструменте, помогающем значительно улучшить доступность данных – Fujitsu ETERNUS Snapshot Manager.



Традиционные методы резервного копирования на ленту часто оказываются неэффективны из-за слишком низкой скорости записи и чтения. Например, если запись полной резервной копии данных выполняется в выходные, а дифференциальных копий — в ночную смену, то в случае крупной аварии (например, выхода из строя нескольких дисков) целевое время восстановления данных (RTO) может быть более суток, а целевая точка восстановления (RPO), определяющая максимальный объем данных, которые можно безвозвратно потерять при серьезном сбое основной системы хранения, равна 24 часам. Кроме того, во многих компаниях основные бизнес-приложения работают круглосуточно, поэтому их нельзя остановить на ночь или на выходные для резервного копирования их данных.



В последние годы все чаще в бизнесе для обеспечения высокой доступности важных для бизнеса данных, в том числе их резервного копирования, применяются реализованные на уровне дисковых массивов корпоративного класса технологии «мгновенных снимков» (snapshots), позволяющие получить снимок состояния данных, хранящихся на массиве, в определенный момент времени (мгновение). Например, получить консистентную копию базы данных, чтобы затем сделать ее резервную копию, не прерывая работы пользователей. Затем по этому мгновенному снимку можно выполнять резервное копирование оригинала данных без прерывания работы бизнес-приложений либо использовать их для других задач, например, обработки данных средствами бизнес-аналитики или тестирования новой версии приложения. В отличие от классического резервного копирования мгновенные снимки позволяют записывать резервные копии несколько раз в день и в результате RPO снижается до нескольких часов. Наконец, мгновенные снимки эффективны для таких решений обеспечения катастрофоустойчивости бизнес-приложений, как репликация на удаленную площадку.



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







Основной экран ETERNUS Snapshot Manager



Эту проблему решает пакет ETERNUS Snapshot Manager (ESM Manager) , который Fujitsu разработала на базе выпускаемого ее стратегическим партнером компанией CommVault продукта IntelliSnap для получения мгновенных снимков данных своих дисковых массивов ETERNUS DX. Основной компонент ESM Manager работает на выделенном сервере и управляет всеми операциями с мгновенными снимками (расписанием генерации мгновенных снимках, операции mounting/dismounting и восстановление с использованием мгновенных снимков), а программы-агенты ESM Manager запускаются на продуктивных серверах.



В соответствии с расписанием генерации агент ESM Manager «замораживает» нужные файловые системы и приложения, после чего ETERNUS DX с помощью его функции Advanced Copy очень быстро генерирует мгновенный снимок их данных, который записывается в специальном разделе массива. Advanced Copy поддерживает как создание полной резервной копии данных (клонирование), так и генерацию мгновенного снимка только новых (измененных) данных.





Схема работы ETERNUS Snapshot Manager

1 – замораживание файловой системы или приложения

2 – запись консистентного мгновенного снимка

3 – mount для мгновенного снимка и его индексирование

4 – удаление журнала




По завершении записи мгновенного снимка файловая система или приложения «размораживаются» и снова продолжают свою работу. Далее ESM Manager работает в фоновом режиме и больше не влияет на продуктивную систему. Пакет выполняет операцию mount для только что полученного мгновенного снимка, индексирует его и создает подробный каталог содержащихся в нем данных. С помощью этого каталога и индекса администратор может при необходимости быстро найти и восстановить отдельные файлы, тома или виртуальные машины, например, почтовые ящики Microsoft Exchange и отдельные сообщения.



ESM Manager поддерживает все основные серверные операционные системы (Windows, Linux/Unix и VMware/Hyper-V) и бизнес-приложения от Microsoft (Exchange, SharePoint, SQL Server), Oracle и SAP. Применение ESM Manager существенно улучшает доступность данных критичных приложений, обеспечивая быстрое восстановление их данных, и упрощает управление и защиту важной для бизнеса информации, снижая связанные с этими операциями расходы.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304744/

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

Последствия drop table: Как «Печкин» пережил серию атак инсайдеров, выжил и стал лучше

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





В интернете можно найти немало историй о том, как акционерные конфликты в компаниях ставили их на грань выживания — однако чаще всего такие случаи кажутся чем-то далеким и никак не влияют на повседневную жизнь. В последние пару месяцев многие пользователи сервиса «Печкин» сталкивались с проблемами при работе с ним — и в нашем случае страшилки из бизнес-СМИ стали реальностью, чуть не похоронив весь проект.



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



Предыстория



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



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



Ночная атака и оборона



17 апреля текущего года около 2 часов ночи было получено системное уведомление о «падении» сервиса «Печкин». Дежурный администратор даже не сразу понял, что именно случилось — для части ключевых таблиц проекта (их несколько сотен тысяч) была выполнена команда drop table. По сути, это означало полное удаление некоторых пользовательских данных. Одновременно оставшиеся таблицы были переименованы для затруднения дальнейших разбирательств. При этом размер БД составлял около 1,5 терабайт, так что только ее копирование для дальнейших манипуляций должно было занять около 30 часов.



Разумеется, для всех удаленных таблиц имелись бэкапы базы — полный, инкрементальный и бинлоги. Этого должно было хватить: полный бэкап был за 20 марта, с этого дня до 2 апреля у нас был инкрементальный бэкап, а с 2 по 17 апреля имелись бинлоги.



Важный момент — 17 апреля был выходным днем (воскресенье), так что команде пришлось в срочном порядке выходить на работу, чтобы попытаться хоть как-то восстановить работу сервиса и ответить на гигантский поток обращений от клиентов, обрушившийся на отдел поддержки. К сожалению, глубокого понимания структуры базы данных у специалистов на тот момент не было, что усложняло работу и приводило к ошибкам — например, часть таблиц была «сломана» и в бэкап попали уже «битые» данные.



Были сделаны несколько копий БД — это позволило «накатывать» бэкапы без риска испортить исходные данные. Мы начали процедуру восстановления — но она должна была занять много времени. Сотни тысяч таблиц, огромный объём — только на восстановление бинлогов требовался в лучшем случае день, а с каждым часом потери бизнеса только увеличивались.



Пользователи были в гневе, и их можно понять. Число тикетов поддержки быстро достигло 3000 — пришлось настраивать автоответы, чтобы хоть как-то объяснить каждому из написавших нам, что в действительности произошло.



Предстояло решить главный вопрос: начинать работу с данными за 20 марта или попробовать совершить невозможное и восстановить все на момент падения сервиса. Мы решили бороться за данные каждого пользоваться до конца. Но требовалось подкрепление, поэтому пока члены команды работали изо всех сил, руководство проекта в авральном режиме за день нашло сильного DBA-специалиста — уже ночью того же дня он присоединился к пожарной бригаде в деле восстановления БД таблицы за таблицей. К сожалению, даже при всем этом полное восстановление заняло еще 4 дня — но в итоге у нас были все данные до последней email-кампании!



Как вообще это стало возможным



Первый вопрос, который возникает после прочтения всего вышенаписанного — как вообще удаленное выполнение команды удаления в БД стало возможным? Ответ сколь прост, столь и неприятен — бывший владелец сервиса оставил в коде «бэкдор», подложив скрипт, с помощью которого можно было получать доступ к базе и запускать команды (тот же drop table).



Как мы уже писали, проект оказался в ситуации акционерного конфликта, поэтому мы ожидали возможных атак и готовились к ним. Однако обнаружить все дыры безопасности просто не удалось — технический директор проекта вместе с разработчиками около четырех суток чистили код от потенциально уязвимых мест, но тот, кто этот код писал, все равно оказывался на шаг впереди. Именно поэтому уже после восстановления после ночной атаки на «Печкин» была произведена еще серия нападений, которые приводили к кратковременных падениям сервиса и отказу ряду его функций.



К каким изменениям это приведет



Для того, чтобы предовтратить повторение подобных проблем, мы укрепили оборону «Печкина». Однако даже сейчас гарантировать безопасность на 100% невозможно — все еще есть люди, которые знают код лучше текущей команды и хотят уничтожить проект. Поэтому старый «Печкин» вскоре прекратит свое существование, а на смену ему придет новый более стабильный и современный продукт.



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



Чему это нас научило: главные выводы



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




  • Покупать сервис у разработчика — плохая идея, а у плохого разработчика — очень плохая идея.

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

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





Кроме того, перечислим несколько мыслей по оптимизации структуры базы данных:



Следует избавляться от неэффективного шардинга — шардинг имеет смысл, когда таблицы разносятся по разным инстансам БД, на разные сервера. Шардинг на уровне каждого пользователя, особенно при огромном количестве таблиц — за гранью добра и зла. Огромное количество небольших таблиц приводит к существенному перерасходу дискового пространства из-за высокой степени фрагментации мелких таблиц.

Объединение все в один набор таблиц даст выигрыш по диску от 1,5 до 2 раз. При этом не нужно бояться больших таблиц. Грамотная структура и использование ключей позволят сохранить высокую скорость работы.



Старые данные нужно выгружать в архив — стоит задуматься над сохранением устаревших данных в архивную БД. Это резко сократит размер базы, уменьшит потребление памяти и диска, ускорит работу mysql.



Стоит отказаться от инкрементальных бэкапов в пользу бинарных логов — в нашем случае двухнедельный инкрементальный бэкап занимал 400 гигабайт, в тоже время бинлоги за 2 недели имели объем в 20 гигабайт. Огромный размер бэкапа объяснялся в том числе и большим количеством таблиц. По нашему мнению, инкрементальный бэкап — это ненадежный, сложный в эксплуатации инструмент, не имеющий никаких достоинств перед обычными бинарными логами.



Важно сохранять mysqldump-файлы копий бэкапа — как и в случае бинлогов, преимущества таких дампов в надежности. Даже если файлы окажутся битыми, большой процент данных все равно можно будет восстановить. Сжатие же позволит хранить достаточное количество бэкапов, а с учетом архивной базы данных — еще больше. Это не отменяет использование xtrabackup, но mysqldump станет хорошим дополнением в арсенале инструментов резервного копирования.



На сегодня все, спасибо за внимание. Мы будем рады ответить на все вопросы в комментариях.
Original source: habrahabr.ru.

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

Метки:   Комментарии (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)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Разница между аварийным восстановлением, резервным копированием и непрерывностью бизнеса

Среда, 08 Июня 2016 г. 16:18 (ссылка)

Мы часто слышим, что словосочетания «аварийное восстановление» и «резервное копирование» употребляются взаимозаменяемо, и иногда в неудачном контексте. Некоторые клиенты могут запрашивать аварийное восстановление в то время, как им нужно и резервное копирование тоже. Итак, в чем же разница и почему это так важно?

image



Аварийное восстановление



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



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



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



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



Cryptolocker ransomware — новый тип программы-вымогателя — это хороший пример того, что последний бэкап может содержать зараженные версии, поэтому вам могут потребоваться более старые сохраненные копии документов. Всем известно, что сохраняя месячный отчет, очень легко промахнуться и нажать «Сохранить» вместо «Сохранить как», переписав таким образом изначальный документ. Без сохранения всех версий документов вы, возможно, будете терять важные данные. Для некоторых организаций законодательно утверждена обязанность сохранять копии всех файлов: например, это касается медицины, где необходимо хранить данные пациентов годами.



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



Непрерывность бизнеса



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



Потребности каждой организации в непрерывности определенных бизнес-процессов различаются. Для некоторых видов бизнеса критично наличие устойчивого телефонного соединения, для других — сохранность специализированного оборудования, которое невозможно переместить в короткие сроки. Какие сотрудники исполняют наиболее важные для бизнеса функции? Каковы эти функции? Где эти сотрудники смогут работать, если работа в офисе будет невозможна? Все эти и многие другие вопросы необходимо задать себе, если вы собираетесь создать эффективный план по непрерывности бизнеса, и восстановление данных — это только один из вопросов, о которых необходимо задуматься.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/302904/

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

Следующие 30  »

<восстановление данных - Самое интересное в блогах

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

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