Hello, Dmitri! You wrote on Mon, 03 Jul 2006 20:00:03 +0400: DK> Контора с 90 тысяч зарегистрированных пользователей, DK> и существовавшая 3 года, вынуждена закрыть свой бизнес: DK> произошел сбой дисков, при некорректном ведении бэкапов. DK> И все. База данных умерла, данных не осталось никаких, вообще.
DK> http://www.techcrunch.com/2006/06/29/couchsurfing-deletes-itself-shuts-down/ -- Я сам недавно по таким граблям прошел месяц назад. Хотя всем и всегда твержу: "Из всех операций для нас важнейшей является BACKUP". Не сбой дисков, свои шаловливые ручки, но... напишу, чтоб другие так не делали. БД - учет ссуд сотрудникам предприятия. В базе (и в софте) изменения были, кроме действительно нужных изменений понастроил FK ON DELETE CASCADE. Когда все было готово, решил еще таблицу персонала обновить (закачать из БД отдела кадров). IBDataPump, "Empty Destination Tables" - включено. При удалении данных по персоналу грохнулись данные по ссудным договорам, связанным по FK с персоналом (каскад, чтоб его!...) и по платежам, связанным с упомянутыми договорами. Сначала произвел операцию на машине разработчика (своей), ошибок нет, ура! Тут же не глядя повторил на боевой базе (идиот!..). И для полноты картины сделал и там, и там backup/restore (backup -c -r...). И только после этого заглянул в данные... Спасло положение то, что ежемесячно делался экспорт проводок в бухучет и экспорт для удержаний из зарплаты. По этим данным все и восстановил (неделю угробил). Для себя резюме: 1. НИКОГДА не использовать backup -c -r... (хотя раньше и другим это говорил). 2. По возможности избегать FK ON DELETE CASCADE. 3. Хранить всю историю BACKUP'ов, на разных носителях. Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venix<angry_dog>tn<dot>tob<dot>ru PS. Потом нашел в папке, где лежит приложение, backup, который сделал до начала всех изменений и в сторонку положил. --~--~---------~--~----~------------~-------~--~----~ -~----------~----~----~----~------~----~------~--~---
