ВсёПросто

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

Содержание

6 типичных ошибок при резервном копировании и восстановлении данных

19.10.2006 Поль Робишо

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

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

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

Неверный выбор метода архивирования

Два основных метода резервного копирования данных Exchange — оперативный и автономный.

В оперативном режиме программный интерфейс Microsoft (такой, как Extensible Storage Engine — ESE, специальные API или служба Microsoft Volume Shadow Copy Service — VSS), обеспечивает копирование избранных данных Exchange при работающих службах Exchange и смонтированной и активной целевой базе данных. Предоставляемые Exchange интерфейсы API архивируют и при необходимости сокращают журналы транзакций.

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

Поставщики некоторых решений утверждают, что данные Exchange копируются без использования Microsoft API и демонтирования баз данных. В статье «XADM: Hot Split Snapshot Backups of Exchange» (http://support.microsoft.

com/?kbid=311898) объясняется, что компания Microsoft относит такие резервные копии к категории автономных.

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

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

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

Сохранение непроверенных резервных копий

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

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

Агент пытался создать резервные копии файлов, но не смог, потому что файлы Exchange Information Store (IS) были открытыми. Даже беглый просмотр отчетов программы резервного копирования или журнала событий приложения показал бы неполадки в копировании данных Exchange.

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

Убедитесь, что данные можно восстановить на сервере и Exchange может извлечь информацию.

Если одна из трех проверок заканчивается неудачей, следует найти и устранить причину отказа.

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

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

Даже корректные резервные копии со временем могут оказаться непригодными после изменений среды, программ архивирования, конфигурации Windows или Exchange.

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

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

Неправильная обработка журналов транзакций

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

И наоборот, если журналы потеряны или испорчены, вероятность полного восстановления снижается.

В процессе восстановления Exchange предпринимает попытки последовательно воспроизвести файлы журналов, начиная с первого журнала, необходимого для базы данных (также называемого нижним якорем — low anchor log), и заканчивая последним доступным журналом (верхний якорь — high anchor log). Если отсутствует файл журнала в промежутке между нижним и верхним якорем, воспроизведение журналов прекращается. Процедура восстановления не может возобновиться до тех пор, пока отсутствующий файл журнала не будет восстановлен.

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

Нельзя удалять файлы журналов самостоятельно. В некоторых случаях может потребоваться скопировать файлы журналов в отдельный каталог для надежного хранения. В статье Microsoft «Offline Backup and Restoration Procedures for Exchange» (http://support.microsoft.

com/?kbid=296788) рекомендуется сохранять копии журналов транзакций в отдельном хранилище, прежде чем восстанавливать данные из автономной резервной копии.

При восстановлении с помощью NTBackup журналы не воспроизводятся, если не установлен флажок Last restore set (или аналогичный флажок в другой программе резервного копирования). Восстанавливаемую базу данных нельзя монтировать, если этот флажок не установлен или для ручного запуска обработки журнала не используется команда Eseutil /r.

Если журналы транзакций отсутствуют или хотя бы один файл журнала испорчен, стоит применить бесплатный анализатор Exchange Server Disaster Recovery Analyzer (ExDRA) компании Microsoft.

Этот инструмент анализирует демонтированную базу данных, сообщает об имеющихся и отсутствующих файлах журналов и возможных вариантах устранения обнаруженных проблем.

ExDRA — ценный инструмент при неожиданных сбоях процесса восстановления, но администратору по-прежнему необходимо знать тонкости процесса восстановления после аварии и консультироваться со специалистами службы Microsoft Customer Service and Support (CSS) или другими экспертами.

Недостаток времени для копирования

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

Типичная ошибка — недооценить время, необходимое для восстановления.

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

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

Почему для восстановления требуется вдвое больше времени, чем для копирования? Предположим, нам нужно получить копию базы данных емкостью 60 Гбайт с использованием системы резервного копирования со скоростью записи 12 Гбайт/ч. Пять часов — приемлемое время для резервного копирования.

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

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

Забытые мелочи

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

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

Создав резервную копию состояния сервера Exchange, нетрудно восстановить данные сервера и Exchange, и значительно ускорить возвращение к нормальной работе, не теряя времени на поиск компакт-дисков, серийных номеров продуктов и т.д. Если в среде Exchange имеются антивирусные программы, фильтры спама, центры сертификации (ЦС) X.

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

