Помощь - Поиск - Пользователи - Календарь
Полная версия: Бэкапы
Онлайн-форум hostobzor.ru > Архив (темы до 1.06.2015). Только для чтения. > Коммерческий хостинг. Общие форумы > Общие вопросы
gylys
Доброго времени суток.

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

1. Акаунт клиента взломали, испортили данные и так далее.
2. Клиент сам испортил что то, после чего лучше залить копию из бэкапа.
3. Клиент просто уходит к другому хостёру.
4. Акаунт клиента был блокирован за неоплату.
5. Акаунт был блокирован за незаконное деятельство.

На этот раз мне в голову пришли пять причин, наверно это самые характерные. Попробуем выяснить как в этих случаюх должен действовать хостёр. По моему мнению:
1-2 похожие, у клиента неприятности, естественно помогаем чем можем и за спасибо.
3. Случай скользкий, так как тут возможные подводные камни. В общем случае, спасение утопающих дело самих утопающих. Мешать не будем, но помогать скорее всего тоже нет. Тем более просбьу клиента зделать полный бэкуп при уходе, я считаю не этичной со стороны клиента.
4. Клиент или продлевает хостинг, на определённый минимальный период, или платит деньги за создание резервных копий. По любому, чтобы подготовить копию требуется потратить время и это время должно оплачиватся.
5. Данные акаунта подлежит немедленому уничтожению, выдаче не подлежит. Так как хостёр не суд, скорее всего каждый хостёр будет эти данные хранить какой то определённый период времени. Но о выдачи речи не должно быть.

Дополнительное разьяснение 3,4 пункта. Клиент имеет намерение нагрузить работой администратора сервера. Он мог сам делать копии, но не делал. Так как это инициатива со стороны клиента, то эта работа должна оплачиватся как любая другая платная работа. То есть, утром деньги, вечером стулья biggrin.gif
eSupport.org.ua
Если по-человечески - то клиенту надо отдать его бекап.
gylys
Цитата(eSupport.org.ua @ 21.03.2008, 16:14) *

Если по-человечески - то клиенту надо отдать его бекап.

Ни кто не ведёт разговора о том, что не отдать. Клиент имеет право сам его забрать.
r2w
Цитата(gylys @ 22.03.2008, 00:51) *

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

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

Цитата

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

Заблокировать сайт и дать время на погашение задолженности. И только после этого удалять.
Хостер что, бекапы руками делает? blink.gif
Установить панель, в которой бекапы делаются автоматически. А скопировать архив в общий доступ не такая уж и большая работа.

Цитата

5. Данные акаунта подлежит немедленому уничтожению, выдаче не подлежит. Так как хостёр не суд, скорее всего каждый хостёр будет эти данные хранить какой то определённый период времени. Но о выдачи речи не должно быть.

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

Цитата

Дополнительное разьяснение 3,4 пункта. Клиент имеет намерение нагрузить работой администратора сервера. Он мог сам делать копии, но не делал. Так как это инициатива со стороны клиента, то эта работа должна оплачиватся как любая другая платная работа. То есть, утром деньги, вечером стулья biggrin.gif

О какой загрузке администратора идет речь? У хостера администратор несколько раз в день выдает бекапы уходящим клиентам? Тогда стоит подумать, что в королевстве не так...
Сайт клиента - его ребенок. Как его можно уничтожить (не выдать бекап)?

PS: Изменил текст на общие выражения...
gylys
r2w в таком тоне, я с Вами не хочу вести разгорор.
WebXL
Цитата(gylys @ 21.03.2008, 16:51) *

1-2 похожие, у клиента неприятности, естественно помогаем чем можем и за спасибо.
3. Случай скользкий, так как тут возможные подводные камни. В общем случае, спасение утопающих дело самих утопающих. Мешать не будем, но помогать скорее всего тоже нет. Тем более просбьу клиента зделать полный бэкуп при уходе, я считаю не этичной со стороны клиента.


Если бэкап регламентирован хостером и клиент просит предоставить бэкап, в том числе и при уходе, но в течение оплаченного срока - бэкап нужно предоставить. ИМХО.

Цитата(gylys @ 21.03.2008, 16:51) *

