Семь бед — один рестор
Пословицу «Семь бед — один ресет» я услышал, когда был ещё мало разбирающимся в компьютерах подростком. Она стала для меня своего рода аксиомой, ведь во времена Windows ME, XP без сервис-паков и Vista (особенно когда она была ещё только «Лонгхорном») тормоза и зависания и так не слишком сильной машинки легче всего решались именно нажатием на эту волшебную кнопку, а потеря данных обычно сводилась к 15–20 минутам несохранённой игры.
Чуть позже, когда я уже собирал и разбирал компьютер на время, а установка системы стала простым и понятным процессом, к панацеям была с лёгкой руки записана полная переустановка ОС. Ведь если запорол что-то кривыми драйверами или удалил какой-то «неоправданно большой» файл с такого маленького раздела С:, то вместо того, чтобы долго искать решение проблемы (а Гугл тогда ещё не был таким всезнающим, как сегодня), можно было за час по накатанной процедуре полностью переустановить систему. Опять-таки, потеря данных тогда была минимальной, ведь всегда был раздел D:, на котором хранилось «самое важное».
Уже когда я был начинающим айтишником, мне быстро и доходчиво объяснили, что необоснованный ресет компьютера в бухгалтерии может закончиться истерикой и выговором со штрафом, а система, полеченная от знакомой болячки через Safe Mode, а не переустановкой, экономит очень много времени и усилий по восстановлению очень древнего и уже не поддерживаемого, но такого необходимого софта. Именно тогда я раз и навсегда решил, что радикальные методы — это не наше и использовать их можно только в самом крайнем случае.
Сейчас я работаю в компании, которая пишет очень специфический софт для очень специфических клиентов с базой данных на основе PostgreSQL. Так как и софт и клиенты специфические, то в каждую конкретную БД могут вноситься точечные изменения по просьбе клиента. Все изменения документируются и учитываются в последующих патчах. Я работаю в команде, отвечающей за установку и обновления, а также решение внезапных проблем, но у каждого региона есть команда техников, которые должны решать мелкие проблемы самостоятельно и передавать нам то, что решить уже не в состоянии.
Это всё была присказка, а сказка начинается скорее как анекдот.
Итак, встретились как-то раз индус и русский. Индус должен был тестировать новую версию софта перед обновлением, а русский по мере возможности помогать. Звонят они как-то и говорят: так и так, есть проблема, программа не поднимается, выдаёт кучу ошибок, всю голову уже сломали, но понять ничего не можем.
Так как эту конкретную систему ставил и базово проверял я сам, то сразу почуял неладное. Лезу в систему — правда не поднимается, в логах полная истерика, ошибок столько, что читать сложно, но через какое-то время понимаю, что всё сводится к чтению данных из БД. Лезу в БД, первым делом проверяю версию и наличие хоть каких-то данных. Версия правильная, записи существуют, тогда почему же оно не работает? На всякий случай проверяю, когда установлена БД. Так, что значит три дня назад? Я ж систему на проверку уже две недели как передал!
Спрашиваю у русского, что делали с системой. Он говорит, что ничего особенного не делали, всё по инструкциям. На прямой вопрос отвечает: да, три дня назад восстанавливал базу по просьбе индуса, потому что были проблемы.
Спрашиваю индуса, что делал. Говорит, что начал тестировать систему, но некоторые конфигурации через клиент у него «по-старому» не вносились, поэтому он их сделал напрямую через БД. Ясно, через клиент срабатывала «защита от дурака», но так как текст ошибки читать недосуг, то этот самый дурак кривые параметры запихал в БД напрямую, потому что там такой защиты нет.
Идём опять к русскому — сначала
Ладно, восстанавливаем старую базу со старой схемой, патчим до новой версии, проверяем систему. Два имейла — и волшебные пендели и индусу, и русскому обеспечены. Чёрт, как так рабочий день закончился? Я ж сегодня ничего не успел… Ясно, опять из дома на выходных работать.
Ребят, честное слово, пословица «Семь раз отмерь, один раз отрежь» намного умнее. Лучше сначала инструкции перечитайте или спросите. Радикальные методы — это не наше, правда-правда.
Чуть позже, когда я уже собирал и разбирал компьютер на время, а установка системы стала простым и понятным процессом, к панацеям была с лёгкой руки записана полная переустановка ОС. Ведь если запорол что-то кривыми драйверами или удалил какой-то «неоправданно большой» файл с такого маленького раздела С:, то вместо того, чтобы долго искать решение проблемы (а Гугл тогда ещё не был таким всезнающим, как сегодня), можно было за час по накатанной процедуре полностью переустановить систему. Опять-таки, потеря данных тогда была минимальной, ведь всегда был раздел D:, на котором хранилось «самое важное».
Уже когда я был начинающим айтишником, мне быстро и доходчиво объяснили, что необоснованный ресет компьютера в бухгалтерии может закончиться истерикой и выговором со штрафом, а система, полеченная от знакомой болячки через Safe Mode, а не переустановкой, экономит очень много времени и усилий по восстановлению очень древнего и уже не поддерживаемого, но такого необходимого софта. Именно тогда я раз и навсегда решил, что радикальные методы — это не наше и использовать их можно только в самом крайнем случае.
Сейчас я работаю в компании, которая пишет очень специфический софт для очень специфических клиентов с базой данных на основе PostgreSQL. Так как и софт и клиенты специфические, то в каждую конкретную БД могут вноситься точечные изменения по просьбе клиента. Все изменения документируются и учитываются в последующих патчах. Я работаю в команде, отвечающей за установку и обновления, а также решение внезапных проблем, но у каждого региона есть команда техников, которые должны решать мелкие проблемы самостоятельно и передавать нам то, что решить уже не в состоянии.
Это всё была присказка, а сказка начинается скорее как анекдот.
Итак, встретились как-то раз индус и русский. Индус должен был тестировать новую версию софта перед обновлением, а русский по мере возможности помогать. Звонят они как-то и говорят: так и так, есть проблема, программа не поднимается, выдаёт кучу ошибок, всю голову уже сломали, но понять ничего не можем.
Так как эту конкретную систему ставил и базово проверял я сам, то сразу почуял неладное. Лезу в систему — правда не поднимается, в логах полная истерика, ошибок столько, что читать сложно, но через какое-то время понимаю, что всё сводится к чтению данных из БД. Лезу в БД, первым делом проверяю версию и наличие хоть каких-то данных. Версия правильная, записи существуют, тогда почему же оно не работает? На всякий случай проверяю, когда установлена БД. Так, что значит три дня назад? Я ж систему на проверку уже две недели как передал!
Спрашиваю у русского, что делали с системой. Он говорит, что ничего особенного не делали, всё по инструкциям. На прямой вопрос отвечает: да, три дня назад восстанавливал базу по просьбе индуса, потому что были проблемы.
Спрашиваю индуса, что делал. Говорит, что начал тестировать систему, но некоторые конфигурации через клиент у него «по-старому» не вносились, поэтому он их сделал напрямую через БД. Ясно, через клиент срабатывала «защита от дурака», но так как текст ошибки читать недосуг, то этот самый дурак кривые параметры запихал в БД напрямую, потому что там такой защиты нет.
Идём опять к русскому — сначала
DROP DATABASE
, потом CREATE DATABASE
по новой схеме и затем pg_restore
на всякий случай с флагом -c
, чтобы быстрее. Откуда бэкап взял? Ну так вот же он. Фух, теперь всё ясно: бэкап брался с живой системы, со старой версии БД. Естественно, на новую схему восстановился он криво, а логи читать — это не для нас, система-то тестовая все равно.Ладно, восстанавливаем старую базу со старой схемой, патчим до новой версии, проверяем систему. Два имейла — и волшебные пендели и индусу, и русскому обеспечены. Чёрт, как так рабочий день закончился? Я ж сегодня ничего не успел… Ясно, опять из дома на выходных работать.
Ребят, честное слово, пословица «Семь раз отмерь, один раз отрежь» намного умнее. Лучше сначала инструкции перечитайте или спросите. Радикальные методы — это не наше, правда-правда.
1 комментарий