Перенос сайтов нового клиента уже стал как бы стандартом у всех хостёров и при том практически со всех панелй управления. По этому миграция действительно для клиента ощутима только каким то доунтаймом на время делегирования днс и естественно проверкой своих сайтов после переноса с последующим информированием о проблемах. Решение проблем обычно дело нового хостёра. В этом помогла достаточно жесткая конкуренция на рынке. Естественно перед переносом надо уточнять нужные версии php.
По поводу гарантий - Вы уверенны в том, что после обновления php на текущем хостинге всё будет работать без проблем? Если да, то будут гарантии на новом сервере.
Будьте внимательней и пройдёт желание придираться.
Если не варез или другой запрещённый контент, то без проблем в Франции, 1 gbps сеть.
Странные посчёты и по моему далеки от реальности.
Невозможно смотреть на бэкап только как на гигабайты, которые лежат на дисках.
1. Для начала бэкап надо создать. Если это архив, то на 100 гб реального хостинга на мощном сервере с RAID10 (сервере, не на десктопе типа i920, которые пользуется спросом у хостёров) уйдёт около часа, если нет пользователей с огромным количеством мелких файлов на акаунте. Если не повезло, то 100 гб может создаватся 5-6 часов или даже больше. Если надо лимитировать использование ресурсов на копирование, чтобы не тормозить сервер, времени понадобится ещё больше.
2. 100 ГБ надо скинуть на удаленный сервер. На 100 мбпс сети, если не жалко отдать практически весь канал на резервное копирование, за час можно слить около 36 ГБ. На 100 ГБ грубо уйдёт три часа. Если сервер на который сливается копии способен принять весь трафик на полной скорости, в это время сайты клиентов будут тормозить достаточно сильно. В реальности на резервный сервер в одно и тоже время сливается с нескольких серверов, по этому канал рабочего сервера забит меньше, но весь процес длится дольше.
В неблагополучных условиях такая схема резервирования станет тормозом и фактихески сервер будет большую часть времени перегружен, а клиенты недовольны.
Также такой прогон трафика скажем с одного датацентра на другой обойдётся достаточно дорого, так как всё таки реальные 3 ТБ в месяц. По этому на практике чаще всего бекапы делается на тот же диск который на самом сервере и чаще всего даже не RAID1.
С другой стороны так тупо тратить ресурсы нелогично, на акаунтах хостинговогого сервера меняется доли процента информации за сутки, по этому хочется того или не хочется приходится городить достаточно сложную систему внешнего резервирования данных для клиентов, которые за это платят. А для тех клиентов которые платят только за дешовый хостинг, есть ежедневные резервные копии, с которых польза только для хостёра в случае выхода из строя оборудования. Вот по этому и куча тем на форумах о том, как потерялись данные у того или иного хостинга.
Резюме - если экономите на бэкапах, то обязательно сливайте данные себе в ПК такими интервалами, чтобы потеря данных между бэкапами не была критичной. Я не знаю ни одного хостинга в мире, который гарантирует сохранность данных, хотя многие реально делают ежедневные копии....
Как обойтись хостёру без удаленного резервного хранилища я не представляю. В реальности нужна несколько хранилишь на разных датацентрах, офисе, дома и тому подобное.
1. А почему не менять если звонит с телефона, который в билинге? (было именно такое, но звонил пупкин 2, не 1)
2. Пупкины чаще всего сами не помнят что они вводили в форме заказа.
3. Узнать мыло не проблема для любого заинтересованного.
Двойные стандарты господин Yafet88, типа хостёр должен волноватся кому отдавать данные, а вот клиент может себе спокойно подставлять хостёру любую липу ;)
Верно, у хостёра в случае Васи Пупкина вобще нет проблем:
1. Заказал 1 Вася Пупкин хостинг, домен на левые данные.
2. Раскрутил свой сайт на какое то определённое число оборотов, которые мерится в зелённой валюте.
3. Уехал 1 Вася в отпуск, после своих трудов.
4. Хостёру пишет 2 Вася Пупкин, с проспекта Ленина, Мавзолея города Москвы (адрес взят с панели билинга, при том нашего, так что не вините...) что так и так, мой любимый хостёр, я потерял (у меня украли) даные для подключения к управлению домена, хостинга, да и вобще я такой несчастный....
5. Хостёр обрадовался, что клиент вспомнил про его и добрым словом упомянул, да и поменял все пароли и вручил своему клиенту Васе, Пупкин который. Все рады :)
6. Приехал 1 Вася Пупкин с отпуска и с надеждой что в партнёрке его раскрученного домена будет несколько кило баксов, но увы, 1 Вася нищий, всем владеет второй Вася :)
Убедительная басня? Хостёру пофиг, который Вася ему будет бабки платить ;) Какая разница, данные у обоих пупкинов левые 🤪
Я тут нарисовал картинку не совсем грустную, но может быть и другая, на которой нарисован хостёр за окном в клеточку....
А куда хостёру деватся после таких съехавших клиентов? Доказывать в суде что не он сам (хостёр) этот варез у себя держал?
По сути, сами понимаете, что подставляете хостёра, но прикидываетесь что миленькие и пушистые ;)
Говорят о том, что они грамотно подходит к самой сути общего хостинга. Это не та услуга, на которой надо забивать себе голову как защитить всех самоубиц. Кстати, после шести лет работы с suphp я лично склонен опять вернутся к этому дырявому mod_php. Это тоже о чём то говориит, так как обычно от добра ни кто не отварачивается ;)
Вы не внимательно прочли что я написал, и такая невнимательность сводит на нет все прелести общения на форуме. Также я в этой теме нигде не написал что надо делать администратору севера, писал только о том, что надо делать пользователям чтоб их не ломал каждый турецкий хакер. Про те файлы, которые не должны читатся каждому посетителю сайта я упомянул права 600. Будьте внимательней колега и не разводите пустой флейм.
По поводу phpmyadmin cPanel - нет там рутовского пароля и вобще там никаких паролей нет и не может быть.
Включаем мозг и думаем, перед тем как писать такой коментарий.... Обычно апачу надо иметь права записи на один - два файла, так зачем разрещить на все? Я не знаю ни одного движка, который требовал бы право записи на index.php. Типично, ламеры заливают на акаунт файлы и чтоб было проще на все махом 777.
Не весь сервер, а тех у которых нет ума. Нормального пользователя на том же сервере ни кто не укусит. Дураков и в церкви бьют.... :)
Не всё так красиво как кажется в таком конфиге. У нас cPanel тоже так работает уже шетсь лет, но как то мы сами начали анализировать и оказалось что такой конфиг взломать ещё проще если уровень взломщика достаточно высокий. То есть, банальный mod_php фактически более безопасный, если пользоатель грамотный, а производительность выше примерно раз пять. Дополнительно если взломали акаунт с suPHP, то самому этому акаунту возможен полный каюк....
А по теме - это очередной раз когда безграмотные пользователи пострадали из за своей неграмотности. Ну на сколько надо быть тупому, чтоб оставить возможность для апача редагировать файлы? Сами виноваты, хостёр тут не причём. Права на файлы которые доступные только на чтение 644, на папки 755, на недоступные на чтение 600 и 700 и ваш акаунт будет жить спокойно.
