Архив за день: 24 октября, 2008

>Из жизни. SQL, Mirror & все-все-все.

>

Многие, думаю, знают, что такое зеркалирование в MS SQL Server. Я тоже в курсе, мало того, часто приходится с этой технологией работать. Спасает она меня регулярно, но и подводные камни иной раз подставляет такие, что мама не горюй.

Например, в какой-то момент случилась такая вот оказия:

Перестает отвечать сервер principal. Мы его перезагрузили, но переключение зеркала не произошло, хотя и присутствовал witness. Мало того, после перезагрузки основного сервера у меня на руках оказалось два Principal… Да-да. Именно так мне и писалось. Увы, скриншот снять не догадался – не до того было ;)

Но на одном хосте состояние всех баз было “Principal, Disconnected”, а на втором “Principal, Disconnected/In Recovery” , по-моему.

Ужасная ситуация. Я начал с одной самой маленькой базы – удалил ее с основного хоста и стал восстанавливать зеркало. Восстановил базу на сервер с NORECOVERY и попытался запустить зеркало. Мастер Configure Security отработал на ура, но при попытке запустить зеркалирование я получил ошибку…

image_4

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

image

Совсем упс… Пинговаться все пингуется, никаких внезапных файрволлов между узлами за те несколько минут, что все лежит тоже не появилось… Ужас. Совершенно непонятная ситуация, а время идет. Дальнейшее расследование нужного результата не давала. Даже нужный порт слушался на обоих серверах. Все было бессмысленным, надежда на премию таяла… И тут где-то промелькнула мысль, что, о ужас, строка, показанная на предыдущем скриншоте, может выдавать неверную информацию не только в случае, указанном в разделе Using The Error Log File For Diagnosis в последней ссылке. Итак, срочно запускаем

alter endpoint mirror state = started

на обоих серверах и – вуаля! Как только я это сделал, все старые базы просто-напросто заработали в штатном режиме зеркала, а та, где я успел убить зеркало дала его восстановить.

Глубинные причины происшедшего мне непонятны пока – расследование все еще ведется, но сам результат уже почти устраивает ;)

>“Ну да, конечно”, или не полагайтесь на средства защиты сверх меры. Часть 7.

>

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

image Как говорится – последняя надежда. Да, если Вас взломали, уничтожили серверную или просто пользователь легким движением руки отправил важные для бизнеса документы в утиль («совершенно случайно нажал shift и delete одновременно сразу после ctrl+A…» (c)), то остается один шанс – резервная копия, она же уже прочно вошедшее в нашу лексику слово бекап. Казалось бы, чего проще, залил раз в неделю (в месяц, в день, в час, в 15 минут…) резервную копию на ленту, CD, DVD, винчестер и живи спокойно. Однако и тут выясняется, что есть над чем подумать – неправильная стратегия может привести к тому, что последняя надежда может оказаться кладбищем самой себя. Прямо таки скажем, могилой. Как? Легко!

Пример 1: Вы просто заливаете бекапы, не проверяя их, и забываете на своем рабочем столе. В итоге, в момент, когда приходит час «Ч» Ваши носители оказываются залиты кофе или потеряны. А еще на них нет меток что и на чем записано, и, пока Вы перетряхиваете их содержимое, Ваш бизнес медленно, но верно умирает вместе с надеждами встретить старость на этом теплом месте. =(

Пример 2: Вы ни разу не пытались произвести тестовое восстановление систем. А когда пришло время восстанавливать их «в бою» выяснилось, что:

1) нужной копии нет под рукой, и никто не знает, как ее найти.

2) Когда копия находится, Вы понимаете, что никогда не читали «disaster recovery guide» к этой системе и уж точно никто не написал инструкцию.

3) И как только нужный документ проштудирован (а время идет…) становится ясно, что именно нужная копия либо испорчена кофе, или имеет ошибки записи, или бекап производился по схеме, которая не дает возможности отката на нужное время.image

Пример 3: Ваши бекапы украдены (ага, с того самого стола). И только после обнаружения пропажи выясняется, что копирование производилось без шифрования. А то и вовсе пропажа не обнаружится. А что может сделать злоумышленник с резервной копией Вашего контроллера домена, рассказать может Саша Станкевич.

Ссылки на публикации серии.
Часть 1: вводная
Часть 2: антивирус
Часть 3: Firewall
Часть 4: SSL
Часть 5: VPN + обновления
Часть 6: процедуры и регламенты + принцип наименьших полномочий
Часть 7: резервное копирование
Часть 8: контроль доступа и биометрия
Часть 9: шифрование
Часть 10: UAC