Product SiteDocumentation Site

9.10. Резервное копирование

Создание резервных копий — одна из основных обязанностей любого администратора, но это сложная задача, для которой используются мощные инструменты, которыми подчас непросто овладеть.
Существует множество программ, таких как amanda, bacula, BackupPC. Это клиент-серверные системы, имеющие много опций, настройка которых довольно сложна. Некоторые из них предоставляют дружественный веб-интерфейс, чтобы компенсировать это. Но в Debian есть десятки других программ для резервного копирования на все возможные случаи, в чём можно легко убедиться с помощью apt-cache search backup.
Вместо того, чтобы описывать некоторые из них, в этом разделе будут приведены рассуждения администраторов Falcot Corp при определении ими стратегии резервного копирования.
В Falcot Corp резервные копии нужны для двух целей: восстановления ошибочно удалённых файлов и быстрого восстановления любого компьютера (сервера или рабочей станции) после отказа жёсткого диска.

9.10.1. Резервное копирование с помощью rsync

Поскольку резервные копии на магнитной ленте сочли слишком медленными и дорогими, данные будут сохраняться на жёстких дисках на выделенном сервере, на котором использование программного RAID (см. Раздел 12.1.1, «Программный RAID») защитит данные от сбоя диска. Резервные копии отдельных настольных компьютеров не делаются, но пользователи извещены, что будет выполняться резервное копирование их учётных записей на файловом сервере их отдела. Команда rsync ежедневно используется для резервного копирования этих серверов.
Доступное дисковое пространство не позволяет реализовать полное ежедневное резервное копирование. Поэтому команде rsync предшествует дублирование содержимого предыдущей резервной копии с помощью жёстких ссылок, что предупреждает использование слишком большого дискового пространства. Процесс rsync затем заменяет только те файлы, которые были изменены с момента создания предыдущей копии. С помощью этого механизма огромное число резервных копий можно хранить на небольшом пространстве. Поскольку все резервные копии немедленно становятся доступными (например в разных каталогах на сетевом ресурсе), можно быстро выполнять сравнения между двумя заданными датами.
Этот механизм резервного копирования легко реализуется с помощью программы dirvish. Она использует хранилище резервных копий («bank» — «банк» — в её терминологии), в котором размещает копии наборов файлов резервных копий с временными метками (в документации dirvish эти наборы называются «vaults» — «подвалы»).
Основные настройки хранятся в файле /etc/dirvish/master.conf. Он определяет местоположение пространства для резервных копий, список управляемых «подвалов» и значения сроков хранения резервных копий по умолчанию. Остальные настройки находятся в файлах bank/vault/dirvish/default.conf и содержат конфигурацию соответствующего набора файлов.

Пример 9.3. Файл /etc/dirvish/master.conf

bank:
    /backup
exclude:
    lost+found/
    core
    *~
Runall:
    root    22:00
expire-default: +15 days
expire-rule:
#   MIN HR    DOM MON       DOW  STRFTIME_FMT
    *   *     *   *         1    +3 months
    *   *     1-7 *         1    +1 year
    *   *     1-7 1,4,7,10  1
В настройке bank указывается каталог, в котором хранятся резервные копии. Настройка exclude позволяет указать файлы (или типы файлов), которые не должны включаться в резервную копию. Runall — это список наборов файлов для резервного копирования с временной меткой для каждого набора, что позволяет установить корректную дату копии, если резервное копирование ну запускается периодически в определённое время. Нужно указать время, непосредственно предшествующее времени запуска (по умолчанию в Debian это 22:04, в соответствии с файлом /etc/cron.d/dirvish). Наконец, настройки expire-default и expire-rule определяют политику хранения резервных копий. В приведённом выше примере резервные копии, созданные в первое воскресенье каждого квартала, хранятся вечно, созданные в первое воскресенье каждого месяца — удаляются через год, а созданные в другие воскресенья — через 3 месяца. Прочие ежедневные резервные копии хранятся 15 дней. Порядок правил имеет значение: Dirvish применяет последнее подходящее правило или expire-default, если ни одно из других правил expire-rule не подходит.

Пример 9.4. Файл /backup/root/dirvish/default.conf

client: rivendell.falcot.com
tree: /
xdev: 1
index: gzip
image-default: %Y%m%d
exclude:
    /var/cache/apt/archives/*.deb
    /var/cache/man/**
    /tmp/**
    /var/tmp/**
    *.bak
В вышеприведённом примере определяется набор файлов для резервного копирования: это файлы на машине rivendell.falcot.com (для копирования локальных данных нужно просто указать имя локальной машины в том виде, как оно отображается командой hostname), а именно файлы корневого каталога (tree: /) за исключением тех, которые перечислены в exclude. Резервная копия будет ограничена содержимым одной файловой системы (xdev: 1). В неё не войдут файлы из других точек монтирования. Будет создан индекс сохранённых файлов (index: gzip), и имя образа будет соответствовать текущей дате (image-default: %Y%m%d).
Существует множество других опций, и все они описаны на странице руководства dirvish.conf(5). Когда конфигурационные файлы подготовлены, необходимо инициализировать каждый набор файлов с помощью команды dirvish --vault vault --init.После этого при ежедневном вызове dirvish-runall будет автоматически создаваться новая резервная копия после удаления устаревшей.

9.10.2. Восстановление машин без резервных копий

На настольных компьютерах, резервное копирование которых не выполняется, будет легко переустановить программное обеспечение со специальных DVD-ROM, подготовленных с помощью Simple-CDD (см. Раздел 12.3.3, «Simple-CDD: решение «всё-в-одном»»). Поскольку при этом происходит установка с нуля, все настройки, которые могли быть сделаны после предыдущей установки, теряются. Это не страшно, поскольку все системы привязаны к центральному каталогу LDAP с учётными записями, и большая часть настольных приложений предварительно настроены благодаря dconf (более подробно об этом см. в Раздел 13.3.1, «GNOME»).
Администраторы Falcot Corp осознают ограничения своей политики резервного копирования. Поскольку они не могут защитить сервер резервных копий так же хорошо, как магнитную ленту в несгораемом шкафу, они установили его в отдельной комнате, чтобы стихийное бедствие, такое как пожар в серверной комнате, не уничтожило резервные копии вместе со всем остальным. Кроме того, они делают инкрементальные резервные копии на DVD-ROM раз в неделю — туда включаются только те файлы, которые были изменены со времени предыдущего резервного копирования.