Если ваша база данных сравнительно небольшая, вы можете выполнять лишь полное резервное копирование.
Недостаток стратегии полного резервного копирования состоит в том, что по сравнению с другими стратегиями она реализуется довольно медленно. Например, если вы каждую ночь выполняете полное резервное копирование базы данных объемом 100 Мбайт, то вы архивируете 100 Мбайт каждую ночь. Если же, наряду с пол-ным, вы используете дифференцированное резервное копирование, вам не придется еженощно резервировать все 100 Мбайт.
Основное преимущество стратегии лишь полного резервного копирования заключается в том, что процесс восстановления выполняется быстрее, чем в других стратегиях, поскольку в нем используется только одна копия. Например, если вы каждую ночь выполняете полное резервное копирование, и в четверг база данных выдает сбой вам нужно лишь восстановить полную резервную копию, сделанную в ночь на четверг.
Выполнение полного и дифференцированного восстановления
Если ваша база данных чересчур велика, чтобы каждую ночь выполнять полное резервное копирование, вы можете добавить в стратегию и дифференцированное резервное копирование. Стратегия полного/дифференцированного резервного копирования работает быстрее, чем исключительно полного копирования. Используя стратегию одного полного резервного копирования, вы каждый раз копируете всю базу данных. Как показано на рис. 20, при использовании стратегии полного/дифференцированого резервного копирования вы резервируете только изменения, сделанные в базе данных после полного резервного копирования, что выполняется быстрее, чем создание резервной копии всей базы данных.
Рис. 20. Дифференцированное резервное копирование выполняется быстрее, чем полное, поскольку записываются лишь те изменения базы данных, которые были сделаны после последнего создания полной резервной копии
Основной недостаток стратегии полного/дифференцированого резервного копирования заключается в том, что процесс восстановления выполняется медленнее, чем в стратегии лишь полного резервного копирования, поскольку полное/дифференцированное копирование требует создания нескольких резервных копий. Предположим, вывыполняете полное резервное копирование в ночь на понедельник и дифференцированное в остальные дни недели, а ваша база данных была повреждена в среду. Чтобы вернуть базу данных в устойчивое состояние, вам понадобится восстанавливать полную резервную копию, сделанную в понедельник, и дифференцированную копию, сделанную во вторник. Если база данных перестанет работать в четверг, вам придется восстанавливать резервные копии, сделанные в понедельник и среду.
Еще один недостаток, о котором следует знать, заключается в том, что дифференцированное резервное копирование, также как и полное, не очищает журнал транзакций. Если вы хотите использовать эту стратегию, вам придется очищать журнал транзакций вручную путем создания его резервной копии с использованием предложения TRUNCATEONLY.
Полное резервное копирование и копирование журнала транзакций
Еще одна стратегия, которую следует рассмотреть независимо от размеров базы данных, это стратегия комбинации полного резервного копирования и копирования журнала транзакций. Этот подход имеет несколько преимуществ. Во-первых, это самый лучший метод хранения журналов транзакций в чистоте, поскольку это единственный тип резервного копирования, который автоматически очищает старые транзакции из журналов.
Этот метод также обеспечивает большую скорость создания резервных копий. Например, вы можете выполнить полное резервное копирование в понедельник и выполнять резервное копирование журнала транзакций три-четыре раза в день в течение недели. Это возможно, поскольку SQL Server выполняет оперативное резервное копирование, а журнал транзакций копируется быстро (пользователи этого практически не заметят).
Резервное копирование журнала транзакций является также единственным типом резервного копирования, позволяющим выполнять восстановление к состоянию на определенный момент времени. Вы можете спросить: "Как часто мне этим пользоваться?". Если в компании есть ненадежный человек, то имеет смысл время от времени использовать эту возможность, чтобы в случае необходимости она оказалась под рукой.
Недостаток этой стратегии состоит в том, что процесс восстановления выполняется немного медленнее, чем при использовании полного/дифференцированного резервного копирования. Причина в том, что нужно восстановить больше резервных копий, и каждый раз при добавлении новой работы в процесс он становится медленнее. Предположим, к примеру, что вы выполняете полное резервное копирование в понедельник и копирование журналов транзакций три раза в день (в 10:00, 14:00 и 18:00) на протяжении недели. Если ваша база данных перестанет функционировать во вторник в 15:00, то вам потребуется восстановить полную резервную копию, сделанную в понедельник, а также резервные копии журнала транзакций, сделанные во вторник в 10:00 и 14:00. Однако если база данных откажет в четверг в 15:00, вам придется восстановить полную резервную копию, сделанную в понедельник, а также все резервные копии журнала транзакций, сделанные во вторник, среду и четверг перед сбоем. Таким образом, хотя этот тип резервного копирования, на первый взгляд, должен работать быстрее, процесс восстановления может замедляться. В принципе, вы можете комбинировать все три типа резервного копирования.
Полное, дифференцированное резервное копирование и копирование журнала транзакций
Если вы комбинируете все три типа резервного копирования, то получите самые лучшие результаты. Процессы резервного копирования и восстановления все еще будут выполняться относительно быстро, и у вас появится преимущество восстановления базы данных к конкретному моменту времени. Предположим, что вы осуществляете полное резервное копирование в понедельник, копирование журнала транзакций каждые четыре часа (10:00, 14:00 и 18:00) на протяжении дня и дифференцированное резервное копирование каждую ночь. Если база данных выходит из строя, вам потребуется лишь восстановить полную резервную копию, сделанную в понедельник, дифференцированную резервную копию, сделанную в ночь перед сбоем, и последнююкопию журнала транзакций, сделанную до момента выхода сбоя. Такой метод довольно простой и быстрый. Однако ни одна из вышеуказанных стратегий не годится для гигантских баз данных, для которых следует использовать резервное копирование группы файлов.
