[26.09.2010] Катастрофа (пропали данные)

Luchnik> Это излечимо... В отличии от.

Да как же оно излечимо-то? Тему прочитал или только шапку по диагонали глянул?

Luchnik> Может быть... А может быть со стороны оно кажется в другом свете...

Со стороны часто многое кажется иначе, чем изнутри. Особенно, когда нет личного опыта работы в сравниваемых системах (или я тут ошибся? )

Luchnik>> Это излечимо... В отличии от.
Balancer> Да как же оно излечимо-то? Тему прочитал или только шапку по диагонали глянул?

Я про то, что это принципиально можно доделать и починить. Хотя, конечно, "дорога ложка к обеду".

Luchnik>> Может быть... А может быть со стороны оно кажется в другом свете...
Balancer> Со стороны часто многое кажется иначе, чем изнутри. Особенно, когда нет личного опыта работы в сравниваемых системах (или я тут ошибся? )

Есть, но сильно разный по объёму.

Luchnik> Я про то, что это принципиально можно доделать и починить.

Так и сломавшийся бэкап можно доделать и починить. И даже не принципиально, а практически И уж тем более сделать невозможным удаление БД (и даже запрет на удаление отдельных записей) на продакшн-сервере.

Luchnik>> Я про то, что это принципиально можно доделать и починить.
Balancer> Так и сломавшийся бэкап можно доделать и починить. И даже не принципиально, а практически И уж тем более сделать невозможным удаление БД (и даже запрет на удаление отдельных записей) на продакшн-сервере.

Э, нет... Если данные потёрты и бэкапа нет, то тут же всё - никакие чинки потерянные данные не вернут.

Алдан-3> Сильнее настораживает "сам" сломавшийся бакап.

Он не «сам» сломался. Само ничего не ломается. Как обычно — человеческий фактор. Были сменены права на директорию, куда складывались файлы бекапа, а потом, видно, благополучно об этом забыли. Пруф

Алдан-3> И как такое контролировать то?

Уведомлениями. Если бы сразу были сделаны уведомления о таких важных штуках на jabber/e-mail, то после первого же фейла можно было бы принять меры. Но… В общем, пример Ромы — другим админам наука.

Алдан-3> Сильнее настораживает "сам" сломавшийся бакап.

Не сам. Я уже писал где-то выше - тюнил систему на предмет доступа и снял юзеру backup права записи в каталог /data/backup. А систем самоконтроля на Авиабазе не вводил на тему отлавливать актуальность бэкапа.

Алдан-3> В системе таких размеров ведь не только бакап может "сам" случайно отвалиться и неизвестно сколько пролежать отпавшим.

Безусловно. Вон, после отката форума БД поисковая оказалась неактуальной и высыпала ошибки. Никто, ведь, не сказал об этом, пока сам сегодня не заметил.

Алдан-3> И как такое контролировать то?

Никак. В сложных системах 100%-й безошибочности избежать нельзя. Вон, у меня Ютуб по паре раз в неделю отваливается (перестаёт работать сервер статики), а работающий AudioSwap я, вообще, ещё ни разу не видел

yacc> Я что-то вот что не понимаю - а Линукс-то ( у господ "наезжающих" ) тут причем?

Похоже, такая лютая ненависть к Linux'у, что к месту и не к месту поминают

HolyBoy> Уведомлениями. Если бы сразу были сделаны уведомления о таких важных штуках на jabber/e-mail, то после первого же фейла можно было бы принять меры.

Тут всё сложнее. Обнаружить непредвиденную ошибку крайне сложно. Это уже ИИ нужен Просто в логи смотреть смысла нет, логгинг бэкапный итак забит мусором.

Вот когда на грабли уже один раз наступишь - тогда можно сделать проверку на эти грабли. Но никто не отменяет того, что завтра попадутся другие грабли...

Balancer> Вот когда на грабли уже один раз наступишь - тогда можно сделать проверку на эти грабли. Но никто не отменяет того, что завтра попадутся другие грабли...

