Спасение утопающих – дело рук, а не ног

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

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

Сбой системы

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

В работе администратора самое главное - не паниковать, а сразу после катастрофы грамотно оценить обстановку и сделать правильные выводы.

В случае непредвиденной ситуации и при использовании модели Full или Bulk-Logged можно попытаться восстановить все данные и вернуть ее в любом состоянии до сбоя. Продвинутые админы держат файлы данных и журнала на разных дисках, а оба они накрываются редко. Если потеряли диск с журналом, то делаем полную копию данных и восстанавливаем на новом винчестере. А если полетел диск с данными, то прежде чем начать процесс восстановления данных, попытаемся зарезервировать журнал, в котором хранится информация о последних изменениях данных. Только после этого можно приступать к восстановлению работы сервера на новом винчестере, и данные будут восстановлены полностью.

Оригинальность - сестра хакера

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

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

А что если в эту систему поставить еще один сервер, который тоже будет участвовать в репликации, но не будет использоваться в работе? Получится реальный сервер, который будет железной резервной копией. Будут проблемы - можно в считанные секунды превратить резервный сервер в рабочий, и он будет содержать реально работающие данные. Правда, свежатина этих данных зависит от настроек репликации (как восстановление от настроек резервирования).

Итого

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

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