Почти все наши заказчики, внедрившие себе системы резервного копирования (СРК), думают, что на этом все их проблемы решены. Они сделали все от них зависящее, чтобы все было зарезервировано, а в случае аварии корректно восстановлено. Но часто случается так: компания сталкивается с серьезной проблемой, и традиционная система резервного копирования не позволяет восстановиться за то время, которое в компании считается целевым. По факту 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 дня. Некоторые документы, возможно, так и не удалось восстановить.

Итого

Проблема с массивом вызвала потерю данных и простой около недели! В современных условиях это может привести к банкротству компании.

Основные проблемы:

• СРК была настроена неверно, пробные восстановления не проводили.
• Не было средств оперативного восстановления в случае аварии и дублирующих систем.
• Не было четкого DR-плана.

Как можно было этого избежать:

• Использовать Oracle Standby, расположенный на другом массиве. Это позволило бы в течение непродолжительного времени переключиться на работающий экземпляр данных.
• Oracle ZDLRA позволил бы в гораздо более сжатые сроки восстановить БД на резервном оборудовании.
• Грамотные планирование процессов резервного копирования и восстановление позволили бы избежать таких больших потерь и восстановиться менее чем за сутки.

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

Основные проблемы систем резервного копирования

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

Скорость резервного копирования и последующего восстановления

На данный момент скорость backup прямо пропорциональна объему данных, при этом у всех наших заказчиков годовой рост данных не менее 30%. За 3–4 года данные как минимум удваиваются, но у некоторых компаний этот показатель даже выше, при этом за то же время скорость резервного копирования не меняется вовсе. Здесь можно сделать простой вывод, что те сроки и те SLA, которые были 3–4 года назад актуальны, сейчас нужно увеличивать как минимум вдвое. При этом требования бизнеса к восстановлению данных (RPO/RTO) постоянно растут.

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

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

Зависимость времени восстановления от объема данных

Низкая гранулярность восстановления

Фактически большинство ошибок связано с потерей какой-то части данных. При этом традиционные средства резервного копирования позволяют восстанавливать данные напрямую из backup, но чаще приходится восстанавливать систему целиком. Если ваша база данных занимает 15 ТБ, вы потратите на это несколько суток. Заказчиков, у которых требование RTO (Recovery Time Objective) - 2 дня, мы не знаем. В нашей практике таких примеров не было, когда бы клиент сказал: «Ребята, восстанавливаться 2 дня - это нормально, я потерплю», - если администратор случайно удалил несколько строк из базы данных. Довольно частая проблема, с которой сталкиваются наши клиенты: как вычленить небольшой кусочек данных из резервной копии, не восстанавливая ее саму (и не тратить на это несколько суток).

Чрезмерное RPO (Recovery Point Objective)

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

Скрытые ошибки

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

Увы, большинство наших клиентов этим не занимается. Часто складывается такая ситуация, что все делают резервные копии, но к моменту восстановления, оказывается, что их можно было не делать - они просто не восстанавливаются, несмотря на внешне правильную работу СРК. Это происходит по различным причинам. И лучше всего это можно продемонстрировать на примере. Один наш заказчик использовал систему 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-системах, которые можно достаточно быстро развернуть и проверить. Времени и сил это займет несравнимо меньше, чем «разматывание» всей резервной копии. Конечно, это помогает далеко не всегда, но оставляет чуть больше надежды, что в случае ЧП будет можно восстановить данные хотя бы этими средствами.

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

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

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

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

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

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

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

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

Бэкап программа для Windows

Handy Backup – надежная программа для резервного копирования и восстановления данных для компьютерах, работающих под Windows, известная своим простым и удобным интерфейсом и огромным количеством функций. Чтобы создать копию или восстановить данные, нужно просто создать новую "задачу" (с помощью пошагового Мастера создания задач). Handy Backup поможет вам создать резервные копии следующих данных:

• Файлы и папки

Handy Backup может восстанавливать как резервную копию целиком, так и отдельные файлы и папки.

• Популярные утилиты и приложения

Программа может выполнять автоматический поиск и бэкап многих популярных приложений, включая Outlook, Skype, Adobe Photoshop и др.

• Образ диска

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

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

• Поддержка всех версий систем Windows

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

• Базы данных

Программа может копировать ODBC совместимые базы данных, а также имеет специальные плагины для точного копирования баз DB2, Oracle, MS SQL, MySQL и др.

• MS Exchange и данные почты

Приложение способно выполнять резервное копирование и восстановление данных MS Exchange Server, без остановки работы сервера. А также создавать автоматический бэкап почты с серверов Яндекс.Почты, Mail, Gmail, Yahoo Mail и др.

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

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

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

