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


Содержание

Резервное копирование и восстановление MS SQL Server

Приветствую, в данной заметке будет рассмотрено создание резервных копий и восстановление в MS SQL Server

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

1 Резервное копирование системных баз данных.

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

3 Разностное резервное копирование базы данных.

4 Резервное копирование журнала транзакций базы данных.

5 Резервное копирование файловых групп базы данных.

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

6 Восстановление из полной резервной копии.

7 Восстановление из разностной резервной копии.

8 Восстановление журнала транзакций.

9 Восстановление файловых групп.

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

Создадим нашу тестовую базу данных “sbase”, модель восстановления — полная:

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

1Резервное копирование системных баз данных.

Список системных баз: master, model, msdb, tempdb.

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

Model: Используется в качестве шаблона для создаваемых баз данных. Резервное копирование необходимо при изменении настройки самой базы model.

Msdb: Содержит сведения о заданиях и для агента сервера MS SQL Server. копирование необходимо делать каждый раз при добавлении задания для агента сервера MS SQL Server.

Tempdb: Хранит временные данные например для транзакций. Уничтожается и создается при перезапуске экземпляра MS SQL Server. Резервное копирование делать нет смысла.

Создадим новый запрос:

Выполним следующий запрос:

BACKUP DATABASE master

TO DISK = ‘C:\sql\master.bak’

BACKUP DATABASE model

TO DISK = ‘C:\sql\model.bak’

BACKUP DATABASE msdb

TO DISK = ‘C:\sql\msdb.bak’

Как видим, на диск ‘C’ было произведено успешное резервное копирование системных баз данных.

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

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

Включает в себя:

Резервное копирование данных в базе.

Резервное копирование изменений, возникающих во время резервного копирования

Резервное копирование транзакций, не зафиксированных в журнале транзакций.

Способ 1(Графический интерфейс):

Выберем «создать резервную копию»

Указываем куда копировать и модель – полная.

Способ 2(Запрос SQL):

BACKUP DATABASE sbase

TO DISK = ‘C:\sql\sbase.bak’

3 Разностное резервное копирование базы данных.

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

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

При создании разностного резервного копирования выполняются следующие действия:

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

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

—Создадим таблицу test

