Как стать автором
Обновить

Комментарии 113

Использую под бэкапы Amazon S3 даже если у них что-то где-то погорит выручит репликация амазона. Для небольших проектов отдать 10-20$ в год за надежные бэкапы не так много.
Да, просто до этого случая казалось что на дружественный сервер в соседней стойке скинуться раз в месяц — это хорошо и надежно =)
Оказалось что нет.
НЛО прилетело и опубликовало эту надпись здесь
У нас в Беларуси, канал в 2 мегабита — предел мечтаний, полный бекап — больше 10 гигов, он за ночь не успевает выкачаться даже если все остальное стоит, т.е. это не так просто как хотелось бы.

Но основная причина была, как уже писал: «Ну что может случится такого что бы потерять данные на 2-х серверах одновременно?» — теперь знаем что =)
rsync, телемаркет.
Научите? :)
Используй для бэкапа amazon s3, Люк!
Уже смотрим в эту сторону. Хотя есть мысль взять полностью дублирующий сервер, что бы переключиться в случае чего «в 2 клика».
вам винт отдали, а нам его пришлось стырять с дц, когда его опечатали.
Ну мы только во вторник добрались до этой задачи, а там уже печатей не было
я прошу прощения, я не про hosting.ua говорил, наш дц опечатали давно и не в этой стране, этот дц так и стоит с кучей серверов выключенный
Сочусвтую, это тот же пожар =(
>Чему мы научились?

Как в южном парке, сегодня мы научились многому. Забить на это, не Чернобыль же.
> сегодня мы научились многому
Так и есть =)

> Забить на это, не Чернобыль же.
Ну если забивать, то локальные «чернобыли» будут повторяться постоянно. Очень важно из таких косяков выность что-то «полезное».
спасибо за топик, я хоть и не админ, но выводы для себя сделал)
Интересно сколько в Одессе за первые дни происшествия открылось минифирм, которые умеют ездить в ДЦ забирать железо клиентов, быстро его вскрывать/сушить/чинить и заливать владельцам. Имхо отличный бизнес для «надёжных линуксоидов»
Не знаю, но очень многие готовы были платить хорошие деньги. На то что бы обеспечить работу «фирме» конечно не хватит, но на то что бы сделать 2-3-4 зарплаты за неделю — это вполне.
Вы не правы. все сервера в датацентре были опечатаны. мы посылали даже ребят из СБУ, чтобы узнать судьбу нашего F301 (таки полносьбю сгорел), но никто никому ничего не отдавал. отсюда Ваше предположение неверно. а вот цены на хостинг в некоторых конторах реально поднялись, стервятники мля…
НЛО прилетело и опубликовало эту надпись здесь
дело в том, что сидя в Донецке ситуация неизвестности очень изматывает, поэтому приходится идти на такие крайние меры. понятно, что при рядовых рабочих моментах с этими ребятами никто и связываться не стал бы.
Я опирался исключительно на рассказ автора поста. А то что такой срочный сервис не предложил сам хостер это свинство. Они должны были имхо с первого момента предложить любую помощь через сторонние сервисы, через срочно найденных партнёров, через кого угодно, вместо того чтобы затягивать, я так понимаю до сих пор масса людей не смогла ещё ничего восстановить
НЛО прилетело и опубликовало эту надпись здесь
откуда у Вас столько внутренней кислоты к людям?
Пошел делать бэкапы в третий ДЦ…
НЛО прилетело и опубликовало эту надпись здесь
С тех пор к в датацентрах сталис тавить системы пожаротушения и т.д. Мне казалось что «сгореть» целое помещение ну просто никак не может (да еще и то где мы размещаемся).