• Информация с компьютера
• Информация с планшетов и смартфонов
• Рекомендации пользователю

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

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

Информация с компьютера

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

Windows 7

• Переходим в панель управления компьютера с помощью кнопки Пуск или любых других средств навигации.
• Нажимаем на меню «Система и безопасность».
• Далее, перед вами откроется окно с вкладками, где нужно будет нажать на «Резервное копирование и восстановление данных».
• Итак, в новом окне вы увидите меню с настройками архивации. Нажмите на пункт «Архивация и восстановление».
• Далее, нам понадобится настроить резервное копирование с помощью одноимённой синей кнопки.

Нажимаем на «Настроить резервное копирование»

• Затем перед вами появится диалоговое окно с настройками архивации. Выберите свой жёсткий диск и жмите на кнопку «Далее».

Выбираем расположение архива

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

Выбор объектов для архивации самостоятельно

• Далее, мы проверяем установленные параметры. Здесь вы можете установить расписание для автоматического создания копии с помощью кнопки «Изменить расписание».

• Когда всё будет установлено и проверено, нажмите «Сохранить параметры и запустить архивацию».

Процесс выполняется

• Дождитесь окончания процесса, затем проверьте ваш внешний жёсткий диск: записались ли на него ваши данные.

Windows 8.1

• Запустите панель инструментов в правой части экрана. Для этого отведите мышь в правый верхний угол затем нажмите на «Поиск».
• Наберите с клавиатуры словосочетание «История файлов» без кавычек и нажмите Enter. В полученных результатах нажмите на одноимённую папку.
• Вы попадёте в окно, где нужно будет нажать на ссылку «Резервная копия образа системы», которая расположена в левом нижнем углу окна.

• Выбираем место хранения архива (как мы договорились выше, это должен быть внешний жёсткий диск). Жмите «Далее».
• Следующее окно покажет вам объём памяти, который потребуется. Проверьте все данные и нажмите кнопку «Архивировать».
• Подождите, пока система создаст резервную копию Windows на внешнем носителе информации. Этот процесс может занять некоторое время, поэтому не спешите паниковать.

Windows 10

• Запустите «Параметры» с помощью кнопки Пуск на панели задач.
• Теперь откройте вкладку «Обновление и безопасность».
• В левом столбике с параметрами нажмите на пункт «Служба архивации».
• С помощью одноимённой кнопки настройте систему автоматического резервного копирования.
• Обратите внимание, что вы там же без проблем можете легко регулировать папки, копии которых будут создаваться. Это намного облегчит вашу работу.
• Если же вы хотите создать полную резервную копию вместе с операционной системой, а не отдельные библиотеки и директории, то воспользуйтесь инструкцией для Windows.

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

Информация с планшетов и смартфонов

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

• Подключите своё устройство к компьютеру или ноутбуку. Дождитесь установки соответствующих драйверов.
• Запустите программу, которая предназначена для синхронизации с вашим девайсом. То есть, если у вас Айфон, то откройте приложение iTunes на своём ПК.
• Найдите вкладку или пункт «Синхронизация», или «Резервное копирование». Кликните по ней и, следуя подсказкам на экране, создайте копию.

• Для восстановления данных в этом же окне найдите одноимённую кнопку и нажмите на неё.
• Во время выполнения компьютером этих действий ни в коем случае не отсоединяйте устройство от USB. Это может кончиться программной поломкой девайса.
• Обратите внимание, что вы можете просто перенести некоторые файлы со смартфона или планшета на ПК. Особенно это актуально для владельцев гаджетов под управлением операционной системы Android: здесь имеется полный доступ ко всем файлам и папкам.
• Владельцы iOS-девайсов могут хранить только фотографии и видео аналогичным образом: зайдите в «Компьютер» и кликните правой кнопкой мыши по вашему устройству. Нажмите на «Импорт фотографий и видео». Следуя подсказкам на экране, вы можете не только сделать импорт, но и настроить его.

Облачные хранилища

Сегодня этот типа хранения данных достаточно популярен на рынке: не нужны никакие флешки, кабели и другие средства периферии. Нужно лишь активное скоростное подключение к интернету, и все ваши файлы у вас в руках. Их настройку рассматривать мы не будем (для этого есть отдельная тема), а просто скажем о каждом хранилище для определённой ОС:

• OneDrive для Windows
• iCloud и iCloud Drive для iOS и MacOS
• Google диск для Android

Стоит отметить, что есть ещё универсальные, которые ставятся на любое устройство, вне зависимости от установленной ОС:

• Облако Mail
• OneDrive
• Google диск