CREATE TABLE test(

INSERT INTO test (id,name)

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

Проведем полный бэкап, добавим еще данных, проведем разностный бэкап:

—Делаем полный бэкап

BACKUP DATABASE sbase

TO DISK = ‘C:\sql\sbase_razh2’

—Добавим еще данные

INSERT INTO test (id,name)

BACKUP DATABASE sbase

TO DISK = ‘C:\sql\sbase_razh3’

А вот и результат:

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

4 Резервное копирование журнала транзакций базы данных.

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

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

В процессе выполняются следующие действия:

Создается копия журнала транзакций от последнего резервного копирования лога до конца текущего.

Очищаются части журнала транзакций до начала активной части и отбрасываются сведения в неактивной части.

По аналогии с полным и разностным копированием запускаем задачу, но тип выбираем – лог транзакций:

Или с помощью запроса:

BACKUP LOG sbase

TO DISK = ‘C:\sql\sbase_tran.bak’

5 Резервное копирование файловых групп базы данных.

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

Файлы журналов не входят в состав файловых групп.

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

Пример полного копирования:

По аналогии с другими видами копирования запускаем мастер:

Тоже, только запросом:

BACKUP DATABASE sbase

TO DISK = ‘C:\sql\primary.bak’

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

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

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

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

Режим WITH RECOVERY включает и стадию повтора, и стадию отката и восстанавливает базу данных. Более поздние резервные копии восстановить невозможно. Это значение по умолчанию.Если набор данных наката не был восстановлен в достаточной степени, чтобы обеспечить согласованность с базой данных, стадия отката выполнена быть не может. Компонент Database Engine выдает ошибку и прекращает восстановление. Если весь набор данных наката согласован с базой данных, то выполняется восстановление, после чего базу данных можно перевести в режим в сети.

Предложение WITH NORECOVERY позволяет пропустить стадию отката, чтобы сохранить незафиксированные транзакции. Пропуск стадии отката позволяет восстановить другие резервные копии, чтобы выполнить накат базы данных на более поздний момент времени. Иногда инструкция RESTORE WITH NORECOVERY выполняет накат данных до момента, пока они не будут согласованы с базой данных. В таких случаях компонент Database Engine выдает информационное сообщение, указывающее, что набор данных наката теперь можно восстановить при помощи параметра RECOVERY. Другими словами, параметр NORECOVERY нужно использовать, когда для восстановления базы используются несколько восстанавливаемых резервных копий, за исключением последней восстанавливаемой резервной копии. После применения параметра NORECOVERY, база данных переходит в состояние восстановления.

6 Восстановление из полной резервной копии.

Или с помощью запроса:

RESTORE DATABASE sbase

7 Восстановление из разностной резервной копии.

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

Графический интерфейс аналогичен с предыдущим примером за исключением типа выбираемой копии, а запрос будет таков на примере наших разностных копий:

RESTORE DATABASE sbase

FROM DISK = ‘C:\sql\sbase_razh2’

WITH FILE = 1, NORECOVERY, REPLACE

RESTORE DATABASE sbase

FROM DISK = ‘C:\sql\sbase_razh3’

WITH FILE = 1, RECOVERY

8 Восстановление журнала транзакций.

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

Графический вариант интуитивно понятен, будет продемонстрирован только SQL запрос:

Для того, чтоб все отработало корректно, вернемся разностному бэкапу 2, и после него накатим журнал транзакций:

RESTORE DATABASE sbase

FROM DISK = ‘C:\sql\sbase’

WITH FILE = 1, NORECOVERY, REPLACE

RESTORE DATABASE sbase

FROM DISK = ‘C:\sql\sbase_razh2’

WITH FILE = 1, NORECOVERY, REPLACE

RESTORE LOG sbase

FROM DISK = ‘C:\sql\tran.bak’

WITH FILE = 1, NORECOVERY

9 Восстановление файловых групп.

Графический вариант показан не будет, он довольно интуитивен, запрос SQL:


RESTORE DATABASE sbase FILEGROUP = ‘PRIMARY’

FROM DISK = ‘C:\sql\primary.bak’

WITH PARTIAL, RECOVERY, REPLACE

Так как мы восстанавливали только часть базы – файловую группу, то мы использовали параметр «PARTIAL».

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

Если экземпляр SQL сервера доступен, то системные базы восстанавливаются согласно приведенной таблице:

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

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

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

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

Запускаем экземпляр сервера в однопользовательском режиме: выключим и включим экземпляр сервера с параметром запуска /m, введя в командной строке Windows (CMD):

net stop MSSQLSERVER

net start MSSQLSERVER /m

Подключимся к серверу и запустим процесс восстановления базы.

sqlcmd

RESTORE DATABASE master FROM DISK = ‘C:\sql\sbase.bak’ WITH REPLACE;

GO

Вернем экземпляр SQL в состояние «в сети».

Стартуем сервер в многопользовательском режиме:

net start MSSQLSERVER

На этом – все, желаю удач.

Если Вы хотите обменяться ссылками со мной между сайтами — пишите в контактах

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

Резервное копирование данных позволяет переносить Сервер администрирования с одного устройства на другое без потерь информации. С помощью резервного копирования вы можете восстанавливать данные при переносе информационной базы Сервера администрирования на другое устройство или при переходе на более позднюю версию Kaspersky Security Center.

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

  • Создать и запустить задачу резервного копирования данных через Консоль администрирования.
  • Запустить утилиту klbackup на устройстве, где установлен Сервер администрирования. Утилита входит в состав комплекта поставки Kaspersky Security Center. После установки Сервера администрирования утилита находится в корне папки назначения, указанной при установке программы.

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

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

Восстановление данных Сервера администрирования возможно только с помощью утилиты klbackup.

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

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

Восстановление базы данных из резервной копии в MS SQL Server 2012

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

0. Оглавление

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

Подключаемся к MS SQL Server c помощью программы «SQL Server Management Studio». В Microsoft Windows Server 2012 R2 ее можно найти в списке всех программ.

В Microsoft Windows Server 2008 R2 в меню «Пуск» (Start) — «Microsoft SQL Server 2012» — «Среда SQL Server Management Studio».

Вводим адрес сервера или его псевдоним, данные для авторизации и нажимаем «Соединить» (Connect).

Слева, в обозревателе объектов (Object Explorer), раскрываем вкладку «Базы данных» (Server Oblects), находим в списке базу данных из которой (или в которую) необходимо восстановить данные, кликаем по ней правой кнопкой мыши, затем в появившемся контекстном меню выбираем «Задачи» (Tasks) — «Восстановить» (Restore) — «База данных…» (Database…)

Запустится мастер восстановления базы данных (Restore Database). Выбираем базу источник (Source for restore), при этом мастер попробует автоматически подобрать последовательность файлов резервных копий для восстановления базы на текущий момент времени.

Если же требуется загрузить данные из конкретного файла или устройства резервного копирования, то необходимо установить соответствующий переключатель в положение «Устройство» (From device) и вручную указать источник для восстановления.

Затем необходимо выбрать базу данных назначения (Destination for restore), т. е. ту информационную базу в которую будут загружаться данные. Эта может быть как база с которой делалась резервная копия, так и любая другая база данных, зарегистрированная на текущем экземпляре SQL Server.

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

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

На вкладке «Параметры» (Options) можно указать дополнительные параметры резервного копирования. В частности:

  • Флаг «Перезаписать существующую базу данных (WITH REPLACE)» (Overwrite the existing database) указывает, что операция восстановления перезапишет файлы любой базы данных, в настоящее время использующей имя, указанное в качестве базы данных назначения.
  • Флаг «Сохранить параметры репликации (WITH KEEP_REPLICATION)» (Preserve the replication settings) сохраняет настройки репликации при восстановлении опубликованной базы данных на сервере, отличном от сервера, на котором была создана база данных. Этот параметр имеет значение, только если во время создания резервной копии проводилась репликация базы данных.
  • Флаг «Ограничение доступа к восстановленной базе данных (WITH RESTRICTED_USER)» (Restrict access to the restored database) ограничит доступ к базе данных, за исключением пользователей с правами db_owner, dbcreator или sysadmin. Данный параметр имеет смысл использовать, например, если необходимо последовательно восстановить базу из нескольких файлов резервных копий, и доступ пользователей необходимо ограничить до завершения всех операций по восстановлению данных.
  • Если оставить флаг «Создание резервной копии заключительного фрагмента журнала перед восстановлением» (Take tail-log backup before restore) то будет создана резервная копия заключительного фрагмента журнала транзакций. Если для точки во времени, выбранной в окне «Временная шкала резервного копирования» (Backup Timeline) требуется резервная копия заключительного фрагмента журнала, этот флажок будет установлен и снять его будет нельзя.
  • Флаг «Закрыть существующие соединения» (Close existing connections option) переводит базу данных в однопользовательский режим перед началом выполнения процедуры восстановления, а затем возвращает в многопользовательский режим после ее завершения.
  • Ну и наконец, флаг «Выдавать приглашение перед восстановлением каждой резервной копии» ( Prompt before restoring each backup ) указывает, что после восстановления каждой резервной копии будет выводиться диалоговое окно с вопросом, нужно ли продолжать последовательность восстановления. Этот параметр позволяет приостанавливать последовательность восстановления после восстановления каждой резервной копии. Он будет полезен, например, когда нужно поменять ленты в устройстве, если на сервере имеется только одно ленточное устройство.
Илон Маск рекомендует:  Блок с указателем

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

2. Просмотр информации о событиях резервного копирования и восстановления для базы данных

Для того чтобы узнать, когда производилось создание резервных копий конкретной базы данных, а также восстановление базы данных из резервной копии, можно воспользоваться стандартным отчетом «События резервного копирования и восстановления» (Backup and Restore Events). Для формирования данного отчета необходимо в Обозревателе объектов (Server Oblects) кликнуть правой кнопкой мыши по соответствующей базе данных, в контекстном меню выбрать «Отчеты» (Reports) — «Стандартный отчет» (Standart Reports) — «События резервного копирования и восстановления» (Backup and Restore Events).

Сформировавшийся отчет содержит в себе следующие данные:

  • Среднее время, затрачиваемое на операции резервного копирования (Average Time Taken For Backup Operations)
  • Успешные операции резервного копирования (Saccessful Backup Operations)
  • Ошибки операции резервного копирования (Backup Operation Errors)
  • Успешные операции восстановления (Saccessful Restore Operations)

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

Смотрите также:

Ниже приведена пошаговая инструкция, показывающая как добавить новую базу данных в Microsoft SQLServer 2012 (в более старых редакциях, например в Microsoft SQL Server 2008 R2, набор действий аналогичен). Запускаем…

Системная база данных tempdb служит рабочим пространством для хранения временных объектов, таких как временные таблицы, промежуточные результаты вычислений, временные хранимые процедуры, результаты буферов и сортировки, внутренние объекты, создаваемые компонентой Database…

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

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

Резервное копирование (англ.backup copy) — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения.

Резервное копирование данных (резервное дублирование данных) — процесс создания копии данных.

Восстановление данных — процесс восстановления в оригинальном месте.

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

Кроме этого решаются смежные проблемы: Передача данных и работа с общими документами

Требования к системе резервного копирования:

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

— простота в эксплуатации — автоматизация (по возможности минимизировать участие человека: как пользователя, так и администратора).

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

Ключевыми параметрами резервного копирования являются:

— RPO — Recovery Point Objective и

— RTO — Recovery Time Objective.

RPO определяет точку отката — момент времени в прошлом, на который будут восстановлены данные, а RTO определяет время, необходимое для восстановления из резервной копии.

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

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

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

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

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

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

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

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

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

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

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

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

Хранение резервной копии:

— Лента стримера — запись резервных данных на магнитную ленту стримера;

— «Облачный» бэкап» — запись резервных данных по «облачной» технологии через онлайн-службы специальных провайдеров;

— DVD или CD — запись резервных данных на компактные диски;

— HDD — запись резервных данных на жёсткий диск компьютера;

— LAN — запись резервных данных на любую машину внутри локальной сети;

— FTP — запись резервных данных на FTP-серверы;

— USB — запись резервных данных на любое USB-совместимое устройство (такое, как флэш-карта или внешний жёсткий диск);

— ZIP, JAZ, MO — резервное копирование на дискеты ZIP, JAZ, MO.

Вопросы для самоконтроля:

1. Что такое резервное копирование?

2. Назовите вид резервного копирования.

3. Назовите способы хранения резервной копии?

4. Что такое восстановление данных?

Единая система программной документации. Общие положения. Основополагающие стандарты

Дата добавления: 2020-10-15 ; просмотров: 613 | Нарушение авторских прав

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

  • Главная
  • Резервное копирование баз данных Microsoft SQL Server

Резервное копирование баз данных Microsoft SQL Server

  • Автор: Уваров А.С.
  • 15.02.2015

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

Модели восстановления


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

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

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

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

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

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

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

Виды резервных копий

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

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

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

Резервная копия журнала транзакций — применяется только при полной модели восстановления и содержит копию журнала транзакций начиная с момента создания предыдущей копии.

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

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

Журнал транзакций

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

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

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

Та часть журнала, которая содержит активные транзакции и используется для восстановления данных называется активной частью журнала. Она начинается с номера, который называется минимальным номером восстановления (MinLSN).

В простейшем случае MinLSN — это номер записи первой незавершенной транзакции. Если посмотреть на рисунок выше, то открыв синюю транзакцию мы получим MinLSN равную 321, после ее фиксации в записи 324, номер MinLSN изменится на 323, что будет соответствовать номеру зеленой, еще не зафиксированной, транзакции.

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

  • При явном выполнении инструкции CHECKPOINT. Контрольная точка срабатывает в текущей базе данных соединения.
  • При выполнении в базе данных операции с минимальной регистрацией, например, при выполнении операции массового копирования для базы данных, на которую распространяется модель восстановления с неполным протоколированием.
  • При добавлении или удалении файлов баз данных с использованием инструкции ALTER DATABASE.
  • При остановке экземпляра SQL Server с помощью инструкции SHUTDOWN или при остановке службы SQL Server (MSSQLSERVER). И в том, и в другом случае будет создана контрольная точка каждой базы данных в экземпляре SQL Server.
  • Если экземпляр SQL Server периодически создает в каждой базе данных автоматические контрольные точки для сокращения времени восстановления базы данных.
  • При создании резервной копии базы данных.
  • При выполнении действия, требующего отключения базы данных. Примерами могут служить присвоение параметру AUTO_CLOSE значения ON и закрытие последнего соединения пользователя с базой данных или изменение параметра базы данных, требующее перезапуска базы данных.
Илон Маск рекомендует:  Как в PowerPoint вставить анимацию картинки или текста

В зависимости от того, какое событие произошло раньше, MinLSN будет присвоено значение либо номера записи контрольной точки, либо начала самой старой незавершенной транзакции.

Усечение журнала транзакций

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

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

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

Если количество транзакций велико и к моменту достижения 70% размера физического файла не окажется неактивных логических журналов, то размер физического файла будет увеличен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С другой стороны, если одна из копий лога транзакций будет повреждена, скажем, предпоследняя, то восстановить данные мы сможем только на момент последней резервной копии + период в неповрежденной цепочке копий журналов. Например, если журналы делались в 12, 14 и 16 часов и поврежден журнал, созданный в 14 часов, то располагая суточной копией мы сможем восстановить базу до момента окончания непрерывной цепочки, т.е. до 12 часов.

Резервное копирование и восстановление БД

Резервная копия может быть создана как средствами ПО, так и через SQL Server Management Studio.

Использование средств ПО RusGuard

Для того чтобы создать резервную копию БД:

1. Запустите утилиту Управление данными системы RusGuard Управление данными системы RusGuard (меню Пуск ОС Windows > список Все программы > папка RusGuard ).

Загрузится окно утилиты. По умолчанию открыта вкладка Обслуживание (см. рис. 1).

Рисунок 1 — Окно Утилиты «Управление данными системы RusGuard»

2. Нажмите на кнопку в области Резервное копирование и восстановление .

Откроется стандартный диалог Windows для сохранения файла резервной копии в формате .bak .

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

Система обратится к БД и выполнит резервное копирование.

Для того чтобы восстановить резервную копию:

1. Запустите утилиту Управление данными системы RusGuard Управление данными системы RusGuard (меню Пуск ОС Windows > в список Все программы > папка RusGuard ).

Загрузится окно. По умолчанию открыта вкладка Обслуживание .

2. Нажмите на кнопку в области Резервное копирование и восстановление .

3. Выберите нужный файл резервной копии и откройте его.

4. После восстановления обязательно проверьте совместимость с версией БД (кнопка ). Запустите процесс обновления в случае положительного ответа (кнопка ).

Использование SQL Server Management Studio

Если необходимо выполнить восстановление резервной копии на ПК с другой конфигурацией, используйте утилиту Microsoft SQL Server Management Studio (доступна через меню Пуск ).

Для того чтобы создать резервную копию БД:

1. Запустите SQL Server Management Studio.

2. Перейдите к пункту Базы данных > База данных RusGuard (т.е. установите курсор на папку с базой данных СКУД).

3. Вызовите контекстное меню и выберите пункты Задачи > Создать резервную копию (см. рис. 2).

Рисунок 2 — Окно Утилиты SQL Server Management Studio. Создание резервной копии

4. Укажите путь для создания резервной копии.

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

• Не сохраняйте резервные копии на Рабочем столе или в корневом каталоге ПК.

Для того чтобы восстановить резервную копию БД:

5. Запустите SQL Server Management Studio.

6. Перейдите к пункту Базы данных .

7. Вызовите контекстное меню и выберите пункты Задачи > Восстановить .

8. Выберите файл с резервной копией и установите настройки как показано ниже (см. рис. 3, 4, 5 и 6). Нажмите на кнопку ОК .

Рисунок 3 — Окно Утилиты SQL Server Management Studio. Восстановление резервной копии

Рисунок 4 — Окно Утилиты SQL Server Management Studio. Восстановление резервной копии

Рисунок 5 — Окно Утилиты SQL Server Management Studio. Восстановление резервной копии

Рисунок 6 — Окно Утилиты SQL Server Management Studio. Восстановление резервной копии

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

Резервное копирование и восстановление базы данных Oracle Database

Oracle Database хранит все файлы созданной базы в файлах данных. Несмотря на то, что все данные логически содержатся в табличных пространствах, фактически они являются содержимым файлов на жестком диске компьютера. Так, каждая таблица базы данных хранится в виде строк конкретного файла данных. Часто, для восстановления данных определённой базы, достаточно восстановить её файлы данных и импортировать их в Oracle Database.

Структура базы данных Oracle Database

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

Файлы данных и табличных пространств (*.DBF).

Название файлов данных и табличных пространств, а также пути к ним можно посмотреть с помощью SQL Plus если выполнить следующий запрос:

В результате работы этого запроса получится подобный отчет:

Файлы конфигурации базы данных (*.ora).

Конфигурационные файлы базы данных Oracle имеют расширение *.ora и расположены в папке:

Управляющие файлы базы данных (*.DBF).

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

Также, чтобы определить названия и пути к управляющим файлам в SQL*Plus необходимо выполнить запрос:

Файлы журналов транзакций (*.LOG).

Чтобы узнать имена онлайновых журналов транзакций и пути к ним, необходимо в SQL Plus выполнить следующий запрос:

В результате работы этого запроса получится подобный отчет:

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

В результате работы этого запроса получится отчет:

Файл паролей (*.ora).

Как правило, это файлы с расширением *.ora, имя которых начинается с символов PWD.

Итак, для сохранения, архивирования или бэкапа базы данных Oracle Database, копии именно указанных групп файлов следует создавать, а это:

  • *.DBF – файлы данных, табличных пространств и управляющие файлы базы данных. Расположены:
    C:\oraclexe\app\oracle\oradata\XE
  • *.ora – файлы конфигурации базы данных и файлы паролей.
    Файлы конфигурации:
    C:\oraclexe\app\oracle\product\11.2.0\server\dbs
    Файлы паролей (PW…ora):
    C:\oraclexe\app\oracle\product\11.2.0\server\database
  • *.LOG – файлы журналов транзакций:
    C:\oraclexe\app\oracle\fast_recovery_area\XE\ONLINELOG

Резервная копия базы данных Oracle Database

Резервную копию базы данных Oracle Database (backup) можно сделать двумя способами:

  • Архивации средствами операционной системы.
  • Используя встроенные инструменты Oracle Application Express (APEX) – Import / Export.

Архивация средствами операционной системы

Архивация средствами операционной системы подразумевает «ручное» копирование всех рабочих файлов базы данных Oracle, таких как:

  • Файлы табличных пространств.
  • Управляющие файлы.
  • Файлы журналов транзакций.
  • Файлы конфигурации.

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

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

Архивация и восстановление при помощи инструментов Export / Import


Архивацию и восстановление базы данных Oracle Database можно производить с помощью стандартных механизмов Экспорта и Импорта в Oracle. Для повышения надежности сохранности данных необходимо периодически, в зависимости от интенсивности работы с базой, производить полный экспорт. При достаточно интенсивном внесении изменений в данные, необходимо делать экспорт один раз в неделю.

Откройте Oracle Application Express и выберите меню Application Builder / Export

Укажите тип экспорта: рабочее пространство полностью или одну из его составляющих

Установите формат файла для экспорта данных и нажмите кнопку Export Workspace (справа)

После указания места сохранения файла экспорта данных, они будут сохранены в SQL-файле.

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

Откройте Oracle Application Express и выберите меню Application Builder / Import

Выберите файл для импорта и укажите его тип

Установите импортированную базу данных

Восстановление утерянной базы данных Oracle Database

В случае удаления или утери по какой-то из причин базы данных Oracle Database, её можно восстановить, восстановив файлы с помощью Hetman Partition Recovery и восстановить их способом, описанном в разделе «Архивация средствами операционной системы».

Запустите Hetman Partition Recovery и проанализируйте с её помощью диск на котором находилась база данных

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

Замените файлы базы Oracle Database на восстановленные.

Для примера, восстановления файлов базы данных описан процесс восстановления файлов *.DBF. Но учтите, что для восстановления всех данных работоспособной базы, также необходимо восстановить соответствующие *.ORA и *.LOG файлы.

Резервирование и восстановление базы данных с помощью Oracle Recovery Manager (RMAN)

Oracle Recovery Manager (RMAN) – это ещё один инструмент создания резервной копии базы данных Oracle Database. Отличается он от других инструментов тем, что с его помощью создаётся полная копия всей базы данных, а не только данных из неё. А также, что немаловажно, Oracle Recovery Manager совмещает в себе функциональность SQL Command Line одновременно освобождая пользователя от полной зависимости от её команд. Устанавливается данный инструмент на компьютер одновременно и вместе с установкой Oracle Database.

Чтобы создать резервную копию базы с помощью RMAN:

Запустите файл Backup.bat в папке

или выберите Backup Database среди приложений в меню Пуск

Дождитесь окончания выполнения бэкапа базы данных инструментом RMAN

В результате в папке с названием даты создания резервной копии базы будет создан файл бэкапа с расширением *.BKP

Чтобы восстановить базу данных из резервной копии базы с помощью Oracle Recovery Manager (RMAN):

Запустите файл Restore.bat в папке

или выберите Restore Database среди приложений в меню Пуск

Дождитесь окончания выполнения базы данных из созданного раннее бэкапа инструментом RMAN

К слову, в случае утери или удаления файла бэкапа базы данных Oracle Database, *.BKP файл бэкапа можно также восстановить с помощью Hetman Partition Recovery, после чего восстановить описанным выше способом в базе данных используя Oracle Recovery Manager (RMAN).

Нашел данную статейку на просторах интернета. Решил поделиться с коллективом нашего дружного сообщества , так сказать! ;-)

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

