IHC.RU - Качественный хостинг, VPS, сервера в надёжных ДЦ без переплаты. Скидки!

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

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

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

Ну и конечно... бекапы бекапы бекапы. Если их нет, то вина только ваша. Каким бы идеальным ваш хостинг-провайдер не был, делайте ежедневные нелокальные бекапы.

Где вы увидели, что я прошу хостера следить за сайтами? Читайте внимательнее...

Замена оборудования это забота хостера, а не моя. Но хостер как оказалось не в состоянии даже корректно заменить вытелевший диск

---------- Добавлено 11.10.2015 в 14:08 ----------

бекапы конечно же имеются - но заливать из на новый сервер по домашнему соединению несколько геморойно

Я прочитал всё правильно. Хостер заменил вам диск и/или находится в процессе этого. С чего вы решили, что он в это время должен следить не упало ли чего у вас на сервере - не ясно.

Бекапы нужно хранить не дома, а на быстром внешнем сервере. Например в облаке.

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

Если вы считаете что менять диск 4 дня вместо обещанных 20 минут это норма - то чтото вам доказывать считаю бесполезным.

Это не нормально.

Хостер должен иметь ipmi и прочие доступы в таких случаях к своим серверам если он размещает их в дата-центе.

Когда нет доступов, остается надеется только на сотрудников дата-цетра что бы те подняли сервер.

Но так как воскресенье достучаться до сотрудников дц тоже не легко.

Я не полагаюсь утверждать что у ihc нет доступа к своему серверу, я лишь предполагаю.

В данном случае считаю должен быть следующий порядок действий:

1. проверить состояние второго диска (быстрая проверка);

1.1. если диск сбойный настоять на создании backup, заменить два диска и переустановить систему;

1.2. если диск в норме предложить создать рез. копию или напомнить об необходимости создавать такие регулярно;

2. изъять диск из рейда;

3. заменить сбойный диск;

4. запустить сервер;

5. добавить новый диск в массив, тем самым запустив синхронизацию данных;

5.1. при больших нагрузках на дисковую у клиента поменять операции 4 и 5 местами;

6. при наличии просьбы клиента уведомить об окончании синхронизации.

Наблюдать работает ли сайт клиента хостер не должен, если не заказана услуга мониторинга.

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

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

---------- Добавлено 11.10.2015 в 14:31 ----------

поправочка, уже имею, но пока не лезу - жду сообщения от поддержки

porutchik, Хорошая шутка. Я арендую этот сервер у вас, это не впс.

Дедик или vps/vds разницы нет. Это ваш сервер и вы можете купить ssl-сертификат для isp.

Если купите у нас, то мы его вам бесплатно поставим на панель ispmanager.

А можете не покупать и пользоваться самоподписанным.

На наших серверах стоят валидные сертификаты: https://master1.ispmgr.ihc.ru:1500/

xclydelx, к сожалению, имеет место быть человеческий фактор со стороны наших администраторов, которые занимались расширением массива.

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

Максимальное время решения вашей проблемы должно было бы составить 10-15 минут для загрузки предыдущего ядра, и в случае возникновения проблем - 40-60 минут при возвращении предыдущих дисков и загрузки предыдущей версии ядра.

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

Приносим искренние извинения за доставленные неудобства.