Как вы заметили, из всех хранилищ, только компания Apple сделала свой продукт доступным лишь для своей системы. Плохо это или хорошо - решать вам.

• При использовании внешнего жёсткого диска или флешки, позаботьтесь о том, чтобы она обладала достаточным объёмом свободного пространства.
• Обратите внимание, что большинство облачных хранилищ имеют ограниченную память для бесплатного доступа. Например, в iCloud Drive вам доступно будет пять гигабайт. Чтобы расширить её вам нужно будет покупать подписку. Если у вас не так много файлов, то покупать ничего не нужно. Можете также пользоваться несколькими облачными хранилищами.
• Проверяйте создание копий: если память на диске или в облаке закончилась, то копия не создастся. Вы рискуете потерять некоторые данные, что будет очень печальным последствием.
• Если вы просто копируете некоторые файлы, то желательно удалить их с копируемого девайса для освобождения памяти на нём.
• Если вы хотите сохранить очень важные документы, то лучше сделать две копии. Например, можете одну сделать на внешнем жёстком диске, а другую с помощью программы облачного хранилища.

Подведём итоги

Дорогие друзья, сегодня мы с вами обсудили очень обширную и важную тему: резервное копирование и восстановление данных. Особый акцент был сделан на компьютерной информации, затем мы рассмотрели общий принцип создания копии смартфонов и планшетов, а также познакомились с облачными хранилищами. В конце мы дали несколько рекомендаций, чтобы ваша работа была максимально продуктивной. Запомните: вовремя сохранённые данные являются залогом сохранения ваших нервов. Если вы потеряете файлы своей дипломной работы, которую вы делали несколько недель или месяцев, то будет не очень весело, не так ли? Расскажите в комментариях, какими службами архивации вы больше всего предпочитаете пользоваться и почему.

Аналитическая компания Gartner в очередной раз провела исследование рынка решений резервного копирования данных для предприятий. Специалисты проанализировали условия развития направления резервного копирования, актуальные продукты, техники и решения для сохранения и восстановления данных физических и виртуальных серверов, приложений и т.д. Основные представители рынка были оценены по многим критериям. Лидерство в индустрии аналитики Gartner отдали таким компаниям: Commvault, Symantec, EMC и IBM. В качестве нишевых игроков на рынке были выделены Dell, Acronis, Asigra, FalconStor и другие.

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

РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ ОТ КОМПАНИИ SYMANTEC

Symantec в последнее время продолжает расширять внедрение интегрированных средств резервного копирования; появилось большее разнообразие функций (например, NetBackup Accelerator для быстрого резервного копирования и Instant Recovery для виртуальных машин VMware).

Сильные стороны Symantec:

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

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

РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ ОТ КОМПАНИИ ACRONIS

Предоставляет решения для малого и среднего бизнеса или отдельных подразделений предприятия. Предоставляется несколько вариантов услуг резервного копирования и удаленного хранения данных, основанных на облачных технологиях. Копии могут быть записаны в 5 разных хранилищах, включая Acronis Cloud или через FTP/SFTP в частное облако. Специальные технологии дают возможность полного или выборочного восстановления данных с поддержкой Exchange, Microsoft SQL Server и SharePoint, а также других сервисов Microsoft, VSS-совместимых программ и баз данных. Для ускорения процессов резервного копирования, дедупликация и сжатие на стороне источника комбинируются с постобработкой (индексирование, каталогизация) на стороне конечного объекта.

Сильные стороны Acronis: гибкая модель лицензирования, удобный интерфейс, поддержка любых типов миграции (V2V, V2P, P2V и P2P), поддержка 6 разных типов гипервизоров вне зависимости от приобретенной версии и т.д.

Специалисты предостерегают: Acronis может оказаться не очень подходящим для крупных компаний, а поддержка сетевых хранилищ данных (NAS) ограничена протоколами CIFS/NFS.

РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ ОТ КОМПАНИИ VEEAM

Veeam давно признанный пользователями лидер в сфере резервного копирования виртуальных машин. В данной области выигрывает у многих конкурентов, благодаря предоставлению особых функций (например, Veeam Explorer и Snapshot Hunter), простоте и надежности использования. В последнем релизе были добавлены такие важные для предприятий функции как: комплексное шифрование, усовершенствованный контроль резервного копирования, поддержка EMC Data Domain Boost, NetApp Snapshot, SnapMirror, SnapVault и другие.

Сильные стороны:

• Veeam Backup & Replication – надежное и многофункциональное решение для защиты данных виртуальных сред;
• Veeam предлагают одни из самых простых в использовании и недорогих продуктов для резервного копирования на уровне предприятий;
• Имеет множество положительных отзывов пользователей по опыту использования разных функций.

Специалисты предостерегают:

• поддерживает только VMware и Hyper-V, следовательно, резервное копирование для других гипервизоров или физических серверов не предлагается;
• Собственная дедупликация Veeam имеет довольно низкий коэффициент, требуя больше места для хранения резервных копий;
• Поскольку Veeam предлагают функцию U-AIR, то отдельно поддержка восстановления для таких решений, как Domino, MySQL и Oracle, пока не предоставляется.

РЕШЕНИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ ОТ КОМПАНИИ COMMVAULT

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

Сильные стороны Commvault:

• единая административная консоль и механизм отчетов/аналитики для всех резервных копий (дата-центр, удаленный офис, приложения SaaS или ПК), архивирования, синхронизации и передачи файлов, поиска и функций предупреждения потери данных;
• целевые пакеты решений, многоплановая система лицензий Simpana и другие.

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

Специалисты предостерегают: цена приобретения и дальнейшей поддержки может быть довольно высокой.

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

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

Копирование баз данных

Используемые базы данных делятся на две категории: 3 системные БД (oktell, oktell_cc_temp и oktell_settings) и БД для модулей веб-клиента Okapp. Для запуска Oktell после восстановления нужны только системные базы. Остальные БД нужны только, если вы хотите сохранить ваши настройки веб-модуля.

Например, база WO_Module_journal используется модулем Журнал хранит в себе теги записей разговоров. База WO_Module_dashboards нужна для работы модуля Дашборды Okboard и содержит настройки используемых индикаторов.

Шаг 1. Копии системных таблиц создаются автоматически каждый день, по умолчанию в 02:00 по серверному времени, если не отключен параметр DBAutoDailyBackup . Создание копий происходит особым образом, оставляя копии

• последние две недели - каждый день
• далее три месяца - раз в неделю
• далее два года - каждый месяц
• далее раз в год

Все копии находятся в папке \oktell\server\Backup, если не переопределено в параметре DBBackupDir .

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

После окончания резервного копирования созданные бэкапы будут доступны в корне папки oktell\server\backup .

Шаг 2. Для созданий копий остальных баз данных откройте SQL Server Management Studio. Кликните правой кнопкой на нужной БД и в контекстном меню выберите Задачи, затем Создать резервную копию . В открывшемся окне вы можете поменять путь для создания бэкапа, для начала копирования нажмите ОК. Копии по умолчанию создается в папке C:\Program Files\Microsoft SQL Server\MSSQL11.OKTELL\MSSQL\Backup\ .

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

Восстановить базы данных можно только на такую же версию SQL-сервера или выше. Если базы были созданы на версии SQL Server 2008 R2, их нельзя восстановить на SQL Server 2008.

Шаг 1. Остановите службу oktellserver. Запустите командную строку с правами администратора и введите туда следующую строчку:

Net stop oktellserver

Шаг 2. Запустите SQL Server Management Studio с учетной записью sa:

• Login: sa
• Password: 123Oktell321

Шаг 3. Если у вас есть ранее установленные базы данных Oktell, то их нужно удалить. Это касается системных БД и БД, используемых веб-модулями.

Шаг 4. Приступаем к процедуре восстановления. Нажмите правой кнопкой на System Database (Системные базы данных) и нажмите Restore Database (Восстановить резервную копию).

Выберите файл с копией баз данных. Для этого выберите пункт Device (Устройство), в открывшемся окне Add (Добавить) и выберите ваш файл с резервной копией, например db_ok_130628.bak (в данном случае, это БД oktell).

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

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

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

Шаг 6. Если вы перенесли базу данных на сторонний сервер, то проверьте настройки в серверном конфигурационном файле \oktell\server\oktell.ServerService.exe.config . Убедитесь что в строке с ключом DBConnectionString ссылка на базу данных, логин и пароль указаны верно. По умолчанию, строка подключения выглядит следующим образом:

Server=(local)\OKTELL;database=oktell;uid=AutelService;pwd=;pooling=true

Новое название сервера нужно указать вместо значения (local)\OKTELL . Например, SQL-сервер перенесен на сервер WORK с IP-адресом 192.168.0.3. Следовательно, в параметре вам нужно указать WORK\OKTELL . Если сервер не запускается с этой настройкой, попробуйте указать только название сервера без инстанса - WORK . Вместо названия сервера можно указать IP-адрес - 192.168.0.3/OKTELL или только 192.168.0.3 .

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

Узнать название вашего сервера (инстанс) вы всегда можете с помощью команды

Sqlcmd.exe -L

в командной строке Windows.

Шаг 7. Запустите службу oktellserver . Для этого в командной строке выполните