|
|
Защита данных
Защита данных
Основы баз данных OpenEdge
Защита данных
Стратегия резервного копирования (backup)
Идентификация файлов для резервирования
Определение типа копии
Создание резервной спецификации
Резервное копирование базы данных
Использование PROBKUP
Выполнение offline копии
Выполнение online копии
Использование точек останова (quiet points)
Формирование копии средствами операционной системы
Примеры копирования базы данных
Пример инкрементального копирования
Пример полного копирования
Проверка копий
CRC код и избыточность при восстановлении копии
Востановление базы данных
After-imaging
Обеспечение безопасности
Auditing
Репликация данных
Failover Clusters
Поддержка и мониторинг базы данных
Команды запуска и останова
Параметры запуска баз данных
Утилиты OpenEdge RDBMS
Виртуальные системные таблиц (VST)
Стратегия резервного копирования (backup)
Стратегии резервирования и восстановления, это системы тесно связанные между собой, общая цель которых – восстановить базу данных в случае возникновения сбоя. Очень важно разработать такую стратегию, которая позволит последовательно и эффективно произвести восстановление базы данных.
Идентификация файлов для резервирования
Для правильного резервного копирования базы данных OpenEdge необходимо архивировать все файлы связанные с ней. Описание этих файлов приведено ниже.
База данных (.db, .dn) и файлы Before-image (.bn)
Эти файлы содержат данные и информацию о последних прошедших транзакциях. Эти файлы обязательно нужны для восстановления базы данных.
AI-файлы (.an)
Если для базы активирован механизм after-imaging, то эти файлы содержат информацию, которая будет необходима для восстановления в случае повреждения диска на котором расположена база. Эти файлы содержат все транзакции которые были совершены с момента формирования последней резервной копии. Архивация этих файлов происходит когда они полностью заполняются или когда база данных находится в остановленном состоянии.
Лог базы данных (.lg)
Файл лога базы данных содержит дату и время всех событий происходящих в ней. Он также содержит сообщения базы и другую историческую информацию, которая помогает диагностировать сложные проблемы, понимать и решать их. Регулярно копируйте этот файл. Для этого необходимо использовать утилиты операционной системы.
Transaction log (.tn)
Если используется механизм “two-phase commit”, то эти файлы содержат необходимую информацию для его работы. Копируйте эти файлы регулярно как часть общей процедуры резервирования. Вы можете использовать утилиты резервного копирования операционной системы.
Файлы приложений и библиотеки программ (.pl)
Ваша база данных это не всегда только одна база, в общем она может содержать прочие дополнительные файлы. Их так же необходимо учитывать при резервном копировании. Для архивирования необходимо использовать утилиты операционной системы.
Если триггеры базы данных загружаются в библиотеку программ, то также необходимо делать копии библиотек, для поддержания соответствия схемы базы данных и библиотек. Т.е. когда происходит копирования базы утилитой PROBKUP, то вместе с данными копируется схема базы данных, которая ссылается на триггера ABL, но сам код триггеров при этом не резервируется.
Определение типа копии
Необходимо определиться какими средствами будет происходить резервное копирование базы данных, это в большей мере зависит от важности данных, их ценности.
В таблице 4-1 указаны возможные способы копирования как средствами OpenEdge, так и средствами операционной системы.
Таблица 4-1 Выбор резервирования
OpenEdge
|
Операционная система
|
| Online или offline |
Только Offline |
| Полный или инкрементальный |
Только полный |
Для определения в каком режиме формировать копию, в offline или в online, ответьте:
- База данных активна 24 часа 7 дней в неделю?
- Возможно ли остановить ее для резервного копирования?
Если база работает в режиме 24\7\365, то используем online копирование. Если есть возможность остановить базу, то offline.
Для определения – полное или инкрементальное копирование использовать, ответьте на следующие вопросы. Какой объем данных может принять резервный носитель? Если он большой – хватит ли размера носителя и кто будет менять его? Имеет ли смысл формировать постоянно полную копию, а следовательно файл большого размера? Сколько по времени занимает полное копирование?
Если размер базы очень большой, то имеет смысл формировать инкрементальные копии.
Если выбран способ резервирования не с помощью PROBKUP, можно использовать утилиты операционной системы, но помните, в этом случае не возможно использовать online и инкрементальные копии. Исключением из этих правил может быть только в случае когда необходимо сделать копию базы если произошли повреждения на диске. Но в этом случае перед копированием необходимо использовать команду proquit. При этом, так же необходимо быть уверенным, что эти утилиты обеспечат целостность данных и файлов. Частичное копирование может привести к разрушению базы в целом.
Примечание: независимо от выбранного метода резервирования, после копирования необходимо протестировать копии, для подтверждения ее корректности.
Полная копия подразумевает копирование всех файлов базы данных, включая файлы BI. Сформировать полную копию можно используя утилиту PROBKUP или используя утилиты операционной системы. В идеале, выполнять полную копию базы данных необходимо каждый день. Тем не менее, в зависимости от принятого плана восстановление, можно сократить количество полных копий прибегнув к использованию копий инкрементальных, или даже к механизму after-imaging.
Инкрементальная копия – это когда копируется только та часть данных, которая была изменена с момента формирования последней полной или инкрементальной копии. Такие копии занимают меньше места на носителе и соответственно меньше времени для их формирования. Для формирования инкрементальной копии необходимо использовать утилиту PROBKUP.
В базах данных OpenEdge, master-блок и каждый блок данных содержит счетчик копий. Счетчик в мастер блоке увеличивается каждый раз когда происходит копирование базы данных, не зависимо от режима копирования: online, offline, full или incremental. Когда блок базы данных изменяется, PROBKUP копирует значение счетчика в основном блоке в счетчик в изменяемом блоке базы. Когда выполняется инкрементальная копия, PROBKUP копирует каждый блок базы у которого счетчик больше или равен счетчику в мастер блоке. Если был определен параметр “–io” (Overlap parameter), PROBKUP копирует каждый блок базы у которого счетчик больше или равен счетчику в мастер блоке, меньше величины перекрытия (overlap).
Перед началом выполнения инкрементальных копий, обязательно необходимо выполнить полную резервную копию. Так же необходимо выполнять полные копии через определенное количество инкрементальных. Если регулярно не будут формироваться полные копии, размеры инкрементальных копий будет увеличиваться, равно как и будет увеличиваться время восстановления из-за увеличения количества инкрементальных копий после последнего полного копирования.
Online копирование позволяет создавать копии когда база данных используется пользователями. Для этого также используется утилита PROBKUP. К этому методу прибегают когда база данных не может находиться в недоступном состоянии длительное время, достаточного для формирования копии в offline. Здесь также можно выполнять полные и инкрементальные копии.
Для принятия решения об использовании online копирования, рассмотрите следующие вопросы:
- Нельзя использовать online копирование в базах данных запущенных в однопользовательском режиме.
- Если у базы активирован after-imaging, при выполнении online копии произойдет автоматическое переключение на следующий ai-файл. Прежде чем запустить online копирование, необходимо убедиться, что следующий файл ai пустой. Если он окажется не пустой, PROBKUP не сформирует бэкап и завершится с уведомлением о невозможности переключиться на новый ai-файл.
- Если необходимо активировать after-imaging в базе, находящейся в online, это можно сделать вместе с полной online копией. Которая и будет считаться базовой для ai файлов.
- Когда запускается online копирование, база данных на время замораживается пока не будет записан заголовок копии. Убедитесь, что резервный носитель правильно настроен и готов к передаче данных командой PROBKUP, для того чтобы минимизировать длительность паузы. Пока не будет записан заголовок , будет не возможно вносить изменения в базу данных. Если формируется многотомная копия, то задержка в работе будет возникать при каждом переключении на новый том.
- Нельзя использовать для online копирования параметры PROBKUP –scan и –estimate.
Для выполнения offline копии с начала необходимо остановить базу данных. Если будет выполняться offline копия средствами утилит операционной системы на запущенной базе данных - она будет разрушена. Для offline копирования можно использовать утилиты операционной системы или команду PROBKUP.
Создание резервной спецификации
Резервная спецификация является фундаментальной частью плана восстановления. Она определяет, как часто необходимо выполнять резервное копирование и назначает ответственных за его выполнение.
В идеале, необходимо выполнять полные копии каждый день, но в зависимости от плана восстановления, полные и инкрементальные копии могут чередоваться, что может быть вполне достаточно.
Чтобы сохранить целостность базы данных вам необходимо часто копировать базу данных, копировать ai-файлы отдельно от основной копии, использовать проверочные параметры команды PROREST, такие как -vp (Partial Verify); -vf (Full Verify).
Если база данных очень большая, то вероятно, что непрактично выполнять полное копирование ежедневно. Здесь можно принять решении о полном копировании через день, или даже раз в неделю. В замен частых полных копий можно использовать ежедневное инкрементальное копирование, или, если активирован механизм after-imaging, то копировать только ai-файлы.
Инкрементальные копии содержат только те блоки базы данных, которые были изменены с момента формирования предыдущей копии. Можно определять показатель перекрытия (overlap factor), чтобы формировать избыточность в каждой копии, тем самым еще более защищая базу данных. Тем не менее, необходимо выполнять полное копирование хотя бы раз в неделю, чтобы ограничивать используемое пространство резервного носителя, предназначенного для инкрементальных копий, а также чтобы уменьшать время восстановления данных.
Если у вас активирован after-imaging, архивируйте ai – файлы каждый раз перед началом формирования основной копии. Немедленно после формирования полной или инкрементальной копии, начинайте работу с нового ai-файла. Когда происходит резервирование ai-файлов, то резервируются именно транзакции базы данных, в то время когда инкрементальная копия содержит блоки базы данных, которые уже были изменены. Как результат, ai-файлы могут использоваться более обширно, чем инкрементальные копии. Если активность в базе данных очень высока, т.е. объемы изменяемых данных достаточно большие, и при этом формируется только полная еженедельная копия базы данных, ai-файлы могут вырасти до очень больших размеров. Поэтому их необходимо архивировать каждый день и помечать как пустые. Этот метод позволяет держать ai-файлы сравнительно небольшими. Для этого вы можете использовать утилиты AI File Management, информацию о которой вы сможете найти в этой книге.
Примечание: команда PROBKUP не архивирует ai-файлы, для этого необходимо использовать утилиты операционной системы или AI File Management.
При создании резервной спецификации, необходимо учитывать время, необходимое для формирования копии, и время, требуемое для восстановления базы данных из копии. Выполнение ежедневных полных копий может потребовать слишком много времени.
Если в базе данных изменения происходят не часто, то ежедневная полная копия могла бы быть не обязательной. Т.е. можно выполнять ежедневные инкрементальные копии и еженедельно полную копию. Если активирован after-imaging, то также не забывайте о необходимости архивировать ai-файлы.
Если полные копии формируются не менее чем раз в неделю, вы должны поддерживать многочисленные инкрементальные копии, которые делают восстановление более сложным, при котором также вырастает вероятность совершения ошибки администратором. Восстановление становится, так сказать, многошаговым, т.е. сначала необходимо восстановить последнюю полную копию, а затем пошагово восстанавливать инкрементальные копии.
Если у вас активирован after-imaging, то можно ежедневно производить архивирование ai-файлов вместо инкрементальных копий. Тем не менее, восстановление из ai-файлов происходит последовательно путем поочередного наката, что занимает несомненно больше времени чем восстановление базы из копии с помощью команды PROREST.
Дополнительно к запланированному копированию, иногда по некоторым причинам возникает необходимость формирования дополнительных копий. Например для следующих целей: чтобы запускать программу выполняющую большую работу с параметром запуска No Crash Protection (-i) (перед запуском, обязательно необходимо сделать резервную копию); как часть процесса восстановления; до и после серьезных изменении в базе данных; при установке новой версии СУБД OpenEdge и т.п.
Резервное копирование базы данных
Резервирование базы данных – это важнейшая часть в ее эксплуатации. Регулярное резервирование обеспечивает отправную точку для восстановления базы данных в случаях возникновения программных или аппаратных сбоев.
Использование PROBKUP
Используя для резервирования утилиту OpenEdge PROBKUP, вы получаете возможность выполнять полную online копию, инкрементальную online копию, полную offline копию и инкрементальную offline копию. Это зависит от вашего резервного плана. Вы также можете активировать after-imaging и AI File Management как часть полной online копии. Синтаксис PROBKUP указан ниже:
probkup [ online ] db-name [ incremental ] device-name
[ enableai ] [ enableaiarchiver -aiarcdir dirlist
[-aiarcinterval n] [-aiarcdircreate]]
[ -estimate | -vs n | -bf n | -verbose | -scan
| -io i | -com | -red i| -norecover
]
За более подробной информацией по использованию PROBKUP обратитесь к главе “PROBKUP”. А для информации по использованию PROBKUP для активирования after-imaging и AI File Management смотрите главу “After-imaging.”
Для выполнения online полной копии, запустите команду PROBKUP из командной строки операционной системы со следующим синтаксисом:
probkup online db-name device-name [ parameters ]
Пример полной копии для UNIX:
Администратор базы данных некоторой компании X выполняет полную копию базы данных devel.db каждую пятницу. Он подготавливает резервный носитель согласно документации операционной системы и затем выполняет полную online копию базы. Для чего выполняет следующие действия:
1. проверяет что база данных ни кем не используется
proutil devel -C BUSY
2. выполняет формирования полной online копии
probkup online devel /dev/rrm/0m -vs 35 -bf 20 –verbose
где,
devel,
определяет имя базы данных для копирования;
online,
определяет что копия выполняется в online;
/dev/rrm/0m,
определяет расположение копии базы;
-vs 35,
указывает, что размер тома базы данных – 35;
-bf 20,
определяет показатель блокировки – 20;
-verbose,
информирует о процессе копирования, выводя информацию на экран каждые 10 секунд.
Если не будет определен размер тома, PROBKUP будет заполнять свободное пространство памяти пока оно не закончится, т.е. место может кончится прежде чем процедура завершится до конца.
Как только начнется копирование, на экран будет выведена следующая информация:
64 bi blocks will be dumped.
336 out of 336 blocks in devel will be dumped.
This will require 369664 bytes of backup media.
This backup will require a minimum of 400 blocks to restore.
1 volume will be required.
Backed up 400 blocks in 00:00:05.
Wrote a total of 18 backup blocks using 369664
bytes of media.
Backup complete.
Количество записанных блоков это число определенное параметром –bf. Каждый резервный блок содержит необходимую информацию для его восстановления.
Этот пример использован для совсем не большой базы. Использование параметра –red увеличивает время и требует больший размер резервного носителя. Также, PROBKUP отображает количество блоков и их количество для несжатой базы данных, поскольку для online копии нельзя указать параметр –scan.
3. Если активирован after-imaging скопируйте ai-файлы на отдельный диск или ленту, используя утилиты копирования Unix.
Примечание: если after-imaging активирован, OpenEdge автоматически переключит AI экстент перед началом online копированием.
Тестируйте копии всегда! Это позволит гарантировать, что они будут актуальный и доступны когда это понадобится. Не забудьте также протестировать копию перед тем как восстанавливать базу данных. В идеале, копия должна быть протестирована сразу после того как сформирована. Т.к. если обнаружится проблема во время тестирования, вы всегда можете сразу сформировать новую копию. Если же вы оставите тестирование копии до момента, когда она вам понадобится, вы просто можете потерять всю базу данных, в случае если тест покажет отрицательный результат.
Таблице 5-1 содержится список параметров команды PROREST, которые можно использовать для тестирования копии выполненной командой PROBKUP.
Таблица 5-1 Утилиты проверки команды PROREST
Параметр
|
Описание |
| -vp |
Partial Verify
Определяет для утилиты восстановления необходимость чтения томов копии
и вычисления и сравнения CRC в заголовках блоков. Для восстановления
данных из битого блока, необходимо при резервном копировании определить
показатель избыточности. Вы можете использовать этот параметр как в
offline так и в online.
|
| -vf |
Full Verify
Определяет, что утилита PROREST сравнивает резервный блок для каждого блока. |
С параметрами Partial Verify и Full Verify не происходит восстановления базы данных, а также в нее не вносятся изменения.
Если Вы используете утилиты операционной системы для копирования, обязательно проверяйте, что вы скопировали целую, полную базу данных. Утилиты PROBKUP автоматически поддерживает копирование всех необходимых файлов, при копировании же средствами операционной системы необходимо самостоятельно убедиться, что все файлы базы включены в список копирования.
Правильное архивирование резервной копии это гарантия целостности базы данных. Следуйте следующим принципам для достижения хорошего результата:
- Ясно помечайте каждый том копии. Метка тома должна содержать следующие данные: Тип копии (инкрементальная или полная, online или offline)
Дата и время копии
Полный путь к базе данных
Номер тома и количество томов в копии (например 1 из 4)
Инициалы человека, выполнившего копию
Точная команда, используемая для копирования базы данных
- Имейте как минимум 10 поколений полных копий. Ежедневные копии храните в течении по крайней мере двух недель, еженедельные – в течении двух месяцев, и ежемесячные в течении года. Поверьте, покупка дополнительных носителей гораздо менее дорога чем вручную восстанавливать потерявшиеся базы данных.
- Храните копии отдельно от сервера на котором расположена база данных, желательно даже в другом здании. В противном случае, в случае разрушения здания, вы потеряете не только сервера, но и саму базы данных.
Выполнение offline копии
В Offline вы можете выполнять как полные так и инкрементальные копии. Перед выполнением инкрементальной копии необходимо сначала выполнить полное копирование. После первой полной копии можно выполнять сколько угодно инкрементальных. Тем не менее, целесообразнее выполнять полное копирование хотя бы раз в неделю.
Порядок выполнения полной и инкрементальной копии:
1. Проверьте, что база данных не занята. Если выполняется копирование в offline, база данных не должна использоваться. Это означает, что база данных должна быть остановлена и к ней не должно быть подключения в однопользовательском режиме. Команда PROBKUP при выполнении также не допустит подключений к базе данных. В Unix системах, поддерживаемых файловый блокировки, системные утилиты (например, cpio) при копирования базы данных, как бы зависнут, если в это время с базой работает сеанс OpenEdge. В других системах ни чего не мешает копировать базу данных, когда она используется.
Используйте утилиту PROUTIL BUSY для определения занятости базы:
proutil db-name -C busy
Классификатор BUSY возвращает код, который указывает на статус базы. Этот код можно использовать при написании сценариев и процедур. Для получения большей информации по классификатору BUSY обратитесь к главе “Классификатор PROUTIL BUSY”
2. Остановите базу данных. Перед копированием базы данных остановите её. Смотрите главу “Старт и останов баз данных OpenEdge”, для получение полной информации по останову базы данных.
3. Выполнение offline копирования. Запустите команду PROBKUP из командной строки операционной системы:
probkup db-name device-name [ parameters ]
По умолчанию, PROBKUP выполнит полное копирование. Для выполнения инкрементальной копии необходимо указать дополнительные классификаторы команды. Как только начнется копирование, на терминале появится информация, которая указывает на следующее:
- Количество байт необходимых на резервном носителе
- Количество блоков данных записываемых на носитель
- Количество скопированных блоков
- Количество блоков, необходимых для восстановления базы
Когда копирование будет завершено, на экране отобразится информация об общем количестве байт на резервном носителе, и сколько времени потребовалось для завершения копирования.
Примечание: если во время копирования произошел какой-либо сбой, необходимо выполнить копирование снова.
Выполнение online копии
Online копирование может также быть выполнено как полное так и инкрементальное. Для этого запустите команду PROBKUP со следующим синтаксисом:
probkup online db-name device-name [ parameters ]
По умолчанию, будет выполнена полная online копия. Для формирования инкрементальной копии, используйте классификатор incremental:
probkup online db-name incremental device-name [ parameters ]
Примечание: в случае, если база данных запущена с параметром No Crash Protection (-i), выполнение online копирования не возможно.
Для баз данных, у которых активирован механизм after-image, перед online копированием произойдет автоматическое переключение AI экстентов.
Использование точек останова (quiet points)
Для баз данных можно использовать quiet points (точки останова), которые позволяют выполнять с базой данных некоторые действия средствами ОС.
Для этого используйте команду PROQUIET:
proquiet dbname enable
Где
dbname,
имя базы данных для которой активируется точка останова.
Во время активирования точки останова вся деятельность базы данных, связанная с файловой системой, прекращается. Любой процесс, который попытается открыть транзакцию в этот момент, будет вынужден ждать, пока точка останова не будет деактивирована.
Используйте утилиты операционной системы только после активирования точки останова. В этом случае можно быть уверенным, что Ваша копия сформируется правильно и будет работоспособна.
Для деактивации точки останова используйте следующую команду:
proquiet dbname disable
Далее обновите структурный файл (.st) для копии базы данных, замените логические ссылки базы данных на физические.
Используйте утилиту PROSTRCT с классификатором REPAIR для обновления сегментов разделяемой памяти и информации о семафорах, и для обновления информации о файлах базы данных из структурного файла
prostrct repair dbname [ description-file ]
Где,
dbname
имя базы данных
description-file
имя структурного файла (.st)
Формирование копии средствами операционной системы
При формировании копии с использованием утилит операционной системы, отличной от PROBKUP, необходимо сделать ряд дополнительных шагов, а именно:
1. убедитесь, что копируются все необходимые файлы
2. убедитесь, что база данных не используется во время копирования. Иначе, копия будет повреждена. Если у вас установлена лицензия Enterprise , вы можете использовать PROQUIT для активация точки останова (quit point).
3. После выполнения и проверки копии, пометьте базу данных как скопированную.
Порядок копирования системными утилитами:
1. остановить сервер базы данных
2. проверьте, что базы данных не используется, с помощью PROUTIL BUSY.
proutil dbname -C busy
BUSY возвращает код статуса базы данных, который можно использовать для обработки скриптами и программами. Для получения более подробной информации обратитесь к главе “Классификатор PROUTIL BUSY”
3. Установите отметку в логе базы данных, о начале копирования. Она поможет в дальнейшем для проверки, например, чтобы быть уверенными, что во время копирования база данных ни кем не использовалась.
4. Скопируйте базу данных. Используйте утилиты операционной системы для копирования файлов базы данных. Проверьте, что эти утилиты гарантируют полное копирования файлов. На некоторых unix системах, размер файлов контролируется значением параметра ULIMIT.
5. Проверьте, что копия правильна и целая. Сначала проверьте лог базы данных, после вашей отметки не должно быть каких либо записей. Если были изменения после отметки, то вероятно что базу данных использовали. В этом случае копия считается не работоспособной. Необходимо выполнить новую копию. Во-вторых, проверьте, что все файлы базы данных скопированы. Утилита PROBKUP автоматически гарантирует копирование всех файлов базы данных, при использовании утилит операционной системы ответственности за полное копирование лежит на вас.
6. Пометьте базу данных как скопированную. После копирования и проверки копии, пометьте базу данных с помощью утилиты RFUTIL MARK BACKEDUP как скопированную
rfutil dbname -C mark backedup
Для получения более подробной информации по использованию утилиты обратитесь к разделу “Утилита RFUTIL”
Примеры копирования базы данных
Этот раздел включает в себя описания примеров использования утилиты PROBKUP под Unix и Windows
Пример инкрементального копирования
Этот пример демонстрирует использование параметров инкрементального копирования в offline для базы данных под Unix. Для выполнения online копии необходимо пропустить шаги со 2 по 4.
1. Подготовьте резервный носитель.
2. Проверьте что база данных не используется с помощью следующей команды:
proutil devel -C BUSY
3. Остановите базу данных командой PROSHUT
proshut devel
4. Запустите команду PROBKUP с ключом –estimate чтобы определить какой размер резервного носителя понадобится
probkup devel incremental /dev/null -estimate
5. Выполните инкрементальное offline копирование с использование следующей команды:
probkup devel /dev/rrm/0m incremental -vs 4000 -bf 20 -verbose -io 1 -com -red 5 –scan
Для выполнения online инкрементального копирования используйте следующую команду:
probkup online devel /dev/rrm/0m incremental -vs 35 -bf 20 -verbose -io 1 -com -red 5
Где,
devel -
имя базы данных для копирования
online –
определяет что копирование в online
/dev/rrm/0m –
место расположения формируемой копии
incremental –
определяет что копия инкрементальная
-vs 35 –
Указывает что размер тома в блоках базы данных равен 35. По умолчанию, при формировании будет использован один том, размер которого будет расти пока не кончится место на носителе (что приведет к ошибке), либо копирование не будет завершено.
-bf 20 –
Определяет фактор блокировки как 20
-verbose –
Отображает информацию о процессе копирования с интервалом в 10 секунд
-io 1 –
Определяет что восстановление базы будет возможным при потери одной инкрементальной копии.
-com –
Указывает, что данные должны быть сжаты прежде чем записаны на носитель. Если определен это параметр и не указан параметр –scan, PROBKUP отобразит информацию о количестве блоков и необходимом размере носителя для не сжатой базы данных.
-red 5 –
Указывает утилите о необходимости определения перед копированием количества блоков базы данных для копирования.
При выполнении инкрементальной копии на экране будет отображена следующая информация:
64 bi blocks will be dumped.
13 out of 336 blocks in devel will be dumped.
This will require 103424 bytes of backup media.
This backup will require a minimum of 400 blocks to restore.
1 volume will be required.
Backed up 77 blocks in 00:00:01.
Wrote a total of 5 backup blocks using 103424 bytes of media.
Backup complete.
Количество резервных блоков записанных на носитель, это значение указанное в параметре –df. Резервные блоки содержат данные, bi и блоки коррекции ошибок .
Это пример приведен для значительно маленькой базы данных. Если при копировании большой базы данных использовать параметр –red, то время копирования и размер носителя будет увеличен.
При выполнении online копирования на экране будет отображена следующая информация:
Incremental backup started.
Backed up 70 blocks in 00:00:01.
Wrote a total of 3 backup blocks using 103424 bytes of media.
Backup complete.
6. Если на базе данных активирован After Imaging, то позаботьтесь о копировании ai – файлов.
Пример полного копирования
База данных копируется каждый день, в течении недели формируется инкрементальная копия, и только в последний день, в воскресенье, - полная. База данных работает по Windows. И копия сохраняется на дискетах.
Напомним, при выборе параметров при копировании –com и –red, формирование копии будет происходить дольше. К тому же при использовании параметра –red размер дискового пространства понадобится так же значительно больше.
1. Подготовьте дискеты J
2. Проверьте что база данных не используется с помощью следующей команды:
proutil devel -C BUSY
3. Остановите базу данных командой PROSHUT
proshut devel
4. Запустите команду PROBKUP с ключом –estimate чтобы определить какой размер резервного носителя понадобится
probkup devel a:\devback -com -red 5 -scan –estimate
На экране отобразится информация о состоянии базы и размер необходимого носителя.
devel requires a total of 338 blocks of full backup media.
devel requires a total of 3 blocks of incremental backup media.
devel requires a total of 14 blocks of incremental backup media
with one overlap.
Total number of allocated blocks = 336
Total number of allocated blocks that are free: 2
Total number of allocated blocks that are used: 334
5. Введите следующую команду для выполнения полной offline копии базы данных:
probkup devel a:\devback -vs 708 -verbose -com -red 5 -scan
Следующая команда выполняет полную online копию:
probkup online devel a:\devback -verbose -com -red 5
Примечание: параметр –scan не может быть использован при online копировании
Где,
devel
имя копируемой базы данных
online
Определяется, что копирование будет в online
a:\devback
определяется, что копия сохраняется в файл devback на диск a:
-verbose
Отображение информации о ходе копирования с интервалом 10 секунд
-com
Указывает, что прежде чем данные будут записаны на диск, они будут сжаты. Если определяется этот параметр баз параметра –scan, PROBKUP отобразит количество блоков и размер копируемой не сжатой базы данных.
-red 5
Создание блока коррекции ошибок для каждых пяти блоков копируемых данных
-scan
Сканирование базы данных для определения необходимого количества копируемых блоков.
При выполнении полной offline копии на экране отобразится примерно следующая информация:
64 bi blocks will be dumped.
336 out of 336 blocks in devel will be dumped.
This will require 369664 bytes of backup media.
This backup will require a minimum of 400 blocks to restore.
1 volume will be required.
Backed up 400 blocks in 00:00:04.
Wrote a total of 12 backup blocks using 369664 bytes of media.
Backup complete.
Для online копии отображаться будет следующее:
64 bi blocks will be dumped.
336 out of 336 blocks in devel will be dumped.
This will require 369664 bytes of backup media.
This backup will require a minimum of 400 blocks to restore.
Backed up 400 blocks in 00:00:04.
Wrote a total of 12 backup blocks using 369664 bytes of media.
Backup complete.
Проверка копий
Сразу же после формирования копии базы данных желательно проверить ее на предмет наличия поврежденных блоков данных. С помощью утилиты восстановления PROREST, можно проверить целостность как полной так и инкрементальной копии.
Делается это следующим образом:
- Запустите команду PROREST c параметром –vp (Partial Verify). Этот параметр проверяет копию на наличие испорченных блоков и выдает отчет.
- Запустите команду PROREST c параметром –vf (Full Verify). С этим параметром, PROREST сравнивает блоки копии с блоками базы данных.
Использование этих параметров не приводит к восстановлению базы данных. Они только проверяют состояние копии, сообщают об испорченных если таковые существуют, и исправленных блоках. Для восстановления базы данных, необходимо запустить PROREST снова, но без этих параметров.
При использовании параметра –vp, PROREST сканирует копию и пересчитывает CRC код для каждого блока. Затем сравнивает полученный результат с CRC кодом, расположенном в заголовке блока. Если коды не совпадают, PROREST помечает блок как испорченный и выдает на экран следующую информацию:
CRC check failed reading backup block n
Если копия содержит блоки коррекции ошибок и набор избыточности содержит только один испорченный блок, PROREST использует их чтобы восстановить поврежденный блок. Точнее, используется либо блок коррекции ошибки, либо копия блока из набора избыточности. Если PROREST восстанавливает поврежденный блок, на экран выдается следующее сообщение:
Recovered backup block n
Если в наборе избыточности содержится более чем один поврежденный блок и если отсутствуют блоки коррекции ошибок, PROREST не сможет восстановить блок и отобразит следующую информацию на экране:
n CRC error within recovery group - recovery impossible
Так же PROREST не сможет произвести восстановление, если CRC не совпадают в самом блоке коррекции ошибок. Если такая ситуация произойдет, то будет выдано следующее сообщение:
Unable to recover previous block in error
Если в течении проверки будет обнаружено 10 ошибок, то вам будет предложено остановить процесс или продолжить его:
10 read errors have occurred.
Do you want to continue? [y/n]
CRC код и избыточность при восстановлении копии
При восстановлении поврежденного блока для определения поврежденного блока, PROREST использует CRC код. Этот код рассчитывается для каждого блока резервной копии. Так же используется блок коррекции ошибок. Эти блоки включаются в резервную копию только если при ее формировании использовался параметр –red.
CRC код
Когда PROBKUP записывает блок данных на резервный носитель, вычисляется код CRC, основанный на содержимом блока, который записывается вместе с ним. При восстановлении, PROREST просматривает содержимое блока и проверяет его на соответствие сопутствующему коду CRC. Если содержимое не соответствует CRC коду – блок поврежден.
Если копия содержит блоки коррекции ошибок, PROREST автоматически использует информацию из этих блоков для восстановления поврежденного блока. Если же копия не содержит блоков коррекции ошибок, то PROREST не сможет восстановить поврежденный блок при восстановлении базы данных.
Блоки коррекции ошибок
Блоки коррекции ошибок содержат информацию о всех блоках резервной копии и позволяют PROREST восстанавливать поврежденные блоки. Блоки коррекции ошибок и блоки на которых они основаны называют набором избыточности (redundancy set). Включение блоков коррекции обеспечивается добавлением параметра –red в команде копирования.
Параметр –red определяет показатель избыточности. Это показатель определяет количество блоков копии в каждом наборе избыточности. Например, если определяется показатель избыточности как 2, PROBKUP создает блок коррекции ошибки для каждых двух блоков копии. Следовательно, каждый набор избыточности содержит два блока копии и один блок коррекции ошибок.
PROREST в состоянии восстановить поврежденный блок, только если он единственный в установленном наборе избыточности. Если набор избыточности содержит более чем один поврежденный блок или один поврежденный блок копии и поврежденный блок коррекции, PROREST не сможет восстановить их.
Если определяется очень маленький показатель избыточности (например, 2), шанс получить два и более поврежденных блоков в наборе избыточности очень мал. Соответственно при увеличении значения показателя избыточности, увеличивается и вероятность ошибки. Тем не менее, низкий показатель увеличивает размер копии, и как следствие увеличивается время на формирование копии и размер необходимого резервного носителя. Выбор зависит от надежности резервного носителя, если он считается надежным – показатель можно увеличить, либо наоборот, при менее надежном носителе – уменьшается и значение показателя избыточности.
Размер каждого блока копии, и следовательно и каждого блока коррекции ошибок, определяется параметром –bf. По умолчанию, значение этого параметра равно 34. Например, если размер блока базы данных 1024 байт и значение параметра задано 40, то каждый блок копии это 40K, или 40 блоков базы данных.
|
|
|
|
Главная
