Опубликовано (http://lists.gnu.org/archive/html/savannah-users/2009-05/msg...) объявление с описанием причин недоступности в течение нескольких дней хостинга открытых проектов savannah.gnu.org (http://savannah.gnu.org/). В четверг на сервере возникли проблемы с RAID-массивом, которые привели к повреждению файловой системы и утере части CVS/SVN/Git/Hg репозиториев исходных текстов. Проблема усугубилась тем, что последний бэкап оказался не полным, так как был произведен уже после частичного повреждения данных.В настоящее время работа сервиса полностью восстановлена (http://lists.gnu.org/archive/html/savannah-announce/2009-06/...), система переустановлена с нуля, а данные подняты из ленточного бэкапа, сделанного в конце апреля. Разработчики утверждают, что обычно бэкапы на ленту производились регулярно, но в силу определенных обстоятельств именно за месяц до краха с системой ленточного резервирования возникли проблемы. Статус восстановления можно (http://lists.gnu....
URL: http://lists.gnu.org/archive/html/savannah-users/2009-05/msg...
Новость: http://www.opennet.me/opennews/art.shtml?num=21980
Да уж, нафиг-нафиг такие хостинги, у которых нет денег на нормальную избыточность и на нормальный персонал.
>Да уж, нафиг-нафиг такие хостинги, у которых нет денег на нормальную избыточность
>и на нормальный персонал.Мы с удовольствитем опробуем и заценим ВАШ хостинг, избыточный и с нормальным персоналом.
Да, и самое главное - бесплатный.
>Мы с удовольствитем опробуем и заценим ВАШ хостинг, избыточный и с нормальным
>персоналом.Вы свой юмор демонстрируйте лучше владельцам проектов, которые потеряли свои данные из-за этого сбоя, они непременно его оценят.
Раз уж "назвался груздем, полезай в кузовок". Перед тем, как браться за какое-то дело, в особенности ответственное, то необходимо трезво оценивать свои возможности. Чтобы потом не получалось так, как в этом случае.
>Раз уж "назвался груздем, полезай в кузовок". Перед тем, как браться за
>какое-то дело, в особенности ответственное, то необходимо трезво оценивать свои возможности.
>Чтобы потом не получалось так, как в этом случае.С таким подходом человечество до сих пор бы сидело на дереве...
Планета была бы зелёная, деревьев море, море чистое, воздух чистый, ... а сомнительные развлечения вида "поубивать монстров на компе до 5-ти утра" заменены подобными же развлечениями, но в реале.
Проблема в том, что не мы бы развлекались охотой на монстров, а монстры бы развлекались охотой на нас.
> же развлечениями, но в реале.Да.И дохли бы в среднем к 30 годам... из-за элементарных заболеваний и укусов монстров в съедобные части тела.
>>Мы с удовольствитем опробуем и заценим ВАШ хостинг, избыточный и с нормальным
>>персоналом.
>
>Вы свой юмор демонстрируйте лучше владельцам проектов, которые потеряли свои данные из-за
>этого сбоя, они непременно его оценят.
>Раз уж "назвался груздем, полезай в кузовок". Перед тем, как браться за
>какое-то дело, в особенности ответственное, то необходимо трезво оценивать свои возможности.
>Чтобы потом не получалось так, как в этом случае.Я могу себя представить на месте владельцев таких проектов. Любой здравомыслящий человек должен понимать, что на шару не может быть такой же надёжности и сервиса, как за деньги. Я бы делал бэкап системы самостоятельно в дополнение к бэкапу хостинга.
А вас послушать, так лучше ничего не делать - всё равно ведь без денег круто не получится. Сплошной максимализм.
>Я могу себя представить на месте владельцев таких проектов. Любой здравомыслящий человек
>должен понимать, что на шару не может быть такой же надёжности
>и сервиса, как за деньги. Я бы делал бэкап системы самостоятельно
>в дополнение к бэкапу хостинга.
>А вас послушать, так лучше ничего не делать - всё равно ведь
>без денег круто не получится. Сплошной максимализм.github.com, bitbucket.org, code.google.com, sourceforge.net денег за хостинг небольших проектов не берут.
>github.com, bitbucket.org, code.google.com, sourceforge.net денег за хостинг небольших проектов не берут.к чему это вообще? У меня нет претензий ни к какому хостингу. Просто в случае бесплатных я предлагаю перестраховаться.
>Просто в случае бесплатных я предлагаю перестраховаться.бесплатно = плохо? меня именно этот момент интересует
>>Просто в случае бесплатных я предлагаю перестраховаться.
>
>бесплатно = плохо? меня именно этот момент интересуетне плохо. Просто по-другому. Менее надёжно (в случае хостинга).
>не плохо. Просто по-другому. Менее надёжно (в случае хостинга).Обычно эту песенку поют ... платные хостеры. При том что далеко не любой из них может похвастаться надежностью даже сравнимой с savannah, которая упала раз за сколько-то-там-дохрена лет.А уж померяться с какойнить гуглей надежностью им обычно и вовсе слабо.
А если что я видел минимум 2 платных хостеров частично потерявших недавние изменения.Вообще это достаточно заурядная ситуация у хостеров.И если кто платит деньги за хостинг - это еще не 100% гарантия и совсем не повод выключить мозг.
Кроме всего прочего - только тот кто лил изменения знает точный момент когда стоит сделать бэкап, а хостер делает когда ему там удобнее.При откате даже ежедневного бэкапа неизбежно будут профуканы все изменения за день.То есть, немало народа останется недовольно потерянными изменениями которые они как раз внесли а тут то и обломинго.Как ни крути.
Очень мило, что вы решили сообщить нам своё мнение о платных хостерах. Только непонятно, причём тут я и мои посты? Вам кроме как пофлудить делать больше нечего?
>Очень мило, что вы решили сообщить нам своё мнение о платных хостерах.
>Только непонятно, причём тут я и мои посты? Вам кроме как
>пофлудить делать больше нечего?наверное при том, что «бесплатно — это менее надёжно» (очевидно, чем платно) — это твоя теория была.
Как правило, "платно" = "выплата неустойки при аварии", причём размер неустойки существенно выше, чем месячная плата за хостинг. Предполагается, что угроза неустойки сподвигнет хостера обеспечить надёжность.Но если в EULA не оговорены неустойки (а т.б. оговорено, что неустоек не будет), платность ни грамма не означает надёжность. Я думаю, все поняли, в чей огород камешек.
>Как правило, "платно" = "выплата неустойки при аварии",Далеко не у всех - отвечать за свои ляпы никто не любит (а те кто отвечает - не забывают отразить в ежемесячной плате соответствующий риск своего ремесла, разумеется).И кроме того неустойка это конечно круто, но даунтайм - в любом случае неприятно.И что интересно - случается же.
>выше, чем месячная плата за хостинг. Предполагается, что угроза неустойки сподвигнет
>хостера обеспечить надёжность.Повышать надежность имеет смысл до определенного предела.Да, можно например сделать пятикратное резервирование всего и вся.Надежность будет на уровне.Но - затраты на инфраструктуру вырастут в 5 раз и скорее всего хостить вообще станет невыгодно.
>Но если в EULA не оговорены неустойки
А что такое EULA у хостеров?Вообще-то EULA - у программ ;)
>поняли, в чей огород камешек.
Лично я понял только одно: стафф комерческих хостеров пытается вещать про то как у них все круто, оппортунистично пользуясь удобным случаем (надо же, впервые за хренадцать лет упал какой-то опенсорцный хостинг!).Я бы на их месте кивал на дерьмовые дешевые (и "псевдобесплатные") хостинги лучше - это более показательный пример т.к. падают отнюдь не раз в хренадцать лет :)
>и сервиса, как за деньги.Пардон, коммерческие хостеры без проблем про%#ывают данные.Надеяться на "дядей" в вопросах бэкапов - последнее дело.Я лично видел минимум 2 буржуйских хостеров которые профукали клиентские данные и смогли вернуть как максимум частичную копию на момент сбоя и не шибко свежий бэкап.А еще можно вспомнить как отечественный (а хотя-бы и платный) хостер после возникновения конфликтной ситуации на сайте bitchx.ru (или как его там) когда автор вывесил спорные картинки просто снес проект.Отказавшись отдавать бэкапы вообще.Сильно приложив мордой об стол владельца сайта, поленившегося самостоятельно делать бэкапы регулярно и положившись на сервис хостера.
Кто-то учится на чужих ошибках, заранее.Ну а растяпы получают честно заслуженный урок.А суть в том что самый надежный бэкап - это который делаете лично вы, в физически иное место нежели оригинал.А надеясь на дяденек, даже платных, можно и обломиться.
правильно ли я понял, что вы считаете, что за деньги сервис ничем не лучше, чем бесплатно?
К несчастью это именно так в подавляющем большинстве случаев. Есть отдельные товарищи, которым можно доверять. Но на каждого такого товарища дофига баблорубов.
В *среднем* платный лучше, конкретные случаи могут отличаться.
>В *среднем* платный лучше, конкретные случаи могут отличаться.В среднем имхо достаточно однохренственно, если сравнивать с нормальными хостерами типа сорсфоржей, саванн и уж тем паче гуглей.Лично я плачу платным хостерам по более другой причине: бесплатно никто мне не даст машину с рутом где я буду сам себе режиссер в плане выбора настроек, сервисов, приложений, ... ;).А стандартный набор приложений это немного не то что мне надо как правило.Это вариант решения для тех кто настолько нищ что не может наскрести денег на оплату своего сервера или хотя-бы VDS - да, бомжи могут рассчитывать на стандартный бомж-пакет.А кастомизабельность под себя - удел тех кто может заплатить.
Более того - могу показать дерьмового и платного хостера, на фрибсд кстати :).FirstVDS называется.Номинально он платный.Реально - годен только для бомжей.Даром что на фряхе - общая стабильность работы всего этого фуфлохостера загонит в гроб любого админа мало-мальски ответственного сервера.Платные хостеры тоже как видим бывают разные, так что нефиг юродствовать...
>В *среднем* платный лучше, конкретные случаи могут отличаться.Ну... это как средняя температура пациентов в больнице.
Посчитать её можно, но информации от неё нет)
>Вы свой юмор демонстрируйте лучше владельцам проектов, которые потеряли свои данные из-за
>этого сбоя, они непременно его оценят.
>Раз уж «назвался груздем, полезай в кузовок». Перед тем, как браться за
>какое-то дело, в особенности ответственное, то необходимо трезво оценивать свои возможности.
>Чтобы потом не получалось так, как в этом случае.можно узнать, где в ToS саванны пункт «мы обязуемся во что бы то ни стало вне зависимости от чего бы то ни было сохранять ваши данные целыми»?
а пользоваться code.google.com или соурс-форжем религия не позволяет?
>а пользоваться code.google.com или соурс-форжем религия не позволяет?сообщение абсолютно не в тему. Зачем мне code.google.com? Я не программист и у меня нет своих проектов.
Да это то как раз и так понятно :)
Программисты и так знают что у них есть всё в локальной VCS,и кстати там прямо в новости написано что им предложили "перезалить". Но ты же не знаешь как это всё работает :)PS: А ваша професия - "набрасывальщик на вентилятор" называется да? :-)
>Программисты и так знают что у них есть всё в локальной VCS,и
>кстати там прямо в новости написано что им предложили "перезалить". Но
>ты же не знаешь как это всё работает :)Знаю в общих чертах.
>PS: А ваша професия - "набрасывальщик на вентилятор" называется да? :-)
Да. Именно так. А ваша - "раздаватель советов не в тему"?
>а пользоваться code.google.com или соурс-форжем религия не позволяет?неа. у гугля нету git, а у саурсфоржа настолько дебильный интерфейс, что никак не получается комфортно его использовать.
> у гугля нету gitон и не нужен, там есть средства получше.
>> у гугля нету git
>
>он и не нужен, там есть средства получше.а я, в данном случае, не обсуждаю, что лучше, что хуже. лично мне вот нужен git. а его нет. а жаль, потому что минималистичная морда гуглокода мне по нраву. но увы.
>а пользоваться code.google.com или соурс-форжем религия не позволяет?Если вы такой умный то чего строем не ходите? :D
У меня на проекте sf.net был утерян форум и часть багтрекера, ну и что? сказали что были сбои в системе, извинились. Бывает. Тот же шелл на сф.нет тоже лежал совсем нередко. С свн были очень серьезные глюки, рассинхронизация ro и rw репозиториев. Скорость тоже порой крайне низкая. Так что не надо ляля про беспроблемный sf - проблемы бывают у всех и не всегда получается восстановить все как было, увы.
эх коллеги, сразу видно у вас ни разу не падало сразу два винта в 5-ом рейде и FC HBAшка двухпортовая :-)
думаю у пользователей DVCS и так нормально все с избыточностью :)
интересно что за ФС полетела
А какая разница. Полетела не система, а RAID.
У меня на серваках были случаи когда SATA диски (WD RAID edition) выходили из строя через 3-6 месяцев. Ну ни как не ожидал.
Без одного диска RAID остается работоспособным, но надо срочно бежать - менять т.к. без двух дисков RAID разрушится.
Я пользуюсь 1U серваками. Там обычно не более 4 дисков. Значит или RAID5 или RAID10. Даже на RAID6 дисков не хватает.
>Я пользуюсь 1U серваками. Там обычно не более 4 дисков. Значит или
>RAID5 или RAID10. Даже на RAID6 дисков не хватает.Тогда это не хостинг, а какой-то трудноподдерживаемый бред. Зачем вообще нужно много мелких массивов с мизерной избыточностью? Значительно проще и дешевле эксплуатировать большой массив в корпусе 2U или 4U с hot-spare, чтобы не бегать сломя голову при каждом сбое.
Да хоть на все 43U!!! Если с железякой проблемы ты всё одно приплыл! :(Кстати - перечитай новость еше пару сотен раз чтобы понять - по крайней мере ежемесячный долгохранимый снапшот они делают. Так что я думаю они представление о DR & BC вполне себе имеют.
>они представление о DR & BC вполне себе имеют.Да просто дерьмо может случиться у любых.И то что отколупали на саванне - не самый плохой вариант.И тем кто молится на гугля и SF - а вы железно уверены что в следующие хренадцать лет эти двое не просрут ни толики данных ни у одного проекта?
>>они представление о DR & BC вполне себе имеют.
>
>Да просто дерьмо может случиться у любых.И то что отколупали на саванне
>- не самый плохой вариант.И тем кто молится на гугля и
>SF - а вы железно уверены что в следующие хренадцать лет
>эти двое не просрут ни толики данных ни у одного проекта?
>Скажу больше - у сф были очень серьезные проблемы с СВН когда они его ввели. Ну а главное - действительно стоит помнить что никакого SLA в данном случае нет и делать дамп репозитория самостоятельно, благо они это позволяют. Ну а локальная копия полюбому есть, так что самое страшное что может случиться в случае отс-вия бекапов - это потеря логов изменений, ну так это не такая уж и беда для проекта.
В рассылках savannah также отмечено преимущество Git и Mercurial (Hg) в такой ситуации - репозиторий можно полностью восстановить из локальной копии. Так что пользуйтесь распределенными системами управления версиями и ничего не бойтесь.
Полетел бы массив у другого хостера, и всякие анонимусы гнали бы на него.
И приводили бы в пример Savannah, у которого ничего не падает.
Риск, что железо вот так откажет, есть всегда.
Пусть очень маленький, с вероятностью 1 на 1 000 000.
Поэтому лучше не верить свято в какую-то технологию и делать свои бекапы.
>лучше не верить свято в какую-то технологию и делать свои бекапы.где они, эти ежедневные или хотя бы еженедельные бэкапы?
>>лучше не верить свято в какую-то технологию и делать свои бекапы.
>
>где они, эти ежедневные или хотя бы еженедельные бэкапы?Решили сойти за умного?
Я написал "свои бекапы".
Думаю, те пользователи Savannah, кто делали бекапы, уже восстановили свои данные из них.
Подозреваю, пользователи Git и Mercurial пострадали меньше всех. Поскольку локальный репозиторий всегда с собой :)
>Подозреваю, пользователи Git и Mercurial пострадали меньше всех. Поскольку локальный
>репозиторий всегда с собой :)Хороший подход, не спонсирующий слепую веру в "дядей".Дяди - не боги.Они тоже могут лажануться.А хотя-бы и раз в хренадцать лет.
>Хороший подход, не спонсирующий слепую веру в "дядей".Дяди - не боги.Они тоже
>могут лажануться.А хотя-бы и раз в хренадцать лет.У google слишком много сотрудников имеют долступ к bigtable, у которого, насколько я понимаю, нет разеделния данных и прав доступа к ним. Т.е. любой прграммер из поискового отдела имеет доступ к допустим к данным gmail. То что google официально не сливает спецслужбам данные, еще не гарантирует внутренней утечки через сотрудников. У нас именно из-за нечистоплотных сотрудинков разных гоструктур в сети и гуляют базы ГАИ, паспортного стола и налоговой.
>>Хороший подход, не спонсирующий слепую веру в "дядей".Дяди - не боги.Они тоже
>>могут лажануться.А хотя-бы и раз в хренадцать лет.
>
>У google слишком много сотрудников имеют долступ к bigtable, у которого, насколько
>я понимаю, нет разеделния данных и прав доступа к ним. Т.е.
>любой прграммер из поискового отдела имеет доступ к допустим к
>данным gmail. То что google официально не сливает спецслужбам данные, еще
>не гарантирует внутренней утечки через сотрудников. У нас именно из-за
>нечистоплотных сотрудинков разных гоструктур в сети и гуляют базы ГАИ, паспортного
>стола и налоговой.Сливает, кстати. Было пару скандалов, связанных именно со сливом спецслужбам Китая.
только скандал был с yahoo.
Сервера находящиеся на территории китая подчиняются юрисдикции китая, и априоре не гуглу решать могут или нет их спецслужбы пользоватся инфой с тех серверов. Где-то они заявляли что почтовые сервера в китае не держат поэтому
>только скандал был с yahoo.
>Сервера находящиеся на территории китая подчиняются юрисдикции китая, и априоре не гуглу
>решать могут или нет их спецслужбы пользоватся инфой с тех серверов.
>Где-то они заявляли что почтовые сервера в китае не держат поэтому
>Да, вы правы, перепутал. Нашел их пресс релиз о работе в Китае:
(3) Limit Services
Google.cn today includes basic Google search services, together with a local business information and map service. Other products – such as Gmail and Blogger, our blog service – that involve personal and confidential information will be introduced only when we are comfortable that we can provide them in a way that protects the privacy and security of users’ information.
> имеют долступ к bigtable, у которого, насколько я понимаю, нет разеделния данных и прав доступа к ним. Т.е. любой прграммер из поискового отдела имеет доступ к допустимвы далеко зашли в своих фантазиях, но это осталось лишь вашей фантазией. И пожалуйста не сравнивайте Google с Гаи.
>не гарантирует внутренней утечки через сотрудников.Понимаете, если вы хостите какой-либо ресурс у "дяди" эту возможность никогда не стоит сбрасывать со счетов, как не стоит сбрасывать со счетов ненулевой шанс что "дядя" возымеет на вас зуб или лопухнется.Также не стоит сбрасывать со счетов то что ВАШ трафф прет по ЧУЖИМ каналам за тридевять земель.И что там с ним на этих каналах сделают - тоже никому не известно.Решения этих проблем - есть.Просто нефиг проявлять излишний оптимизм, тогда не будет мучительно больно за глупые промашки...
>Подозреваю, пользователи Git и Mercurial пострадали меньше всех. Поскольку локальный репозиторий всегда
>с собой :)А SVN не с собой?
>>Подозреваю, пользователи Git и Mercurial пострадали меньше всех. Поскольку локальный репозиторий всегда
>>с собой :)
>
>А SVN не с собой?В локальной копии свн нет истории всех изменений.
>А SVN не с собой?Насколько я понимаю git клонирует полноценную копию репа, с всей историей изменений и прочая (можно запретить, но зачем?) а не обрубки как у svn.
>Разработчики утверждают, что обычно бэкапы на ленту производились регулярно, но в силу
>определенных обстоятельств именно за месяц до краха...Действительно, ну не западло? Иначе, как саботажем назвать не могу.
У нас крутится ежедневный бэкап - тупо архивируем и кидаем на второй, независимый винт. Ежедневно. Что интересно, жмётся всё на ура и в результате становится не так накладно хранить на винте. Ленты - дело хорошее, но слишком спецефичное оборудование - винты куда доступнее и проще в эксплуатации.
>Действительно, ну не западло? Иначе, как саботажем назвать не могу.Обычно всякие ЧП так и бывают - ряд технических накладок завязываются в узел.Получается авария...