Спасение утопающих – дело рук, а не ног

Фленов Михаил aka Horrific

Спецвыпуск: Хакер, номер #052, стр. 052-078-4

Частота резервирования

Вечная проблема - частота создания резервных копий. Все зависит от количества данных, частоты их обновления и их же важности. Расскажу о разных вариантах сочетания всего этого.

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

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

Если данных много и изменения появляются постоянно, то тут уже нужна модель Full или Bulk-Logged. Полную резервную копию делаем в нерабочее время, а в рабочее время (пару раз в день или даже каждые два часа) можно делать резервирование журнала.

Когда в базе данных очень часто происходят массовые загрузки или изменения, когда данных мало, используй модель Simple. Если данных много, то полезнее будет Bulk-Logged, а не Full. Это позволит увеличить производительность и уменьшить журнал транзакций.

Вне зависимости от выбранной частоты резервирования я всегда делаю внеплановые копии в следующих случаях:

- до и после массового обновления данных или загрузки (полная резервная копия по возможности);

- после изменения структуры данных или добавления/удаления индексов (полная резервная копия по возможности);

- перед праздниками, когда офис уходит на несколько дней на заслуженную попойку (полная резервная копия обязательно);

- до и после осуществления репликации данных.

Восстановление данных

Восстановление данных зависит от метода резервирования. Если делали полную копию, то достаточно просто ее восстановить. Если производилось дифференцированное резервирование, то сначала нужно восстановить последнюю полную копию, а после нее - дифференцированную.

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

При восстановлении журнала на закладке Options нужно оставлять возможность восстановить другие журналы, если они есть. Для этого выбираем переключатель Leave database nonoperational but able to restore additional logs или Leave database read-only and able to restore additional logs. Если восстанавливаешь последний журнал, то выбирай Leave database optional, иначе база будет недоступна для изменений. После восстановления этой опцией больше журналы восстанавливать нельзя.