Потеря данных и резервное копирование. Хранитель резервных копий

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

Выход жесткого диска из строя – явление сегодня редкое, однако такое случается. Быть 100% уверенным, что хранящиеся на жестком диске фотографии или другие важные данные надежно защищены, невозможно.

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

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

Возможности программ резервного копирования данных

• Сохранение отдельных файлов и папок. Это могут быть хранящиеся на жестком диске фотографии, видео, музыкальные коллекции или же важные документы и таблицы.
• Резервирование Windows. Чтобы при фатальном сбое системы не переустанавливать ОС и не искать потом драйвера и установленные ранее программы, целесообразно заранее сделать резервную копию системного раздела.

Выбор места для хранения резервной копии

1. Внешний жесткий диск – это наилучшее решение: и надежно, и места хватит на создание полной копии.

3. Оптические диски CD/DVD/Blu-ray – не очень удобно для периодического резервирования. Но если других вариантов нет, то можно использовать.

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

5. Хранение данных в Интернете (облачные сервисы) – высокая надежность резервной копии и возможность получения доступа из любой точки земного шара. Однако при низкой скорости доступа в Интернет создание резервной копии затянется на продолжительный промежуток времени.

Дополнительные возможности программ

• Создание диска аварийного восстановления – при выходе системы из строя, восстановить данные без специального ПО не удастся. Поэтому рекомендуется заранее создать диск аварийного восстановления на случай выхода системы из строя.
• Защита резервных копий данных – есть возможность зашифровать данные с помощью пароля.
• Клонирование жесткого диска – полезная функция, когда требуется перенести целый раздел на другой жесткий диск большего размера. Создается абсолютно точная копия диска или раздела.
• Синхронизация данных позволяет привести данные двух компьютеров (источников данных) в идентичное состояние.
• Безопасное удаление данных – данная функция позволяет надежно удалить конфиденциальные данные, предотвратив любую возможность их восстановления.
• Безопасная среда – функция подобна “Песочнице” в антивирусах. Позволяет установить программу в локальной копии ОС. Если ПО начинает себя подозрительно вести, нарушает работу системы, все сделанные ею изменения можно без труда отменить.

Стратегии резервного копирования

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

Существует два метода подобного резервирования:

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

“+” Так как хранятся копии данных всех предыдущих резервов, то можно восстановить любой файл в любой сохраненной редакции.

”–” Требует много места на диске и занимает много времени.

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

“+” Высокая скорость выполнения резервирования.

”–” Возможно восстановить только последнюю версию редактируемого файла.

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

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

3. После установки программы резервного копирования сразу же создайте диск аварийного восстановления и проверьте его работу.

4. Особо важные и ценные данные храните в двух экземплярах. Создайте две таких копии, одну из которых можно хранить в Интернете в зашифрованном виде.

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

6. При клонировании раздела и последующем его восстановлении имеется вероятность перепутать буквенное обозначение разделов и полностью перезаписать диск. Чтобы этого не допустить, укажите наглядное и понятное название каждому разделу (например, “System (C:)”, “ Work (D:)”).

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

Рассматриваем резервное копирование и создание бекапов с точки зрения организации рабочего процесса

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

Основными тенденциями на 2017-2019 годы мы видим следующие виды резервного копирования:

• копирование с любых устройств по принципу “подписки” за каждый гигабайт данных с помощью облачных сервисов, которые через предустановленный в систему агент “заливают” копии в облако. Пример тому –
• копирование в облако с помощью Veaam и подобных продуктов (Acronis/Symantec/HP Data Protector). Требует подготовки провайдера, настройки коннектора между облаком провайдера и “наземной” виртуальной средой.
• копирование “инхаус” с помощью софтовых решений от производителей NAS систем или выделенных хранилищ корпоративного сектора
• распределенный бекап с помощью встроенных в ОС Windows Server решений

Задачи резервного копирования в организации

Резервное копирование информации чаще всего преследует две цели:

