Резервное копирование с применением механизма репликаций
Не секрет, что любая автоматизированная система работает до первого сбоя. Сбой произойдет всегда, как бы все не казалось надежным. Вопрос стоит лишь в быстроте устранения сбоя, в количестве потерянной при сбое информации и в мере ответственности эксплуатирующих ее лиц за последствия сбоя.
В документации упоминаются следующие способы резервного копирования баз данных:
· выгрузка на стример,
· выгрузка на файл-сервер,
· использование репликаций для поддержки резервных реплик.
По первому и второму вариантам, прежде чем начинать резервное копирование, необходимо остановить сервер Notes. Если же остановка "рабочего" сервера недопустима, предлагается "завести" выделенный сервер, "несущий" реплики баз всех рабочих серверов, а собственно резервное копирование выполнять на нем.
По третьему варианту также необходим отдельный архивный сервер, "несущий" реплики баз со всех рабочих серверов. Рассмотрим настройки в списках управления доступом (ACL) реплик баз, рекомендуемые в этой ситуации:
· ACL "рабочей" реплики:
· -Default- - редактор с правом удалять документы,
· архивный сервер - читатель,
· рабочий сервер - менеджер с правом удалять документы;
· ACL архивной реплики:
· -Default-
- читатель,
· архивный сервер - менеджер с правом удалять документы,
· рабочий сервер - дизайнер или редактор.
Кроме того, в репликационных установках находящихся на архивном сервере реплик баз следует выбрать опцию Do not send deletions made in this replica to other replicas.
Еще один способ решения проблемы резервного копирования состоит в использовании кластеров из серверов Notes (см. 10.4).
