Корпоративный бэкап

ЗАРАЗА

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

1. Процесс восстановления многогигабайтной базы занимает длительное время. Насколько длительное — определить невозможно.

2. Клиенты не могут воспользоваться услугами, и, вместо того чтобы восстанавливать базы данных, приходится искать временное решение, которое не заступорилось предоставление хотя бы основных услуг.

3. Весь этот процесс сопровождается постоянными звонками доброжелателей из различных подразделений: «Да у вас проблемы с базой! Удачи!»

4. Никто не знает, что делать, чтобы реанимировать базу и в целом систему после процесса восстановления. Приходится читать документацию.

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

6. На коленке без тестирования написаны необходимые утилиты, но вдруг выясняется, что часть записей оказалась продублирована и их необходимо вычистить.

Итог — процесс полного восстановления занял свыше пяти дней.

7. Еще через два дня происходит аналогичный сбой SCSI-драйвера :).

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

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

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

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