просто многооконный тырфейс суть зло. я с секретарём раза общнулся в аське жены - похожий эпик фейл

Balancer> Похоже, такая лютая ненависть к Linux'у, что к месту и не к месту поминают
Если это из-за траблов AMD - то еще можно пошутить.
Но если это БД... И MS SQL ты совершенно легко можешь уложить Удаленно, через isql.

yacc> Если это из-за траблов AMD - то еще можно пошутить.

Ну, как бы очевидно, что ни ОС, ни железо, ни даже web-подсистема тут совершенно не при чём. Разве что очень косвенно можно обвинить хостера, из-за того, что по его вине кабель питания несколько раз отходил, после чего приходилось много лихорадочно ковыряться в файловой системе, а потом всё чистить, следствием чего и стал отказ бэкапа. Но даже такая цепочка слишком уж длинная

yacc> Но если это БД... И MS SQL ты совершенно легко можешь уложить

Именно так Не говоря уже про том, что и под виндой бы я всё равно на том же MySQL сидел бы И в точно таком же phpMyAdmin...

Balancer> Тут всё сложнее. Обнаружить непредвиденную ошибку крайне сложно. Это уже ИИ нужен Просто в логи смотреть смысла нет, логгинг бэкапный итак забит мусором.

А зачем в логи? Вот, у меня давно настроена система бекапа bacula. Отчёты о сделавшихся бекапах я настроил тогда же. Типичный вид в папке для системных писем:

1. Bacula: Backup OK of backupsrv-fd Full дата
2. Bacula: Backup OK of mainserv-fd Differential дата
3. Bacula: Backup OK of gate-fd Differential дата

Бросил взгляд на заголовки и сразу всё видно. Дня 4 назад была проблема: Bacula: Backup Fatal Error of gate-fd Differential и я её сразу засёк. Посмотрел тело письма:

19-Сен 23:05 backupsrv-dir JobId 432: Start Backup JobId 432, Job=MailBackup.2010-09-19_23.05.00_23
19-Сен 23:05 backupsrv-dir JobId 432: There are no more Jobs associated with Volume "Diff-Mail-0010". Marking it purged.
19-Сен 23:05 backupsrv-dir JobId 432: All records pruned from Volume "Diff-Mail-0010"; marking it "Purged"
19-Сен 23:05 backupsrv-dir JobId 432: Recycled volume "Diff-Mail-0010"
19-Сен 23:05 backupsrv-dir JobId 432: Using Device "FileStorage"
19-Сен 23:35 gate-fd JobId 432: Fatal error: Failed to connect to Storage daemon: backupsrv:9103
19-Сен 23:35 backupsrv-dir JobId 432: Fatal error: Bad response to Storage command: wanted 2000 OK storage
, got 2902 Bad storage

 

и вспомнил, что я недавно крутил настройки фаерволла. Настроил фаерволл снова и всё заработало. Если окажется, что место для бекапов закончилось, то об этой проблеме я снова узнаю не в самый неприятный момент, а сразу.

Для почты у меня тоже сборный отчёт делается. Я каждый день просматриваю его по верхам: а, столько-то спама и тд и тп. Но если вдруг окажется, что писем за какой-то день было 0, то это повод посмотреть: а что это такое с почтовым сервером случилось-то?

И так со многими сервисами.

Balancer> Вот когда на грабли уже один раз наступишь - тогда можно сделать проверку на эти грабли. Но никто не отменяет того, что завтра попадутся другие грабли...

Да, ты прав, но стоит всё же соломку заранее класть, если есть возможность.

Всё-таки 19 августа - мистическая дата

HolyBoy> Вот, у меня давно настроена система бекапа bacula.

Надо будет посмотреть. Надеюсь, она делает MySQL-дамп без всяких хитростей и уже только потом пакует его, смотри диффы и т.п.? А то проблема ряда бэкап-систем, что я щупал в том, что они делают дамп, совмещая сразу и его обработку. И когда объём базы достигает 5-6Гб, дамп выливается не в минуту-две остановки работы сервера, а в 10-15 минут...

HolyBoy> Для почты у меня тоже сборный отчёт делается. Я каждый день просматриваю его по верхам: а, столько-то спама и тд и тп.

Ну, почту я благополучно перенёс на гугл-аппс

HolyBoy> Да, ты прав, но стоит всё же соломку заранее класть, если есть возможность.

Угу. Когда оно достаточно оправдано

Balancer> Разве что очень косвенно можно обвинить хостера, из-за того, что по его вине кабель питания несколько раз отходил, после чего приходилось много лихорадочно ковыряться в файловой системе, а потом всё чистить, следствием чего и стал отказ бэкапа. Но даже такая цепочка слишком уж длинная

Не, ты глянь как на Билли стрелки перевёл...

Balancer> Надо будет посмотреть. Надеюсь, она делает MySQL-дамп без всяких хитростей и уже только потом пакует его, смотри диффы и т.п.?

Не знаю. Я её для бекапа файлсервера и почты использую. Уже несколько раз пригождалось. Сразу скажу — сложная в настройке. Маны пришлось покурить. Зато теперь всё работает само. Добавление новых объектов и хостов по шаблону несложно.

Подозреваю, скоро понадобится делать бекапы СУБД, но уже подошёл PostgreSQL 9, там с бекапами вроде без особых проблем должно быть из коробки.

Balancer> Ну, почту я благополучно перенёс на гугл-аппс

Требования компании к почте отличаются от требований сайта к ней же.

Balancer> Угу. Когда оно достаточно оправдано

Сам же видишь, что оправданно было. Да и несложно, подозреваю. Всего лишь проверка статуса исполнения и по нему отправка тревожного письма уже повысили бы надёжность. Так у меня, кстати, реализован бекап для MS SQL 2005 (вот уж глюкалово-то!). Периодически проверяю, но вроде без проблем.

GOGI> И приблизил себя еще на шаг к финалу премии Дарвина.
гоги, да понимаю, что глупо.. Но всё равно на сухую покрытую цементной пылью кожу не особо контакт идет.. Потому и касание оголенного конца 3-жильного провода (фаза, ноль, только земля не подключена) по ощущению не более чем капля горячего чая.

Алдан-3>> Сильнее настораживает "сам" сломавшийся бакап.
HolyBoy> Он не «сам» сломался.
Balancer> Не сам.

Блин. Потому же и кавычки написал же.

И вообще Т9 на телефоне не знает "поломалось", оно знает только "поломали" и это не спроста

HolyBoy> Уведомлениями

Ага-ага. Вот у меня однажды "сама" поломалась система уведомлений.

И я только где-то через год заволновался, что как то всё подозрительно тихо.

Теперь сделал так что каждый день приходит уведомление о том, что уведомления работают

GOGI> Чего, будем меряться у кого круче "Упс"ы? А то по показателю незначительность действия - масштабность последствий промышленность айтишников зарулит не напрягаясь

Можно и упсами. А по делу, вот, когда доходит до автоматизма и случается страшное. Писал сиквели, работал с кучей таблиц, создал несколько временных, потом опять выборки. И уже название таблицы печатаешь автоматом. И пофигу — select, insert, delete, truncate или drop. Я для себя сделал правилом, что все удаления таблиц, данных, обрезку таблиц, удаление БД пишу в маленький скриптик. А его запускаю. Именно по этой причине. Т.е. delete, drop, truncate я руками стараюсь не выдавать. И эта беда общая девелоперская. По настоящему админы другие люди. У них может не столько "полёта фантазии", но они ориентированы на то, чтобы не делать сразу то, что не восстановить.

Luchnik> Михаил, я это всё понимаю. Но если делать, то делать.

Так и делает. А ещё и семью кормить надо, и ребёнка растить. А так выходит, что другим это очень важно, а никто не помогает.

Luchnik> И тут ты прав. Однако же База из личного хобби Романа уже давно превратилась в нечто большее, важное для многих людей.

Дык, набор координаторов он объявлял. Набор кодеров он объявлял (гы, я попросил доступа к исходникам, поковырялся немного, но так ничего толком и не сделал). По ходу дела надо обычных админов надо, которые бы следили за бэкапами, функционированием, классификацию ошибок (в ту же систему репорта ошибок заводили, там ответы писали), согласовывали бы дейтсвия.


Luchnik> А вот представь они бы так базу подчистили. Ты приходишь на поезд - а билета нет в БД.

Ещё раз, если бы они это всё бесплатно сделали (систему), то и вопросов бы не было. А вот за денюжки — это их задница в ответе.

Luchnik> Это так к слову... Меня иногда сильно корёжит Ромина агрессивная предвзятость к виндам.

А зачем в кучу всё валить?

Luchnik> Ну про высокодохувность это ты зря писал... Скажи, а чем тут помочь можно было ? Я мог как-то предотвратить такое ? Вопросы риторические.

Ты кто по профессии? Можешь следить за бэкапами, скажем? Или за состоянием файловой системы (возникают периодически переполнения). Я бы бэкапы себе утаскивал, но у меня трафик зарубежный.

Luchnik> Рома молодец. Низкий ему поклон за многолетние труды и неиссякаемый энтузиазм. Но я думаю, что ты понимаешь, что случившегося можно было избежать.

Я понимаю, что не особо. Потому, как сам в такое дерьмо вляпываюсь. И ничего особо не сделать. Потому и жгу на ДВД, на диски копии бесконечные бросаю. А на работе у нас доступ только к тестовым и QA машинам, а к production только у эксплуатантов, а у нас read only.

Luchnik> P.S. Михаил, предлагаю не устраивать больше срач на эту тему тут. Что случилось, то случилось. Думаю, что все сделают правильные выводы и примут нужные меры.

Предлагаю, чтобы Рома провёл набор помощников. На разные техдолжности, а народ бы подписался. Отбирать ему. Вот я бы Ведмедю доступ на всякие бэкапы и слежение выписал точно. Если бы он согласился. Только надо понимать, что это работа требует усилий каждый день. Или хотя бы неделю.

Luchnik> Гм... У нас тут паренёк написал update один для сущности товаров. В 2 коротких строчки. Патч к клиенту попал. Паренёк трети ЗП лишился. Клиент месячную абонентку урезал. Мужики из поддержки густо намазывали вазелин.

А какой у вас цикл релиза патчей? Если это одноразовое действие, то паренёк не причём. Тут надо манагера по релизам сношать. Или поддержку, если через неё идёт.

Kuznets> значит парадигма кривая. ну нельзя тестить боевую базу. сделай себе копию / тестовую и играй скока влезет. как на бирже

Машинку оплатишь? Наша немноно стоила — всего пару лимонов уе. Я тебе напомню, что у нас БД была за 100 гигабайт в 1995 году. Это когда винты на несколько гигов были супер-пупер.

Kuznets> хотя система тоже кривая - на полное удаление такого объема должно быть стописят предупреждений (и в конце отказ с просьбой подумать еще раз ).

Тогда админы затрахаются. Ну и любые временные рабочие таблицы (но не те, которые создаются по create temp table), что создал, придётся сутками удалять.

Kuznets> пс хотя можно в любой наверное системе залогиниться под самым-самым админом, отключить все-все-все предупреждения и начать тестировать запросы на удаление. но как это называется я не скажу

Это не под самым админом-админом. В том-то и дело. Если посмотреть на современные СУБД, то там уровней (вариантов) прав может легко превышать 100. И систему можно поставить раком не только drop-м. Можно просто исчерпать свободную память или другие ресурсы.

Luchnik> Это излечимо... В отличии от.

Нет. Это не излечимо было. Дорога ложка к обеду. А икра второй свежести — кому она нужна. Хочешь тебе тот билет распечают, и ты будешь доволен? Вот только денег вернуть и поехать никуда нельзя.