|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Tolik Tentser 2:5020/400 04 Mar 2001 09:52:20 To : All Subject : Re: безопасность превыше всего? -------------------------------------------------------------------------------- Hi, Ruslan Bikmetov /Tr! В чреве акулы, пойманной Sat, 03 Mar 2001 09:20:28 +0300, дети капитана Гранта нашли письмо на тему 'безопасность превыше всего?': > >> TT> И сколько реализация твоих нормальных требований стоит ? > >> Во всяком случае дешевле утерянных даных. > TT> Ты считал ? Hу хоть раз ? > TT> Да таки для "всякого случая" > > Андрей вообщем-то дело говорит, хотя высказывания несколько радикальные :) Бред он говорит. БД на SQL-сервере без наличия бэкапа рассматривать просто незачем - надо просто немедленно уволить админа. При наличии же (регулярного) бэкапа - стоимость данных равна: стоимость_набитого_от_последнего_бэкапа + стоимость_простоя_на_время_подъема_бэкапа Как правило - это 10 минут - час неработы фирмы (отдела) Мало, ничтожно мало систем, в который эта сумма настолько велика, что требует дополнительных мер по повышению надежности сверх штатного. И именно эти системы называются 24х7 и требуют действительно сложных решений. Кстати - неоднократно приходилость веселиться над разработчиками, которые учиняли едва не кластер, горячее резервирование и замену всего, что можно - но не решели банальную проблему с электропитанием (резервный генератор), которая есть основная причина остановок и которую UPS, конечно не решит. Рассуждвть же, что сбой сервера может привести > Про бэкапы, резервное копирование и прочее я вкурсе, вообщем-то все в >курсе... конечно оно было, но... :( Ага, поэтому, вместо того, чтобы потратить 10 минут на то, чтобы зашедулить бэкап - надо было построить кластер, который бы позволил (хотя, реально - все равно бы не позволил) этого бэкапа не делать. >А теперь вопрос практически в топик :) Hе секрет, что организации имеющие >системы работающие в реальном времени или близкие к ним при остановке на сутки >либо несколько суток могут понести существенные убытки. Одной из причин >подобных проблем могут быть акты сабботажа со стороны пользователей. >Как в современных SQL серверах можно защититься от подобного? Hа 100% задачу решает трехзвенная архитектура. У пользователей просто нету прямого доступа к серверу. Hу и бэкап, бэкап .... Bye ... Тенцер А.Л. tolik@katren.nsk.ru ICQ 15925834 --- ifmail v.2.15dev5 * Origin: AO Katren (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/20808d5e3740.html, оценка из 5, голосов 10
|