При резервном копировании состояния системы с помощью NTBackup собираются все системные данные локального компьютера, в том числе реестр, файлы Active Directory (AD) Directory Information Tree (DIT) на контроллере домена (DC), данные Windows Certificate Services, базы данных серверов DHCP и DNS и другие обязательные данные. Большинство утилит резервного копирования независимых поставщиков также располагают данной функцией, но можно обойтись и без этих инструментов; с помощью NTBackup можно составить расписание копирования состояния системы в файл на диске, а затем ввести этот файл в каждую резервную копию Exchange. Данный метод гарантирует своевременно обновляемую копию состояния системы. Не забывайте периодически обновлять диск автоматического восстановления системы (Automated System Recovery (ASR). С его помощью часто удается исправить поврежденные экземпляры Windows без полной переустановки операционной системы.

Пренебрежение практикой

Освоить процесс восстановления данных лучше всего до возникновения неполадок. Отрабатывать восстановление можно, даже если на предприятии имеется всего одна база данных и единственный сервер. Для этого нужно получить экземпляр Microsoft Virtual PC 2004 или VMware Workstation, построить испытательный сервер и практиковаться в восстановлении данных.

Работая с Exchange Server 2003, необходимо изучить группы RSG и способы их использования. Нужно узнать, как восстановить данные с исходного сервера на другом сервере с помощью программы резервного копирования. Установочные компакт-диски и серийные номера продуктов должны находиться в надежном месте (не в текстовом файле на сервере, который требуется восстановить).

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

Время, затраченное на тренировку, окупится, если произойдет сбой.

Тратим время, экономим деньги

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

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

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

Поль Робишо — Главный инженер компании 3sharp, имеет сертификаты MCSE и Exchange MVP. Автор нескольких книг, в том числе The Exchange Server Cookbook (Издательство O?Reilly and Associates). Поддерживает Web-сайт http://www.exchangefaq.org. С ним можно связаться по адресу troubleshooter@robichaux.net

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

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

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

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

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

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

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

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

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

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

Также проследите за тем, что во время записи не произошёл какой-нибудь сбой: если кто-то случайно заденет кабель и он отсоединится, то вы можете потерять данные.

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

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

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

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

Windows 7

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

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

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

Расписание

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

Windows 8.1

«Резервная копия образа системы»

Windows 10

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

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

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

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

Резервное копирование с iPad на компьютер

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

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

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

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

Рекомендации пользователю

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

Бортовой журнал

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

Как их делали раньше?

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

И тот, и другой способ имели свои плюсы и минусы.

“Ручные” копии

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

Преимущества “ручных” резервных копий:

Недостатки:

Автоматические копии

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

Преимущества автоматических резервных копий:

Недостатки:

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

Какое решение мы предлагали раньше?

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

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

Мы начали с того, что добавили функции:

Однако это решение еще не было оптимальным, потому что, например, копии нельзя было скачать.

А что сейчас?

Мы полностью переработали раздел “Резервные копии”. Теперь у каждого пользователя всегда есть подстраховка:

Как восстановить сайт из резервной копии, созданной по запросу?

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

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

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

Лучше всего его делать в разделе PHPMyAdmin в панели управления. Заранее локально распакуйте архив с базами данных и найдите в нем нужную вам базу для восстанавливаемого сайта (если у вас на аккаунте больше одного сайта).

Готово!

Если у вас что-то не получается, обязательно напишите в службу поддержки и мы поможем вам восстановить ваш сайт из резервной копии по запросу в любое время суток. Желаем вам приятной работы!

О резервном копировании данных

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

Тип бэкапа

Кто инициирует

Где хранятся резервные копии

Где настраивается

Для каких приложений реализовано

Системное резервное копирование

Автоматически, раз в сутки

На сервере администратора сервиса
 

Настраивается сотрудником администратора сервиса

Для всех

Настраиваемое резервное копирование (по расписанию)

По расписанию, определяемому пользователем

На сервере администратора сервиса

Настройка расписания и управление резервными копиями – в  Менеджере сервиса

«1С:Бухгалтерия 8», «1С:Управление небольшой фирмой», «1С:Отчетность предпринимателя»

Резервное копирование по требованию

Вручную пользователем

На сервере администратора сервиса

Из приложения в разделе Администрирование или из Менеджера сервиса.

Управление резервными копиями – в Менеджере сервиса

«1С:Бухгалтерия 8», «1С:Управление небольшой фирмой», «1С:Отчетность предпринимателя»

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

Вручную пользователем

На компьютере пользователя

Из приложения в разделе Администрирование

Для всех

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

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

Вид резервной копии Условия создания и хранения копий
Файлы, из которых была загружена область в начале ведения учета в сервисе (при переносе данных из локальной версии) Сохраняется в том случае, когда учет в сервисе ведется не «с нуля», а данные были перенесены из коробочной версии приложения..
Хранятся бессрочно.
Ежегодные копии Все копии. Хранятся бессрочно.
Ежемесячные копии Создаются, если за период (месяц) в базу входили интерактивно. По умолчанию хранятся 2 последние копии, т.е. при постоянной работе в базе – за последние два месяца.

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

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

Резервные копии, хранящиеся на сервере администратора сервиса в зашифрованном виде, надежно защищены от несанкционированного доступа.

Рассмотрим перечисленные выше типы резервного копирования подробнее.

Системное резервное копирование

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

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

Настраиваемое резервное копирование (по расписанию)

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

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

Настраиваемое резервное копирование дает пользователю сервиса следующие возможности:

Расписание резервного копирования настраивается пользователем в Менеджере сервиса, который открывается с сайта сервиса  по ссылке Личный кабинет на странице «Мои приложения».

Для настройки резервного копирования выполните в Менеджере сервиса следующее.

  1. Откройте из списка «Приложения» карточку приложения, для которого нужно настроить резервное копирование.
  2. В карточке приложения выберите действие Резервное копирование / Настройки резервного копирования.
  3. В открывшемся окне Настройка резервного копирования приложения установите параметры расписания, по которому будет проводиться резервное копирование в сервисе.
  4. Сохраните настройки по кнопке Записать и закрыть.

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

В этом случае так же, как и при настраиваемом по расписанию резервном копировании, созданные резервные копии хранятся на сервере администратора сервиса (в «облаке»). 

Резервное копирование по требованию дает пользователю следующие возможности:

Создание резервных копий по требованию

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

Рассмотрим оба варианта создания копий.

Чтобы создать резервную копию из приложения, запустите его и выполните следующее:

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

Для создания резервной копии по требованию из Менеджера сервиса, откройте его с сайта сервиса по ссылке Личный кабинет на странице «Мои приложения» и выполните следующее:

  1. Откройте из списка «Приложения» карточку приложения, для которого нужно создать резервную копию на текущий момент.
  2. В карточке приложения выберите действие Резервное копирование / Создать резервную копию.
  3. В открывшемся диалоговом окне нажмите кнопку ОК и затем дождитесь окончания процесса.

Управление резервными копиями

Управление резервными копиями (например, восстановление из них данных в новое приложение) осуществляется из Менеджера сервиса, который открывается с сайта сервиса по ссылке Личный кабинет на странице «Мои приложения».

Вы сможете управлять резервными копиями:

Управление резервными копиями происходит следующим образом:

  1. Откройте список резервных копий ваших приложений, выбрав в Менеджере сервиса действие Еще / Архивные копии приложений.
  1. В открывшемся окне Архивные копии приложений вы увидите список существующих резервных копий. Для каждой копии отражается  информация о типе ее создания.
  2. Выберите, при необходимости, нажатием соответствующей кнопки требуемое действие (из возможных):
  1. Например, если вы выбрали вариант Восстановить приложение, то определите наименование создаваемого приложения и часовой пояс, нажмите кнопку Далее и пройдите остальные шаги мастера восстановления данных. По завершении восстановления в списке приложений в Менеджере сервиса появится новое приложение в состоянии «Конвертируется». Восстановленное приложение будет готово к использованию, когда его состояние изменится на «Используется». Информационное сообщение об этом придет на электронный адрес пользователя. 

Выгрузка данных в формате XML

Помимо создания резервной копии «в облаке», т.е.

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

Для этого в приложении перейдите в раздел Администрирование и выберите команду Выгрузить данные в локальную версию.

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