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

В случае настольных систем перед тем, как копировать файлы, все они должны быть закрыты, т. е. на время копирования работа информационной системы должна быть прекращена. Впрочем, для настольных систем, возможно, более эффективным будет написание программных модулей в среде СУБД, которые позволят создавать резервные копии в период работы информационной системы. Многие информационные системы (особенно это касается ИС на основе настольных СУБД) имеют встроенные функции резервного копирования.

Какие же виды резервных копий, как правило, используют? Обычно различают резервные копии базы данных и резервные копии отдельных файлов. Средства промышленных СУБД позволяют делать и то, и другое. Почему актуальным может быть резервное копирование отдельных файлов? Дело в том, что базы данных могут быть очень больших объемов. Даже в тех СУБД, в которых базы данных могут состоять всего из одного файла, есть смысл разбить большую базу данных на несколько файлов. Причем эти файлы про мобильные выставочные стенды могут располагаться также на разных носителях. Поскольку большую базу данных трудно копировать сразу, это занимает много времени, можно копировать отдельные файлы по очереди. В общем случае можно выделить следующие типы резервных копий.

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

• накладывается блокировка на базу данных;
• устанавливается метка (М1) в журнале транзакций;
• снимается блокировка с базы данных;
• производится копирование базы данных;
• накладывается блокировка на базу данных;
• устанавливается метка (М2) в журнале транзакций;
• снимается блокировка с базы данных;
• копируются все транзакции между метками М1 и М2.

Алгоритм, таким образом, позволяет сохранить информацию, из которой можно восстановить базу данных в рабочем состоянии. Записанный выше алгоритм позволяет сохранить данные на момент окончания резервного копирования. В некоторых СУБД резервное копирование носит более упрошенный характер. Так в СУБД PostgreSQL для резервного копирования используется утилита pg_dump. Данная утилита при копировании учитывает только те транзакции, которые на момент копирования были завершены. Для относительно небольших баз данных это вполне приемлемо.

Для больших же баз данных, создание резервных копий которых занимает слишком много времени, к концу процесса копирования мы получаем копию, которая может уже значительно отличаться от оригинала. Полное сохранение базы данных возможно также простым копированием файлов, из которых она состоит. В СУБД Oracle это называется холодным или автономным резервным копированием, которое осуществляется после остановки сервера баз данных. В MS SQL Server имеется операция отсоединения базы данных. После отсоединения файлы базы данных можно скопировать на устройство хранения. Затем базу данных можно снова подсоединить к серверу.

Инкрементальные резервные копии. Они делаются, если уже сделана полная резервная копия. Такая резервная копия содержит все изменения, которые произошли с момента последней полной резервной копии либо предыдущей инкрементальной резервной копии. Таким образом, если сделана полная резервная копия и N инкрементальных резервных копий, то для того чтобы восстановить базу данных, необходимо вначале восстановить базу данных из полной резервной копии, а потом последовательно из инкрементальных резервных копий. Удобство использования инкрементальных резервных копий заключается в том, что если их делать достаточно часто, они занимают небольшой объем внешней памяти. Кроме этого, и время их создания также невелико.

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

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

В качестве средства резервного копирования можно использовать также средства экспорта. Обычно в качестве инструмента экспорта выступает некоторая утилита командной строки (в Oracle, например, это утилита ехр). Такая утилита создает некоторый файл, содержащий информацию об указанной базе данных или ее отдельных объектов. Этот файл может содержать просто набор команд SOL, которые создают объекты базы данных и заполняют их содержанием, или же иметь какой-то другой формат. Для того чтобы превратить этот файл в рабочую базу данных, используется утилита импорта.

Таким образом, базу данных можно перенести на другой сервер той же СУБД или даже сервер баз данных другого типа (если имеется соответствующая утилита импорта). Но данный механизм можно использовать также и как резервное копирование, т. к. из файла экспорта можно восстановить базу в случае ее утери. Иногда процесс создания файла экспорта называют процессом логического резервного копирования. Процесс экспорта более гибок, чем собственно процесс резервного копирования, поскольку, как правило, позволяет экспортировать не только всю базу, но и ее отдельные объекты.