Почти все наши заказчики, внедрившие себе системы резервного копирования (СРК), думают, что на этом все их проблемы решены. Они сделали все от них зависящее, чтобы все было зарезервировано, а в случае аварии корректно восстановлено. Но часто случается так: компания сталкивается с серьезной проблемой, и традиционная система резервного копирования не позволяет восстановиться за то время, которое в компании считается целевым. По факту SLA, которому должна соответствовать система резервного копирования, не выполняется. Увы, за время своей работы мы накопили множество печальных примеров, подтверждающих это. Ниже мы приведем два кейса и дадим советы, какие технические средства позволят сократить время восстановления. Выбирая кейсы, мы останавливались на примерах, связанных с базами данных, где хранилась наиболее критичная для бизнеса информация.
Краткое описание причины аварии: ошибка персонала, неправильная установка патча на Oracle.
Речь идет о крупной компании, которая имеет зрелое ИТ-подразделение и вкладывает достаточно средств в его оборудование и персонал. Достаточно сказать, что СУБД Oracle работала на двух Oracle Exadata, распределенных по двум технологическим площадкам, с проработанным DR-решением и настроенной системой резервного копирования.
В один печальный день было принято решение установить патч на СУБД Oracle. К сожалению, инженер не дочитал инструкцию до конца: «Что я, патч не установлю без бумажки?!» - и неправильно сделал это. Ошибку заметили через несколько часов, когда СУБД стала вести себя странно и сообщать об этом в журналах. Тогда инженер принял решение откатиться. Это действие окончательно обездвижило оба экземпляра базы (все изменения успели отреплицироваться на Standby) и испортило все данные.
Компания осталась без своего главного информационного актива - базы данных, через которую работали все бизнес-процессы. Бизнес практически встал.
Заказчик принял решение восстанавливаться из резервной копии. В то время восстановление базы в 5 ТБ (сейчас ~15 ТБ) заняло - внимание! - более 30 часов! Итого, через 1,5 дня восстановили базу на день раньше аварии. Но данных-то было больше! Все остальное силами программистов и персонала восстанавливали из других систем компании, из первичной документации (бланков заявлений, копий, сканов). На это ушло еще 1,5 дня напряженной работы.
2 High-End системы Oracle Exadata, Oracle Standby, работающая система резервного копирования и 3!!! дня полного простоя при неправильной установке патча. Было ли это допустимо согласно регламенту компании? Конечно же, нет.
Основная проблема: отсутствие средств быстрого восстановления при логических ошибках.
Для смягчения последствий подобных аварии нужно двигаться в двух направлениях. С одной стороны, делать резервирование чаще, а с другой - иметь возможность быстро восстановиться. Могли бы помочь следующие продукты:
Oracle FlashBack - технология, позволяющая делать не только «накат» новых данных на резервную систему Oracle, но и откат до нужной транзакции. При такой схеме можно было бы откатить систему до начала проблем с патчем, что сильно бы облегчило восстановление данных.
Технология Snapshot. Мгновенные снимки позволяют резервировать и восстанавливать данные за секунды. При этом они слабо влияют на производительность, и есть возможность делать снимки достаточно часто (например, раз в час). Таким образом, можно было откатиться на час назад и восстанавливать только час потерянных данных.
Continuous Data Protection - непрерывная защита данных. Это проприетарные устройства или ПО, позволяющее логировать все записи с возможностью отката на любую точку во времени. Действует аналогично Oracle FlashBack, но для любых данных.
Заказчик: Федеральная служба в одном из субъектов РФ
Краткое описание причины аварии: аппаратная ошибка внутри дискового массива.
В этот раз у компании чуть менее развитая ИТ-инфраструктура, зато чаще встречающаяся у наших заказчиков: дисковые массивы среднего уровня, СУБД Oracle, Standby не используется.
Как это часто бывает, в пятницу, когда все уже радостно собирались домой, произошел аппаратный сбой массива. Из-за бага в прошивке при отказе диска массив превратил данные в кашу. От этого перестали работать базы данных сервиса федерального уровня. Более суток заказчик ждал решения от вендора СХД. После анализа всех логов вендор дал свое заключение: данные потеряны!
Заказчик принял решение о восстановлении из резервной копии. Этот процесс занял примерно сутки, несмотря на все ухищрения и тюнинг производительности (база довольно большая). Пока восстанавливалась БД, резервная копия логов была утеряна (был выставлен слишком маленький Retention Period, СРК удалила их сама).
Дальше - глубже. Компания, как и многие другие, в некоторые моменты использовала нелогируемые операции в Oracle, что серьезно повышает производительность, но не оставляет шансов восстановиться, кроме как из резервной копии. То есть делать ее надо сразу же после прохождения сессии операций. Естественно, об этом с годами в службе эксплуатации забыли. Таким образом, часть данных была полностью утеряна.
Еще несколько дней потребовалось на полное воссоздание инфраструктурных сервисов - не было резервных копий операционных систем, бинарников, конфигураций и т.п.
Всю потерянную информацию собирали из первичных документов (сторонние базы, бумажные документы, данные на компьютерах операционистов), что заняло еще 3 дня. Некоторые документы, возможно, так и не удалось восстановить.
Проблема с массивом вызвала потерю данных и простой около недели! В современных условиях это может привести к банкротству компании.
Вывод. Из вышеприведенных примеров видно, что системы резервного копирования были установлены и настроены, но несмотря на это восстановиться в сроки, указанные в SLA, им и близко не удалось.
Опираясь на свой опыт, мы решили выделить ряд проблем, на которые, по нашему мнению, читателям стоит обратить особое внимание.
На данный момент скорость backup прямо пропорциональна объему данных, при этом у всех наших заказчиков годовой рост данных не менее 30%. За 3–4 года данные как минимум удваиваются, но у некоторых компаний этот показатель даже выше, при этом за то же время скорость резервного копирования не меняется вовсе. Здесь можно сделать простой вывод, что те сроки и те SLA, которые были 3–4 года назад актуальны, сейчас нужно увеличивать как минимум вдвое. При этом требования бизнеса к восстановлению данных (RPO/RTO) постоянно растут.
Постепенно происходит перевод всех бизнес-процессов компании в ИТ и отмирание бумажной первички (копии и оригиналы документов, заявления, сканы и т.п.). Все крутится внутри ИТ-систем, и потеря данных - это, по сути, потеря всего. ИТ больше не имеет права на ошибку. В тех кейсах, которые мы привели, все то время, пока данные в силу разных обстоятельств были недоступны, компании не могли функционировать. Это приводило как к прямым потерям, когда невозможно осуществлять основной бизнес-процесс организации, так и к неявным, например, к репутационным, которые не так просто измерить в денежном эквиваленте, но которые в перспективе могут нанести не меньший ущерб компании.
На рисунке я отразил свои наблюдения, касающиеся времени восстановления (RTO). C ростом данных фактическое время восстановления непременно растет, при этом требования SLA только ужесточаются. Точка на графике, где фактическое время равно требуемому, для большинства заказчиков уже пройдена.
Зависимость времени восстановления от объема данных
Фактически большинство ошибок связано с потерей какой-то части данных. При этом традиционные средства резервного копирования позволяют восстанавливать данные напрямую из backup, но чаще приходится восстанавливать систему целиком. Если ваша база данных занимает 15 ТБ, вы потратите на это несколько суток. Заказчиков, у которых требование RTO (Recovery Time Objective) - 2 дня, мы не знаем. В нашей практике таких примеров не было, когда бы клиент сказал: «Ребята, восстанавливаться 2 дня - это нормально, я потерплю», - если администратор случайно удалил несколько строк из базы данных. Довольно частая проблема, с которой сталкиваются наши клиенты: как вычленить небольшой кусочек данных из резервной копии, не восстанавливая ее саму (и не тратить на это несколько суток).
В мире, где пропала бумажная первичка и все хранится в ИТ-системах, каждую секунду создаются данные, которые хотелось бы сразу защитить, - в тот же момент, когда они были созданы. Но с помощью классических систем резервного копирования это сделать невозможно. Для каждой порции данных есть определенный длительный период времени, в течение которого эти данные существуют во всем мире в единственном экземпляре. Наши заказчики хотят защищать данные непрерывно, с момента их появления. При принятии решения о восстановлении с резервной копии, скорее всего, придется восстановиться на сутки назад, дальше данные за сутки нужно будет еще откуда-то получить. Как правило, это долгая работа администраторов, занимающая несколько дней. При самом негативном развитии событий это может обернуться потерей важнейшей информации. Конечно, вопрос не ограничивается только резервным копированием, он касается построения ИТ-системы в целом, но тема СРК в данном случае очень важна, нельзя ей пренебрегать.
К сожалению, до сих пор нет вариантов дешево и быстро проверить, насколько качественно сделана резервная копия. Конечно, это можно сделать с помощью периодических тестовых восстановлений, но это очень дорогая операция с точки зрения усилий людей и ИТ-ресурсов. Эта работа отдельной команды на отдельном железе.
Увы, большинство наших клиентов этим не занимается. Часто складывается такая ситуация, что все делают резервные копии, но к моменту восстановления, оказывается, что их можно было не делать - они просто не восстанавливаются, несмотря на внешне правильную работу СРК. Это происходит по различным причинам. И лучше всего это можно продемонстрировать на примере. Один наш заказчик использовал систему SAP с базой данных Oracle. Резервное копирование осуществлялось встроенными средствами SAP с помощью одного из крупнейших вендоров СРК.
Были настроены 2 разные политики резервного копирования: одна из них файловая - копировала данные операционных систем и настройки ПО, а вторая - саму базу данных. Поскольку они были направлены на одну и ту же систему, был настроен список исключений, в который занесли базу данных. Файловая политика учитывала этот список и не резервировала те директории, в которых лежала БД. Из-за особенностей архитектуры СРК, политика резервирования БД игнорировала список исключений и корректно копировала нужные данные.
В одном из релизов ПО данный вендор исправил эту «ошибку», с этого дня обе политики стали учитывать список исключений и обходить базу данных стороной. Причем это никак не отразилось на ошибках в ПО СРК, так как она работала штатно: все данные, не указанные в списке, резервировались нормально. Система рапортовала о своей исправности.
Таким образом, все работало больше полугода. До того момента, пока не понадобилось восстановиться...
Немаловажная проблема – несистемный подход к проблеме резервного копирования. СРК исторически строилась силами либо самой компании, либо привлеченного со стороны интегратора. На момент построения она, безусловно, отвечала всем требованиям и выполняла свою функцию целиком и полностью. С течением времени ИТ-ландшафт компании изменялся. При этом система резервного копирования просто подстраивалась под него по мере развития системы, и чаще всего никакой системный подход, который бы учитывал важность соответствия системы изначальным показателям на всех последующих этапах, не соблюдался. Строя СРК у себя в организации, помните - это только часть вашей стратегии по защите данных.
Мы представили несколько кейсов, которые демонстрируют, что подход к защите данных должен быть комплексным. Увы, СРК - это всего лишь резервный парашют, а не серебряная пуля, поэтому приступая к ее созданию, нужно четко представлять, какое место она займет в рамках глобальной стратегии по защите данных.
Чтобы проверить, насколько системно вы подошли к вопросу построения СРК, ответьте на несколько простых вопросов:
Опираясь на собственный опыт и опыт наших заказчиков, мы постарались выработать подход, позволяющий решить или существенно уменьшить последствия перечисленных проблем. Суть нашего подхода:
Первое - необходимо отвязать скорость резервного копирования и восстановления от объема системы. Производители систем хранения данных, прикладного ПО и СРК предлагают использовать некоторый инструментарий, применимый для решения этой проблемы. Ниже я опишу самые перспективные из них.
Мгновенные снимки (snapshot), позволяющие производить резервное копирование и восстановление данных за секунды, практически не влияя на производительность. Это делается средствами массива, и при этом может управляться СРК, быть частью ее политики. Такой backup и восстановление реально занимают секунды, что выгодно отличает эту технологию от классических систем с отчуждаемыми носителями.
Другим решением может быть использование различных средств приложений, например, Oracle Standby, DB2 HADR, MS SQL Always On. Все эти средства позволяют иметь работающую копию продуктивной системы, отвязанную от исходной, которую можно развернуть мгновенно. Это позволяет начать работу сразу после сбоев.
Второе - дать возможность восстанавливать только нужные данные. Наш подход учитывает, что при восстановлении части данных нам не требуется копировать всю систему целиком, мы можем восстановить данные, которые нам нужны на данный момент. Это достигается возможностью быстро развернуть либо использовать уже развернутые системы, которые эти данные содержат. Так же как и в первом случае, snapshot позволяют решить эту проблему (можно быстро открыть snapshot на соседний сервер и вытянуть необходимый кусочек данных). Сюда же можно отнести технологии непрерывной защиты данных, например, Oracle Standby с Flashback, решения continuous data protection (CDP). Они позволяют быстро развернуть работающую копию данных на нужный момент времени.
Когда нужно достать один логический блок, например, строку или таблицу БД, эти средства серьезно облегчают задачу, позволяя восстановить необходимый кусочек данных, не восстанавливая всю копию целиком.
Третье - уменьшить промежуток между появлением данных и их защитой. Этого можно достигнуть несколькими методами, опираясь на специфику того или иного конкретного случая и степень важности данных.
Например, для менее критичных систем временной интервал для резервного копирования может быть уменьшен до нескольких часов. В этом случае мы используем мгновенные снимки. Они могут служить точкой восстановления, которую можно делать раз в час. Часть современных массивов достаточно хорошо справляется с этими процессами и может хранить достаточно большое количество снимков систем. Это прекрасный выход из ситуации, когда нужно откатиться на некоторое время назад.
Для наиболее критичных систем временного интервала может не быть совсем – данные нужно защищать непрерывно. Существует несколько решений этого класса, например, Oracle Standby с FlashBack, который позволяет откатить базу данных на некоторое время назад благодаря логированию всех изменений. Также можно использовать ПАК Oracle ZDLRA, который практически синхронно получает все изменения в БД, либо программно-аппаратные комплексы общего назначения, например, EMC RecoverPoint, ПО Vision Solutions Double-Take. Они тоже логируют все изменения и позволяют восстановиться на любую точку в интервале времени.
Если говорить об инновациях в системах резервного копирования и восстановления, нельзя не упомянуть Oracle Zero Data Loss Recovery Appliance (ZDLRA). Этот программно-аппаратный комплекс семейства Oracle Engineered Systems предоставляет возможность резервного копирования и быстрого восстановления Oracle Database любых платформ и любых Edition (Enterprise и Standard). В основе ZDLRA лежат виртуальные backup-базы (Virtual Full Backup), получаемые на основе первого полного backup и последующих журналов изменений. За счет этих виртуальных backup можно восстановить базу данных на любой момент времени значительно быстрее, чем при классическом использовании СРК по схеме «раз в неделю полный backup, раз в сутки инкрементальный». Можно сказать, что ZDLRA продолжает направление, заданное Oracle Exadata. В Exadata за счет специального Software реализована инновационная система хранения, оптимизированная под задачи Oracle Database. А в ZDLRA функционирует специальное Software, оптимизирующее резервное копирование именно Oracle Database.
Сейчас мы говорим только об оперативном восстановлении. В случае больших аварий или необходимости восстановиться на большее время назад обычные резервные копии остаются незаменимым инструментом. Но в нынешних условиях это только запасной парашют, раскрываемый в последний момент.
Четвертое - уменьшение скрытых ошибок. Существует только один способ убедиться в корректной работе резервной копии - попробовать ее восстановить. Это самый правильный и редко используемый нашими заказчиками метод.
Но мы предлагаем выход и из этой ситуации. Во-первых, иметь легко восстанавливаемые экземпляры систем. Это опять история о snapshot- и standby-системах, которые можно достаточно быстро развернуть и проверить. Времени и сил это займет несравнимо меньше, чем «разматывание» всей резервной копии. Конечно, это помогает далеко не всегда, но оставляет чуть больше надежды, что в случае ЧП будет можно восстановить данные хотя бы этими средствами.
Во-вторых, некоторые СРК позволяют выполнять автоматизированное тестирование. В определенное время по расписанию можно запускать виртуальные машины в изолированной среде и по заранее заданным алгоритмам проверять, действительно ли данные восстановились, доступно ли приложение, консистентно ли оно, отвечает ли на нужные запросы. Таким способом администраторов можно избавить от долгой рутинной работы.
Пятое - прозрачность системы резервного копирования. Описанный комплексный подход предполагает построение сложной системы с применением множества технологий от разных производителей. Задача сделать эту систему действительно работоспособной, заложить в нее возможность дальнейших изменений и масштабирования, нетривиальна, и решить ее можно двумя способами:
К сожалению, пока нет универсального рецепта, который позволил бы решить проблему восстановления данных в текущих условиях постоянного роста и усложнения систем. Только совокупность вышеописанных решений и системный подход позволят компаниям восстанавливать данные в сроки, которые требует бизнес.
Системы резервного копирования обеспечивают непрерывность бизнес-процессов и защиту информации от природных и техногенных катастроф, действий злоумышленников. Эти технологии активно используются в ИТ-инфраструктурах организаций самых разных отраслей и масштабов.
Резервное копирование данных - процесс создания копии данных на носителе, предназначенном для восстановления данных в оригинальном месте их расположения в случае их повреждения или разрушения. Кроме того, система резервного копирования - это один из необходимых методов обеспечения непрерывности бизнеса. Построение централизованной системы резервного копирования позволяет сократить совокупную стоимость владения ИТ-инфраструктурой благодаря оптимальному использованию устройств резервного копирования и сокращению расходов на администрирование (по сравнению с децентрализованной системой).
Устаревший подход под названием «РЕЗЕРВНОЕ КОПИРОВАНИЕ»
Современный подход под названием «УПРАВЛЕНИЕ ИНФОРМАЦИЕЙ»
Централизованная система резервного копирования имеет многоуровневую архитектуру, в которую входят:
Администратор системы ведет список компьютеров-клиентов резервного копирования, устройств записи и носителей хранения резервных данных, а также составляет расписание резервного копирования. Вся эта информация содержится в специальной базе, которая хранится на сервере управления резервным копированием.
В соответствии с расписанием или по команде оператора сервер управления дает команду программе-агенту, установленной на компьютере-клиенте, начать резервное копирование данных в соответствии с выбранной политикой. Программа-агент собирает и передает данные, подлежащие резервированию , на сервер копирования, указанный ей сервером управления.
Данный тип резервного копирования представляет собой дальнейшее развитие метода внесетевого копирования (LAN -free), поскольку уменьшает количество процессоров , памяти , устройств ввода-вывода, задействованных в этом процессе. Данный процесс архивирует разделы целиком, в отличие от пофайлового архивирования , но при этом позволяет восстанавливать отдельные файлы . По определению, при вне-серверном копировании данные копируются с диска на ленту и обратно без прямого участия сервера. Поскольку для резервного копирования требуется наличие некоторого дополнительного третьего узла, полностью отвечающего за процесс копирования, то отсюда происходит и другое название этого подхода - копирование с участием третьей стороны (Third_-Party Copy, 3PC). Так, в качестве подобного оборудования может использоваться маршрутизатор хранилищ данных, который берет на себя функции, ранее выполнявшиеся сервером.
Одно из преимуществ архитектуры SAN - отсутствие жесткой привязки составляющих ее систем к каким-либо устройствам хранения данных. Это свойство и заложено в основу технологии резервного копирования без участия сервера . В данном случае к дисковому массиву может иметь прямой доступ как сервер данных, так и устройства, принимающие участие в копировании с дисковых массивов. Резервному копированию блоков данных, относящихся к какому-либо файлу, предшествует создание некоего индекса или списка номеров принадлежащих ему блоков. Это и позволяет в дальнейшем привлечь внешние устройства для резервного копирования.
Таким образом, внесерверное копирование позволяет напрямую перемещать данные между подключенными к сети SAN дисковыми массивами и библиотеками. При этом данные перемещаются по сети SAN и не загружают ни локальную сеть, ни серверы . Такое копирование считается идеальным для корпоративных сетей, которые должны функционировать в непрерывном режиме 24 часа в сутки, 7 дней в неделю. Особенно для тех, для которых временной период, в течение которого можно выполнять резервное копирование без существенного влияния на работу пользователей и приложений, становится недопустимо малым.
Современные дисковые массивы обладают средствами создания копий данных внутри самого массива. Данные, созданные этими средствами, носят название Point-In-Time (PIT)-копий, т. е. фиксированных на определенный момент времени. Существует две разновидности средств создания PIT-копий: клонирование и «моментальный снимок» (snapshot). Под клонированием обычно понимают полное копирование данных. Для него требуется столько же дискового пространства, как и для исходных данных, и некоторое время. При использовании такой копии нет нагрузки на дисковые тома, содержащие исходные данные. Иными словами, нет дополнительной нагрузки на дисковую подсистему продуктивного сервера.
Механизм работы «моментальных снимков» иной и может быть реализован как программно на продуктивном сервере, так и аппаратно внутри массива. В момент, когда необходимо начать резервное копирование, программа-агент дает команду приложению завершить все транзакции и сохранить кэш-память на
Пресс-центр
Базовая задача, решаемая любым центром хранения и обработки данных, состоит в обеспечении соглашения об уровне обслуживания между ИТ-подразделением и бизнесом. Ключевой момент в обеспечении требований бизнеса - гарантия сохранности данных, поэтому неотъемлемым инфраструктурным блоком подсистемы хранения данных любого правильно организованного ЦОД является система резервного копирования и восстановления данных.
Ассоциация производителей и потребителей продуктов систем хранения SNIA (Storage Networking Industry Association) так определяет операции резервного копирования:
Все системы резервного копирования данных можно разделить на три типа согласно используемому методу копирования: это может быть пофайловое копирование, блочное или копирование данных на уровне приложений.
Система блочного резервного копирования (англ. image-level или block-level backup) работает напрямую с носителем, игнорируя файловую структуру, и сохраняя все содержимое полностью - операционную систему, рабочие данные, настройки и прочее. Преимуществом выполнения данного вида резервного копирования является высокая скорость. Однако обычно при выполнении операций копирования требуется приостановить работу приложений, чтобы копия была целостной (англ. consistent).
При выполнении операций резервного копирования на файловом уровне (англ. file-level или file-based backup) используется файловая система. В этом случае относительно простой задачей является восстановление некоторых конкретных файлов. В целом же, операции резервного копирования длятся дольше, возникает дополнительная загрузка операционной системы, а также появляется проблема доступа к открытым файлам.
Резервное копирование может производиться и на уровне приложений (англ. application-level backup). Операции копирования и восстановления производятся посредством использования специально предусмотренного в резервируемом приложении программного интерфейса API (англ. Application Programming Interface). Резервная копия представляет собой набор файлов и возможно других объектов, определяемых самим приложением, которые вместе являются отображением состояния приложения на некоторый момент времени. При данном способе резервного копирования может возникать проблема совместимости между разными версиями приложений и систем резервного копирования, реализующих соответствующий интерфейс.
Система резервного копирования является служебной подсистемой ЦОД и имеет следующие особенности:
При построении системы резервного копирования необходимо:
LAN backup
До появления сетей хранения данных (Storage Area Network - SAN) для сокращения трафика резервного копирования в основной сети применялась выделенная сеть резервного копирования, а также многоуровневая структура, включающая несколько серверов копирования. Выделение сервера копирования и расположение его в сети "ближе" к продуктивным серверам, обрабатывающим наибольшие объемы информации, позволяет локализовать трафик резервного копирования между сервером копирования и продуктивными серверами и сократить нагрузку на общую ЛВС.
LAN-free backup
С появлением SAN появилась возможность передавать трафик резервного копирования не через ЛВС, а непосредственно с серверов на устройства хранения данных (обычно это ленточные библиотеки), подключенные к SAN. Такой метод получил название "LAN-free backup". При использовании этого метода сервер-клиент одновременно с другими задачами выполняет функции сервера копирования резервируемых данных на доступные ему через SAN устройства хранения. При этом на сервер управления резервным копированием возлагается задача исполнения расписания резервного копирования путем выдачи через ЛВС (по протоколу TCP/IP) управляющих воздействий и контроля выполнения задач серверами копирования. Таким образом, решается задача уменьшения трафика данных резервного копирования в ЛВС.
Но метод "LAN-free backup" не решает проблему "окна" резервного копирования. Более того, данный метод создает дополнительную нагрузку на сервера-клиенты, возлагая на них дополнительные функции серверов копирования резервируемых данных. Некоторые приложения позволяют проводить резервное копирование без прекращения своей работы (online backup), это реализовано во многих транзакционных приложениях и с помощью специальных опций программного обеспечения резервного копирования, таких как средства копирования открытых файлов. Однако применение подобных технологий не снижает нагрузку на продуктивные сервера, которая при больших объемах данных (терабайты и более) может увеличить время решения основных задач выше допустимого порога.
Serverless backup
Идеальной была бы такая схема резервного копирования, когда данные сервера-клиента копируются через сеть хранения SAN на устройство хранения каким-либо сторонним устройством (получившим название "Data Mover"), не используя при этом вычислительные ресурсы сервера-клиента и не прерывая его работу. Подобный метод резервного копирования получил название "Serverless backup". Роль "Data Mover" может выполнять как выделенный для этой цели сервер, подключенный к тому же дисковому массиву, что и продуктивный сервер, так и специальное устройство - маршрутизатор.
CDP (Continious Data Protector)
Согласно определению SNIA, непрерывная защита данных (CDP) - это методика постоянного отслеживания изменений данных, и сохранение их в независимом от исходных данных хранилище, позволяющая восстановление на любой момент времени в прошлом. CDP системы могут быть реализованы на уровне блоков, файлов или приложений и обеспечивать мелкую гранулярность восстановления объектов на любой момент времени вплоть до одиночной операции записи. Согласно этому определению, все CDP решения имеют следующие свойства:
В этой статье рассмотрим методики резервного копирования данных для предприятий малого и среднего бизнеса.
Типичный вопрос, с которым обращаются заказчики: обеспечение сохранности базы данных системы "1С", размером около 1 Гбайт и базы клиентов в MS Access, около 300 Мбайт. Информация важна вся и терять более дня работы - не желательно. Бюджет, выделенный ИТ-подразделению, не превышает 100 000 рублей.
Необходимо понять требования заказчика - какой объём информации требуется резервировать, сколько времени требуется хранить резервные копии, требуется ли удалённое хранение (offline) резервных копий.
Если заказчику требуется хранить данные за ближайшие несколько дней и стоимость решения должна быть минимальной, то наиболее простым и удобным решением будет небольшое сетевое хранилище данных (NAS - Network Attached Storage). Эти устройства выпускаются различными производителями оборудования, имеют от 2 до 12 дисков и обеспечивают доступ по основным протоколам доступа: CIFS, NFS, HTTP, iSCSI. Структурная схема решения приведена на рисунке 1.
Рис.1 NAS хранение.
Стоимость этого решения составляет от 15 000 до 70 000 рублей в зависимости от объёмов хранения.
Основные недостатки этого решения - это невозможность масштабирования при росте объёмов хранения и необходимость контроля успешности проведения резервного копирования.
Для автоматизации процедур резервного копирования используют специальное программное обеспечение, которое контролирует процесс создания резервных копий и процедуру восстановления, а также позволяет работать с различными носителями данных, в том числе с ленточными устройствами.
Для создания резервных копий создаются политики резервного копирования, которые регламентируют "Что, Куда и Когда". Какие данные, куда и с какой периодичностью должны быть сохранены. Дополнительные возможности ПО централизованного резервного копирования позволяют восстанавливать отдельные письма и таблицы баз данных без необходимости восстановления всего объёма данных. Запись резервных копий на ленточные носители позволяет организовать удалённое хранение резервных копий и сохранность важных данных в случае катастрофы. Использование ленточных носителей для хранения архивных копий позволяет прочитать данные спустя 50 лет после их записи.
Стоимость такого решения начинается от 50 000 рублей и включает сервер для хранения резервных копий и ПО резервного копирования.
Резервное копирование эффективно только тогда, когда оно выполняется регулярно. Если данные часто меняются, копирование тоже должно быть частым. Поэтому многие предпочитают пользоваться специальным программным обеспечением для автоматизации этого процесса, а не копировать данные вручную.
Любой компьютер подвержен риску поломки аппаратного обеспечения и многим другим опасностям, которые могут повлечь потерю важных данных. В сфере бизнеса это имеет особенно тяжелые последствия, поскольку потеря бизнес-данных влечет огромные убытки и потерю клиентов.
Ключевым моментом в средствах резервного копирования является восстановление данных. Действительно, какая польза от резервной копии, если вы не можете ее восстановить? Поэтому, выбирая программу для резервного копирования , необходимо убедиться, что вы можете с ее помощью легко восстановить желаемые данные.
Handy Backup – надежная программа для резервного копирования и восстановления данных для компьютерах, работающих под Windows, известная своим простым и удобным интерфейсом и огромным количеством функций. Чтобы создать копию или восстановить данные, нужно просто создать новую "задачу" (с помощью пошагового Мастера создания задач). Handy Backup поможет вам создать резервные копии следующих данных:
Handy Backup может восстанавливать как резервную копию целиком, так и отдельные файлы и папки.
Программа может выполнять автоматический поиск и бэкап многих популярных приложений, включая Outlook, Skype, Adobe Photoshop и др.
Handy Backup может создавать точную копию HDD, включая операционную систему, загрузочные записи и другую информацию. Вы можете копировать и восстанавливать как полностью жесткий диск, так и отдельные его разделы.
Вы можете создать специальный загрузочный диск восстановления с помощью утилиты Handy Backup Disaster Recovery , с которого можно будет запустить операционную систему в случае сбоя, и восстановить систему, настройки и все данные.
В программе реализована возможность работы в различных версиях Windows, в том числе, можно выполнять резервное копирование и восстановление Windows 8 .
Программа может копировать ODBC совместимые базы данных, а также имеет специальные плагины для точного копирования баз DB2, Oracle, MS SQL, MySQL и др.
Приложение способно выполнять резервное копирование и восстановление данных MS Exchange Server, без остановки работы сервера. А также создавать автоматический бэкап почты с серверов Яндекс.Почты, Mail, Gmail, Yahoo Mail и др.
АЛЕКСЕЙ БЕРЕЖНОЙ, системный администратор. Главные направления деятельности: виртуализация и гетерогенные сети. Еще одно увлечение помимо написания статей – популяризация бесплатного ПО
Резервное копирование
Теория и практика. Краткое изложение
Чтобы организовать систему резервного копирования наиболее эффективно, нужно выстроить настоящую стратегию сохранения и восстановления информации
Резервное копирование (или, как его еще называют, бэкап – от английского слова «backup») является важным процессом в жизни любой ИТ-структуры. Это парашют для спасения в случае непредвиденной катастрофы. В то же время резервное копирование используется для создания своего рода исторического архива бизнес-деятельности компании на протяжении определенного периода ее жизни. Работать без бэкапа – все равно, что жить под открытым небом – погода может испортиться в любой момент, а спрятаться негде. Но как его правильно организовать, чтобы не потерять важных данных и не потратить на это фантастические суммы?
Обычно в статьях на тему организации резервного копирования рассматриваются в основном технические решения, и лишь изредка уделяется внимание теории и методике организации сохранения данных.
В данной статье речь пойдет как раз об обратном: основное внимание уделено общим понятиям, а технические средства будут затронуты только в качестве примеров. Это позволит абстрагироваться от аппаратного и программного обеспечения и ответить на два главных вопроса: «Зачем мы это делаем?», «Можем ли мы это делать быстрее, дешевле и надежнее?».
Цели и задачи резервного копирования
В процессе организации резервного копирования ставятся две основные задачи: восстановление инфраструктуры при сбоях (Disaster Recovery) и ведение архива данных в целях последующего обеспечения доступа к информации за прошлые периоды.
Классическим примером резервной копии для Disaster Recovery является образ системной партиции сервера, созданный программой Acronis True Image.
Примером архива может выступить ежемесячная выгрузка баз данных из «1С», записанная на кассеты с последующим хранением в специально отведенном месте.
Есть несколько факторов, по которым отличают резервную копию для быстрого восстановления от архива:
Иногда возможно совмещение этих задач. Например, годовой набор ежемесячных полных «снимков» файлового сервера, плюс изменения, сделанные в течении недели. В качестве инструмента для создания такой резервной копии подойдет 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-туннель.
Мы разобрали основные моменты при организации резервного копирования. В следующей части будут рассмотрены методические рекомендации и приведены практические примеры для создания эффективной системы резервного копирования.
Вконтакте
