Kwert-soft.ru

IT Софт для ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Восстановление и защита данных

Методы аварийного восстановления для защиты базы данных

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

  • Неисправности аппаратного обеспечения
  • Вирусы
  • Некорректное использование инструкций UPDATE и DELETE
  • Ошибки программного обеспечения
  • Аварийные ситуации, например, пожар или затопление

Чтобы избежать потери данных, можно реализовать для базы данных стратегию восстановления. Стратегию восстановления необходимо спланировать, реализовать и протестировать с учетом возможных неисправностей, с которыми можно встретиться в процессе работы системы, и необходимого уровня защиты данных. В витринах данных, то есть в случаях, когда данные можно восстановить из других систем, вероятно, нет необходимости создавать резервные копии каждой отдельной транзакции. Возможно, будет достаточно выполнять полное резервное копирование данных с регулярными временными интервалами. И наоборот, для базы данных , в которой хранятся транзакции интернет-магазина, возможно, будет необходимо сохранять резервные копии каждой отдельной транзакции. СУБД SQL Server предоставляет полный комплекс функций для реализации именно того вида резервного копирования, который вам необходим. В данной лекции рассматриваются наиболее широко используемые в Microsoft SQL Server стратегии для защиты данных.

Полное резервное копирование базы данных

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

Полная резервная копия базы данных содержит все данные и метаинформацию базы данных , которые необходимы для восстановления базы данных полностью, включая полнотекстовые каталоги. При восстановлении базы данных из полной резервной копии восстанавливаются все файлы базы данных , причем данные извлекаются в непротиворечивом состоянии на тот момент времени, в который выполнялось резервное копирование . Пока выполняется резервное копирование , база данных работает в рабочем режиме, и пользователь может выполнять транзакции, изменяя данные обычным путем. Термин «непротиворечивое состояние» означает, что все транзакции, которые были зафиксированы в процессе выполнения резервного копирования базы данных , применяются, а все транзакции, которые не были завершены, подвергаются откату. Для ситуаций, которые могли бы привести к нарушению непротиворечивости данных вследствие выполнения транзакций, изменяющих данные в процессе выполнения резервного копирования, в SQL Server есть особый процесс, который позволяет гарантировать непротиворечивость данных. Этот процесс выполняет запись на устройство резервного копирования как страниц данных, так и журнала транзакций.

Скорость резервного копирования определяется скоростью используемых устройств ввода/вывода (тех устройств ввода вывода, которые используются для сбора и хранения информации). Чтобы добиться наилучшей производительности, SQL Server считывает файлы последовательно. Если ваши устройства ввода/вывода способны одновременно обрабатывать данные ввода/вывода резервного копирования и данные ввода/вывода, поступающие в результате обычного использования системы, то создание резервной копии окажет на производительность системы незначительное воздействие. Тем не менее, лучше выполнять полное резервное копирование базы данных при отсутствии пиковых нагрузок.

В следующем разделе мы рассмотрим варианты реализации этой стратегии резервного копирования.

Простая модель восстановления

Следует заранее уведомить SQL Server о том, какой тип резервного копирования вы намерены использовать, поэтому надо сконфигурировать базу данных так, чтобы настройки соответствовали выбранному вами типу резервного копирования. Такая настройка выполняется посредством выбора значения параметра «модель восстановления базы данных». Модель восстановления базы данных, которая используется по умолчанию, является производным от модели восстановления модели базы данных, определенной при ее создании. Чтобы реализовать стратегию резервного копирования, которая будет включать только полные резервные копии, следует выбрать простую модель восстановления ( SIMPLE ).

