|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Tolik Tentser 2:5020/400 05 Mar 2001 18:50:40 To : All Subject : Re: безопасность превыше всего? -------------------------------------------------------------------------------- Hi, Ruslan Bikmetov! В чреве акулы, пойманной Mon, 5 Mar 2001 14:15:53 +0000 (UTC), дети капитана Гранта нашли письмо на тему 'Re: безопасность превыше всего?': >>> Андрей вообщем-то дело говорит, хотя высказывания несколько >радикальные :) >>Бред он говорит. >>БД на SQL-сервере без наличия бэкапа рассматривать просто незачем - >>надо просто немедленно уволить админа. > >Могут существовать проблеммы с самими бакапами, он может >оказаться битым в силу тех или иных причин. По недосмотру админа, >либо из-за глюков железа. Что может еще увеличить размер >потерянных данных. Тока не нужно говорить, что не бывает такого >Бывает, сам видел :-)) Админа - уволить. Hахрен. С волчьим билетом. В дворники. Ты ж пойми, что все эти танцы с бэкапами, вплоть до достижения ими приемлемого уровня стабильности - должны производиться ДО рассмотрения вопроса о кластерах и т.п. И одно, кстати, другого абсолютно не заменяет. >>При наличии же (регулярного) бэкапа - стоимость данных равна: >>стоимость_набитого_от_последнего_бэкапа + >>стоимость_простоя_на_время_подъема_бэкапа >>Как правило - это 10 минут - час неработы фирмы (отдела) > >Ты бывал в подобных ситуациях? Hет. Hо рассматривал их. >Дело в том, что специфика >рассчетов, как уже отмечалось, реальное время. Система не может >быть запущена, без востановления (набивания) минимума недостоющих >данных, то есть пока счета клиентов не станут вновь актуальными. >Пересчет задним числом чреват. Это и есть стоимость_набитого_от_последнего_бэкапа >Про кластер я вообщем-то ничего не говорил :)))) А с бакапами >бывают свои проблемы. Дело конечно решается прямыми руками >админа, но как часто бывает админ в России больше чем админ :) >Иногда просто нет времени на всяческие профилактические работы >на сервере. Что повышает вероятность утери данных. Выгнать из админов. Хороший админ - или должен потребовать, чтобы все было как положено - или уйти. >Кстати моя изначальная посылка была, что данные объемом несколько >сот мегабайт это уже большая ценность, что говорить о гигабайтных базах. Тем более не понимаю, что в этих условиях означает "Иногда просто нет времени на всяческие профилактические работы на сервере" >>>Одной из причин >>>подобных проблем могут быть акты сабботажа со стороны пользователей. >>>Как в современных SQL серверах можно защититься от подобного? >>Hа 100% задачу решает трехзвенная архитектура. >>У пользователей просто нету прямого доступа к серверу. > >Hа сколько сложно перевести существующию 2-ух звенную систему >на трехзвенную??? В простейшем случае - банальный транслятор запросов делается тривиально >И имеет ли это таинство смысл? Depends on ... Bye ... Тенцер А.Л. tolik@katren.nsk.ru ICQ 15925834 --- ifmail v.2.15dev5 * Origin: AO Katren (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/20805438ebe6.html, оценка из 5, голосов 10
|