• сохранить данные для максимально быстрого (disaster recovery), если с ИТ-системой компании произошла авария, ее атаковал вирус и т.д. У таких резервных копий сравнительно небольшой период хранения (чаще всего сутки или двое, потом они перезаписываются более новыми), к данным можно получить доступ очень быстро. Копируются пользовательские и бизнес-данные, а также настройки ОС, прикладного ПО и вся информация, необходимая для восстановления работоспособности системы
• создать долговременный архив сведений о деятельности компании, к которому можно обратиться при необходимости получить данные за прошедшие периоды. Такие архивы хранятся долго (месяцы и годы), скорость доступа к ним не особенно важна – обычно не страшно, если получение данных займет несколько дней. Хранятся только бизнес-данные и данные пользователей, нет необходимости хранить какую-либо системную информацию.

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

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

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

Резервное копирование VS Избыточное резервирование

Чтобы оборудование продолжало работать, даже если какой-то отдельный компонент откажет, в него вносится определенная избыточность – «лишние» компоненты или вычислительные ресурсы, которые в обычном рабочем режиме могут показаться ненужными.

Пример избыточного резервирования:

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

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

Распорядок резервного копирования

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

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

Виды резервного копирования в организации

Существуют разные технологии резервного копирования, которые отличаются затратами средств и времени:

• полное резервное копирование – выбранные данные копируются целиком. Самый надежный способ, но требует наибольшего количества ресурсов, места для хранения данных и времени копирования, поэтому в чистом виде применяется редко, обычно комбинируется с другими видами (например, первый раз с системы снимается полная копия, а потом резервируются только внесенные изменения). Позволяет восстановить утраченные данные с нуля быстрее всех остальных видов копирования
• инкрементное копирование – записываются только те данные, которые были изменены со времени прошлого бэкапа. Для таких копий требуется значительно меньше памяти, чем при полном копировании, и снимаются они значительно быстрее. Разумеется, при таком подходе необходимо периодически делать и полную резервную копию, при любой аварии систему восстанавливают из такой копии, а затем накатывают на нее все последующие инкрементные копии в хронологическом порядке. Важный момент: инкрементное копирование восстанавливает удаленные файлы и все предыдущие версии файлов, которые изменялись, так что при восстановлении следует предусмотреть дополнительное дисковое пространство на этот случай
• дифференциальное резервное копирование – похоже на инкрементное, т.е. копируются только изменения, сделанные с момента последнего полного копирования. Отличие в том, что в каждую последующую копию сохраняются изменения из предыдущей и добавляются новые. Получается, что для восстановления после аварии понадобится только полная копия и последняя из дифференциальных, что значительно сокращает время восстановления. Минусами, по сравнению с инкрементным копированием, являются большой объем копий (иногда сравнимый с полным копированием) и большее время копирования.

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

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

По своей топологии схемы резервного копирования также различаются.

• Децентрализованная схема . Её суть в том, что на каждом сервере и рабочей станции может быть собственное ПО для резервного копирования, работающее независимо от других узлов сети. Все данные выгружаются на какой-либо общий сетевой ресурс, откуда потом попадают в архив или восстанавливаются, при необходимости. Достоинства схемы в том, что она чрезвычайно простая, легко реализуется и обычно не требует дополнительного ПО, копирование выполняется штатными средствами операционной системы или СУБД. Есть и недостатки – сложно установить общую политику резервного копирования и защиты информации, общее для всех программ расписание бэкапов, настраивать и мониторить деятельность каждой из программ придется отдельно, что усложняет администрирование. Поэтому децентрализованная схема резервного копирования подойдет либо для небольшой и несложной сети, либо для случаев, когда централизованную схему невозможно организовать в силу каких-либо ограничений
• Централизованная схема – для ее реализации необходимо специализированное клиент-серверное ПО. Серверная часть устанавливается на сервер резервного копирования и централизованно управляет установленными у пользователей программными агентами, которые собирают, копируют информацию о системе или восстанавливают ее из копии. В таком варианте легко настраивать общие политики создания резервных копий, расписание бэкапов, все участники могут работать согласно с общей для компании инструкцией по резервному копированию информации
• Централизованная схема резервного копирования без программ-агентов – упрощенный вариант предыдущей схемы, когда серверная часть использует только существующие службы и сервисы (например, собирает данные из специально назначенных общих папок Windows). Схема не очень надежная, в ней есть известная проблема, когда открытые в текущий момент для редактирования файлы не попадают в резервную копию и при сбое системы могут быть утрачены. Поэтому применять ее стоит только на небольших сетях и при условии высокой пользовательской дисциплины
• Смешанная схема – сочетание централизованной и децентрализованной. Программы-агенты устанавливаются только на некоторых серверах сети, от остальных устройств данные на эти сервера отправляют их локальные программы, каждая своими средствами. А уже с этих серверов накопленную информацию программы-агенты централизованно соберут, обработают и отправят в общее хранилище.

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

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

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

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

