Издательский дом ООО "Гейм Лэнд"СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #62, ЯНВАРЬ 2006 г.

Админский back-up

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

Спецвыпуск: Хакер, номер #062, стр. 062-036-7


Для подобных данных я использую семь перезаписываемых носителей. Каждый из них я называю именами дней недели: в понедельник копирую данные на диск с надписью «Понедельник», во вторник пишу на диск «Вторник» и т.д. Помимо этого, каждый понедельник все данные записываются на одноразовый носитель типа CD-R или DVD-R.

Часто, но не все

Далеко не все пользовательские файлы изменяются ежедневно, в основном они могут храниться без изменений годами. Чтобы не тратить каждый раз время на неизмененные данные, можно использовать программы, которые копируют только измененные. Самый простой вариант — выбрать все файлы, дата изменения которых попадает на определенный промежуток времени.

При использовании такой политики можно действовать следующим методом:

- производить полное копирование директорий с пользовательскими данными в конце недели;

- измененные файлы сохранять каждый день.

В случае аварии восстановление должно происходить точно в той же последовательности, в которой происходило резервирование. Сначала восстанавливается полная копия. Потом последовательно возвращаем на родину все файлы из резервных копий, в которых находишь изменения. Если последовательность нарушена, возникает риск перезаписать не новый файл, а старый.

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

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

Благодаря сохранению изменений (каждый день изменяется не так уж много файлов), резервирование будет происходить достаточно быстро и его можно делать в процессе работы сервера. Однако в данном случае мы рискуем испортить файлы. Допустим, есть два жестко связанных файла, информация в которых должна быть взаимосвязанной. Например, если в один файл записываются данные, то такие же данные должны быть добавлены и в «другой». Если во время копирования одного файла изменяется «другой» файл, то в резервную копию первый попадает измененным, а второй — нет. При восстановлении возникнут серьезные проблемы, потому что нарушится целостность, а за ней, возможно, и работа после восстановления.

Периодичность

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

Назад на стр. 062-036-6  Содержание  Вперед на стр. 062-036-8