Лагоша О.Н. - Сертификация информационных систем (2021). Курс лекций по дисциплине Сертификация информационных систем. Предназначено для студентов специальности Информационные системы и программирование
 Скачать 5.4 Mb.
|
|
Внесерверное копирование. Данный тип резервного копирования пред- ставляет собой дальнейшее развитие метода внесетевого копирования (LAN- free), поскольку уменьшает количество процессоров, памяти, устройств ввода- вывода, задействованных в этом процессе. Данный процесс архивирует разделы целиком, в отличие от пофайлового архивирования, но при этом позволяет вос- станавливать отдельные файлы. По определению при внесерверном копирова- нии данные копируются с диска на ленту и обратно без прямого участия серве- ра. Поскольку для резервного копирования требуется наличие некоторого до- полнительного третьего узла, полностью отвечающего за процесс копирования, то отсюда происходит и другое название этого подхода — копирование с уча- 4 / 10 45 стием третьей стороны (Third_-Party Copy, 3PC). Так, в качестве подобного оборудования может использоваться маршрутизатор хранилищ данных, кото- рый берет на себя функции, ранее выполнявшиеся сервером. Одно из преимуществ архитектуры SAN — отсутствие жесткой привязки составляющих ее систем к каким-либо устройствам хранения данных. Это свойство и заложено в основу технологии резервного копирования без участия сервера. В данном случае к дисковому массиву может иметь прямой доступ как сервер данных, так и устройства, принимающие участие в копировании с дис- ковых массивов. Резервному копированию блоков данных, относящихся к ка- кому-либо файлу, предшествует создание некоего индекса или списка номеров принадлежащих ему блоков. Это и позволяет в дальнейшем привлечь внешние устройства для резервного копирования. Таким образом, внесерверное копирование позволяет напрямую переме- щать данные между подключенными к сети SAN дисковыми массивами и биб- лиотеками. При этом данные перемещаются по сети SAN и не загружают ни локальную сеть, ни серверы. Такое копирование считается идеальным для кор- поративных сетей, которые должны функционировать в непрерывном режиме 24 часа в сутки, 7 дней в неделю. Особенно для тех, для которых временной пе- риод, в течение которого можно выполнять резервное копирование без сущест- венного влияния на работу пользователей и приложений, становится недопус- тимо малым. Репликация данных. Современные дисковые массивы обладают средст- вами создания копий данных внутри самого массива. Данные, созданные этими средствами, носят название Point-In-Time (PIT) копий, т. е. фиксированных на определенный момент времени. Существуют две разновидности средств созда- ния PIT-копий: клонирование и «моментальный снимок» (snapshot). Под кло- нированием обычно понимают полное копирование данных. Для него требуется столько же дискового пространства, сколько и для исходных данных, и некото- рое время. При использовании такой копии нет нагрузки на дисковые тома, со- держащие исходные данные. Иными словами, нет дополнительной нагрузки на дисковую подсистему продуктивного сервера. Механизм работы «моментальных снимков» иной и может быть реализо- ван как программно на продуктивном сервере, так и аппаратно внутри массива. В момент, когда необходимо начать резервное копирование, программа-агент дает команду приложению завершить все транзакции и сохранить кэш-память на диск. Затем создается виртуальная структура — snapshot, представляющая собой карту расположения блоков данных, которую ОС и другое ПО воспри- нимает как логический том. Приложение прерывает стандартный режим работы на короткое время, необходимое для сохранения данных. После этого приложе- ние продолжает работать в стандартном режиме и изменять блоки данных, при этом перед изменением старые данные блока с помощью драйвера snapshot ко- пируются в область кэш-памяти snapshot и в карте расположения блоков дан- ных указывается ссылка на новое местоположение блока. Таким образом, карта snapshot всегда указывает на блоки данных, полученные на момент завершения транзакций приложением. Блоки данных, которые не были изменены, хранятся 5 / 10 46 на прежнем месте, а старые данные измененных блоков — в области кэш- памяти snapshot. Программа-агент копирует непротиворечивые данные, полу- ченные на момент завершения транзакций приложением, осуществляя доступ к ним через драйвер snapshot, т. е. используя карту расположения блоков. Созда- ние копий с помощью «моментальных снимков» экономит дисковое простран- ство, но создает дополнительную нагрузку на дисковую подсистему продук- тивного сервера. Какой из методов создания PIT-копий выбрать, решается на этапе проектирования системы резервного копирования исходя из бизнес-тре- бований, предъявляемых к системе. 6 / 10 47 ЛЕКЦИЯ 6. ВОССТАНОВЛЕНИЕ ИНФОРМАЦИИ 1. Сохранение и восстановление информации Поскольку данные, хранимые компьютерными средствами, подвержены потерям и повреждениям, вызываемым разными событиями, важно обеспечить средства восстановления данных. Приведение базы данных точно в то состоя- ние, которое существовало перед отказом, не всегда возможно, но процедуры восстановления базы данных могут привести ее в состояние, существовавшее незадолго до отказа. В процессе эксплуатации информационных систем может происходить разрушение информации по причинам: – физическое разрушение носителя информации или отдельных частей носителя с информацией; – аппаратные сбои и разрушение информации; – программное разрушение информации из-за ошибок в программах; – воздействие вредоносных программ; – ошибки оператора (персонала); – преднамеренное разрушение с использованием различных средств. Поэтому обязательным элементом любых ИС являются процедуры со- хранения и восстановления информации как защитная мера от разрушения (по- тери) данных. Сохранение информации — это процедура получения резервной копии с целью ее последующего использования при ликвидации возможных разруше- ний информации. При сохранении информации используют термины копирова- ние, дублирование, дампирование, выгрузка. Копирование (сохранение) информации выполняется периодически по графику. Между точками снятия копий сохраняются все данные, которые ис- пользовались для внесения изменений в файлы (базы данных). Копирование проводится по схеме «отец — сын», что означает хранение двух копий для двух последовательных процедур копирования. При файловой обработке между точками снятия копий сохраняют исход- ные файлы корректур. При работе с базами данных в режиме онлайн использу- ют системный журнал и процедуру накопления изменений информации. Сис- темный журнал — это файл, в который вносится информация (протоколирует- ся) о ходе работы информационной системы, включая все изменения баз дан- ных. Восстановление информации — это процедура ликвидации разрушений данных с использованием сохраненной информации на некоторый момент вре- мени (копии) и возможной корректуры с момента создания копии. В интерактивных (онлайновых) системах предусматривается несколько уровней восстановления: – оперативное восстановление. Оперативное восстановление использу- ется, когда отдельные изменения в базах данных могут быть отменены при об- наружении ошибок в программах, аргументах поиска данных и т. д.; 7 / 10 48 – промежуточное восстановление. Для целей промежуточного восста- новления используется метод контрольной точки. Контрольная точка — это дамп оперативной памяти и (или) областей баз данных, сохраняемый в систем- ном журнале в процессе работы информационной системы в определенный момент времени для возможного последующего восстановления работоспособ- ности системы и баз данных на этот момент времени. Контрольная точка созда- ется через заданный интервал времени, через определенное количество измене- ний в базах данных, при выполнении определенных условий в системе; – длительное восстановление. Используются копии баз данных для вос- становления информации и массивы корректур (накопленных изменений). При проектировании ИС и создании рабочей документации следует про- цедуры сохранения и восстановления информации выделять особо. Указанные процедуры входят также в состав функций по ведению баз данных. Ведение базы данных — это комплекс мероприятий по поддержанию данных в актуальном и достоверном состоянии. Восстановление базы данных — функция СУБД, которая в случае логи- ческих и физических сбоев приводит базу данных в актуальное и консистент- ное состояние. 2. Журнал транзакций. Восстановление через откат Реализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции обеспечивается специальным механиз- мом, для поддержки которого создается некоторая системная структура, назы- ваемая журналом транзакций. Журнал транзакций содержит дополнительную информацию об изменениях базы данных и предназначен для обеспечения на- дежного хранения данных в БД. Целью журнализации изменений баз данных является обеспечение воз- можности восстановления согласованного состояния БД после любого рода сбоев (аппаратных и программных). Основой поддержания целостного состоя- ния БД является механизм транзакций. Транзакция — последовательность операций над базой данных, отслежи- ваемая системой управления БД от начала до завершения как единое целое. Выделят следующие типы транзакций: 1) плоские или классические (традиционные); 2) цепочечные; 3) вложенные. Плоские или традиционные транзакции характеризуются следующими свойствами: – атомарности — выражается в том, что транзакция должна быть вы- полнена в целом или не выполнена вовсе; – согласованности — гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое — транзакция не разрушает взаимной согласованности данных; 8 / 10 49 – изолированности —означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполня- ются параллельно; – долговечности —означает, что если транзакция завершена успешно, то те изменения данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах. Общими принципами восстановления являются следующие: 1) результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных; 2) результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных. К ситуациям, при которых требуется восстановление базы данных, отно- сятся: – индивидуальный откат транзакции (аварийное завершение работы и т. д.); – восстановление после внезапной потери содержимого оперативной па- мяти (аварийное выключение электропитания, неустранимый сбой процессора и т. д.); – восстановление после поломки основного внешнего носителя базы дан- ных. Возможны два основных варианта ведения журнальной информации: 1) отдельный локальный журнал, который поддерживается для каждой транзакции и используется для индивидуальных откатов транзакций; 2) общий журнал изменений базы данных, используемый для восстанов- ления состояния базы данных после мягких и жестких сбоев. Структура журнала условно может быть представлена в виде последова- тельного файла, в котором фиксируется каждое изменение базы данных. Каж- дая запись в журнале транзакций помечается номером транзакции, к которой она относится, и значениями атрибутов, которые она меняет. Откат транзакции (возможность для незаконченных транзакций) вы- полняется следующим образом: – выбирается очередная запись из списка данной транзакции; – выполняется противоположная по смыслу операция, восстанавливаю- щая предыдущее состояние объекта базы данных; – любая из обратных операций также заносится в журнал; – при успешном завершении отката в журнал заносится запись о конце транзакции. При восстановлении базы данных после мягкого сбоя в журнале отмеча- ются точки физической согласованности базы данных — моменты времени, в которые во внешней памяти содержатся согласованные результаты операций, завершившихся до соответствующего момента времени, и отсутствуют резуль- таты операций, которые не завершились. Основой восстановления базы данных после жесткого сбоя являются журнал и архивная копия БД. Восстановление начинается с обратного копиро- 9 / 10 50 вания БД из архивной копии. Затем для всех закончившихся транзакций по журналу в прямом направлении выполняются все операции, для транзакций, которые не закончились к моменту сбоя, выполняется откат. В случае логического отказа или сигнала отката одной транзакции жур- нал изменений сканируется в обратном направлении и все записи отменяемой транзакции извлекаются из журнала вплоть до отметки начала транзакции. Со- гласно извлеченной информации выполняются действия, отменяющие действия транзакции. Этот процесс называется «откат» (rollback). В случае физического отказа, если ни журнал изменений, ни сама база данных не повреждены, выполняется процесс прогонки (rollforward). Журнал сканируется в прямом направлении, начиная от предыдущей контрольной точ- ки. Все записи извлекаются из журнала вплоть до конца журнала. Извлеченная из журнала информация вносится в блоки данных внешней памяти, у которых отметка номера изменений меньше, чем записанная в журнале. Если в процессе прогонки снова возникает сбой, то сканирование журнала вновь начнется с на- чала, но восстановление фактически продолжится с той точки, где оно прерва- лось. В случае физического отказа, если журнал изменений доступен, но сама база данных повреждена, должен быть выполнен процесс восстановления базы из резервной копии. После восстановления база будет находиться в состоянии на момент выполнения резервной копии. Для восстановления базы данных на момент отказа необходимо выполнить прогонку всех изменений, используя журнал изменений. В случае физического отказа, если журнал изменений недоступен, но са- ма база данных не повреждена, восстановление возможно только на момент предыдущей контрольной точки. В случае физического отказа, если повреждены как журнал изменений, так и сама база данных, восстановление возможно только на момент выполне- ния резервной копии. 3. Восстановление поврежденной базы данных Всегда существует вероятность того, что любое информационное храни- лище будет повреждено и часть информации из него потеряна. Базы данных не являются исключением из этого правила. Обычно базу данных называют по- врежденной, если при попытке извлечь или модифицировать содержащуюся в ней информацию возникают ошибки и (или) извлекаемая информация оказы- вается утерянной, неполной или вообще неправильной. Порой повреждения ба- зы данных скрыты и обнаруживаются только при проверке специальными средствами, но бывают и явные поломки базы данных, когда к базе невозмож- но подключиться, отлаженные программы-клиенты выдают нестандартные странные ошибки (в то время как никаких манипуляций над базой данных не производилось) или когда невозможно восстановить базу данных из резервной копии. 10 / 10 51 Основными причинами повреждения баз данных являются следующие. 1. Аварийное завершение работы серверного компьютера, особенно вне- запное отключение электропитания. Поэтому необходимо иметь на сервере ис- точник бесперебойного питания. При отключении питания на компьютере-сервере все процессы обработки данных резко прерываются. В результате информация в базе данных может ис- казиться или пропасть. После восстановления питания сервер просматривает данные, отслеживает незавершенные транзакции, не ассоциируемые ни с одним из клиентов, и «откатывает» все изменения, проведенные в рамках этих пре- рванных транзакций. Однако отключение питания не всегда сопровождается лишь такими незначительными потерями. Если сервер в момент отключения питания производил расширение базы данных, то велик риск получить «поте- рянные» страницы в файле базы данных (orphan pages), т. е. такие страницы, которые физически распределены и зарегистрированы на страницах учета стра- ниц, но запись данных на которые невозможна. Бороться с потерянными стра- ницами в файле базы данных умеет только инструмент починки и модификации BackUtil или gfix (стандартная утилита FireBird). Потерянные страницы приво- дят только к излишнему расходу дискового пространства и как таковые не слу- жат причиной потери или порчи данных. Но отключение питания может приво- дить и к более серьезным повреждениям. После отключения питания и повтор- ного включения может пропасть большое количество данных, в том числе и подтвержденных. Это происходит из-за того, что подтвержденные данные за- писываются не напрямую в файл базы данных на диске, а используют для этой цели файловый кэш операционной системы. То есть серверный процесс переда- ет операционной системе команду на запись данных на диск, операционная система, в свою очередь, отправляет подтверждение на сервер, что данные со- хранены на диске, а на самом деле данные находятся в файловом кэше. Опера- ционная система не сбрасывает эти данные на диск, так как оценивает, что опе- ративной памяти еще много, и откладывает медленные операции записи на диск до тех пор, пока не закончится свободная оперативная память. 2. Дефекты и неисправности серверного компьютера, особенно дисков, дисковых контроллеров, оперативной памяти компьютера и кэш-памяти RAID- контроллеров. 3. Файловое копирование или другой файловый доступ к базе данных при запущенном сервере. Выполнение команды shutdown или отключение пользо- вателей обычным порядком не является гарантией того, что сервер ничего не делает с базой; если sweep interval не установлен в 0, может выполняться sweep. Кроме того, после отключения последнего пользователя сервер убирает лиш- нюю информацию. Обычно эта процедура занимает 1–2 мин, но если перед этим выполнялось много операций delete или update, то процесс может быть более длительным. 4. Исчерпывание свободного дискового пространства во время работы с базой. 5. Для всех серверов Borland FireBird превышение допустимого количест- ва транзакций без выполнения backup/restore. 1 / 10 52 Во избежание подобных ситуаций, начиная с версии 1.0.12, предусмотре- на работа программы «Планировщик резервного копирования данных» с рас- ширенным набором функций архивации данных. Программа предназначена для выполнения операций резервного копиро- вания, восстановления, починки данных и копирования данных за выбранный период в автономном режиме. После старта она выполняет свои функции со- гласно заданному расписанию без привлечения к себе внимания со стороны пользователя. Лог работы программы ведется в журнале событий ОС Windows. В отличие от программ, которые работают как сервисы Windows и могут запускаться до логина пользователя в ОС, «Планировщик резервного копиро- вания данных» останется не запущенным пока пользователь не пройдет регист- рацию в ОС. Поэтому для запуска программы необходимо произвести вход в Windows. Так как программа поставляется в дистрибутиве серверной части сис- темы, то такой пользователь должен обладать правами администратора ОС. Важно отметить, что: 1) планировщик резервного копирования можно закрыть только через меню пиктограммы из системного трея; 2) если он выполняет какие-либо действия, то закрыть программу нельзя пока процесс не завершится; 3) если в процессе выполнения архивирования, профилактики попытаться выключить компьютер, то программа не даст этого сделать. Лог работы программы ведется в журнале событий ОС Windows. Перед выполнением операций резервного копирования (BackUp) и вос- становления базы данных (Restore) происходит анализ свободного места на диске. При этом: 1) свободного места на диске, где находится БД должно быть достаточно для хранения самой БД и ее копии, которая создается при восстановлении БД (Restore). Если БД состоит из нескольких файлов, то при оценке места на диске учитывается их общий размер; 2) свободного места на диске, где находятся файлы архивной копии БД, должно быть не меньше общего размера самой БД. При отсутствии свободного места выполнение функций будет остановлено. Программа реализует следующие функции. Регулярное резервное копирование данных — позволяет создать архивную копию всей базы данных (Backup). При этом могут создаваться многофайловые архивы, что определяется настройкой программы. Профилактика базы данных (Backup/Restore) — включает в себя выпол- нение сразу двух операций: резервного копирования данных (Backup) и восста- новления данных (Restore). Профилактика выполняется как для получения ре- зервной копии базы данных, так и для очистки базы данных от временных за- писей, что позволяет уменьшить размер БД. На этапе восстановления могут создаваться многофайловые БД, что определяется настройкой программы. При восстановлении все БД отключаются немедленно, а также происходит переза- пуск сервера БД. Восстановление по этой причине возможно только на сервере БД. Следует отметить, что функция профилактики БД имеет приоритет выпол- 2 / 10 53 нения перед функцией регулярного резервного копирования данных. В случае, когда в расписании для этих функций указаны одинаковые параметры запуска (например, совпадает день и время запуска), будет выполнена только профи- лактика БД. Это обусловлено тем, что профилактика уже включает в себя опе- рацию резервного копирования данных (BackUp). Перед выполнением восстановления БД (Restore) создается копия теку- щей БД с расширением docpoint2.__b. Копия БД необходима для быстрого от- ката при возникновении нештатных ситуаций. Для восстановления работоспо- собности системы достаточно переименовать файл(ы) копии БД. Например, ко- пия БД docpoint2.__b переименовывается в docpoint2.gdb. При каждом запуске «Планировщика резервного копирования» проверяется, есть ли файл БД docpoint2.gdb. В случае если файл не найден (такое может произойти, напри- мер, в случае если во время выполнения профилактики БД произошло отклю- чение сервера), то выдается текстовое сообщение о том, что файл БД отсутст- вует и администратору системы предлагается восстановить базу из копии (ав- томатически переименовать docpoint2.__b в docpoint2.gdb). Починка БД — при выполнении починки БД происходит также и провер- ка целостности БД. При починке БД происходит отключение всех подключен- ных на момент проверки пользователей и включение БД при завершении опе- рации. При этом починка БД происходит в два этапа, сначала БД проверяется на наличие ошибок, после чего выдается запрос о том, были ли обнаружены ошибки в БД и нужно ли выполнять исправление БД (дело в том, что в некото- рых случаях рекомендуется сделать резервную копию файла, поскольку про- цесс восстановления будет вносить в БД изменения). В случае же если ошибки не найдены, то проверку нужно прекращать. Сама проверка должна произво- диться только в случае повреждения БД. Следует четко различать ошибки по- вреждения БД и, например, ошибки подключения к БД по причине отсутствия соединения. Обычно ошибки в БД могут возникать по причине нестандартного отключения электропитания. Восстановление БД — восстановление БД из резервной копии происхо- дит автоматически при выполнении функции «Профилактика БД», однако эта операция может быть сделана по запросу пользователя. Для этого необходимо в меню «Операции» выбрать пункт меню «Восстановить БД». Резервная копия БД находится в каталоге, определенном в настройках программы. Удаление документов по указанную дату — используется для удаления «устаревших» документов и уменьшения размера БД. Пользователь может вы- брать дату и время, на которую требуется удалить документы. Удаление доку- ментов происходит от самой ранней даты изменения документа, найденной в БД, до даты, выбранной пользователем. По умолчанию дата устанавливается из расчета: текущая дата минус один год. Периодически необходимо выполнять ревизию документов, для того чтобы те документы которые необходимо отста- вить, имели относительно свежую дату их изменения. Для этого, например, можно иметь некий переход в технологической схеме, прохождение через ко- торый меняло бы дату изменения документа. Информация о количестве уда- ленных документов сохраняется в лог-файле BackUtil.log. 3 / 10 54 Очистка BODY_LOG — удаление в каталоге BODY_LOG временных файлов, не связанных ни с одним документом БД. При откате (RollBack) транзакции, например, когда пользователь отказы- вается от сохранения изменений в документе, работая в ПЗ «Модуль обработки документов», в каталоге каталога BODY_LOG формируются временные файлы. Удаление таких файлов, не связанных ни с одним из документов, выполняется автоматически при выполнении функций регулярного резервного копирования и профилактике БД. Однако очистка каталога может быть выполнена по запро- су пользователя. Для этого следует выбрать в меню «Операции» пункт «Очи- стить BODY_LOG». Эта операция, а также период, за который будет произве- дена очистка, возможны при соответствующей настройке программы. Физическое копирование БД — при выполнении этой операции происхо- дит только копирование БД, без проведения процедуры backup/restore. Копиро- вание производится в каталог для резервных копий БД. Возврат состояния до последней операции — при выполнении этой опе- рации происходит переименование копии базы, оставшейся после последнего выполнения операции «Профилактика БД». Важно запомнить, что при выпол- нении этой операции текущий вариант базы будет перезаписан более старой ее копией, без возможности возврата к нему. Как происходит восстановление уже поврежденной БД в случае внезап- ного отключения электропитания? Для понимания этого сравним БД с файло- вой системой FAT. Для того чтобы восстановить конкретный файл в файловой системе, выполняются два действия: 1) проверка файловой системы на целостность (логическую), например утилитой scandisk; 2) проверка, остался ли этот файл без изменений (например, специальной программой, работающей с файлом). Аналогичные действия необходимо произвести и над неисправной БД. 1. Проверить целостность БД. База данных, как и файловая система, по- строена на страницах, которые выделяются в одном пространстве по мере не- обходимости. 2. Выполнить одну за другой функции «Выполнить резервное копирова- ние» (Backup) и «Выполнить восстановление БД» (Restore). Эти операции позволят выяснить, удачно ли прошло логическое восста- новление БД. Если в ходе этих операций не возникло никаких ошибок, то база данных логически цела и может использоваться для работы. Исключением мо- жет быть «потеря» нескольких документов по причине того, что они в момент выключения находились в памяти операционной системы и не были сохранены (или были сохранены частично) на диске. Если базу восстановить не удается, то при наличии резервной копии (если она создается регулярно) есть возможность просто восстановить данные на момент последнего резервного копирования, при этом вся работа, происходившая после создания резервной копии, будет утеряна, но будут восстановлены в полном объеме данных за весь период до ре- зервного копирования. 4 / 10 55 Для восстановления БД в случае ее поломки (повреждения), не связанной с отключением электропитания, существует другой алгоритм. Важно запомнить, что ввиду особой сложности этой процедуры, ее может выполнять только вручную администратор системы. При этом восстановление выполняется только для одной конкретной БД. Восстановление требует оста- новки работы подразделения, так как во время операции производится останов- ка сервиса СУБД. 5 / 10 |