16.04.2010 - сбой на сервере в России

[admin]

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

[ServTecH.Ru]

Но ведь могли бы сообщить, что у вас нет бэкапа ещё 11 апреля.

[kosmosmax]

Добавлю свои пять копеек..

1 Если регулярный бекап не сработал, наверно лучше попробовать забекапить малыми частями вручную, во время наименьшей нагрузки на сервер с перемещением удачных бекапов с проблемного сервера, не дожидаться следующего задания. Вроде ИМХО.

2 Сообщать об этом массовой рассылкой считаю сервероубийственно, представляю, если почти все ломануться бекапить свои сайты. 99% это добьёт сервер.

3 Про локальные копии данных- не совсем верно, частенько в рабочих папках бардак накапливается и через неделю-две там сам черт ногу сломит, очень трудно вспомнить что там и к чему.Но все же, залил на сайт, проверил и вроде как надежда на хостера, что не подведет.(думаю, что так не только у меня)

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

[Гость Maxim Kulikov]

У вас к описанию тарифного плана идёт пункт "Еженедельный BackUp Аккаунта на Второй Диск" каким образом получилось что все бэкапы моего аккаунта двухнедельной давности? Вы обманываете клиентов? Кстати уже не первый раз такое, в прошлый раз было что-то похожее и я в аське спрашиваю вашего человека мол у вас бэкапы делаются каждый день, он отвечает мол ДА, я говорю отлично скиньте мне тогда самый последний бэкап моего сайта, а то там всё полетело, и мне скидывают бэкап помоему даже более чем двухнедельной давности!

[admin]

Но ведь могли бы сообщить, что у вас нет бэкапа ещё 11 апреля.

1. Кому?

2. Зачем?

 

1 Если регулярный бекап не сработал, наверно лучше попробовать забекапить малыми частями вручную, во время наименьшей нагрузки на сервер с перемещением удачных бекапов с проблемного сервера, не дожидаться следующего задания. Вроде ИМХО.

Резервное копирование выполняется скриптом cPanel, который запускается по расписанию раз в неделю.

Почему 7 апреля он не запустился, а 14 апреля начал работу как и должно быть - непонятно. То, что 14 апреля запустится, мы были уверены больше, чем не уверены, да и надо было бы разобраться, если бы не запустилось. Поэтому 14 апреля момент автоматического запуска скрипта отслеживался вручную.

Шестнадцатого же апреля, ночью, когда нагрузка на CPU и MEM невысока, однако в пиковые моменты может из-за бекапа грузить HDD (копирование, архивация), вылетели файловые системы /var и /usr:

Однозначно связать это с повышенной нагрузкой на HDD, нельзя, но скорее всего так и есть. Почему вылетели разделы, на которых находятся логи и MySQL, а /home (/) - нет, также непонятно. Явно какой-то сбой.

 

Предположить можно что угодно, но по крайней мере у нас нет ни одной версии, связывающей незапуск бекапа 7 апреля и ЧП 16 апреля.

Если у кого-то после анализа всей информации в этой теме есть какие-либо версии о взаимосвязи, пишите (ServTecH.Ru, Maxim Kulikov, к Вам не относится). Нами же сделан вывод, что это - стечение несвязанных обстоятельств, которые если и происходят, то в разное друг от друга время, но в нашем случае произошли максимально близко во временном интервале.

 

Если бы что-то предвещало беду, то обязательно бы приняли меры.

Запустить бекапирование вручную было возможно, но на основе анализа той информации, которой мы располагали, да и учета всеразличных технических особенностей, было принято правильное на тот момент решение дождаться запуска бекапа по расписанию, но вручную мониторить его выполнение.

 

3 Про локальные копии данных- не совсем верно, частенько в рабочих папках бардак накапливается и через неделю-две там сам черт ногу сломит, очень трудно вспомнить что там и к чему.Но все же, залил на сайт, проверил и вроде как надежда на хостера, что не подведет.(думаю, что так не только у меня)

Если данные ценные, то всецело доверять их сохранность третьим лицам не надо. На Бога надейся, а сам не плошай.

 

У вас к описанию тарифного плана идёт пункт "Еженедельный BackUp Аккаунта на Второй Диск" каким образом получилось что все бэкапы моего аккаунта двухнедельной давности? Вы обманываете клиентов?

Еще раз перечитайте эту тему, моменты про незапуск бекапирования по расписанию.

 

Кстати уже не первый раз такое, в прошлый раз было что-то похожее и я в аське спрашиваю вашего человека мол у вас бэкапы делаются каждый день, он отвечает мол ДА, я говорю отлично скиньте мне тогда самый последний бэкап моего сайта, а то там всё полетело, и мне скидывают бэкап помоему даже более чем двухнедельной давности!

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

[Гость Maxim Kulikov]

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

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

Итог сбоя на сервере

- два сайта просто выпали, благо остался бэкап и Я лично сам восстановил их

- один сайт просто умер, базу данных потеряли

- по остальным сайтам потеряна информация за 2 недели. Я надеюсь хоть деньги за 2 недели вернут, всё таки реально говоря две недели работы коту под хвост?

[admin]

- один сайт просто умер, базу данных потеряли

Вам все по два раза повторять надо?

Повторю еще раз: использование для русских символов кодировок MySQL, отличных от по умолчанию (cp1251), и возможно от UTF8 и koi-x, - на свой страх и риск.

 

Я надеюсь хоть деньги за 2 недели вернут, всё таки реально говоря две недели работы коту под хвост?

Тоже повторяю по второму разу: вопрос о компенсации будет поднят после окончания всех работ, связанных с этим сбоем.

[Гость Maxim Kulikov]

Кхм ладно извиняюсь за свою тупость... =) кстати на умершем сайте благо нашел старый старый бэкап на компе...хоть что то

 

Зы. 21.55 сайты перестали откликаться

[admin]

Зы. 21.55 сайты перестали откликаться

Такое бывает, см. F.A.Q.

[admin]

В датацентре новый сервер был поставлен в очередь на сборку.

Однако это не означает, что он будет готов скоро, ведь надо собрать, протестировать, поставить ОС, поставить cPanel и только после этого выдать сервер нам, после чего с нашей стороны уже нужно будет настроить, протестировать и только потом начать переносить аккаунты.

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

[admin]

Информация для клиентов хостинга и реселлинга:

1. Если к почтовым ящикам не подходят пароли, то нужно изменить их через cPanel.

2. При отсутствии на аккаунте дополнительных и паркованных доменов, субдоменов - пересоздайте их через cPanel. Будут ошибки - сообщайте в техническую поддержку данные доступа cPanel и информацию по проблеме.

 

Информация для клиентов реселлинга:

1. Если у каких-либо Ваших клиентов перестали подходить пароли доступа к cPanel, то нужно воспользоваться функцией изменения пароля в WHM -> Password Modification.

[admin]

оффтоп: кстати на форуме часы на час опаздывают

Исправил. Вероятно так показывало из-за летнего времени.

[Alex]

оффтоп: кстати на форуме часы на час опаздывают

Исправил. Вероятно так показывало из-за летнего времени.

 

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

Вот сейчас на сервере UTC время соответствует 20.04.2010 09:44:13.

А должно быть вроде бы на час больше, если не ошибаюсь...

 

 

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

 

 

PS после отправки сообщения посмотрел, что часы теперь на час спешат... Отправлено Сегодня, 14:47 , а сейчас 13.51.

Изменено 20 апреля, 2010 пользователем Alex

[admin]

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

Форум находится на другом сервере.

Проверил сейчас и сервер форума и резервный, на обоих правильное московское время, Tue Apr 20 13:50 MSD 2010

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

 

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

Придется менять.

 

PS после отправки сообщения посмотрел, что часы теперь на час спешат...

В настройках своего профиля на форуме проверьте часовой пояс.

[Alex]

Придется менять

Спасибо, жаль, что вы не сообщаете о том, что сервер SSL изменился и проблемы с почтой у клиентов могут быть связаны именно с этим.

 

Ещё почему-то в вордпресе после этого "переезда" не показывается значок ?, который был записан в мускуле (utf8_general_ci) именно в виде значка.

 

 

 

В настройках своего профиля на форуме проверьте часовой пояс.

 

У меня стоят такие настройки, которые идут по умолчанию на вашем сайте:

Часовой пояс