4. Клиент или продлевает хостинг, на определённый минимальный период, или платит деньги за создание резервных копий. По любому, чтобы подготовить копию требуется потратить время и это время должно оплачиватся.
5. Данные акаунта подлежит немедленому уничтожению, выдаче не подлежит. Так как хостёр не суд, скорее всего каждый хостёр будет эти данные хранить какой то определённый период времени. Но о выдачи речи не должно быть.

Дополнительное разьяснение 3,4 пункта. Клиент имеет намерение нагрузить работой администратора сервера. Он мог сам делать копии, но не делал. Так как это инициатива со стороны клиента, то эта работа должна оплачиватся как любая другая платная работа. То есть, утром деньги, вечером стулья biggrin.gif


В общем считаю, что бэкап нужно предоставить во всех случаях кроме пятого, причем абсолютно бесплатно, если иное конкретно и прямо не указано в договоре и на сайте хостера.
gylys
Цитата(WebXL @ 21.03.2008, 17:34) *

Если бэкап регламентирован хостером и клиент просит предоставить бэкап, в том числе и при уходе, но в течение оплаченного срока - бэкап нужно предоставить. ИМХО.

В течении оплаченного периода, клиент может самостоятельно зделать бэкап. Интересно почему должен хостёр делать за клиента то, что клиент может сам? Просто порассуждаем. Без ухода в личности.
Цитата(WebXL @ 21.03.2008, 17:34) *

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

Опять, попытка уходить в ту степь куда не надо biggrin.gif Уточняю, у нас блокировка акаунта общего хостинга производится на 15 день после окончания оплаченного термина. То есть, клиент имеет 14 дней неоплатив за услугу спокойно зделать бэкуп и уходить. Никому из за этого голова не болит. На 15 день автомат блокирует акаунт и дело с концами biggrin.gif Бэкуп ещё какое то время валяется на фтп, но как долго будет валятся это уже дело счастья, так как ни кто не обращает на такой бэкуп внимания. И найти его, уже надо время.

Но разговор не о нас, разговор в общем плане. Так как все хостёры раньше или позже сталкиваются с этим.

Я поднимаю вопрос о том, что клиент имея все возможности подготовить себе бякуп самостоятельно , требует от хостёра чтоб бякуп подготовил именно хостёр wink.gif

5 пункт отдельный разговор, так как если есть явное нарушение законов, скорее отдавая резервные копии хостёр может сам попасть под удар. Естественно, на такого клиента пришла достаточно обаснованная абуза. Это не сам хостёр придумал что клиент что то нарушает. Мне кажется всем хостёрам не до того, что творится на аакаунтах. По крайней мере я не вижу и мне не интересно....
r2w
Цитата(gylys @ 22.03.2008, 02:56) *

Я поднимаю вопрос о том, что клиент имея все возможности подготовить себе бякуп самостоятельно , требует от хостёра чтоб бякуп подготовил именно хостёр wink.gif

Здесь вопросов вообще не должно возникать.
Хостер или делает бекапы, или нет. И это должно быть отражено на сайте (или договоре, или правилах).
Если клиент обязан делать бекапы сам, то об этом он должен знать при заказе хостинга (сайт, договор, правила).

Цитата

5 пункт отдельный разговор, так как если есть явное нарушение законов, скорее отдавая резервные копии хостёр может сам попасть под удар.

Хотелось бы услышать мнение юридически подкованных людей...
Чем грозит хостеру выдача клиенту бекапа сайта, на который пришла абуза?

gylys
Цитата(r2w @ 21.03.2008, 18:35) *

Здесь вопросов вообще не должно возникать.
Хостер или делает бекапы, или нет. И это должно быть отражено на сайте (или договоре, или правилах).
Если клиент обязан делать бекапы сам, то об этом он должен знать при заказе хостинга (сайт, договор, правила).

Тут может быть несколько вариантов. Одни официально не делают и не обещают, но в реальности делают. Другие разказывают сказки про мощные сервера и удаленные ежедневные бэкупы, но реально не делают даже местных, так как на VPS нехватает места biggrin.gif
Скажем в том случае о чём я говорю, даже не важно, обещает бэкупы или нет. У клиента есть возможность самому их подготовить и качать куда ему угодно. Особенно это касается 3 пункта, то есть уход. (не надо вдаватся почему этот уход)
4 пункт тоже интересный тем, что клиент обратился за долго после того, как закончился оплаченный период. То есть, можем уточнять - обязан ли хостёр хранить бэкупы клиента после того, как клиент изчез?