Применимо к: SQL Server 2020 Preview

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

Резервного копирования команда создает резервную копию Microsoft SQL Server Службы Analysis Services базы данных с использованием Службы Analysis Services (ABF), как описано в разделе резервное копирование баз данных.

Восстановить восстанавливает Службы Analysis Services из базы данных ABF-файле, как описано в разделе восстановление баз данных.

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

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

Илон Маск рекомендует:  Что такое код pdf_add_thumbnail

У учетной записи служб Analysis Services должны быть разрешения на запись в папку резервного копирования, заданную для каждого из файлов. Кроме того, пользователь должен быть членом одной из следующих ролей: роли администратора в экземпляре служб Службы Analysis Services или роли базы данных с разрешениями «Полный доступ (Администратор)» в базе данных, для которой создается резервная копия.

Задание базы данных и файла резервной копии

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

Чтобы указать файл, который должен быть создан и используется для резервного копирования, необходимо задать файл свойство резервного копирования команды. Файл свойство должно быть присвоено UNC-путь и имя создаваемого файла резервной копии.

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

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

Если задать ApplyCompression значение true, файл резервной копии сжат после создания файла.

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

Важно

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

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

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

Значение безопасности свойство ограничена одной из строк, перечисленных в следующей таблице.

Важно
Значение Description
SkipMembership Включает определения безопасности, но исключает сведения о членстве из файла резервной копии.
CopyAll Включает определения безопасности и сведения о членстве в файл резервной копии.
IgnoreSecurity Исключает определения безопасности из файла резервной копии.