Организационные моменты и человеческий фактор

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

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

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

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

Из-за каких причин важные данные могут быть утеряны :

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

Полное резервирование (Full backup) в основном обычно касается полностью всей системы и файлов. Оно может проводиться еженедельно, ежемесячно или ежеквартально. Такой бэкап подразумевает под собой полное копирование оригинала, независимо от времени и его изменений. Это метод является наиболее надежным, хотя он трудоемкий и занимает больше времени чем другие виды бэкапа. Данный тип резервирования лучше всего выполнять на выходных, когда нагрузка на сайт минимальная. Также полное резервирование требует большого хранилища для хранения данных. Какие преимущества такого метода: возможность восстановления системы или необходимого фрагмента практически с нуля в полном объеме.

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

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

Резервирование клонированием – дает возможность скопировать целый раздел или носитель (устройство) со всеми файлами и директориями в другой раздел или на другой носитель. Если раздел является загрузочным, то клонированный раздел тоже будет загрузочным.

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

Пользователи часто не задумываются о надобности и важности бэкапа, когда дело доходит до восстановления утерянных данных. В 2015 году была написана статья о самых дурацких ошибках пользователей по поводу бэкапов (“ 11 Stupid Backup Strategies ”). Так какие же ошибки чаще всего возникают, когда речь заходит о резервном копировании?

Первая и по сути самая существенная ошибка – это отсутствие бэкапов . Если Вы не делаете бэкапов вообще и надеетесь, что и так все будет в порядке, то рано или поздно Ваши данные могут не только пострадать, но и быть полностью утеряны. Так как причины на это бывают самые разные и я их рассмотрела в начале статьи.

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

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

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

Программы для мониторинга работы жестких дисков. Подробнее в статье.

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

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

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

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

Как понять, что жесткий диск Вашего компьютера умирает? Наши советы .

5693 раз(а) 2 Сегодня просмотрено раз(а)

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

Копирование данных с продакшен-сервера на backup-сервер

Продакшен-сервер – это рабочий сервер, который выполняет, какие либо сервисы для пользователей.

backup-сервер – это сервер на который копируется контент с продакшен-сервера. Единственное предназначение такого сервера – хранить данные с других серверов. Обычно сам он никаких сервисов не выполняет. Главное требование – большое дисковое пространство. Скорость дисковых накопителей особого значения не имеет, так как доступ к данным не частый – записать бекап на диск и считать его в случае необходимости.

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

Перекрестное копирование данных

Когда два или более продакшен серверов копируют друг на друга свои данные. В случае, когда на продакшен серверах есть достаточное количество дискового пространства для хранения данных с других серверов, их можно использовать как backup-серверы. Мы копируем данные с сервера server1 на server2 а данные с server2 на server1.

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

Системы хранения данных

“Классические” сервера для хранения бекапов хороши при относительно небольших объемах. Сейчас это несколько сотен гигабайт. Когда же объемы гораздо больше на помощь приходят СХД, Системы Хранения Данных.

Дисковые массивы

