Файл: Сохранение и восстановление информации.pdf

СОХРАНЕНИЕ И ВОССТАНОВЛЕНИЕ ИНФОРМАЦИИ
Поскольку данные, хранимые компьютерными средствами подвержены потерям и повреждениям, вызываемым разными событиями, важно обеспечить средства восстановления данных. Приведение базы данных точно в то состояние, которое существовало перед отказом не всегда возможно, но процедуры восстановления базы данных могут привести ее в состояние, существовавшее незадолго до отказа.
В процессе эксплуатации информационных систем может происходить разрушение информации по причинам:
- физическое разрушение носителя информации или отдельных частей носителя с информацией;
- аппаратные сбои и разрушение информации;
- программное разрушение информации из-за ошибок в программах;
-воздействие вредоносных программ;
- ошибки оператора (персонала);
- преднамеренное разрушение с использованием различных средств.
Поэтому, обязательным элементом любых ИС являются процедуры сохранения и восстановления информации как защитная мера от разрушения (потери) данных.
Сохранение информации - это процедура получения резервной копии с целью ее последующего использования при ликвидации возможных разрушений информации. При сохранении информации используют термины копирование, дублирование, дампирование, выгрузка.
Копирование (сохранение) информации выполняется периодически по графику. Между точками снятия копий сохраняются все данные, которые использовались для внесения изменений в файлы (базы данных). Копирование проводится по схеме “отец-сын”, что означает хранение двух копий для двух последовательных процедур копирования.
При файловой обработке между точками снятия копий сохраняют исходные файлы корректур. При работе с базами данных в режиме онлайн используют системный журнал и процедуру накопления изменений информации. Системный журнал - это файл, в который вносится информация (протоколируется) о ходе работы информационной системы, включая все изменения баз данных.
Восстановление информации - это процедура ликвидации разрушений данных с использованием сохраненной информации на некоторый момент времени (копии) и возможной корректуры с момента создания копии.
В интерактивных (онлайновых) системах предусматривается несколько уровней восстановления:
- оперативное восстановление. Оперативное восстановление используется, когда отдельные изменения в базах данных могут быть отменены при обнаружении ошибок в программах, аргументах поиска данных и т.д.
- промежуточное
восстановление. Для целей промежуточного восстановления используется метод контрольной точки. Контрольная точка - это дамп оперативной памяти и/или областей баз данных, сохраняемый в системном журнале в процессе работы информационной системы в определенный момент времени для возможного последующего восстановления работоспособности системы и баз данных на этот момент времени. Контрольная точка создается через заданный интервал времени, через определенное количество изменений в базах данных, при выполнении определенных условий в системе.
- длительное восстановление. Используются копии баз данных для восстановления информации и массивы корректур (накопленных изменений).
При проектировании ИС и создании рабочей документации следует процедуры сохранения и восстановления информации выделять особо. Указанные процедуры входят также в состав функций по ведению баз данных.
Ведение базы данных - это комплекс мероприятий по поддержанию данных в актуальном и достоверном состоянии.

Восстановление базы данных — функция СУБД, которая в случае логических и физических сбоев приводит базу данных в актуальное и консистентное состояние.
Журнал транзакций. Восстановление через откат
Реализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции обеспечивается специальным механизмом, для поддержки которого создается некоторая системная структура, называемая Журналом транзакций. Журнал транзакций содержит дополнительную информацию об изменениях базы данных и предназначен для обеспечения надежного хранения данных в БД.
Целью журнализации изменений баз данных является обеспечение возможности восстановления согласованного состояния БД после любого рода сбоев (аппаратных и программных). Основой поддержания целостного состояния БД является механизм транзакций.
Транзакция – последовательность операций над базой данных, отслеживаемая системой управления БД от начала до завершения как единое целое.
Выделят следующие типы транзакций:
1. плоские или классические (традиционные);
2. цепочечные;
3. вложенные.
Плоские или традиционные транзакции характеризуются следующими свойствами:

атомарности выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе;

согласованности, которое гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое – транзакция не разрушает взаимной согласованности данных;

изолированности означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно;

долговечности означает, что если транзакция завершена успешно, то те изменения данных, которые были ее произведены, не могут быть ее потеряны ни при каких обстоятельствах.
Общими принципами восстановления являются следующие:
1. результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;
2. результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных.
К ситуациям, при которых требуется восстановление базы данных, относятся:
 индивидуальный откат транзакции (аварийное завершение работы и т.д.);
 восстановление после внезапной потери содержимого оперативной памяти
(аварийное выключение электропитания, неустранимый сбой процессора и т.д.);
 восстановление после поломки основного внешнего носителя базы данных.
