Причем здесь какое-то "ведение бизнеса"? Просто сталкивался (и как клиент; и как сотрудник) - с работой многих компаний. И с теми кто врет клиентам (в указанном выше смысле - скрывая проблемы), и с теми кто нет. "Вруны" - медленно, но верно проигрывают.
Естественно, это можно мнением: вы всерьез считаете, что в подобном вопросе кто-то владеет информацией настолько, чтобы опубликовать суръезно социологическое исследование? Так что если вы считаете, что врать клиентам - не беда, то кто я такой чтобы вас в этом разубеждать?
Может быть, вы просто недостаточно умны?
Только в одном случае примеров навалом (ткни в любой крупный vps-хостинг), а в другом - нуль. И все вполне понятно - у VPS-провайдеров чуть иные задачи и возможности.
Вранье состоит в самом сокрытии проблемы. В нормальном случае - выпускается пресс-релиз. Если проблема затрагивает четко ограниченный и небольшой список клиентов - они персонально оповещаются (вне зависимости от того, заметили они проблему или нет).
Да никому внутренняя кухня не интересна, речь и не об этом.
"Не любо - не слушай" :D Пишу в расчете на тех читателей, у кого есть собственная голова на плечах. Если там каша - в любом случае "пиши пропало". Хоть слушай - хоть не слушай.
Меряться будем, да? :) Чего тут меряться - вы не админ, а я не манагер.
Ну, этой весной метеорит диаметром 10км не столкнулся с Землей. Какие вам нужны еще "доводы" в подобном случае, кроме отсутствия факта проблемы как такового? :)
Я, в принципе, вам охотно верю. Но здесь больше вопрос доверия - ваши сервисы менее публичны, клиентов чуть меньше и т.п.
Ну, выше вы конкретные рекоммендации по созданию хранилища для бекапа и его проверке - дать отказались. Так что черт его знает - "устойчива" ли эта работа, или вы просто не заметили порчи данных. И такое бывает.
В случае гугла - все куда более прозрачно. Известно и как устроено хранение данных, да и с теоретической стороны - никаких препятствий созданию сколь угодно надежного распределенного хранилища нет.
Почему?! Повторяю, вранье клиентам и сокрытие проблем - не лучший метод ведения бизнеса. Жаль, если вы так это и не усвоили.
Так что не переживайте и можете снять вашу шапочку из фольги.
Гм... Это вы про хостеров из одного сервера али аж из двух? :)
Это значит что единственная доступная практическая оценка - нуль. Все остальное высосано из пальца.
Клиенты гугла.
Да (кстати, что - а гугл уже единственный поисковик?). Врать и скрывать проблемы - не выгодно. Это только для отечественных "бизнесменов" является сюрпризом.
Разница в провайдерах. Проблемы с облаком у гугла - пока надуманны, а про VPS провайдеров мы все знаем. И диски в рейде вовремя не меняют, и raid5 используют, чтобы место было задешево. Потеря данных тут - дело обычное.
Совет глупый. Вы не знаете про шифрование? ТС, к примеру, знает и использует.
Но проблемы-то была вообще в другом ;)
Я *не* советую GDisk. Выше я дал вполне конкретные советы по поводу вполне конкретных проблем ТС (напоминаю, они *не* заключались в выборе gdisk vs vps).
Что касается выбора между облаком и локальным бекапом - маловато данных, чтобы что-то советовать. Сам выберет. Я лишь показал, что в плане надежности (а есть еще куча параметров) - приемущества локального хранилища иллюзорны.
Мне жаль, что я не сумел убедить вас в этом. Но обратите еще раз внимание: ваше "а что будет когда google скажет 'упс'" - целиком было гипотетическим (пример *потери* данных в студию?), в то время как я вам приводил уже несколько вполне конкретных сценариев потерь данных на "localhost" хранилище. На некоторые из которых вы даже сами натыкались.
PS: Ну и VPS не лучше гугла по той простой причине, что вы опять полагаетесь на провайдера. Никто вам SMART-параметры не даст мониторить ;) Надеюсь, вы опять "опечатались" и перепутали дедик с vps.
Не флеймил. Но мое мнение о дискуссии не обязано совпадать с мнением модератора(ов).
Открыть для себя существование документации:
https://developers.google.com/appengine/docs/
Покажите конфиг виртуального хоста + содержимое htaccess.
Вероятно, данный "адрес" обрабатывается у вас PHP интерпретатором. Нужно будет
1) убрать обработчик для данного урл: директивы Location и RemoveHandler
2) выставить подходящий тип для файлов: директивы Directory и DefaultType
Вам сюда: http://httpd.apache.org/docs/
Хм, не вижу причин для появления безумных записей в access_log. Что-то странное.
Нужен более быстрый вариант - правьте скрипты, кеширование используйте (на уровне HTTP, на уровне опкода), а не занимайтесь ерундой. От простой смены шила на мыло - быстрота не появится.
Согласен. Иллюзия полного контроля и возможности прогнозировать проблемы у вас есть (оставим в сторонке оговорку - все-таки на редком *VPS* вам дают состояние дисков мониторить ;)). Но с другой стороны, тот же google ведет мониторинг, при куда большей избыточности данных, лучшем и более доступном техническом персонале, наличии более представительной и полной статистики (тех же смарт данных).
Вы можете прогнозировать сбой, используя предыдущую статистику проблем у данного провайдера. В случае обостренной паранойи - используйте несколько независимых провайдеров.
Без никакого представления об объеме данных, о том что они собой представляют вообще? Не, ну нафиг такой "совет".
Да в том-то и дело, что все можно посчитать. См. выше процитированную статью, по гуглу или яндексу тоже гуляет порядочно статистики. Глупо думать, что инженеры гугла при проектировании не используют математику на уровне третьего курса ;)
Был вполне конкретный список проблем *при* использовании gdisk + duplicity. Я спросил версию duplicity и посоветовал обновить (поддержку gdocs добавили совсем недавно, до того были патчи в разных дистрибутивах). Либо использовать облака, с которыми можно работать стандартными протоколами (напр, webdav).
RAID6 это не RAID5, речь все-таки шла о последнем у меня и в статье. Большая разница.
У вас действительно есть диплом психиатра? 0_0
Покажите пожалуйста, я в него не верю - и убежден что это не мои "домыслы".
Да всем тут вроде удается. Кроме вас да андрейки, быть может.
