А с какого боку они там *должны* лежать?
Зачем кому-то его ломать? Сгенерировать эти самые бекапы по "секретным ссылкам" и подождать когда вы их зальете.
Грубо говоря - да. Т.е. защита от удаления/некорректного изменения информации пользователями. У которых есть доступ, все дела.
Люди ошибаются часто, знаете-ли. Чаще чем происходят "технические" проблемы (в частности, аппаратные) на основном носителе. Странно, что для вас это такой сюрприз.
Еще один "диагност"-самоучка... Сказать по теме нечего - зачем спамить?
duplicity? Не пробовал, но там походу webdav - должно все нормально работать.
Спекуляция вот:
Больше обращений != выше шанс отказа. Тем более, для конкретного пользователя.
Вон, через любую ГЭС проекает на порядки больше воды чем через ваш крантик на кухне. Но вероятность, что сломается крантик - больше.
У вас один, а я уже такую возможность стал серьезно учитывать, ибо укололся. Тем более для всяких raid5.
Вы выше выступали в роли персонального психиатра-диагноста. Уверен, без диплома. Так что не обижайтесь.
Чтобы советовать конкретное решение ТС в качестве альтернативы - лично для меня данных маловато. А так - я дал ему советы чуть выше и жду ответа на вопросы.
Профессиональный, конкурентноспособный коммерческий сервис, основанный на инженерных решениях, давно опробованных в инфраструктуре гугла - надежнее наколеночных поделок локалхлост-админа. Что тут стыдного?
В общем-то - знаю. Но не настолько чтобы читать персональные лекции - гуглячие доклады с подробными описаниями вполне должно быть вам найти по силам.
Может. Желаю того вам и дальше. Надеюсь, хоть хотсвоп в сторонке курит?
О чем тут спорить? Это бред.
Бекапы обычно нужны, когда секретарша маша похерила важный аччот. Случай технических проблем на основном хранилище - это область, скорее, райд и подобных технологий.
Ну да. Просто я о том, что в пользу "локального" бекапа для меня обычно имеют значения эти факторы. Но уж никак не отказоустойчивость локального хранилища.
Если приведете смешную оценку, конечно.
Ну во-первых, вам стоило бы сперва определиться - что у вас. Рейд-1, одиночный диск, рейд-5. Я писал о прогнозировании сбоя. С этим туго - что с облаком, что без.
А дальше начинаются ваши спекуляции на тему "вероятности" отказа, и что vps васи пупкина надежнее сервиса гугла.
А информацию *старую* вам на новом диске пушкин подарит? Вы дурачок, или просто прикидываетесь? - Конечно, в примере шла речь о потере данных на оставшемся диске в массиве.
Да нет, все кто интересовался - давно вкурсе. Это уже боян: http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162
Поищите в словаре значение словосочетания "здравый смысл". Ссылку как-то неудобно давать, думаю осилите.
Я скромный, конкурировать с гуглом пока не берусь.
Нет. Не я воюю со здравым смыслом и очевидностью.
Думаю, информации ТС на тему выбора схемы бекапа - более чем достаточно ;) Давайте подождем его ответа на заданные вопросы, чтобы не захламлять тему.
PS: Осильте уже цитирование?
Ежели информация *уже* убита - только ленивый или тупой не заметит.
Не обязательно "сразу". Чаще новый всплывает в процессе ребилда. Привет прогресс и терабайтники!
Ну а использующие raid-5 на больших современных дисках - имеют еще больше шансов сказать прощай своим данным.
И еще есть куча сценариев потери данных на одиночных дисках или в raid. Тема большая, сложная - и наивно полагать что вася пупкин сумеет лучше обеспечить сохранность данных чем профессиональный сервис, ориентированный на соответствующее применение.
Мой совет ТС - не полагаться на местных "гуру" и бекапить на облачные сервисы. Лучше, на то что хорошо и давно поддерживается duplicity. Обратите внимание, что в 0.6.18 *нет* gdocs бакенда (в статье, вероятно, использовалась ubuntu с патчем). ТС, какая у вас версия?
Я и не отрицал этого. Просто не вижу прямой связи между нагрузкой и высокой вероятностью отказа.
Повторяю, "фарманы" были проще (во всех смыслах), "нагрузки" на конструкции примитивных самолетов были несравнимы с авиалайнерами. Тем не менее, тогдашняя аварийность несопоставима с современным уровнем. Нет никакой простой связи между сложностью и работоспособностью - инженеров специально учат проектировать очень сложные системы, которые прекрасно работают.
К вам вопрос тот же, что и к Himiko - предложите конкретые пункты, которые нужно выполнить ТС, чтобы создать и поддерживать хранилище. Я готов поспорить, что найду пример того, что вы при этом упустите из виду.
Я не провайдер и не хостер - работаю с крупными веб-проектами. Каждый из них стоит того, чтобы разработать индивидуальную схему бекапа. Есть еще масса параметров, помимо сохранности оного, которые нужно учитывать при планировании - объем, согласованность данных, время на восстановление и т.п.
"Локальный" бекап предпочтителен при больших объемах и/или необходимости быстрого восстановления больших объемов данных. И в этом случае - лучше перебдеть и забекапить часть на облако.
Если упускать из виду существенные факты, которые не ложатся в ваше "мнение" = можно обосновать что угодно и как угодно.
Я подожду "оценки" от Rimlyanin, прежде чем смеяться над вашей.
Интересно, и какова же?
[09-Aug-2012 04:07:27] WARNING: [pool www] child 12043 exited on signal 11 (SIGSEGV) after 35.646667 seconds from start
Даже "фича", которая устраняет один из вариантов отказа? 😂
Всё следует упрощать до тех пор, пока это возможно, но не более того. Да и не очевидно что "проще" - локальное хранилище (с непонятками относительно поведения конкретных моделей дисков, прошивок и проч) или распределенное, где от кучи подобных вещей можно уже абстрагироваться.
Если бы ваша "логика" работала - фарманы были бы надежнее современных авиалайнеров.
Думаю, что даже конкретно вам можно рассказать пару новых вещей о том что нужно "мониторить", чтобы гарантировать себя от потерь данных при локальном хранении. Вас не затруднит предложить *конкретный* и *полный* список действий, который вы бы предложили ТС для сего "мониторинга"?
Ну не до такой степени, чтобы фантазировать о *массовой* потери данных клиентов :) (Чуть выше, другой оратор.)
Как и при локальном хранении. От необходимости регулярно проверять целостность бекапа вас не избавит ничего. Других вариантов убедиться, что все в порядке - нет.
Это "логично" на уровне "я щитаю" (с). А вот "я щитаю", что при добавлении новой фичи они учтут потенциальный рост нагрузки - и ничего подобного не произойдет. Это вопрос проектирования системы - только и всего.
Тоже вполне логично. Не логичным - выглядит ваше заявление, особенно если "новая фича" связана с увеличением отказоустоичивости хранилища.
Короче, главного вы не раскрыли:
1) добавление фичи
2) увеличение нагрузки
3) ???
4) profit!возрастание шанса отказа
Ну замените гугл на внезапно умерший жесткий диск. Или появившийся бед на самом интересном месте. Вы такое спрогнозируете?
venet не имеет мак адреса, потому что оно ему не нужно там. Технически.
> Как решить проблемку?
Если вам неприменно нужно присвоит маки для контейнеров - надо использовать в них veth, а не venet. Почитайте уже вики openvz, а?
Да ну? :)
http://zecrazytux.net/troubleshooting/apache2-segfault-debugging-tutorial#environment-and-symptoms
"Apache sometimes segfault. After investigation, it segfaults under some web vulnerability scans." (с)
Ну тогда конфиг nginx покажите.
Левые репозитарии нужно использовать пореже.
Подозреваю, что кроме поддержки fpm - небыло никаких реальных причин не использовать штатные пакеты php в debian. ТС, советую вам поменьше извращаться - используйте вместо php5-fpm обычный апач. Может быть вам и nginx перед ним ставить не имеет смысла (почему - обсуждали выше).