По сути такой же сервер, но спроектирован специально под хранение данных. Имеет много HDD большего размера. Например, дисковый массив Sun Storage J4500. Масштабируемость – от 24 до 192 Тб. Поддерживаемые ОС: Solaris, RedHat, Suse, Windows

Ленточные накопители

Они же стримеры. Данные, как и в случае с ленточными библиотеками записываются на специальные картриджи. Как правило, картридж – это магнитная лента в пластиковом корпусе. Например, ленточный накопитель HP StorageWorks DAT 160 SAS. Картридж для HP StorageWorks DAT 160 SAS. 160 Гб.

Ленточные библиотеки

Предназначены для автоматизированного резервного копирования данных. Одновременное использование нескольких лентопротяжных механизмов увеличивает производительность библиотеки и сокращает время, необходимое для записи и чтения резервных копий. Одно из самых серьезных решений SUN. Ленточная библиотека Sun StorageTek SL8500. До 56 петабайт данных. До 70 тысяч картриджей.

Другие носители данных

• optical disc (CD-R/RW, DVD-R/RW);
• flash-накопители;
• ZIP, Jaz, MO драйвы.

Виды бекапа

Полное резервирование (Full backup)

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

Дифференциальное резервирование (Differential backup)

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

Инкрементное резервирование (Incremental backup)

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

Резервирование клонированием

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

Резервирование в виде образа

Образ - точная копия всего раздела или носителя (устройства), хранящаяся в одном файле.

Резервное копирование в режиме реального времени

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

Схемы ротации бекапов

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

Одноразовое копирование – администратор делает копирование вручную. Обычно делается полный бекап данных .

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

“Дед, отец, сын” (GFS) – имеет иерархическую структуру ротации.

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

“Ханойская башня” – название пошло от древней китайской игры. Смысл игры заключается в следующем. Есть три стержня и какой-то набор дисков. Диски нужно перемещать со стержня на стержень, но так, чтобы каждый новый диск ложился на диск большего диаметра. Такой метод бекапа достаточно сложен и практически не применяется в настоящее время.

“10 наборов” – метод рассчитан на 10 наборов носителей. Период из 40 недель делится на десять циклов. В течение цикла за каждым набором закреплен один день недели. По прошествии четырехнедельного цикла осуществляется сдвиг номера набора. То есть в первом цикле за понедельник отвечал набор N1, за вторник N2, за среду N3 и т.д. Во втором цикле за понедельник будет отвечать набор N2, за вторник N3, за среду N4 и т.д. Такая схема позволяет равномерно распределить нагрузку между носителями, но из-за своей сложности практически не используется.

Методы резервирования баз данных

• hot backup – горячий бекап базы данных. Это когда резервная копия делается при включенном сервере БД.
• cold backup – холодный бекап базы данных. Это когда сервер БД нужно выключить, чтобы сделать резервную копию.

АЛЕКСЕЙ БЕРЕЖНОЙ, системный администратор. Главные направления деятельности: виртуализация и гетерогенные сети. Еще одно увлечение помимо написания статей – популяризация бесплатного ПО

Резервное копирование
Теория и практика. Краткое изложение

Чтобы организовать систему резервного копирования наиболее эффективно, нужно выстроить настоящую стратегию сохранения и восстановления информации

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

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

В данной статье речь пойдет как раз об обратном: основное внимание уделено общим понятиям, а технические средства будут затронуты только в качестве примеров. Это позволит абстрагироваться от аппаратного и программного обеспечения и ответить на два главных вопроса: «Зачем мы это делаем?», «Можем ли мы это делать быстрее, дешевле и надежнее?».

Цели и задачи резервного копирования

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

Классическим примером резервной копии для Disaster Recovery является образ системной партиции сервера, созданный программой Acronis True Image.

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

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

