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

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

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

www.vr-online.ru

Резервное копирование и восстановление данных

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

Политика

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

Все зависит от того, какие данные хранятся в базе, насколько страшной является их потеря и как сильно можно получить по заднему месту за простой в работе из-за восстановления после сбоя. На простой можно наплевать, если модно быть уверенным, что хотя бы 95% данных восстановится. Большинство боссов на это не обидятся, а наоборот, обрадуются, что данные живы, а не канули в лету.

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

Настройки

Большинство серверов хранят все настройки прямо в базе данных в виде системных таблиц или в виде отдельной базы данных. В MS SQL Server вся служебная информация хранится в базе данных Master. Здесь есть информация о правах доступа, объектах базы данных, пользователях и многое другое. Многие специалисты рекомендуют делать резервную копию этой базы после каждого изменения каких-либо объектов метаданных. В принципе, это несложно и недолго, потому что Master имеет не слишком большой размер, его резервная копия будет делаться достаточно быстро и займет не очень много места.

Однако журнал не рекомендует заморачиваться с этой ерундой :). На MS SQL Server 2000 уже не раз проверено: если файлы базы данных, а лучше и журнал транзакций доступны и не были разрушены, то их легко скопировать на другую машину и просто подключить (Attach database) к другому серверу MS SQL Server. Для этой операции журнал транзакции желателен, но не обязателен. База данных будет работать как родная.

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

Методы резервирования

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

1. Simple - самая простая модель. При ее использовании после каждой резервной копии высвобождается место на диске, которое занимал бы журнал транзакций. Значит, файл журнала не будет увеличиваться в размерах до бесконечности.