Выбираем модель восстановления SIMPLE
  1. В меню Start (Пуск) выберите All Programs,. Microsoft SQL Server 2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда SQL Server Management Studio).
  2. В диалоговом окне Connect To Server (Соединение с сервером) нажмите кнопку Connect (Соединить).
  3. В панели инструментов Standard (Стандартная) нажмите кнопку New Query (Новый запрос), чтобы открыть окно New Query (Новый запрос).
  4. Чтобы задать модель восстановления, можно использовать инструкцию ALTER DATABASE . Введите текст следующей инструкции и нажмите кнопку Execute (Выполнить).
Проверяем настройки модели аварийного восстановления
  1. Чтобы просмотреть заданную для базы данных модель восстановления, можно использовать функцию DATABASEPROPERTYEX , которая извлекает параметры текущей базы даты или свойства указанной базы данных. Выполните инструкцию, приведенную ниже, чтобы извлечь информацию о модели восстановления базы данных AdventureWorks .

Устройства резервного копирования

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

  • Ленточные устройства.Могут использоваться для хранения резервных копий на лентах. Ленточные устройства должны быть установлены локально. Резервная копия может занимать несколько лент, а на одной ленте могут находиться одновременно резервные копии SQL Server и Windows.
  • Дисковые устройства.Файлы на локальном или удаленном диске или дисковом накопителе. К этим файлам обращаются, указывая путь к файлу, в котором хранится резервная копия. Для обращения к удаленным хранилищам следует использовать путь в формате UNC.

Устройства резервного копирования идентифицируются по имени устройства. В качестве имени устройства может использоваться имя логического или физического устройства. Имя физического дискового устройства представляет собой путь к файлу резервной копии, например, «\BACKUPSERVERBackupsadvAdventureWorks. bak » . Этот путь можно включить непосредственно в инструкцию резервного копирования. Имя логического устройства представляет собой имя, указывающее на имя физического устройства резервного копирования и хранящееся в SQL Server . Когда в инструкции резервного копирования используется имя логического устройства, SQL Server осуществляет поиск соответствующего физического устройства в системном каталоге и выполняет резервное копирование , сохраняя резервную копию в указанной папке.

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

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

Читать еще:  Защита файлов от копирования

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

7 полезных советов по защите резервных копий от вирусов-шифровальщиков

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

Проблема вирусов-шифровальщиков затрагивает уже не только отдельно взятые персональные компьютеры, но доходит до уровня дата-центров. Для атак на инфраструктуру компаний применяются, например, Locky, TeslaCrypt и CryptoLocker. Зачастую вирусы используют уязвимости веб-браузеров или их плагинов, а также непредусмотрительно открытые вложения сообщений электронной почты. Проникнув в инфраструктуру, программа-вымогатель начинает быстрое распространение и шифрование данных.

Важной составляющей стратегии защиты данных всегда было наличие резервных копий, из которых можно выполнить восстановление. Рассмотрим же несколько рекомендаций от моего коллеги Rick Vanover относительно того, как как уберечь СХД резервных копий от шифровальщиков (вне зависимости от того, используете вы решения Veeam или других производителей). Итак, добро пожаловать под кат.

1. Используйте отдельную учетную запись для доступа к хранилищу резервных копий

Эта общечеловеческая рекомендация особенно актуальна в эпоху троянов-шифровальщиков.

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

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

2. Имейте резервные копии, хранящиеся offline (без подключения к инфраструктуре)

Весьма действенный способ обезопасить себя от проникновения трояна-шифровальщика – сохранять резервные копии offline (то есть вне работающей инфраструктуры). Например, если вы используете решение Veeam, то можно рассмотреть следующие опции:

Где хранить данныеПояснение
Магнитная лентаВсегда offline (если только не в процессе чтения-записи).
Реплика ВМОбычно выключена; в большинстве случаев будет задействована в среде с аутентификацией, отдельной от продакшена (например, хосты vSphere и Hyper-V в разных доменах).
Аппаратные снимки производственных СХДМожно использовать для восстановления; обычно задействуются в среде с аутентификацией, отдельной от продакшена.
Бэкапы в Cloud ConnectНе подключаются непосредственно к инфраструктуре резервного копирования; задействуют иной механизм аутентификации.
Сменные носители (например, внешний жесткий диск)Всегда offline (если только не в процессе чтения-записи).

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

