66
времени к моменту сбоя;
восстановить резервное копирование заключительного фрагмента
журнала.
Разностных резервных копий может и не быть, но самое главное, чтобы
были полная резервная копированя и непрерывная цепочка журналов с
момента полного резервного копирования.
Выполнять всю последовательность действий самому совершенно не
обязательно, Microsoft SQL Server 2019 самостоятельно сортирует и
восстанавливает резервные копии в нужной последовательности.
У всех баз данных MS SQL Server есть свойство «Модель
восстановления». Модель восстановления – это свойство базы данных,
которое управляет процессом регистрации транзакций, определяет, требуется
ли для журнала транзакций резервное копирование и какие типы операций
восстановления доступны. Данное свойство определяет поведение журнала
транзакций. Модель восстановления играет важную роль в процессе
восстановления базы данных из резервных копий.
Модель восстановления может быть: полной, простой и с неполным
протоколированием. Изменить модель восстановления можно в свойствах
базы в любой момент времени (рисунок 12).
Рисунок 12. Окно выбора параметров восстановления
67
В полной модели восстановления журнал транзакций содержит
максимальную информацию обо всех транзакциях. При этом хранятся не
только текущие активные транзакции, но и все предшествующие изменения
всех транзакций.
Если, например, резервное копирование журнала не выполнялся в
течение месяца, тогда файл журнала транзакций содержит информацию обо
всех изменениях в базе, которые произошли за этот месяц. При полной модели
восстановления файл журнала увеличивается до тех пор, пока не будет сделана
резервная копия лога.
Если не делать резервное копирование лога длительное время, файл
журнала может расти неограниченно и со временем занять все свободное
место на диске (если не установлено ограничение на размер журнала).
В момент создания копии журнала он усекается и в нем остаются только
данные об активных на текущий момент транзакциях.
Для сокращения объема, занимаемого файлом журнала на диске, нужно
выполнить сжатие журнала, то есть выполнить команду DBCC SHRINKFILE.
Усечение журнала – это освобождение места внутри физического файла, в то
же время сжатие файла журнала – это уменьшение размера файла журнала на
диске.
Простая модель восстановления подразумевает, что в журнале
транзакций будет храниться минимальный набор данных. Когда размер файла
журнала транзакций превысит установленное значение система начнет
перезаписывать данные в самое начало файла, стирая данные, созданные
ранее. При простой модели восстановления файл журнала транзакций
занимает небольшой объем на диске, но из-за этого в нём не будет информации
о транзакциях. Так как история транзакций хранится не будет, то не имеет
никакого смысла создавать резервные копии логов.
Если для базы данных выбрана простая модель восстановления, то
резервное копирование журнала транзакций для нее становится недоступным.
Модель восстановления с неполным протоколированием является
68
дополнением к полной модели восстановления и отличается от нее лишь
указанием минимальной информации по изменению данных.
В данной модели восстановления при массовом изменении данных
журнал транзакций не будет разрастаться так сильно, как при полной модели.
Для баз данных, работающих на платформе 1С:Предприятие, данная модель
не имеет большого практического смысла, поэтому далее будут
рассматриваться только первые две модели восстановления.
Модель восстановления напрямую влияет на процесс восстановления
данных из резервных копий.
Для рабочих баз данных считается необходимым использовать полную
модель восстановления, чтобы выполнять резервное копирование логов и
восстанавливать базу данных на момент сбоя.
Следует отметить, что простая модель восстановления, дает некоторое
преимущество в скорости на операциях массовой вставки. В этом случае,
пишется меньше данных на диск в журнал транзакций и за счет этого
получается ускорение. Однако если диск с журналом транзакций не являлся
«узким» местом, то это ускорение будет практически не заметным.
Для Организации будет использована полная модель восстановления
рабочих информационных баз.
Таблица 5
Преимущества и недостатки моделей восстановления
Модель
Преимущества
Недостатки
Применения
Полная
Восстановление на
любой момент времени
Растет журнал лога,
необходимо периодически
делать его резервное
копирование
Для рабочих баз
Простая
Журнал практически
не растет
Нельзя восстановить на любой
момент времени
Для тестовых и
технических баз
69
У системного администратора должен быть разработан регламент
резервного копирования: какие резервные копии, когда создавать, сколько
будут храниться резервные копии, где они будут храниться и т.д.
Не рекомендуется хранить резервные копии на том же физическом
диске, на котором находится сама база данных.
Для Организации подходит следующий регламент резервного
копирования:
Создание резервных копий
Полное резервное копирование – 1 раз в неделю на выходных. Так как
при создании копий чаще, чем 1 раз в неделю, резервные копии будут
занимать достаточно большое количество дискового пространства.
Разностное резервное копирование – 1 раз в день в ночное время.
Резервное копирование лога – каждые 15–30 минут.
Если базы небольшие и достаточно места на дисках, тогда можно
отказаться от разностного резервного копирования. В этом случае можно
делать полные резервные копии каждый день и резервные копии лога каждые
15-30 минут.
Для снижения стоимости хранения, для локальной копии можно
осуществлять резервное копирование с использованием быстрого диска. В
основном, даже в случае сбоя, восстановление данных можно будет
осуществить с помощью локальной резервной копии.
Если полное резервное копирование осуществляется каждую неделю, то
не имеет смысла хранить резервные копии старше 2-3 недель. Иногда
необходимо хранить полные резервные копии за несколько лет, например, для
бухгалтерии.
В Организации необходима четкая и понятная инструкция,
описывающая порядок действий в случае сбоя. Даже опытный специалист,
который все знает и все умеет, в стрессовой ситуации может что-то забыть.
Что может привести к ошибкам или увеличить время простоя. В случае
наличия инструкции есть один неочевидный плюс: в случае если специалист,
70
обслуживающий систему, уходит в отпуск, он должен передать план действий
в случае сбоя своему заместителю.
Необходимо периодически выполнять плановую проверку
восстановления из резервных копий.
Проверки полезны по следующим причинам:
Оценка времени на восстановление. Необходимо всегда обладать
информацией о том, какое количество времени потребуется для полного
восстановления системы при возникновении нештатной ситуации.
Отработка нештатных ситуаций. Что делать, если полный резервное
копирование оказался поврежден? Что делать, если есть полная
резервная копия и резервная копия логов, но разностная резервная копия
оказалась повреждена?
2.4 Испытания разработанного решения
Решение Veeam Backup & Replication Free использует различные методы
резервного копирования данных.
Прямой инкрементный метод, установлен по умолчанию, в связи с чем
его чаще используют. При первом запуске создается полная резервная копия
и далее сохраняется цепь последующих инкрементов. Для того, чтобы
повысить надежность такой цепочки резервных копий и сократить время
восстановления (оно будет линейно расти по мере роста числа созданных
инкрементов), периодически необходимо создавать либо новую полную
копию, либо синтетическую.
Использую прямой метод можно обеспечить высокую скорость
обработки данных, из-за того, что требуется всего одна операция чтения или
записи на каждый сохраняемый блок данных. Время создания инкремента и
время «жизни» снимка состояния виртуальной машины на текущий момент
времени (далее – снапшот) виртуальной машины невелико, что минимизирует
нагрузку на инфраструктуру информационной системы.
71
Рисунок 13. Схема создания резервных копий
В Организации будет установлена политика времени хранения
резервных копий, показано на рисунке 13, регламентирующая количество
доступных точек восстановления или время хранения. Рассматривая данный
случай, схема прямого резервного копирования должна соответствовать двум
условиям:
Цепочка резервных копий должна быть восстановимой, это означает,
что она должна включать в себя полную резеврную копию и все инкременты
(если удалить часть цепочки, восстановить данные из такой резервной копии
будет невозможно). Количество доступных точек восстановления всегда
должно быть не меньше установленного пользователем.
Для избегания перерасхода дискового пространства необходимо
использовать реверсивный инкрементный метод. Создание реверсивных
инкрементных резервных копий немного сложнее: новые инкременты
добавляются в изначально созданную полную резервную копию.
Реверсивный инкрементный метод, позволяет увеличить эффективность
использования системы хранения за счет того, что в наличии всегда есть одна
полная резервная копия и цепочка предшествующих ей инкрементов (при этом
«лишние» инкременты регулярно удаляются согласно установленному сроку
хранения). Также время восстановления данных из резервной копии,
созданной реверсивным методом, минимально, в связи тем, что полная
резервная копия содержит наиболее актуальную версию данных.
72
Но у этого метода есть свои минусы:
Снижается скорость обработки данных и увеличивается время
существования снапшота из-за того, что на каждый сохраняемый блок данных
требуется три операции чтения/записи:
- прочитать вытесняемый блок данных из полной копии,
- записать этот блок на СХД в виде реверсивного инкремента,
- вписать в полную копию новый блок изменившихся данных.
Это приводит к тому, что, если система хранения не поддерживает такой
уровень производительности, процесс создания резервной копии будет
занимать большое количество времени.
Для эффективного выполнения процедуры резервного копирования
решением Veeam Backup & Replication Free необходимо выделить ряд
моментов:
Чаще всего используются прямой инкрементный или бесконечно
инкрементный методы, так как они самые быстрые. Бесконечно-инкрементная
цепочка занимает меньше места и довольно быстро обрабатывается. Обычая
инкрементная цепочка занимает больше места на дисковом пространстве, но
она и более «жизнестойкая», так как в ней содержатся не только
инкрементальные резервные копии, но и периодически создаваемые полные
резервные копии.
Реверсивный инкрементный метод может быть в три или даже более раз
медленнее других, всё зависит системы хранения данных. Тем не менее, в его
использовании есть и свои плюсы: последним в цепочке всегда является
полный резервное копирование, и поэтому восстановиться можно быстрее,
чем из цепочек других типов. Отметим, что различий с обычной инкрементной
цепочкой почти нету.
Операция создания синтетической полной резервной не может быть
осуществлена без точек восстановления, которые хранятся в репозитории. В
связи с этим в качестве альтернативы создавать активные полные резервные
копии.
73
При настройке создания синтетической полной резервной копии,
необходимо обратить внимание на опцию “Transform previous backup chains
into rollbacks”. Ее использование приведет к тому, что будет запускаться
задание преобразования инкрементального резервного копирования (.VIB) в
точки отката (.VRB) (которое будет, однако, потреблять значительную часть
ресурсов СХД репозитория). С помощью данной опции становится
возможным преобразование текущей цепочки в обратно- инкрементальную,
для архивного хранения рисунок 14.
Рисунок 14. Окно выбора метода резервного копирования
Обработка гостевой операционной системы позволяет создавать
консистентные резервные копии виртуальных машин. Работа с гостевой ОC
основана на функциональности VSS (поддерживается Windows), которую
необходимо корректно настроить, иначе резервная копия не сможет корректно
создаться.
Для активации настроек обработки гостевой ОС:
1) В свойствах задания резервного копирования перейдите к шагу Guest
Processing.
2) Включите опцию Application-aware processing (обработка с учетом
74
состояния приложений).
3) В секции Guest OS credentials необходимо указать учетную запись с
правами администратора для доступа к гостевой операционной системе
рисунок 15.
Рисунок 15. Окно настройки обработки гостевой ОС
4) Если для какой-либо ВМ в составе задания резервного копирования
нужна отдельная учетная запись, то нажимаем кнопку Credentials. Далее надо
кликнуть на Set User… и указать нужные данные рисунок 16.
Рисунок 16. Окно резервного копирования отдельной учётной записи
75
5) Настройки для обработки конкретных приложений задаются в
отдельном диалоге, который можно открыть нажатием клавиши
«Applications». При необходимости также можно отключить обработку
гостевой ОС для отдельно взятых машин рисунок 17.
Рисунок 17. Окно настройки обработки конкретных приложений
Если активировать опцию VM Guest File System Indexing
(индексирование файлов гостевой ОС) в настройках резервного копирования,
то Veeam Backup & Replication будет создавать каталоги файлов ВМ.
Если же работать с Enterprise Manager, то мы советуем не включать
данную опцию – так вы сократите окно резервного копирования (порой весьма
существенно) и сэкономите место на диске C: сервера Veeam backup. Создание
дополнительных резервных копий.
Ни один производитель системы хранения данных не может
гарантировать абсолютную целостность данных. Veeam проверяет файл
резервной копии при записи на диск, но, на системе хранения данных
выполняются миллионы операций, можно считать возможной даже
перестановку бит. Чтобы выявить данные повреждения на ранних этапах
Veeam Backup & Replication предлагает использовать такие функции, как