Оказалось что я ошибался.
НЛО прилетело и опубликовало эту надпись здесь
Речь о том, что большинство не относится к пунктам про ЧП серьезно, потому что вероятность ЧП на много порядков ниже, чем вероятность отказа железа, канала, итд
Автор зря смеетеся над процедурой бэкапов. Работаю в датской компании (не связанной с ИТ). У нас процедурное требование — бэкапить все на 400гиговую магнитную кассету раз в день. Недельную кассету увозят на хранение к поставщику. Наслучай ЧП или форсмажора.
Автор был на нервах 4-ро суток, пока восстанавливал данные. Теперь требование «бекапить физически в разные места» не выглядит избыточным.
ну что за мудаки дают минусы таким постам?
НЛО прилетело и опубликовало эту надпись здесь
Нужен профессиональный совет — какой сервис может подключаться раз в день по ftp к сайту и скачивать его полностью? S3 так может?
И сразу про базы данных — есть возможность и к ней подключиться и сделать бэкап.
Конечно, я хочу полной автоматизации, без лишних телодвижений. Настроил и работает.
Спасибо за ссылку, но интересных простых решений там нет. Хотелось бы забить имена/пароли/явки, выставить время и забыть (желательно, конечно, навсегда).
из комплексов — bacula, amanda
Я применяю самописные скрипты на базе mysqldump+tar+scp, авторизация по ключам, никаких паролей палить не нужно, чем не «простое, интересное» решение? Уровень его простоты/интересности зависит только от вас.
Если никогда раньше не делал таких решений — сразу не получится. Хороший мануал бы. Bacula, amanda — по описаниям многообещающие, но для человека, который новичек в создании сайтов это тоже не самое ясное решение.

Хочу большую кнопку Back it up.
И еще одну — Don't panic.
по бекапам очень много хаутушек в сети, в том числе и на хабре раз, два, три, четыре.
rsync. Для него есть графическая оболочка — Gadmin-Rsync, в Убунте есть в родных репозиториях. Один раз настроить, и запускать по крону. У меня на VPS стоит ISP Manager Lite, он делает автоматический бэкап баз. А rsync настроен скачивать сайты и папку с архивами баз. ISP Manager Lite может создавать и архивы сайтов тоже, но для меня это неудобно — слишком много дискового пространства VPS на это расходуется. При безлимитном интернете проще раз в сутки синхронизировать на свой домашний компьютер. В идеале — настроить бэкап по дням недели в семь разных папок, чтобы не оказалось, что последний бэкап содержит неполную (например, в результате сбоя диска) или ошибочную (в результате идиотизма контент-мейкеров) информацию.
Для машины-реципиента под Windows самое лучше решение — GoodSync. А на сервере-доноре обычные скрипты на баше, которые и бэкап базы сделают и архив из папок соберут.
Зачем платить больше если есть SyncToy2 www.microsoft.com/downloads/details.aspx?familyid=c26efa36-98e0-4ee9-a7c5-98d0592d8c52&displaylang=en
Если я правильно понял из описания, то заготовок для разных типов данных ни вижу, потому если уж и платить, то за програму где такие заготовки уже есть, чтобы не выискивать где же этот Outlook хранит настройки, или где базы SQL Server, например пользоватся Genie Backup Manager. Кстати в Window 7/2008 есть встроенная сохранялка, которая знает о «библиотеках» в отличие от большинства «современных» програм.
Во всех статьях рекомендациях по резервному копированию пишут, бекапы нужно хранить физически в разных местах.

до 9.11 в сша одна компания делала бэкапы с из одного здания в другое — потом стала делать на разные побережья.
а тут один дата-центр.

поздравляю что все востановили
> поздравляю что все востановили
Спасибо.

Это был тот самый «бесценный» опыт.
Скоро будут делать с одной планеты на другую
а что говорят в hosting.ua? Они просто извинились или предложили какую-либо компенсацию?
Судя по тому, что в пресс-релизе на главной странице пожар заявлен «форс-мажором», и следовательно, «хостер никакой ответственности не несет», то вряд ли. Там даже извинений не было, просто констатация факта.
Сгорел без возможности восстановления сервер и дополнительный жесткий (как же безопасность, бэкапы… очень помогло! ) ).
На сайте извинений нет, в тикетах (стали доступны через неделю), аналогично.

Такое заманчивое предложение с их стороны, весь в раздумьях… Цитирую:
«так же, принято решение всем пострадавшим клиентам на выделенных серверах выдать скидку на оплату сервера в течении 12 месяцев в 25%»
Они 4 дня вообще молчали (да-да, вообще), ни о какой добровольной компенсации я пока не слышал, судебных перспектив — нет (договор на физ. лицо, доказать убытки сложно, а судится за моральный вред в другой стране — нет смысла).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
я думаю сам яндекс мог бы тоже зарабатывать на хранении кеша как услуги, а не как части поисковой системы
НЛО прилетело и опубликовало эту надпись здесь
Не совсем вариант :)
Моему сайту чуть больше 2х лет. Рекламы самый минимум висит, сделан для людей, до сих пор нет в Архиве…
Мне видится, что кеш поисковиков не сойдет для полноценного восстановления данных. Вернуть можно только текстовую информацию, картинки и другие данные ими не кешируются.

После падения хостера, на котором располагался известный буржуйский блог codinghorror.com, в обсуждении к теме как найти потерянные картинки некто предложил на все запросы img отправлять в ответ 304 код(?), чтобы использовать браузерный кеш, а все вытащенные картинки, используя магию и колдовство, отправлять скриптом обратно на сервер. Конечно эффективность данного метода низка, но от этого не безнадежна.

А как отдельный сервис — уж лучше самим распоряжаться бекапами. С умом, конечно :)
Для полноценного восстановления — нужны бекапы.

А вот для «пожарного» кеш поисковика это то что можно быстро достать, и чем он хорошь, что позволяет сохранить сайт в индексе. С картинками хуже, достать их из чужого кеша нельзя…
НЛО прилетело и опубликовало эту надпись здесь
Не буду голословным, вот ссылка на статью, где приводятся исходники и объясняется принцип: Get cached images from your visitors.

P.S. Я не проверял, насколько это работоспособно, так что пробуйте сами :)
HTML 5 — этим все сказано =)
а кого сейчас этим удивишь? :)
эм, ну пока скорее удивить можно его поддержкой =)
НЛО прилетело и опубликовало эту надпись здесь
Не совсем, вам нужно
1. что бы весь сайт остался в кеше у пользователей которые используют браузер с ПХП5
2. что бы эти пользователи снова пришли к вам на сайт и отсмотрели те же страницы на которых они уже были

учитывая что доля пользователей с поддержкой 5-го ХТМЛа мала, еще меньшая их часть хранит кеш дольше необходимого, и еще меньше из них зайдет на те же страницы где они уже были…

Пока это скорее гепотетическая возможность чем реальный способ получить картинки.
Только не «браузер с ПХП5», а «браузер с ХТМЛ5»
ну да, что-то заработался.
В кэше поисковиком могут храниться и целые страницы, со всеми картинками и пр. (я о оформлении сайта)
Вы имеете ввиду картинки в Google Images? Вполне возможно, но я неуверен. Надо экспериментально проверить.
Ненене, вот таким запросом в гугле «cache:peleken.ru» я сейчас просмотрел сайт фонарно взятой турфирмы. Попробуйте.
В таком случае точно не хранит: посмотрите на свойства изображений. Они загружаются по адресу этого сайта, а не с гугловского сервера, а значит не находятся в кеше.
Хм, точно… Я раньше думал, что страница вся находится в кэше…
Это[грабберы] одно из ведущих направлений, у нас уже был готов граббер вебархива и парсер яндекса, поэтому очевидной реакцией было быстренько его «допилить».

Как «продукт» — я бы его выпускать не стал, это не игрушка, а на заказ — пожалуйста.
А почему 502, а не 503?
«Error 502: Fire in DC.»
Хотя и не смешно, блин, но я свои ресурсы хотя бы восстановил.
Это Вы о чём вообще?

Ситуация автором заметки описана достаточно подробно. Установление сервера, информирующего посетителей об ошибке, на одном из начальных этапов восстановления работоспособности было вполне правомерно и целесообразно.

Мне только непонятно, почему статус поставили не 503 («Service Unavailable», «The server is currently unable to handle the request due to a temporary overloading or maintenance of the server»), а 502 («Bad Gateway», «The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request»).

Моя догадка заключается в том, что в спешке было не до этого и поставили первый пришедший в голову, хоть и неподходящий статус. Тем не менее, я считаю нужным уточнить у автора.
Отдавали 503, ошибся при написании. Хотя думаю что это было не принципиально, важно было
1. показать что сервер недоступен
2. показать что это временно
3. дать информацию о причинах
srv1.smartdesign.by/ вот пример страницы
Ведь казалось бы, прописные истины (разнесённый бакап, step-by-step Disaster Recovery Plan на доске объявлений в офисе и в виде pdf рядом с каждой копией бакапа), а до всего люди доходят своими шишками.
Люди практически до всего доходят своими шишками. Реже — чужими.
Просто чужие шишки часто кажутся такими «надуманными», пока не заимеешь свои такие же =)
пугают меня такие топики — уже года 3 собираюсь начать делать нормальные бекапы… недавно звонил клиент, сайт не работает несколько дней — срочно в саппорт, там говорят мол авария (США), может скоро восстановят. Предлагаю клиенту поднять сайт на личном сервере — те на всё согласны… а у меня БАЦ и последний бекап — сентябрь прошлого года, да еще и только файло, без базы =) в общем клиент расстроился но не ругался

кто что подскажет под бекапы (10-20 Гб) кроме Амазоновских серверов?
hetzner'ы.
посмотри фотки hetzner — стелажи чуть ли не из икеи с десктопами.
Думаю, не самое лучшее место для бэкапов
У нашего сервака в hetzner на днях исполняется 500 суток непрерывного аптайма.

Знаете, я лучше доверю свои бекапы людям, воспитанным в среде пунктуальности и профессиональной ответственности (Германия), и мне пофиг, что стелажи чуть ли не из икеи с десктопами — факты говорят о том, что это волшебные стелажи с волшебными десктопами, где все работает как надо с беспрецедентной надежностью (1,5 года абсолютно непрерывной работы я все же считаю значимым достижением, поскольку эти 1,5 года не просто заявленной надежной работы, а реально осуществленной).

У hosting.ua, насколько мне известно, был достаточно хороший датацентр с сексуальными стойками, и блейдами в них. Вот только был. Разницу чуете?

Так что Вашу иронию считаю тут неуместной.
Спасибо за подробный рассказ. Мне лично пригодится такая информация. Кстати, как и вы, я считаю, что хостер поступил неразумно, не пытаясь освещать произошедшее сразу. Ведь не зря же придумали Twitter, да и много других мест…
как сказал недавно в связи с аварией в датацентре гугла: «Хватит говорить о бекапах, пора говорить о процедурах восстановления»
сказалИ на кранче
> 2 типа: 1-делают бекапы, 2- уже делают
наоборот :) делают и ЕЩЕ НЕ делают
отсутствие чувства юмора детектед
плохо вспомненный анекдот детектед

хотя ладно, я тоже перепутал… в оригинале «не делают и уже делают»
Не делают и УЖЕ не делают… ;)
Не надо хостить инфраструктуру и продакшн на одной машине. Дабы не пришлось потом писать отчет о последствиях взлома.
не совсем понял к чему это, хотя это, конечно, правильно но пока — ждем шишек в этой области.
к тому, что

1 сервер,
— «на котором крутился добрый десяток сайтов наших клиентов в т.ч. магазины с приличными оборотами»
— «хостился баг-трекер, джира, ДНС»

— это не правильно. Лучше 2, с разными административными входами. Извините, если что-то очевидное для вас написал.
баг трекер и джира ничем по сути не отличаются от «десятков сайтов» (строго говоря это и есть «сайты» — только другого назначения).

не совсем понимаю что значит «с разными административными входами», у каждого акаунта/сайта свои реквизиты, БД и т.д., даже если что-то из этого будет взломано — соседям ничего не будет
Спасибо за интересный опыт. Что верно, то верно — понимают проблему и не жалеют сил на бекапы только те, кто сам обжегся и знает, чего это стоит.

Сам делаю бекап сайта каждый день (базу MySQL) и раз в месяц — всего сайта целиком (архив файлов). Вот теперь думаю насчет домашней инфы — может, слишком мало двух копий (двух жестких дисков) на одном компьютере?.. Вот бы и себя заодно забекапить. =)
>> Вот теперь думаю насчет домашней инфы — может, слишком мало двух копий (двух жестких дисков) на одном компьютере?.. Вот бы и себя заодно забекапить. =)

зависит от того что на нем есть, если фильмы — то и хрен с ним, если бухгалтерия — то лучше да =)
Ммм, а сейчас бэкапы не в США случайно?
А то глядишь ядерная война и все такое, и бэкап и оригинал накроет :-)
Надо в место потише, куда-нить в микронезию или там в ЮАР или еще куда :-)
Бекапы должны быть в 2 разных местах, не совпадающих с местом размещения продакшн-серверов, и — с периодичностью от дня до недели, в зависимости от размера, падать на ноутбук админа. При таком раскладе на географию пофиг, и Ваш юмор/сарказм неуместен ;-)
А тут никакого юмора нет.
Представляю кучу топиков на хабре после ядерной войны… Что пожар, что ядерная война — все может быть, и вероятность сравнимая…
Все привыкли все держать только в Москве или где-то еще, а ДЦ обычно выше уровня земли, и их снесет до фундамента…

На Украине вон открывали ДЦ в бункере ядерной войны — там если не будет прямого(целенаправленного) попадания — все с данными будет ok (как каналы восстановят само собой).
>>>> Что пожар, что ядерная война — все может быть, и вероятность сравнимая…
Хочется верить что это всетаки не так =)
Ну смотрите, сколько за всю историю было уничтожено ДЦ пожаром (считаем по пальцам одной руки)?

А сколько городов было уничтожено под 0 (2 штуки)? (Представляете сколько ДЦ бы сейчас ушло при ядерном взрыве в каком-нить Токио). Т.к. при ядерном взрые повредятся почти все ДЦ в городе, это сильно увеличивает вероятность пострадать от ядерной войны по сравнению с пожаром.
>>> Ну смотрите, сколько за всю историю было уничтожено ДЦ пожаром (считаем по пальцам одной руки)?
как оказалось — не так и мало.

>>> А сколько городов было уничтожено под 0 (2 штуки)?
Я бы сказал ниодного, но сильно пострадали — да.

>>> Представляете сколько ДЦ бы сейчас ушло при ядерном взрыве в каком-нить Токио). Т.к. при ядерном взрые повредятся почти все ДЦ в городе, это сильно увеличивает вероятность пострадать от ядерной войны по сравнению с пожаром.
Это слегка извращенный подход к оцениванию вероятности. Продолжая логику: если землю уничтожит комета, то все датацентры погибнут, а значит веротяности ~=

Как-то об этом не подумал (нет, ну а что может случится? война что ли?), но мы еще изредка будем к себе сливаться. На всякий случай.
Честно говоря — хостинг.юа довольно неоправданно дорогой хостинг, при этом уровень сервиса оставляет желать лучшего.

Ничего личного, просто личный опыт. Ситуация с пожаром — только укрепила это впечатление.
хм, может вы знаете хостинг меньше чем в два раза дороже с хорошим пингом по России/Украине? Мы сейчас ищем «ПМЖ» и пока все довольно грустно.
Все грусно, Андрей, и это правда. В Украине мало нормальных хостинг-компаний.

Мы в свое время остановились на фрихосте, на их впс, но по прошествию времени я тоже не особо доволен.
Я 2 года хостился на hosting.ua, нарекания конечно были, но все решалось, а по деньгам ничего лучше мы не нашли (только европа-штаты). А сейчас из-за такого поведения после ЧП вынужден буду оттуда съехать.
Поздравляю с успешным исходом и оперативным восстановлением. Все правильно сделали. Как раз сейчас готовлю доклад по системам резервирования, так что ситуация с вашим хостером очень показательный пример.

Кстати, есть ли шансы, что хостер вернется в строй и будет работать дальше?
Как вы сами думаете: у вас практически уничтожен бизнес, восстанавливать либо компенсировать его никто не собирается зато предлагают скидку в 25% при продлении обслуживания на год — вы согласитесь?
см.ниже, сорри, не туда написал
>>> есть ли шансы, что хостер вернется в строй и будет работать дальше?
Не знаю, по-моему они сделали все что бы усугубить последствия пожара. Играть в молчанку 4 дня — это суперкреативно. Если бы в воскресение была инфорамция и она постоянно обновлялась — то я бы(и, думаю, многие другие) вернулся к ним после восстановления. А так — валить и как можно дальше.

Единственный шанс для них выжить — подробно рассказать что случилось, сделать публичную работу над ошибками. Иначе они вынуждены будут покинуть рынок.
Ну если только хостер не пересмотрит свою политику и пару лет не отработает себе в минус или хотя бы в ноль, замаливая грехи и ублажая пострадавших клиентов, пытаясь решить не только свои проблемы, но и проблемы своих клиентов. В противном случае погорельцы разбредутся и еще и соседям расскажут про все свои мытарства. Что, в принципе, и происходит. Короче, либо хозяин делает человеческое лицо и пытается идти навстречу, либо пусть не жалуется.
Хотя, в любом случае, вопрос доверия теперь под большим вопросом.
Проходили сертификацию по ISO 9001 — там по поводу backup'ов четко сказано: он должен делаться с разумной периодичностью (определяется персонально) и храниться в другом месте.

Потому как кроме пожара еще есть MIB, которые могут придти и опечатать дата-центр, а сервера увезти на экспертизу в неизвестном направлении :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории