foxi: 1) то что сайт перестал работать изза разницы версий ПО - ну чё, бывает, исправляйте свои древние скрипты, чтоб работали на современном ПО или берите вдс и ставьте тот софт что нужен именно вам.
Порой, это задача оказывается невыполнимой, особенно для низкобюджетных проектов. Цены на веб-разработку нынче кусаются. Мы например, до сих пор держим MySQL4, буквально ради одного клиента, у которого старый osCommerce. Который работает только на 4 мускуле.
Ilya74: Мы делаем 3 вида бэкапов - локальный каждую ночь, внешний каждую ночь и внешний каждую неделю. Считаю, что каждый хостер, который называет себя профессиональным, должен делать хотя бы также.
Могу рассказать как это делается у нас:
1.Хостинг сервера работают кластерами по 2 шт. То есть, файловые системы двух серверов абсолютно идентичны и синхронизируются в реальном времени. Сам хостинг крутится в KVM-контейнере, что позволяет его в реалтайме переместить с одного физического сервера на другой.
2. На внешний сервер ежесуточно делаются полные бэкапы аккаунтов.
3. Ротация бэкапов такая: хранится 7 бэкапов за последнюю неделю, 4 недельных бакапа, за последний месяц, 3 бэкапа за последние 3 месяца.
rustelekom: если это позиционируется как отдельная услуга (типа отката версий) - то почему ж нет. Но это специальная задача, это не тот бекап к которому привыкли. Это скорее бекап + хранение версий файлов, баз с частотой большей, нежели раз в день.
Можно по подробней, а то я не много не понял, где услуга в составе хостинга и где специальная задача?
rustelekom: Делать бекапы на тот же диск имеет смысл только для ускорения восстановления отдельных файлов или даже целиком аккаунта.
Сомнительный смысл. Не так часто клиенты просят восстановить сайт/аккаунт из бакапов. Да и при наличии, хотя бы, гигабитной сети с настроенными Jumbo-фреймами, скорость восстановления мало чем отличается от восстановления с локального диска. Да и спешки тут, как правило, никакой нету. Плюс, минус, пара минут ничего не решает.
---------- Добавлено 04.08.2014 в 19:15 ----------
prorok-ua, Ну да, цены опускают ниже плинтуса. Особенно, новички-ресселеры, которые даже не озаботятся сделать расчет себестоимости продаваемой им услуги, думают, что сделают услугу за копейки и все сразу к ним ломанутся. Но Timeweb, вроде не мальчики юные. Хотя, чувствуется соотношение цены и предлагаемого дискового пространства не закладывает возможности нормального резервирования.
rustelekom: Кхм, кхм, сейчас меня съедят наверное хостеры Доверяй, но проверяй (с). Печально, конечно, что приходится об этом напоминать клиенту таймвеба, но факт ведь налицо. Обманули получается. Ну и на будущее простая рекомендация - несмотря на все заверения хостера, делайте бекапы сайтов хотя бы раз в месяц.
Есть не будем ;). (хотя, надо уже сходить пообедать :D)
Полностью согласен, какая бы ни была система резервного копирования. Нужно хотя бы раз в месяц делать бакапы самостоятельно. Мало ли что. Когда есть под рукой копия своего сайта, его всегда можно оперативно развернуть, чтобы ни случилось с хостером.
prorok-ua: Цитата:
Сообщение от Ivan Lungov
Как же так? Бэкапы делаются на тот же сервер/диск, где и основной сайт лежит?
У вас шаред-хостинг или VDS?
Так делают очень многие
Жуть какая, сегодня спать нормально не смогу. Timeweb, вроде как крупный хостер, не ужели не может позволить себе выделенные бэкап-сервера?
Вообще, хостер, все-таки обязан проверять работоспособность сайтов при переносе если это shared-хостинг или хотя-бы попинговать IP-шник, если это VDS.
Вполне, могу предположить, что при смене платформы хостинга что-то может перестать работать и хостер обязан обеспечить совместимость сайтов пользователя со своей новой платформой хостинга или заранее (обычно за 30 дней по договору) уведомить о не возможности предоставления услуги.
Не знаю как у кого, но у нас при переносе сайтов на новое железо:
1. Уведомление по почте за несколько дней до переноса.
1. За 1-2 суток уменьшается TTL доменных зон до 3-минут.
2. Копируется аккаунт на новый сервер.
3. В зонах заменяются IP-адреса.
4. Проверяется работа сайта(ов).
5. Если что-то не так, то айпишники меняются на старые и на скопированной версии ищутся причины не работоспособности и устраняются. Если это занимает много времени, то снова копируются данные.
6. Если клиент использует не наши DNS-сервера, то уведомляем его о необходимости сменить IP сайта.
7. Старый сервер работает нетронутым, как минимум, неделю (иногда до месяца).
Но с другой стороны, ругань с ТП вряд ли может ускорить процесс решения проблемы. Косяки бывают у всех (хотя, вроде DinoHost не новички). Если проблема в работоспособности только ваших сайтов, а не всех переносимых. То, при большом количестве ругани, руководство может принять решение, что дешевле отказать в обслуживании клиенту чем работать под постоянным не цензурным прессингом.
Конечно, клиент всегда прав, но клиент тоже должен понимать, что в ТП работают живые люди и у них тоже есть свой предел терпения.
В вашем случае, виноват хостер, что то пошло не так, но он старается исправить и обязательно компенсирует время простоя. Также, предоставьте хостеру доступ к вашем компьютеру, например по TeamViewer, пусть он сам посмотрит, как открывается сайт на вашем компе. Может проблема с кривым отображением только у вас (были, например, случаи, когда клиента был айпшник сайта жестко прописан в файле hosts на его компе, что мешало обращаться браузеру к правильному айпи, поскольку hosts имеет наивысший приоритет при DNS-резолвинге, были и другие фантастические случаи). В любом случае. Ругая хостера, вы рискуете вообще потерять свой сайт (если у вас нет локальных бэкапов). Лучше, постараться максимально помочь ему с решением проблемы.
Современный хостинг, это одна из сложнейших IT-задач и при ее реализации, хостер может натыкаться на кучу подводных камней. И каждая новая реализация (перенос на новый сервер) это всегда эксперимент. Последствия которого, можно оценить только в боевых условиях. А цена за данную услугу в расчете на одного клиента стремится опустится ниже плинтуса.
1) то что сайт перестал работать изза разницы версий ПО - ну чё, бывает, исправляйте свои древние скрипты, чтоб работали на современном ПО или берите вдс и ставьте тот софт что нужен именно вам.
Порой, это задача оказывается невыполнимой, особенно для низкобюджетных проектов. Цены на веб-разработку нынче кусаются. Мы например, до сих пор держим MySQL4, буквально ради одного клиента, у которого старый osCommerce. Который работает только на 4 мускуле.
С этим готов поспорить.
Поспорьте, с удовольствием выслушаю Вашу точку зрения. Если где есть реальные недочеты, буду знать где исправлять.
Мы делаем 3 вида бэкапов - локальный каждую ночь, внешний каждую ночь и внешний каждую неделю. Считаю, что каждый хостер, который называет себя профессиональным, должен делать хотя бы также.
Могу рассказать как это делается у нас:
1.Хостинг сервера работают кластерами по 2 шт. То есть, файловые системы двух серверов абсолютно идентичны и синхронизируются в реальном времени. Сам хостинг крутится в KVM-контейнере, что позволяет его в реалтайме переместить с одного физического сервера на другой.
2. На внешний сервер ежесуточно делаются полные бэкапы аккаунтов.
3. Ротация бэкапов такая: хранится 7 бэкапов за последнюю неделю, 4 недельных бакапа, за последний месяц, 3 бэкапа за последние 3 месяца.
если это позиционируется как отдельная услуга (типа отката версий) - то почему ж нет. Но это специальная задача, это не тот бекап к которому привыкли. Это скорее бекап + хранение версий файлов, баз с частотой большей, нежели раз в день.
Можно по подробней, а то я не много не понял, где услуга в составе хостинга и где специальная задача?
крупные хостинги могут себе позволить команду техподдержки, в то время как мелкие зачастую и не имеют специально нанятых сотрудников вообще
Под крупными, может подразумевается вот это: http://hostcomm.ru/about/we/?
Ivan Lungov
/ru/forum/860057
может чего предложите?
Если про это:
плохо тоже ищем под cdn РФ, а хотя бы ACL запрещающий UDP протокол и не нульраут по пустякам?
То можем ACL-настроить, собственно говоря так и делаем.
А какой объем трафика нужен?
Делать бекапы на тот же диск имеет смысл только для ускорения восстановления отдельных файлов или даже целиком аккаунта.
Сомнительный смысл. Не так часто клиенты просят восстановить сайт/аккаунт из бакапов. Да и при наличии, хотя бы, гигабитной сети с настроенными Jumbo-фреймами, скорость восстановления мало чем отличается от восстановления с локального диска. Да и спешки тут, как правило, никакой нету. Плюс, минус, пара минут ничего не решает.
---------- Добавлено 04.08.2014 в 19:15 ----------
prorok-ua, Ну да, цены опускают ниже плинтуса. Особенно, новички-ресселеры, которые даже не озаботятся сделать расчет себестоимости продаваемой им услуги, думают, что сделают услугу за копейки и все сразу к ним ломанутся. Но Timeweb, вроде не мальчики юные. Хотя, чувствуется соотношение цены и предлагаемого дискового пространства не закладывает возможности нормального резервирования.
Кхм, кхм, сейчас меня съедят наверное хостеры Доверяй, но проверяй (с). Печально, конечно, что приходится об этом напоминать клиенту таймвеба, но факт ведь налицо. Обманули получается. Ну и на будущее простая рекомендация - несмотря на все заверения хостера, делайте бекапы сайтов хотя бы раз в месяц.
Есть не будем ;). (хотя, надо уже сходить пообедать :D)
Полностью согласен, какая бы ни была система резервного копирования. Нужно хотя бы раз в месяц делать бакапы самостоятельно. Мало ли что. Когда есть под рукой копия своего сайта, его всегда можно оперативно развернуть, чтобы ни случилось с хостером.
Цитата:
Сообщение от Ivan Lungov
Как же так? Бэкапы делаются на тот же сервер/диск, где и основной сайт лежит?
У вас шаред-хостинг или VDS?
Так делают очень многие
Жуть какая, сегодня спать нормально не смогу. Timeweb, вроде как крупный хостер, не ужели не может позволить себе выделенные бэкап-сервера?
Вообще, хостер, все-таки обязан проверять работоспособность сайтов при переносе если это shared-хостинг или хотя-бы попинговать IP-шник, если это VDS.
Вполне, могу предположить, что при смене платформы хостинга что-то может перестать работать и хостер обязан обеспечить совместимость сайтов пользователя со своей новой платформой хостинга или заранее (обычно за 30 дней по договору) уведомить о не возможности предоставления услуги.
Не знаю как у кого, но у нас при переносе сайтов на новое железо:
1. Уведомление по почте за несколько дней до переноса.
1. За 1-2 суток уменьшается TTL доменных зон до 3-минут.
2. Копируется аккаунт на новый сервер.
3. В зонах заменяются IP-адреса.
4. Проверяется работа сайта(ов).
5. Если что-то не так, то айпишники меняются на старые и на скопированной версии ищутся причины не работоспособности и устраняются. Если это занимает много времени, то снова копируются данные.
6. Если клиент использует не наши DNS-сервера, то уведомляем его о необходимости сменить IP сайта.
7. Старый сервер работает нетронутым, как минимум, неделю (иногда до месяца).
Но с другой стороны, ругань с ТП вряд ли может ускорить процесс решения проблемы. Косяки бывают у всех (хотя, вроде DinoHost не новички). Если проблема в работоспособности только ваших сайтов, а не всех переносимых. То, при большом количестве ругани, руководство может принять решение, что дешевле отказать в обслуживании клиенту чем работать под постоянным не цензурным прессингом.
Конечно, клиент всегда прав, но клиент тоже должен понимать, что в ТП работают живые люди и у них тоже есть свой предел терпения.
В вашем случае, виноват хостер, что то пошло не так, но он старается исправить и обязательно компенсирует время простоя. Также, предоставьте хостеру доступ к вашем компьютеру, например по TeamViewer, пусть он сам посмотрит, как открывается сайт на вашем компе. Может проблема с кривым отображением только у вас (были, например, случаи, когда клиента был айпшник сайта жестко прописан в файле hosts на его компе, что мешало обращаться браузеру к правильному айпи, поскольку hosts имеет наивысший приоритет при DNS-резолвинге, были и другие фантастические случаи). В любом случае. Ругая хостера, вы рискуете вообще потерять свой сайт (если у вас нет локальных бэкапов). Лучше, постараться максимально помочь ему с решением проблемы.
Современный хостинг, это одна из сложнейших IT-задач и при ее реализации, хостер может натыкаться на кучу подводных камней. И каждая новая реализация (перенос на новый сервер) это всегда эксперимент. Последствия которого, можно оценить только в боевых условиях. А цена за данную услугу в расчете на одного клиента стремится опустится ниже плинтуса.