ServerAdmin.ru
28K subscribers
224 photos
26 videos
10 files
2.55K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
​​Рассказываю занимательную историю, которая произошла вчера и заняла весь мой день. Пришлось понервничать, но не очень сильно. Сажусь утром за компьютер, проверяю почту и вижу от мониторинга сообщение о недоступности пачки виртуальных машин и самого гипервизора на одном из арендуемых дедиков. Сразу заподозрил неладное, так как обычно такие сообщения сулят проблемы.

Иду в панель управления хостера и вижу, что сервера там просто нет 😱. Смотрю тикеты, а там последние 2 тикета с интервалом в неделю о том, что надо продлить сервер, иначе мы его удалим. С ним была особая история месяц назад. Из-за майских праздников не успел дойти очередной платеж и на продление этого сервера денег не хватило. Через тех. поддержку его вручную активировали, потом пришли деньги на счет и на этом все закончилось.

А оказалось, что не закончилось. Надо было после поступления денег зайти в настройки этого сервера и жмакнуть там кнопку оплаты. Без этого оплата автоматически не прошла, а ТП сама не могла это сделать. Вообще, странная история, так как раньше такие ситуации уже были и всё как-то обходилось без ручных действий с моей стороны.

Оповещения по тикетам приходят на почту заказчика, он их то ли проигнорировал, то ли не заметил. Не суть, я не стал разбираться. Написал сразу в тех поддержку о возникшем недоразумении. Там мне почти сразу радостно сообщили, что сервер только сегодня ночью выключили и еще не обнулили. Сейчас мы его вам вернем. Я обрадовался, даже бэкапы не стал проверять.

Сижу жду час, другой, третий. Заподозрил неладное 🙄 Пошел, проверил бэкапы. Все на месте, но пока не развернешь, наверняка не узнаешь, что с ними 100% все в порядке. Начал переживать. Пишу хостеру, спрашиваю, когда сервер будет готов. Я его уже вижу у себя в панели, но не могу включить.

И тут как гром среди ясного неба. Мне сообщают, что ошиблись. На самом деле сервер уже обнулен, с дисков все удалено ☠️. Извините, но ничего сделать не можем. Пиздец, короче. Тут я уже запереживал немного, но сразу был готов отсечь все претензии, так как моей вины в этой ситуации нет вообще. Бухгалтерия задержала платеж, заказчик не обратил внимание на тикеты. Я в панель управления каждый день не лазию их проверять.

В общем, пошел смотреть бэкапы, искать, где всё разворачивать. С этим больше всего проблем, так как сервак был с 6 Тб данных на борту в рейде 10. Все это рассовать не так просто. Они даже обнуленный сервер не смогли мне запустить, ждал весь день, но так и не дождался. Аналогичного сервера не было доступно.

Проблема еще в том, что бэкапы были сырых данных, а не вируталок, так как бэкапить такие виртуалки целиком и инкрементно не было возможности. В итоге всё основное восстановил вручную, вроде работает. Хостера не буду называть и винить, так как по сути он особо ни в чем не виноват. Сами накосячили. Ему можно вменить только то, что он зачем-то сразу обнуляет сервак после отключения. Можно же хоть сутки подождать. По сути меня, как клиента, потерял, так как если я не получу этот же сервер, больше арендовать у них его не буду. А могли бы просто включить обратно и я бы спокойно остался дальше.

Предвещая комментарии о том, что надо было делать кластер, репликацию, HA и т.д. Этот сервер был в аренде около 5-ти лет. Если бы его дублировали, то потратили бы тонну денег. Простой в течении дня допустим, так что я спокойно восстановил бэкапы предыдущего дня.

Такая вот поучительная история. Со мной случается не первый раз. Я уже терял безвозвратно полностью сервера, поэтому бэкаплю не только данные, но и всё, что сопровождает сервер. Скрипты и конфиги храню в git. Рисую схемы, пишу описания хотя бы для себя, чтобы в тот момент, когда ничего не будет, хоть немного вспомнить, что там вообще было настроено и как. В идеале, конечно, бэкапить виртуалки целиком, но часто это невозможно. Про само наличие бэкапов ничего говорить не буду, и так все знаете - делаем, мониторим, проверяем.

Если дочитал до конца, ты молодец. У тебя наверняка все в порядке с бэкапами.

#история #цод
​​Наступила новая эпоха, а проблемы остались всё те же. Хочу рассказать вам одну поучительную историю, которую я узнал от подписчика. История банальна, так как там отсутствовали бэкапы и системный подход, но нова, потому что не обошлось без ChatGPT.

Как-то поздно вечером сел делать свои дела. Пишет незнакомый человек и очень просит помочь, потому что у него упала база данных Mysql, а он не знает, как починить. Да и база не его, а там много сайтов. Отчаяние сообщения сподвигло меня попробовать помочь. Подключаюсь к серверу и вижу там совершенно незнакомые мне ошибки, суть которых не очень понятна. В логе ошибок был backtrace и информация о том, что нарушен порядок транзакций. Как всё это чинить я совершенно не знал, а времени разбираться и погружаться в проблему не было, так что помочь ничем не смог.

Дальше мне рассказали историю проблемы. База данных очень сильно нагружала процессор. Автор вызвался помочь с решением проблемы, но не рассчитал свои силы. Он запустил mysqltuner.pl и получил некоторые рекомендации от него. Когда он их внёс, в логе были какие-то ошибки. Тогда он решил спросить по ним совета у ChatGPT, и он предложил переместить файлы ib_logfile0 и ib_logfile1, чтобы при запуске были созданы новые. После этих манипуляций база перестала вообще стартовать.

В этих файлах хранится журнал транзакций innodb. Тут я примерно понял, в чем скорее всего проблема. Вероятно эти файлы были переименованы при работающей субд, что и привело к расхождению в транзакциях. Это нарушило целостность баз данных, поэтому служба не стартовала. Как решать подобную проблему, я даже теоретически не знаю. Было бы любопытно узнать хотя бы теорию по восстановлению, если оно вообще возможно при таких вводных.

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

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

Когда вы выполняете какие-то манипуляции в работающих сервисах, всегда держите в голове мысль: "А что я будут делать, если после моих изменений сервис не запустится". Об этом нужно подумать заранее, даже если вы точно знаете, что будете делать. Вы можете банально ошибиться, перепутать консоли и грохнуть работающие базы. Это далеко не редкость, и я сам путал консоли неоднократно.

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

Я сам с чем только не сталкивался. И свои ошибки были, и ошибки разработчиков, которые всё уничтожали. И поддержка хостера роняла серваки, отключив сетевой кабель или питание, и диски не те меняли на развалившихся массивах. Всегда нужно держать в голове план восстановления и сразу же начинать его реализовывать, когда что-то пошло не так, а не сидеть и думать, что же теперь делать. Когда нет плана, это сильно бьёт по нервам и вообще отбивает желание работать в профессии.

#backup #история