Резервирование удаленных секций

Резервное копирование удаленных секций в Службы Analysis Services базы данных, задать BackupRemotePartitions свойство резервного копирования команды значение true. Этот параметр вызывает резервного копирования команду для создания удаленного файла резервной копии для каждого удаленного источника данных, используемый для хранения удаленных секций для базы данных.

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

Восстановить команда восстанавливает указанную Службы Analysis Services базы данных из файла резервной копии. Восстановить команда имеет различные свойства, позволяющие указывать базу данных для восстановления файла резервной копии, восстановление определений безопасности, удаленные секции для хранения и перемещения реляционных объектов OLAP (ROLAP).

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

Важно

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

Задание базы данных и файла резервной копии

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

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

Восстановление параметров безопасности

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

Значением этого элемента может быть только одна из строк в следующей таблице.

Примечание
Значение Description
SkipMembership Включает определения безопасности, но исключает сведения о членстве из базы данных.
CopyAll Включает определения безопасности и сведения о членстве в базу данных.
IgnoreSecurity Исключает определения безопасности из базы данных.

Восстановление удаленных секций

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

Для каждого указанного расположение элемент, Службы Analysis Services экземпляр обращается к удаленным данным источника, заданного в DataSourceID свойство, чтобы восстановить секции, определенные в удаленного файла резервной копии, указанный в файл свойство. Помимо DataSourceID и файл свойства, следующие свойства доступны для каждого расположение элемент, используемый для восстановления удаленной секции:

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

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

Перемещение объектов ROLAP

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

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

Синхронизировать команда синхронизирует данные и метаданные указанной Службы Analysis Services базы данных с другой базой данных. Синхронизировать команда имеет различные свойства, которые позволяют указать базы данных-источника, как синхронизировать определения безопасности, удаленные секции для синхронизации и синхронизацию объектов ROLAP.

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

Указание базы данных-источника

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

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

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

Синхронизация параметров безопасности

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

Значением этого элемента может быть только одна из строк в следующей таблице.

Примечание
Значение Description
SkipMembership Включает определения безопасности, но исключает сведения о членстве из целевой базы данных.
CopyAll Включает определения безопасности и сведения о членстве в целевую базу данных.
IgnoreSecurity Исключает определения безопасности из целевой базы данных.

Синхронизация удаленных секций

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

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

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

Синхронизация объектов ROLAP

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

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

Резервное копирование и восстановление баз данных

Содержание

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

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

Используемые базы данных делятся на две категории: 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. Запустите командную строку с правами администратора и введите туда следующую строчку:

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

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

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

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

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

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

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

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

Новое название сервера нужно указать вместо значения (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 соответственно.

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

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

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL