|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Ruslan Bikmetov 2:5020/400 05 Mar 2001 18:15:53 To : All Subject : Re: безопасность превыше всего? -------------------------------------------------------------------------------- Tolik Tentser пишет в сообщении <4404atgikeq1hi24jgdnjnree5gpj9q9ba@4ax.com> ... >> Андрей вообщем-то дело говорит, хотя высказывания несколько радикальные :) >Бред он говорит. >БД на SQL-сервере без наличия бэкапа рассматривать просто незачем - >надо просто немедленно уволить админа. Могут существовать проблеммы с самими бакапами, он может оказаться битым в силу тех или иных причин. По недосмотру админа, либо из-за глюков железа. Что может еще увеличить размер потерянных данных. Тока не нужно говорить, что не бывает такого Бывает, сам видел :-)) >При наличии же (регулярного) бэкапа - стоимость данных равна: >стоимость_набитого_от_последнего_бэкапа + >стоимость_простоя_на_время_подъема_бэкапа >Как правило - это 10 минут - час неработы фирмы (отдела) Ты бывал в подобных ситуациях? Дело в том, что специфика рассчетов, как уже отмечалось, реальное время. Система не может быть запущена, без востановления (набивания) минимума недостоющих данных, то есть пока счета клиентов не станут вновь актуальными. Пересчет задним числом чреват. >> Про бэкапы, резервное копирование и прочее я вкурсе, вообщем-то все в >>курсе... конечно оно было, но... :( >Ага, поэтому, вместо того, чтобы потратить 10 минут на то, чтобы >зашедулить бэкап - надо было построить кластер, который бы позволил >(хотя, реально - все равно бы не позволил) этого бэкапа не делать. Про кластер я вообщем-то ничего не говорил :)))) А с бакапами бывают свои проблемы. Дело конечно решается прямыми руками админа, но как часто бывает админ в России больше чем админ :) Иногда просто нет времени на всяческие профилактические работы на сервере. Что повышает вероятность утери данных. Кстати моя изначальная посылка была, что данные объемом несколько сот мегабайт это уже большая ценность, что говорить о гигабайтных базах. >>Одной из причин >>подобных проблем могут быть акты сабботажа со стороны пользователей. >>Как в современных SQL серверах можно защититься от подобного? >Hа 100% задачу решает трехзвенная архитектура. >У пользователей просто нету прямого доступа к серверу. Hа сколько сложно перевести существующию 2-ух звенную систему на трехзвенную??? И имеет ли это таинство смысл? Может проще создать все заново? Где можно почитать теорию и практику??? -- Ruslan --- ifmail v.2.15dev5 * Origin: OAO Kirovelectrosviaz (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/6638e4cc8d35.html, оценка из 5, голосов 10
|