Цитата(r2w @ 21.03.2008, 18:35) *

Хотелось бы услышать мнение юридически подкованных людей...
Чем грозит хостеру выдача клиенту бекапа сайта, на который пришла абуза?

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

Есть ещё один нюанс, почему старемся не прикасатся к данным на акаунте и бэкупам. Имелись случаи, когда клиент начал катить на нас, что мол мы не всё ему распаковали, что что то потеряли biggrin.gif
kosmohost.com
На сколько я знаю. В РФ нет в законе "О Связи" пункта о резервном копировании данных клиента.

Если в договоре и тарифах не указывается бэкап, то значит хостер его вообще может не делать, и будет прав.
gylys
Цитата(kosmohost.com @ 21.03.2008, 21:43) *

На сколько я знаю. В РФ нет в законе "О Связи" пункта о резервном копировании данных клиента.

Все мировые мега хостинги не делает резервных копий. В TOS прописанно, что хостёр не несёт никакой ответственности за сохранность данных.
Anatoly Bogdanov
Цитата(gylys @ 21.03.2008, 23:33) *

Все мировые мега хостинги не делает резервных копий. В TOS прописанно, что хостёр не несёт никакой ответственности за сохранность данных.

видимо мы не попадаем под мировые хостинги... даже на 5 мегабайтном тарифе трехразовое бэкапировение... tongue.gif
r2w
Цитата(gylys @ 22.03.2008, 07:33) *

Все мировые мега хостинги не делает резервных копий. В TOS прописанно, что хостёр не несёт никакой ответственности за сохранность данных.

Вот и я про то же самое (выделено жирным)...
gylys
Цитата(Anatoly Bogdanov @ 22.03.2008, 02:11) *

видимо мы не попадаем под мировые хостинги... даже на 5 мегабайтном тарифе трехразовое бэкапировение... tongue.gif

Это понятно, так как хоть таким способом стараемся обеспечить сохранность данных. Хотя при взломе акаунта, чаще всего клиент не сразу замечает проблему и автоматические копии уже не спасают.
Традиция ежедневного резервирования пришла с тех времён, когда акаунты хостинга мерились единицами мегабайт и клиент не имел возможности сам позаботится о бэкупах без специальных знаний. Теперь имеем уже гигабайты на , развитые инструменты управления хостингом.
Когда видишь статистику нагрузки сервера во время резервирования и видишь безполезность этого процеса, тога и приходит мысль что надо закрыть эти безполезные работы. Дополнительно керосина подливает не очень честные клиенты, которые бэкупы использует как средство для шантажа. На среднем сервере, резервное копирование длится 4 - 6 часов (с отсылкой по фтп на другой сервер). В это время, канал полностью забит, доступ к серверу лимитированный. Да и скорость процесов в это время на этом сервере оставляет желать лучшего. То есть, если кто то ночью работает, то ему не повезло, сервер еле дышит.
Скажем у нас ситуация с бэкупами такая, что официально их у нас нет, мы не делаем. В реальности они пока есть и при том паранойдальные. Но скорее всего централизованно их не будет (кроме dB, хотя официально и бэкапа dB не будет biggrin.gif ). Просто увеличиваем обьёмы акаунта и кому надо есть услуга удаленного фтп бэкапа.
За два года с личним работы в сфере хостинга, был один случай, когда действительно клиенту был нужен бэкап, но и то базы данных (форум). Во всех остальных случаях, клиенты просили бэкап по тому, что просто не разобрались что им надо. В реальности обошлись без него.
И самое интересное то, что бэкап не один раз стал именно конфликтом с пользователям. Когда они начали требовать того, что им не обещанно и так далее biggrin.gif

Цитата(r2w @ 22.03.2008, 03:16) *

Вот и я про то же самое (выделено жирным)...


Клиенты не читают правил (TOS). В связи с этим, мы перестали их писать biggrin.gif нет смысла, так как все случаи не предвидишь, а для взрослых людей расписывать что они должны делать чего не должны по пунктам, это унизительно и для нас и для клиентов....
eSupport.org.ua
Под бекапы взять сервер/vds в том-же дц, бекапы валить на него - а с него - на сервер в другом дц. Не?