Возможны два основных варианта ведения журнальной информации:
1. отдельный локальный журнал, который поддерживается для каждой транзакции и используется для индивидуальных откатов транзакций;
2. общий журнал изменений базы данных, используемый для восстановления состояния базы данных после мягких и жестких сбоев.
Структура журнала условно может быть представлена в виде последовательного файла, в котором фиксируется каждое изменение базы данных. Каждая запись в журнале транзакций помечается номером транзакции, к которой она относится, и значениями атрибутов, которые она меняет.
Откат транзакции (возможность для незаконченных транзакций) выполняется следующим образом:
 выбирается очередная запись из списка данной транзакции;
 выполняется противоположная по смыслу операция, восстанавливающая предыдущее состояние объекта базы данных;

 любая из обратных операций также заносится в журнал;
 при успешном завершении отката в журнал заносится запись о конце транзакции.
При восстановлении базы данных после мягкого сбоя в журнале отмечаются точки физической согласованности базы данных – моменты времени, в которые во внешней памяти содержатся согласованные результаты операций, завершившихся до соответствующего момента времени, и отсутствуют результаты операций, которые не завершились.
Основой восстановления базы данных после жесткого сбоя являются журнал и архивная копия БД. Восстановление начинается с обратного копирования БД из архивной копии. Затем для всех закончившихся транзакций по журналу в прямом направлении выполняются все операции, для транзакций, которые не закончились к моменту сбоя, выполняется откат.
В случае логического отказа или сигнала отката одной транзакции журнал изменений сканируется в обратном направлении, и все записи отменяемой транзакции извлекаются из журнала вплоть до отметки начала транзакции. Согласно извлеченной информации выполняются действия, отменяющие действия транзакции. Этот процесс называется откат (rollback).
В случае физического отказа, если ни журнал изменений, ни сама база данных не повреждены, то выполняется процесс прогонки (rollforward). Журнал сканируется в прямом направлении, начиная от предыдущей контрольной точки. Все записи извлекаются из журнала вплоть до конца журнала. Извлеченная из журнала информация вносится в блоки данных внешней памяти, у которых отметка номера изменений меньше, чем записанная в журнале. Если в процессе прогонки снова возникает сбой, то сканирование журнала вновь начнётся сначала, но восстановление фактически продолжится с той точки, где оно прервалось.
В случае физического отказа, если журнал изменений доступен, но сама база данных повреждена, то должен быть выполнен процесс восстановления базы из резервной копии. После восстановления база будет находиться в состоянии на момент выполнения резервной копии. Для восстановления базы данных на момент отказа необходимо выполнить прогонку всех изменений, используя журнал изменений.
В случае физического отказа, если журнал изменений недоступен, но сама база данных не повреждена, восстановление возможно только на момент предыдущей контрольной точки.
В случае физического отказа, если повреждены как журнал изменений, так и сама база данных, то восстановление возможно только на момент выполнения резервной копии.
Восстановление поврежденной базы данных
Всегда существует вероятность того, что любое информационное хранилище будет повреждено и часть информации из него потеряна. Базы данных не являются исключением из этого правила. Обычно базу данных называют поврежденной, если при попытке извлечь или модифицировать содержащуюся в ней информацию возникают ошибки и/или извлекаемая информация оказывается утерянной, неполной или вообще неправильной. Порой повреждения базы данных скрыты и обнаруживаются только при проверке специальными средствами, но бывают и явные поломки базы данных, когда к базе невозможно подключиться, отлаженные программы-клиенты выдают нестандартные странные ошибки (в то время как никаких манипуляций над базой данных не производилось) или когда невозможно восстановить базу данных из резервной копии.
Основными причинами повреждения баз данных являются:
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.0.12, предусмотрена работа программы «Планировщик резервного копирования данных» с расширенным набором функций архивации данных.
Программа предназначена для выполнения операций резервного копирования, восстановления, починки данных и копирования данных за выбранный период в автономном режиме. После старта она выполняет свои функции согласно заданному расписанию без привлечения к себе внимания со стороны пользователя. Лог работы программы ведется в журнале событий ОС Windows.
В отличие от программ, которые работают как сервисы Windows и могут запускаться до логина пользователя в ОС, «Планировщик резервного копирования данных» останется не запущенным пока пользователь не пройдет регистрацию в ОС. Поэтому для запуска программы необходимо произвести вход в Windows. Так как программа поставляется в дистрибутиве серверной части системы, то такой пользователем должен обладать правами администратора ОС.
Важно отметить, что:
1. Планировщик резервного копирования можно закрыть только через меню пиктограммы из системного трея
2. Если он выполняет какие-либо действия, то закрыть программу нельзя пока процесс не завершится.
3. Если в процессе выполнения архивирования, профилактики попытаться выключить компьютер, то программа не даст этого сделать.
Лог работы программы ведется в журнале событий ОС Windows.
Перед выполнением операций резервного копирования (BackUp) и восстановления базы данных (Restore), происходит анализ свободного места на диске. При этом:
1. Свободного места на диске, где находится БД АИСТ-М должно быть достаточно для хранения самой БД и ее копии, которая создается при восстановлении БД (Restore). Если БД состоит из нескольких файлов, то при оценке места на диске учитывается их общий размер.
2. Свободного места на диске, где находятся файлы архивной копии БД должно быть не меньше общего размера самой БД.
При отсутствии свободного места выполнении функций будет остановлено.

Программа реализует следующие функции:
Регулярное резервное копирование данных – позволяет создать архивную копию всей базы данных (Backup). При этом могут создаваться многофайловые архивы, что определяется настройкой программы.
Профилактика базы данных (Backup/Restore) – включает в себя выполнение сразу двух операций: резервного копирования данных (Backup) и восстановления данных (Restore).
Профилактика выполняется как для получения резервной копии базы данных, так и для очистки базы данных от временных записей, что позволяет уменьшить размер БД. На этапе восстановления могут создаваться многофайловые БД, что определяется настройкой программы. При восстановлении все БД отключаются немедленно, а также происходит перезапуск сервера БД.
Восстановление по этой причине возможно только на сервере БД. Следует отметить, что функция профилактики БД имеет приоритет выполнения перед функцией регулярного резервного копирования данных. В случае, когда в расписании для этих функций указаны одинаковые параметры запуска (например, совпадает день и время запуска), то будет выполнена только профилактика БД. Это обусловлено тем, что профилактика уже включает в себя операцию резервного копирования данных (BackUp).
Перед выполнением восстановления БД (Restore) создается копия текущей БД, с расширением docpoint2.__b . Копия БД необходима для быстрого отката, при возникновении нештатных ситуаций. Для восстановления работоспособности системы достаточно переименовать файл(ы) копии БД. Например, копия БД docpoint2.__b переименовывается в docpoint2.gdb. При каждом запуске «Планировщика резервного копирование» проверяется, есть ли файл БД docpoint2.gdb. В случае если файл не найден (такое может произойти например в случае если во время выполнения профилактики БД произошло отключение сервера), то выдается текстовое сообщение о том что файл БД отсутствует и администратору системы предлагается восстановить базу из копии (автоматически переименовать docpoint2.__b в docpoint2.gdb )
Починка БД – при выполнении починки БД происходит также и проверка целостности БД.
При починке БД происходит отключение всех подключенных на момент проверки пользователей и включение БД при заве ршении операции. При этом починка БД происходит в два этапа, сначала
БД проверяется на наличие ошибок, после чего выдается запрос о том, были ли обнаружены ошибки в БД, и нужно ли выполнять исправление БД (дело в том, что в некоторых случаях рекомендуется сделать резервную копию файла, поскольку процесс восстановления будет вносить в БД изменения). В случае же если ошибки не найдены, то проверку нужно прекращать. Сама проверка должна производиться только в случае повреждения БД. Следует четко различать ошибки повреждения БД и, например, ошибки подключения к БД по причине отсутствия соединения. Обычно ошибки в БД могут возникать по причине нестандартного отключения электропитания.
Восстановление БД – восстановление БД из резервной копии происходит автоматически при выполнении функции «Профилактика БД», однако, эта операция может быть сделана по запросу пользователя. Для этого необходимо в меню «Операции» выбрать пункт меню
«Восстановить БД». Резервная копия БД находится в каталоге определенном в настройках программы.
Удаление документов по указанную дату – используется для удаления «устаревших» документов и уменьшения размера БД. Пользователь может выбрать дату и время, на которую требуется удалить документы. Удаление документов происходит от самой ранней даты изменения документа найденной в БД, до даты выбранной пользователем. По умолчанию дата устанавливается из расчета, текущая дата минус один год. Периодически необходимо выполнять ревизию документов, для того чтобы те документы которые необходимо отставить, имели относительно свежую дату их изменения. Для этого, например, можно иметь некий переход в технологической схеме, прохождение через который менял бы дату изменения документа.
Информация о количестве удаленных документов сохраняется в лог файле BackUtil.log.
Очистка BODY_LOG – удаление в каталоге BODY_LOG временных файлов не связанных ни с одним документом БД.
При откате (RollBack) транзакции, например, когда пользователь отказывается от сохранения изменений в документе, работая в ПЗ «Модуль обработки документов», в каталоге