• Период хранения данных. У архивных копий он достаточно длительный. В некоторых случаях регламентируется не только требованиями бизнеса, но и законодательно. У копий для аварийного восстановления он сравнительно небольшой. Обычно создают одну или две (при повышенных требованиях к надежности) резервные копии для Disaster Recovery c максимальным интервалом в сутки-двое, после чего они перезаписываются свежими. В особо критичных случаях возможно и более частое обновление резервной копии для аварийного восстановления, например, раз в несколько часов.
• Быстрота доступа к данным. Скорость доступа к длительно хранящемуся архиву в большинстве случаев не критична. Обычно необходимость «поднять данные за период» возникает в момент сверки документов, возврата к предыдущей версии и т.д., то есть не в аварийном режиме. Другое дело – аварийное восстановление, когда необходимые данные и работоспособность сервисов должны быть возвращены в кратчайшие сроки. В этом случае скорость доступа к резервной копии является крайне важным показателем.
• Состав копируемой информации. В архивной копии обычно содержатся только пользовательские и бизнес-данные за указанный период. В копии, предназначенной для аварийного восстановления, помимо этих данных, содержатся либо образы систем, либо копии настроек операционной системы и прикладного программного обеспечения, а также другой информации, необходимой для восстановления.

Иногда возможно совмещение этих задач. Например, годовой набор ежемесячных полных «снимков» файлового сервера, плюс изменения, сделанные в течении недели. В качестве инструмента для создания такой резервной копии подойдет True Image.

Самое главное – четко понимать, для чего делается резервирование. Приведу пример: вышел из строя критичный SQL-сервер по причине отказа дискового массива. На складе есть подходящее аппаратное обеспечение, поэтому решение проблемы состояло только в восстановлении программного обеспечения и данных. Руководство компании обращается с понятным вопросом: «Когда заработает?» – и неприятно удивляется, узнав, что на восстановление уйдет целых четыре часа. Дело в том, что на протяжении всего срока службы сервера регулярно осуществлялось резервное копирование исключительно баз данных без учета необходимости восстановить сам сервер со всеми настройками, включая программное обеспечение самой СУБД. Попросту говоря, наши герои сохраняли только базы данных, а про систему забыли.

Приведу другой пример. Молодой специалист на протяжении всего периода своей работы создавал посредством программы ntbackup одну-единственную копию файлового сервера под управлением Windows Server 2003, включая данные и System State в общую папку другого компьютера. По причине дефицита дискового пространства эта копия постоянно перезаписывалась. Через некоторое время его попросили восстановить предыдущий вариант многостраничного отчета, который был поврежден при сохранении. Понятное дело, что, не имея архивной истории с выключенным Shadow Copy , он не смог выполнить этот запрос.

На заметку Shadow Copy , дословно – «теневая копия». Обеспечивает создание мгновенных копий файловой системы таким образом, что дальнейшие изменения оригинала никак не оказывают на них влияния. С помощью данной функции возможно создавать несколько скрытых копий файла за определенный период времени, а также на лету резервные копии файлов, открытых для записи. За работу Shadow Copy отвечает служба Volume Copy Shadow Service. System State , дословно – «состояние системы». Копирование System State создает резервные копии критических компонентов операционных систем семейства Windows. Это позволяет восстановить инсталлированную ранее систему после разрушения. При копировании System State происходит сохранение реестра, загрузочных и других важных для системы файлов, в том числе для восстановления Active Directory, Certificate Service database, COM+Class Registration database, SYSVOL-директории. В ОС семейства UNIX непрямым аналогом копирования System State является сохранение содержимого каталогов /etc, /usr/local/etc и других необходимых для восстановления состояния системы файлов.

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

При небольших объемах данных и не очень сложной ИТ-инфраструктуре можно попытаться совместить обе эти задачи в одной, например, делать ежедневное полное копирование всех дисковых разделов и баз данных. Но все же лучше различать две цели и подбирать под каждую из них правильное средство. Соответственно под каждую задачу используется свой инструмент, хотя есть и универсальные решения, как тот же пакет Acronis True Image или программа ntbackup

Понятно, что, определяя цели и задачи резервного копирования, а также решения для реализации, необходимо исходить из требований бизнеса.

При реализации задачи аварийного восстановления можно использовать разные стратегии.

В одних случаях необходимо прямое восстановление системы на «голое железо» (bare metal). Это можно выполнить, к примеру, с помощью программы Acronis True Image в комплекте с модулем Universal Restore. В этом случае конфигурацию сервера удается вернуть в строй за очень короткий срок. Например, раздел с операционной системой в 20 Гб вполне реально поднять из резервной копии за восемь минут (при условии, что архивная копия доступна по сети 1 Гб/с).

В другом варианте целесообразнее просто «вернуть» настройки на только что проинсталлированную систему, как, например, копирование в UNIX-подобных системах конфигурационных файлов из папки /etc и других (в Windows этому приблизительно соответствует копирование и восстановление System State). Конечно, при таком подходе сервер введется в работу не ранее, чем будет проинсталлирована операционная система и восстановлены необходимые установки, что займет гораздо более длительный срок. Но в любом случае решение, каким быть Disaster Recovery, проистекает из потребностей бизнеса и ресурсных ограничений.

Принципиальное отличие резервного копирования от систем избыточного резервирования

Это еще один интересный вопрос, который хотелось бы затронуть. Под системами избыточного резервирования оборудования подразумевается внесение некоторой избыточности в аппаратное обеспечение с целью сохранения работоспособности в случае внезапного выхода из строя одного из компонентов. Прекрасный пример в данном случае – RAID-массив (Redundant Array of Independent Disks). В случае отказа одного диска можно избежать потери информации и безопасно произвести замену, сохранив данные за счет специфичной организации самого дискового массива (подробнее о RAID читайте в ).

Мне доводилось слышать фразу: «У нас очень надежное оборудование, везде стоят RAID-массивы, поэтому резервные копии нам не нужны». Да, конечно, тот же самый RAID-массив убережет данные от разрушения при выходе из строя одного жесткого диска. Но вот от повреждения данных компьютерным вирусом или от неумелых действий пользователя это не спасет. Не спасет RAID и при крахе файловой системы в результате несанкционированной перезагрузки.

Кстати Важность отличия резервного копирования от систем избыточного резервирования следует оценивать еще при составлении плана копирования данных, касается ли это организации или домашних компьютеров. Спросите себя, зачем вы делаете копии. Если речь идет о резервном копировании, то подразумевается сохранение данных при случайном (умышленном) действии. Избыточное резервирование дает возможность сохранить данные, в том числе и резервные копии, при выходе оборудования из строя. Сейчас на рынке появилось множество недорогих устройств, обеспечивающих надежное резервирование с помощью RAID-массивов или облачных технологий (например, Amazon S3). Рекомендуется использовать одновременно оба вида резервирования информации. Андрей Васильев, генеральный директор компании Qnap Россия

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

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

Единственное, что может выступить в качестве неполноценной замены резервного копирования для Disaster Recovery, – наличие зеркального резервного сервера с постоянным реплицированием данных с основного сервера на резервный (по принципу Primary  Standby). В этом случае при выходе из строя основного сервера его задачи будут подхвачены резервным, и даже не придется переносить данные. Но такая система является довольно дорогостоящей и трудоемкой при организации. Не забываем еще про необходимость постоянной репликации.

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

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

Понятие «окно бэкапа»

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

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

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

Виды резервного копирования

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

Полное резервное копирование (или Full backup)

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

Инкрементное копирование

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

Для чего используется этот вид копирования? В случае создания архивных копий он необходим, чтобы сократить расходуемые объемы на устройствах хранения информации (например, сократить число используемых ленточных носителей). Также это позволит минимизировать время выполнения заданий резервного копирования, что может быть крайне важно в условиях, когда приходится работать в плотном графике 24х7 или прокачивать большие объемы информации.

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

Дифференциальное резервное копирование

Отличается от инкрементного тем, что копируются данные с последнего момента выполнения Full backup. Данные при этом помещаются в архив «нарастающим итогом». В системах семейства Windows этот эффект достигается тем, что архивный бит при дифференциальном копировании не сбрасывается, поэтому измененные данные попадают в архивную копию, пока полное копирование не обнулит архивные биты.

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

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

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

Рассмотрим какие бывают схемы резервного копирования.

Децентрализованная схема

Ядром этой схемы является некий общий сетевой ресурс (см. рис. 1). Например, общая папка или FTP-сервер. Необходим и набор программ для резервного копирования, время от времени выгружающих информацию с серверов и рабочих станций, а также других объектов сети (например, конфигурационные файлы с маршрутизаторов) на этот ресурс. Данные программы установлены на каждом сервере и работают независимо друг от друга. Несомненным плюсом является простота реализации этой схемы и ее дешевизна. В качестве программ копирования подойдут штатные средства, встроенные в операционную систему, или программное обеспечение, такое как СУБД. Например, это может быть программа ntbackup для семейства Windows, программа tar для UNIX-like операционных систем или набор скриптов, содержащих встроенные команды SQL-сервера для выгрузки баз данных в файлы резервных копий. Еще одним плюсом является возможность использования различных программ и систем, лишь бы все они могли получить доступ к целевому ресурсу для хранения резервных копий.

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

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

Централизованное резервное копирование

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

Именно по такому принципу работает большинство популярных систем резервного копирования, таких как Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula и другие (см. рис. 2).

Помимо различных агентов для большинства операционных систем существуют разработки для резервного копирования популярных баз данных и корпоративных систем, например, для MS SQL Server, MS Exchange, Oracle Database и так далее.

Для совсем небольших компаний в некоторых случаях можно попробовать упрощенный вариант централизованной схемы резервного копирования без применения программ-агентов (см. рис. 3). Также эта схема может быть задействована, если не реализован специальный агент для используемого ПО резервного копирования. Вместо этого серверный модуль будет использовать уже существующие службы и сервисы. Например, «выгребать» данные из скрытых общих папок на Windows-серверах или копировать файлы по протоколу SSH c серверов под управлением UNIX-систем. Данная схема имеет весьма существенные ограничения, связанные с проблемами сохранения файлов, открытых для записи. В результате подобных действий открытые файлы будут либо пропущены и не попадут в резервную копию, либо скопированы с ошибками. Существуют различные методы обхода данной проблемы, например, повторный запуск задания с целью скопировать только ранее открытые файлы, но нет ни одного надежного. Поэтому такая схема подходит для применения только в определенных ситуациях. Например, в небольших организациях, работающих в режиме 5х8, с дисциплинированными сотрудниками, которые сохраняют изменения и закрывают файлы перед уходом домой. Для организации такой усеченной централизованной схемы, работающей исключительно в среде Windows, неплохо подходит ntbackup. При необходимости использовать подобную схему в гетерогенных средах или исключительно среди UNIX-компьютеров я рекомендую посмотреть в сторону Backup PC (см. ).

Рисунок 4. Смешанная схема резервного копирования

Что такое off-site?

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

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

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

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

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

1. Описание резервного копирования в системе Windows, в том числе System State – http://www.datamills.com/Tutorials/systemstate/tutorial.htm .
2. Описание Shadow Copy – http://ru.wikipedia.org/wiki/Shadow_Copy .
3. Официальный сайт Acronis – http://www.acronis.ru/enterprise/products .
4. Описание ntbackup – http://en.wikipedia.org/wiki/NTBackup .
5. Бережной А. Оптимизируем работу MS SQL Server. //Системный администратор, №1, 2008 г. – С. 14-22 ().
6. Бережной А. Организуем систему резервного копирования для малого и среднего офиса. //Системный администратор, №6, 2009 г. – С. 14-23 ().
7. Маркелов А. Linux на страже Windows. Обзор и установка системы резервного копирования BackupPC. //Системный администратор, №9, 2004 г. – С. 2-6 ().
8. Описание VPN – http://ru.wikipedia.org/wiki/VPN .
9. Дедупликация данных – http://en.wikipedia.org/wiki/Data_deduplication .

Вконтакте