Конечно, есть хостинги без TOS, без бекапов, без менибека, и тд.

Но это уже личное дело владельца - относиться по-человечески к своим клиентам или нет.
cron
1.лучше конечно отдать бэкапы, если таковые есть.
всетаки это личные данные клиента.
(случай №5 спорный очень. опять вопрос о незащищенности хостера и, скорее всего, анонимности клиента. тут уже на усмотрение . так как это его подставляют и ему решать "есть еще бэкап на сервере" или уже "нет").
и по боку все "неправомерно".
хотя это скорее всего уже будет отражать личное мнение хостера к содержанию сайта.
как ни крути, а человеческого фактора не избежать.
2.если в правилах и не прописано, а бэкапы существуют, то отдать не тяжело, но лучше предупредить, что за актуальность и целостность данных ответственности хостер не несет. ибо на "автомате" все.
-касательно случая № 3. предпочтительнее дать возможность клиенту самому слить резервную копию.
иначе есть вариант потом услышать о себе "бэкапы хостер битые отдал".
тоже встречал подобное.
3.мое мнение, что никто и никогда не сделает бэкап актуальнее чем сам пользователь. так что сами должны думать об этом заранее, если ему данные важны. не смотря на то, что там у хостера в правилах прописано.
тем более что есть и встроенные и сторонние средства резервного копирования.
вроде это нормальное отношение к своим трудам.
но зад лучше всегда прикрыть себе))
4. в любом случае, если бы со мной поступили бы как указано выше, по всем пяти пунктам, я бы зла на хостера не держал точно.
нормальная позиция, в общих чертах.
а вот поправочки каждый уже для себя сам делает. так как не предусмотреть же всех возможных развитий ситуации.
5. а вот властям, вместо того что бы думать как запустить свои шаловливые ручки в новый для них бизнес, лучше бы подумать о том, как средства, полученные от лицензирования, налогов и прочей дани, ну оччччень образно говорю, проспонсировать кнопочку в панелях управления:
(Обратить внимание на моего клиента)).
кликнул хостер, прикрыл себе зад и работает дальше, а вот они пусть сами разбираются законен этот контент или нет.
Drug
У нас на хостинге qwarta.ru бекапы делаются для всех клиентов, все бекапы доступны по FTP в кол-ве 15 штук за 15 последних дней, удаленных бекапов не делаем, но диски на сервере в 10 рейде - для скорости и надежности.

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

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

И бывали случаи когда клиенты через 8 месяцев обращались с просьбой восстановить сайт или отдать им бекап если есть!

А ежедневными бекапами до того как они заработали на автомате - клиенты просили восстановить им файлы несколько раз в месяц. Но сейчас все бекапы доступны у них на FTP и саппорт они уже не мучают!
gylys
Цитата(Drug @ 23.03.2008, 04:17) *

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

Тут наверно гвоздь програмы. Скажем у нас уже получается на сервере общего хостинга около 30 - 40 GB полезных данных и эта цыфра имеет тенденцию расти. То есть, с таким обчёмом данных на сервере, уже ежедневный бякуп становится проблематичным. Из практики, уже 5 гигабайтовые акаунты становится проблематичные для бэкапа. Но тут скажем проблемы решаемы, просто сперва надо определится или клиенту дать много дискового пространства или повышенную надёжность . С другой стороны, посмотрел на объём своего почтового ящика и там вижу 1.2 GB.
Из своего горького опыта (потери данных) могу сказать, что потеря очень больно бъёт и с моральной стороны и с финансовой.
По поводу бэкапа на том же сервере, то я считаю что в таком случае не имею бэкапа. Так как у нас общий хостинг дырявый и я в полне верю, что есть возможность чтоб кто то сумеет запустить "rm -f /". Дырявость эта политика, так как я не понимаю зачем нужен хостинг, в котором всё закрыто.

Цитата(Drug @ 23.03.2008, 04:17) *

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

Отличную работу проделали. Я как раз в этом направлении гребу.
Drug
Цитата(gylys @ 23.03.2008, 14:00) *

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

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

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