Чтение онлайн

Итак, сколько носителей информации нам понадобится, с какой частотой и как их использовать? Это зависит от многих факторов:

□ хранящаяся информация;

□ частота изменения данных;

□ наличие возможности ручного восстановления большого количества потерянных данных;

□ максимальное время простоя (недоступности) сервера;

□ категория наиболее часто меняющихся данных.

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

Основные директории, которые должны резервироваться:

□ /etc — содержит конфигурационные файлы;

□ /home — пользовательские файлы;

□ директория, содержащая Web-файлы.

В остальных каталогах администраторы редко держат документы или файлы, требующие дополнительного копирования. Программы из директории /bin или /usr нет смысла дублировать, потому что их легко переустановить, особенно если сохранена вся конфигурация.

К нечасто изменяемым файлам можно сразу отнести конфигурационные файлы (директория /etc). В этом каталоге массовые корректировки происходят на этапе установки сервера. Затем компьютер может работать годами, и изменения происходят в случае обновления программ или внесения каких-то поправок.

Для хранения конфигурации хватит даже самого небольшого носителя с невысокой скоростью. Единственное требование к нему — должна быть возможность перезаписи. Я для этих целей использую ZIP- и JAZ-диски. В заархивированном виде достаточно одной дискеты.

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

При восстановлении данных необходимо всегда начинать с конфигурации, в первую очередь с файлов /etc/passwd и /etc/shadow. Если этого не сделать, то ни одна программа не сможет установить правильные права доступа.

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

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

Часто изменяемыми могут быть базы данных и основные файлы и документы пользователей (директория /home), которые корректируются каждый день. Их резервные копии можно и нужно создавать ежедневно. Если процесс копирования отнимает слишком много времени, то следует это делать после рабочего дня или в обеденный перерыв, когда нагрузка на сервер ниже. Чтобы не сидеть над компьютером в такие моменты, можно создать сценарии, которые будут выполняться по расписанию. Если производить резервирование два раза в день (в обеденный перерыв и в конце рабочего дня), то в случае аварии вы рискуете потерять изменения только за полдня (с момента резервирования до сбоя системы).

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

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

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

□ в конце недели производится полное копирование директории /home;

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

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

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

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

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

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