Romka_Kharkov

Romka_Kharkov
Рейтинг
485
Регистрация
08.04.2009
Должность
Хостинг
Качественный хостинг
aleksejsmir:
В принципе, так оно и есть.. хотя было муторно и долго.
Обратился я в online nic, но они работают с реселлерами, и получалось несколько... дороговато. А потом дернул меня черт попытаться перенести домен в reg.ru... впечатление было ужасное, надолго получил иммунитет от совковых сервисов... в очередной уже, правда, раз.
Ну, выплеснулся я в статье для сайта; кому будет интересно, взгляните... приятное с полезным для меня; и психотерапия, и seo. :) Скажу лишь, что до сих пор не в состоянии понять, как удалось прийти к такой вот концовке - представитель sweb (реселлер online nic) уверял, что трансфер великолепно получился и через несколько дней домен будет уже у нового регистратора, а reg.ru сообщил мне, что перенос потерпел фиаско, заморозил мою заявку и вернул мне деньги на счет.
Так вот они и уверяли меня, каждый на свой лад...
В итоге я плюнул и просто попросил в свебе, чтобы прописали в настройках зоны американские сервера имен (сайт свой я перенес на хостгатор). Ведь домен мой и так был в online nic! только энэсы находились у свеба. Ну и вот. В принципе, online nic, думаю, вполне достойный регистратор... а в spaceweb, где сервера имен работают как бы это сказать.... через... короче, вот так, как описано на форуме, я буду только оплачивать ежегодно свои домены, ну и все.

Т.е Online NIC Inc. на прямую с клиентами не работает, а только через посредников типа sweb?

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

Но это все равно полезная информация :)

Вижу что схема моя не совсем сработала, но главное, что вы получили результат, кстати не стоит забывать теперь о том, что sweb по сути может прямо "сувать палки в колеса", если вдруг чего... так как они по прежнему держат домен для вас на сколько я понял.

megadimon:
почему бы не упростить до автоматических бэкапов панели + rsync по крону в нужное время?

С точки зрения концепции выглядит не совсем правильно, какой мне смысл делать синк по крону (раз ето крон, ето значит раз в X времени), если у меня проходит процедура бекапа и только после нее надо 1 раз отлить это все на отдельный сервер, разницы между например rsync или ftp или scp в данном случае не вижу, так как первый "отлив" идет на локальный сервер... то есть 100Mb/s...... Тут разовая точечная задача я бы так сказал, по этому как тут применять задачи крона - не знаю, по моему не уместно. Но в целом где-то так и выглядит, создал бекап, подготовил на бекап сервере папочку с датой, слил туда.... Кажется все и так довольно просто :)

Romka_Kharkov добавил 31.03.2011 в 20:23

rustelekom:
потому что традиционные бекапы основаны на файловом способе архивирования. сначала смотрят файлы на диске и упаковывают их в один или несколько архивов, затем сжимают. достаточно запустить на обычной cPanel, Directadmin, Ispmanager полный бекап и посмотреть как много ресурсов на это потребляется. Поэтому и появляются жалобы на то, что по ночам (обычно тогда и запускают бекапы) серверы хостингов работают медленно и со сбоями. Особенно это заметно сейчас когда во многих тарифах клиенту дается много места на диске и оно реально занято. Да даже если говорить о собственном сервере - многие видят что бекап притормаживает весь сервер (а это неизбежно при использовании метода бекапарования на файловой основе) и принимают решение ничего не бекапить пусть и рискуя при этом потерей свежих данных. Частично это проблему решает инкрементальный бекап но, его реализация тоже не идеальна (не слишком надежно работает).

Дадада +1 однозначно, но !!!! в случае работы с бекапами и данными вы рано или поздно приходите к тому, что начинаете понимать сколько каждый из ваших клиентов потребляет и начинаются поиски оптимизации данного процесса, в моем случае я делю клиентов на группы в процессе построения бекапов , сперва бекап делается для тех у кого < 2 GB информации, с точки зрения нагрузки на сервере tar не дает никакой мега ядерной нагрузки... .пока пакует до 2 GB информации.... а вот те кто > 2 GB собираются потом, с интервалом в 10-15 минут, что бы мнимый load average мог успеть рассосаться и не писали ночные клиенты...... А если запустить тупо всех под ряд... да, можно среди ночи наступить на мину :))))

Hekcky:
Кто нибудь еще пользуется http://servage.net ? Надежно там хранить бекапы?

Начните с того, что хранить бекапы у "другого провайдера", это уже есть надежно! А степень любви к их услугам вы определите потом.... :) :) :)

mcafeeuser:
А с чем были связаны последние проблемы с каналами?

Последние проблемы были связаны с выходом из строя одного из магистральных маршрутизаторов, пришлось очень быстро менять его на другой. Но я думаю что даунтайм в 4.5 часа при такого рода поломках - вполне допустим, однако надо было оперативно найти в замену не очень то и дешевую железку :)

Хортица:
1 бекап ежедневно
1 бекап еженедельно
1 бекап ежемесячно
С сервера в Германии на Сервер в США. Месячный сливаю на хард - 20мбт канал позволяет лить себе на всякий случай.

С России в США или Германию так же хорошо будут идти ночные бекапы.
Те кто держат сервера в Китае, те в любом случае знают для чего они там.

Континенты бекапам не проблемы ;)

День добрый,

С интервалами все понятно, а чем вы пользуетесь для создание или оперирования бекапами? какой-то софт? Я думаю что как хостерам так и владельцам акаунтов на всяких cPanel, DirectAdmin, прочие .... будет интересно знать чем делать бекапы, например для хостеров от меня информация такая есть: использую cpanel, у нее есть скрипт который инициирует бекапы по $username, получаем список клиентов, запускаем сценарий по всем клиентам.... потом отливаем данные на бекапный сервер. Это концепция. А реализовано все путем perl скрипта в несколько десятков строк :) Для линейных серверов , при использовании одной и той же панели - пришел к выводу , что такой вид бекапа является оптимальным.

Хортица:
Romka_Kharkov, континенты континентами, а бекапится с Германии в США отлично. Бекапы на 80 гб ночью проходят на одном дыхании. Так что надуманные все Ваши проблемы.

Там где паритеты лучше и каналы шире само собой будет все быстрее, тут капитаном очевидностью не надо быть...... я же о чем пытался сказать: Что каждому клиенту реально подходит "свой вариант" и брать в примеры кого-то там с его схемой просто не имеет никакого смысла.... тем более, вы жаждите ответа на вопрос "где размещать, хранить"..... Я бы лучше обменялся информацией по схеме бекапов , их регулярности и тому подобное, а само собой понятно что лить данные на сервер поближе .... будет куда проще чем на сервер подальше :)) Но все зависит от ситуации, места размещения, внешних каналов, приоритетов клиента, и тому подобное.... нет общей схемы, вот я о чем.

🤪

Хортица:
Romka_Kharkov, "Поки вас тут не було-нічого не воняло!" (с) народная поговорка. Это я к тому, что пока Вы не появились в теме, "обычные смертные" делились своим опытом и мнениями. Ваши же сообщения и дискуссии последние 3 страницы ниочем. Ведь тема начинается со слова "Где...", а не "Как ...". Разницу улавливаете ? Вы хоть в каком то сообщении написали ГДЕ ?!

Что где ???? Вы что не понимаете , что ответ на "где?" произростает из ответов на вопросы "Как?"

Вы не сможете оперативно работать с 100 GB например, если ваш сервер будет находиться на другом континенте от вас (это ответ на вопрос "где")..... чем делится? Я понимаю такую тему могут обсудить москвичи которые включены в MSK-IX, я понимаю такую тему могут обсудить украинцы с точки зрения UA-IX, но какой смысл обсуждать вопрос "где" ...... если все находятся в разных точках физически??? не катит ваше "где".... понимаете??? Именно по этому я и не ответил на вопрос "где", а вот информация на тему "как" в данном случае IMHO будет полезней... а "где" каждый выберет себе сам без напутствий соседей, если это конечно не человек который вообще ничего не понимает и купит себе для бекапов сервер в Китае находясь в России...

😡

Cesar_Mt:
Это Вы жестко отожгли! Я бы после этого хоститься у Вас не стал бы :)

После известных событий с Hosting.ua я дрожащей рукой потянулся в сейф за мобильным винчестером, моля Бога о том, чтобы винт стартанул и без сюрпризов.... эти 10 секунд его старта были самыми длинными в моей жизни... :) Часть людей похоронила свой бизнес из-за того, что у их хостера (размещавшего сервера в hosting.ua) не оказалось бекапа в другом ДЦ.

С тех пор бекаплю только к себе на локалку, 20 Гиг 1 раз в неделю и не переклыдываю свои риски на хостеров, для которых потеря бекапа не критична...

Ваш вывод из ситуации с Украинским ДЦ - просто бомба ))) +1 однозначно ☝ Я думаю, что в случае отсутствия винта у вас в сейфе .... вы были бы рады даже месячной давности бекапу ... не то что бы недельному.... А если разобраться, то описанный выше гигант мог бы вполне спокойно содержать в соседнем ДЦ пару спец. серверов для бекапов (не ежедневных, а допустим месячных).

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

futuristian:
Что за бред?


Есть сайты на которых потеря данных за 1 день - это катастрофа.


Замечательное предложение. Я вижу вы из большого города, где с интернетом нет проблем, а как быть на периферии, где 128 килобит на вход стоит 3к рублей? Как на таком слить 100 гигабайт? Вы хотя бы слышали, что такое ДИАЛАП? А им ещё многие пользуются.

Ребята а что FXP уже не актуально в таких случаях???, зачем качать что-то себе на комп и потом выливать в бекапное хранилище, работайте на прямую, лейте сразу с продакшон сервера на бекапный минуя ваш ПК домашний....

Romka_Kharkov добавил 28.03.2011 в 19:37

Хортица:
Господа "хостеры" избавьте пожалуйста нас обычных посетителей форума от Ваших умопомрачительных вариаций на тему, а если бы! Всем уже наверное известна ссылка на лукоморье? Если нет, то ее легко напомнить. А если у Вас есть конкретное предложение, то просто указывайте его плюсы и стоимость.

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

ps: Или это только меня выносит эта вся теория ниочем ?!

Скорее всего только вас, ТС не просил тут пиарить свои услуги и рассказывать чем они лучше чем другие, в таком случае тема вообще в срачь превратится на ровном месте. Многие высказались по своим направлениям бекапов , многие держат нейтралитет в беседе, так как толком не ясно о чем беседа )))) а многие пишут про лукоморье, которое явно будет засчитано как оффтоп в данной теме :)

masterlan:
Предложите актуальную :)
Пока этот вариант работает, над другим не думал.

Так тут весь разговор о том, что для вас ваша схема может быть самой подходящей, но это вовсе не означает что она будет подходить кому-то еще. :)

Romka_Kharkov добавил 28.03.2011 в 02:03

firstman:
Romka_Kharkov,

О боже... Вы разницы между реальными рабочими данными и бакапом не чувствуйте?

1) Да - это бакап. Скопированные на удаленный ХДД данные - это бакап. Разница только в том, что в 2U сервер можно запихнуть только 12 HDD

2) ОГО... Raid10 для бакапа? У Вас на рабочих машинах-то везде Raid10?

3) Любой Бакап - это не критичные данные. Если бакап исчезнет, то веротятнее всего - этого никто не заметит - не критично.

Рейды и прочее нужно строить в боевых серверах - а бакап должен просто быть хотя бы...

Предложенный мной вариант - то же самое, что скопировать на свой компьютер или на "специальный" HDD.

1) Ну так в таком случае мы нашли решение для всех, все ставим себе доп винт и все дела :) Вот оно !

2) Не на всех конечно же, raid10 нужен под какие-то конкретные цели , причем для операций а не для хранения :)

3) Не согласен!

Ну так , предложенный вами вариант звучит где-то так "копируйте куда угодно, лишь бы было, а если помрет - оно же не критичное" :) Не понимаю такого подхода.... Как я уже писал выше внутри DC мы практикуем Raid1+raid1, на двух машинах, вполне уместно , одна тупо для хранения данных, другая непосредственно отдающая данные.

Всего: 6833