(GMT + 3:00) Багдад, Эр-Рияд, Москва, Найроби

Текущее время (включая ваши настройки часового пояса): 20 Апрель 2010 - 16:58

 

v - Коррекция перехода на летнее время

 

Для нормализации времени на форуме почему-то нужно снять галку "Коррекция перехода на летнее время", снять галку "Уже на летнем времени?", сохранить, поставить обратно галку "Коррекция перехода на летнее время", сохранить.

 

 

[admin]

Новый сервер установлен, также мы получили архив с данными со старого сервера. Правда распаковать его целиком не получилось, т.к. он битый, прервалось, разархивировав треть файлов аккаунтов из /home. Завтра попросим заново запаковать /home/ со старого сервера.

 

По MySQL хорошая и плохая новости.

Хорошая: как минимум часть баз MySQL восстановить скорее всего сможем.

Плохая: надо вручную определять какая база кому принадлежит, т.к. при восстановлении базам были даны цифровые имена плюс ко всему в некоторых папках данных нет, в других папках и вовсе файлы, не относящиеся к MySQL (восстановлены из других разделов системы /var):

 

Сейчас на новый сервер переносим хостинговые аккаунты с DNS ns*.unlimits.net, по завершении чего начнем перенос реселлеров, использующих эти же DNS.

Ручной выдачей файлов из /home/ и восстановлением и выдачей MySQL займемся по окончании переноса всех аккаунтов с резервного сервера на новый. Информация будет сообщена дополнительно.

[admin]

IP нового сервера: 89.108.110.88

cPanel: http://89.108.110.88:2082

 

Как только завершим перенос аккаунтов клиентов и реселлеров, использующих наши DNS, переключим IP в DNS на новый сервер.

Реселлеров с выделенными DNS перенесем сегодня, максимум завтра. О переносе каждому реселлеру сообщим посредством стола помощи (надо будет изменить IP в DNS).

 

По MySQL: сверили по названиям таблиц уцелевшие неименные базы с таблицами баз на резервном сервере. Совпала каждая пятая база, т.е. именно столько как минимум сможем восстановить. Как только будем готовы к этим работам и работам по восстановлению /home, сообщу в т.ч. и по e-mail алгоритм действий. Для MySQL скорее всего нужно будет сообщить имя базы, список таблиц в ней и какую-либо особенность в таблице, например встречающееся уникальное словосочетание, т.к. у имеющихся папок с базами затерты как названия (см. картинки в предыдущем посте), так и атрибуты "owner" (владелец), т.е. определить кому что принадлежит без наших дополнительных усилий и информации от владельца не сможем.

[admin]

Аккаунты всех клиентов хостинга перенесены, IP в DNS unlimits.net изменены.

Сейчас на новый сервер закачивают /home со сбойнувшего HDD. После того, как канал освободится, начнем перенос реселлеров с резервного сервера, а на резервный перекинем и распакуем закачиваемый сейчас датацентром /home и остатки mysql.

 

UPD 16:00 MSK: на сервер все еще копируется архив с /home со сбойнувшего HDD.

 

UPD 18:00 MSK: архив /home скопирован, скорее всего также не совсем полный (49GB), перебрасываем его в США. Поработали над MySQL. Как минимум 20% от общего количества баз - полные, и около 60% смогли "выцедить", но они неполные. Начат перенос реселлерских аккаунтов и их клиентов.

[Betatest]

Ребят, ну откуда руки растут? То при переезде на запасной сервант слетели пароли, теперь на этот. Или не хватает знаний? ППЦ, а не конторка, благо осталось два некритичных проекта, остальные успел вытащить.

[admin]

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

[Геннадий]

Вся информация на сайте http://pogran-zastava.ru/, за сегодняшний день утеряна! В чём дело на этот раз?

[admin]

Проверил, сайт открывается без проблем. Перепроверьте все.

[Геннадий]

Я не говорил, что сайт не открывается.

Вся информация загруженная на сайт, примерно с 7ч до 18ч, исчезла.

[admin]

Скорее всего, Вы произвели добавление на резервном сервере. Вручную добавьте нужные данные уже на новый сервер.

Рассылку с некоторой информацией произведем по окончании переноса аккаунтов.

[Геннадий]

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