3. Используйте для хранения бэкапов СХД с разными файловыми системами

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

  • СХД Data Domain со встроенной дедупликацией и использованием DDBoost (рекомендованный метод) или с монтированием NFS в случае, если DDBoost не используется
  • СХД Hewlett Packard Enterprise (HPE) StoreOnce со встроенной дедупликацией и использованием Catalyst
  • ExaGrid со встроенной дедупликацией и использованием Veeam agent

При указанных вариантах доступ к СХД со стороны процессов Veeam будет происходить в рамках специфического контекста безопасности (security context).

4. По возможности создавайте аппаратные снимки СХД резервных копий

Аппаратные снимки являются, так сказать, «полу-оффлайновым» способом сохранения данных в случае работы с основной СХД. Если же есть возможность создания аппаратных снимков и для СХД резервного копирования, то вполне резонно задействовать ее для предотвращения атак шифровальщиков.

5. Применяйте правило «3-2-1-1»

Как вы помните, есть правило «3-2-1», которое предписывает хранить 3 резервных копии как минимум на носителях двух типов, и одну из этих копий держать на резервной площадке (а не в месте расположения производственной инфраструктуры).

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

6. Контролируйте работу оборудования и ПО

Одна из угроз, которые несут с собой шифровальщики — это потенциальная возможность распространения на другие системы. Поэтому важно контролировать работу оборудования, процессов и приложений с целью выявления подозрительной активности. Так, Veeam ONE 9.5 предлагает вашему вниманию новое встроенное оповещение Possible ransomware activity (вероятная активность шифровальщика). Оно срабатывает, если замечена повышенная активность в использовании ЦПУ и рост количества операций записи на диск.

7. Задействуйте задания переноса резервных копий Backup Copy Job

Для того, чтобы получить точку восстановления, хранящуюся на удаленной СХД и имеющую свою политику хранения (отличную от той, что задана в настройках бэкапа), удобно использовать задание переноса резервных копий Backup Copy Job. Это задание берет данные из репозитория резервных копий и на их основе создает точки восстановления на удаленной СХД. Так, например, если вы добавили еще одну СХД к инфраструктуре резервного копирования (допустим, Linux), то можно создать соответствующий репозиторий и затем настроить задание переноса для работы с ним.

Читать еще:  Как отключить защиту паролей

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

Что еще почитать и посмотреть

Статья на Хабре о правиле 3-2-1 для резервного копирования:

Образовательный блог — всё для учебы

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

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

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

Восстановление СУБД означает восстановление самой БД, т.е. возвращение в исходное (правильное) состояние, если в результате какого-либо сбоя состояние данных стало неверным или подозрительным.
Для того, чтобы данные восстанавливать, надо иметь избыточность (путем резервирования, за счет дополнительных исходных данных), реализуется на физическом уровне, поэтому скрыта от конечного пользователя.

1. Транзакции

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

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

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

Ключевые операторы:
Commit – подтвердить изменения. Сигнализирует серверу БД (диспетчеру управления транзакциями), что все операторы успешно выполнены и можно подтвердить изменения.
Roll back – отменить назад. Извещает, что произошел сбой и нужно все, что было сделано, отменить.

Среди операторов, которые можно отменять назад, есть операторы, которые внутри транзакции делать нельзя, поскольку сделать их откат назад нельзя: операторы создания новых объектов (таблиц, домена, индекса), процедур, триггеры (все операторы, начинающиеся на create (создать), alter (изменить), drop (удалить).

Модель транзакции:
В стандарте ANSIISO принята модель: транзакция автоматически начинается с выполнения первого оператора обновления от пользователя и продолжается до тех пор, пока не появится Commit или Roll back,которые заканчивают транзакцию.

В некоторых СУБД (SyBase, SQL Server) принята другая модель транзакций: прежде, чем начать транзакцию, надо ввести команду Begin Transaction.Считается, что после этого любой оператор обновления входит в транзакцию. Если есть единичный оператор обновления за рамками команды Begin Transaction,то он считается оператором обновления с авто commit-ом.

Свойства АСИД (ACID):
1. Атомарность (atomicy) – в транзакции выполняются либо все операторы, либо ничего не выполняется — все откатывается назад, БД возвращается в исходное состояние.
2. Согласованность (consistency) – транзакции переводят БД из одного согласованного состояния в другое без обязательной поддержки в промежуточных точках (операторах).
3. Изолированность (isolation) – транзакции отделены друг от друга. Выполнение нескольких конкурирующих транзакций скрыто друг от друга до их окончания.
4. Долговечность (durability) – после выполнения транзакции ее обновление сохраняется даже если после этого произойдет отказ или сбой системы.

Именованные транзакции:
Существует много моделей транзакций от чисто теоретических до практических, используемых в разных СУБД.
— Плоская транзакция: простейшая транзакция. Она может только начаться и только закончиться, ничего другого она не предполагает.
— Вложенная транзакция (предложены в 1981 году Моссом): Внутри одной транзакции начинается другая. Чтобы их отличать, чтобы разобраться, какая началась, какая закончилась, было принято именовать транзакции. Для вложенных транзакций существует 2 правила:
1) Правило отката: откат внешней транзакции приводит к откату внутренней, даже если она уже зафиксирована оператором Commit.
2) Правило видимости: все изменения, подтвержденные во внутренней транзакции, должны быть видны во внешней.

Хроники:
Гарсия-Малина в 1987 году предложил концепцию хроник, которая предполагает наличие компенсирующей транзакции: последовательно выполняются несколько плоских (одноуровневых) транзакций, при необходимости посылается компенсирующая транзакция, которая все отбрасывает назад (устраняет результаты нескольких плоских транзакций). Применяется такой механизм, когда транзакции относительно независимы друг от друга.

Точки сохранения (save points):
Приняты в стандарте и многие СУБД используют их на практике. Во многом похожи на подтранзакцию и предполагают, что внутри транзакции может происходить откат не к началу, а к некоторому промежуточному значению (точке сохранению), которое может отметить разработчик.
Rollback to

Файлы регистрации (журнал транзакций, log-файлы):
Для того, чтобы иметь возможность отменять транзакцию, СУБД должна поддерживать журнал транзакций и запись в него обновлений. Запись в него обычно происходит до начала транзакции (протокол предварительной записи в журнал). Т.е, как только пользователь посылает команду изменения, СУБД автоматически вводит в журнал транзакций 1 запись для каждой изменяемой строки, которая включает в себя идентификатор транзакции, время начала транзакции, 2 копии строки (до и после изменения).

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

Отложенные транзакции
Проверка всех доменов, ограничений и т.п. происходит не сразу после выполнения оператора, а на момент завершения транзакции. В этом случае протокол предварительной записи в журнал не используется, а данные заносятся в БД после получения команды фиксации.

Работа проще и быстрей, но вызывать отложенную транзакцию тяжело. Необходимо в тех случаях, когда промежуточные данных не отвечают существующим ограничениям, но до завершения транзакции это несоответствие может быть исправлено. Используются только крупными СУБД (ORACLE,SyBase).

Читать еще:  Защита от фишинга

На практике в крупных СУБД журнал регистрации часто состоит из 2-х частей: активной (интерактивной) и архивной (автономной). Интерактивная часть используется в процессе работы, она имеет размер, и пока он не заполнится, архивный специальными методами сжимается. Как только текущий журнал заполняется, он переводится в режим архивации, а заполняется уже чистый. Архивный журнал нужен для того, чтобы восстановить журнал при сбое. Размер журналов нужно рассчитывать так, чтобы не получилось, что активный журнал заполняется быстрее, чем архивируется автономный.

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

Рекомендуемый размер журнала транзакций для реляционной БД 10-25% от основной БД, для БД, работающей в режиме большого числа параллельных транзакций и высокой скорости изменения, 70-75% от БД.

Оперативная обработка транзакций (OLTP – On-Line Transaction Processing):
Первоначально реляционные СУБД не использовались для систем с оперативной обработкой транзакций из-за низкого быстродействия, доминировали иерархические СУБД. В 1986 году фирма SyBase первой представила СУБД для OLTP-систем, которая обрабатывала до 250-ти транзакций в секунду), временные СУБД обрабатывают 1000 транзакций в секунду).
Для тестирования производительности СУБД существуют специальные тесты ТРС-АВС.

2. Контрольные точки (Check-points)
Необходимы для того, чтобы периодически фиксировать состояние системы. Т.е. с некоторым периодом времени система принимает контрольную точку, в этот момент содержимое всех оперативных буферов, т.ч. и выполняемые транзакции, записываются на диск. Если происходит отказ системы, то все транзакции, которые были начаты до или после записи контрольной точки, но успели закончиться до отказа, эти транзакции заново повторяются за счет информации, которая хранится на диске журнала, если они не закончились до отказа, то они автоматически отменяются.

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

4. Двухфазная фиксация
При работе с несколькими базами данных, имеющими раздельные журналы транзакций, необходим системный компонент – координатор. Его назначение – гарантировать восстановление данных, если произошло нарушение. Фактически он берет на себя функции принятия решения, фиксировать или отменять транзакцию в системе вообще. Данные могут подтверждаться в каждой БД в разное время и в соответствии со своим журналом транзакций. Координатор принимает положительные отзывы от каждой из баз данных, и если все они получены, производит фиксацию, а если какой-либо отзыв не получен, происходит общий откат глобальной транзакции.

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

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

Для поддержки зеркального копирования, напр. в SQL Server, есть специальный пользователь, управляющий зеркальным копированием (Mirror Handing User),в списке процессов он имеет имя speed1.

Восстановление и защита данных. Резервное копирование. Управление дисками.

Содержимое жестких дисков нередко представляет огромную ценность для пользователя. Предлагаем Вам курс «Восстановление и защита данных. Резервное копирование. Управление дисками» – Вы сможете самостоятельно устранять проблемы, связанные с потерей данных.

Вы научитесь использовать системные утилиты Paragon Drive Backup и Paragon Partition Manager, предназначенные для удобной и безопасной работы с жесткими дисками. Это уникальное программное решение позволит Вам устранить риск потери и повреждения информации в случае системных сбоев при существенной экономии средств, времени и усилий. Утилита Drive Backup предоставляет широкий набор функций резервного копирования и восстановления данных.

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

Вы научитесь созданию резервных копий (образов). Вы сможете записать резервную копию непосредственно на CD/DVD диски, при этом образ будет автоматически разнесен на несколько дисков. Это позволит восстановить данные даже в том случае, если операционная система не загружается. Для этого используется специальный загрузочный CD (Recovery CD).

Прекрасным дополнением к программе резервного копирования будет универсальная утилита для работы с жесткими дисками Partition Manager, которая предоставляет полный спектр функций для простого и надежного управления жесткими дисками и разделами. С ее помощью Вы сможете легко и безопасно выполнять любые операции с разделами жесткого диска.

Защитите Вашу информацию! Овладейте методами восстановления и защиты данных в Центре «Специалист»!

Цель курса:

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

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

Учебный центр «Специалист» при МГТУ им. Н.Э.Баумана — авторизованный учебный центр компании Paragon Software Group на территории Российской Федерации, проводящий обучение по линейке продуктов Paragon

Продолжительность курса — 16 ак. ч.

Ссылка на основную публикацию
Adblock
detector