Как да не правим като dir.bg

B

bnight

New Member
Здравейте,

Предполагам повечето от вас са запознати със събитият от weekend-a и пожара в дата центъра на dir.bg.

За това ви предлагам една статия изготвена от техническият екип на http://skyhost.bg/ как да не се случи същото и с нашият сайт.

Или иначе казано как да предпазим сайта си от катастрофи.

Ето и въпросната статия:

http://blog.skyhost.bg/backup/howto-backup-site/

Надяваме се че това ще е интересно и полезно четиво за вас.

В случай че не съм оцелил мястото на темата моля модераторите да я преместят.
 
От: Как да не правим като dir.bg

С риск да си навлека огромния гняв на модератора, ще ти кажа, че е доста некоректно да се опитваш да извлечеш преки дивиденти от проблемите на твой конкурент (dir.bg предлагат хостинг). Не забравяй, че утре подобно нещо може да се случи и на тебе, колкото и backup-и да правиш.

За съжаление моралът не е нещо което се цени тези дни.

Нямам идея какъв хостинг предлагате, но като гледам българския на този дето прави PR по форумите, и ми става лошо... вземи научи правилата за членуване, както и как се пише "уцелил".

===
PS: Нямам каквато и да е връзка с dir.bg, освен че съм купувал два-три пъти импресии преди години.
 
От: Как да не правим като dir.bg

Това не е опит да се извлече пряк дивидент от темата. А опит хора като теб и другите колеги във форума да се научат как да не правят така.

Лично мен ме дразни когато компания от сорта на dir.bg или dnevnik.bg постъпва непрофесионално.

За мен като човек занимаващ се с хостинг от няколко години това което се е случило е най-малкото недопостимо и искрено съчувствам на колегите от техническият отдел на dir.bg

Естествено е такива проблеми да се случват но планът за реакция в такива ситуации трябва да е професионално прегледан и тестван почти ежедневно.

Незнам дали ти се е случвало да си загибиш сайт по подобен нелеп начин но вярвай ми не е приятно ако нямаш бекъп.

И не става дума само за бекъп но и за процедурата по възстановяване на този бекъп.

Всеки от тук пишещите има някакъв сайт. От който евентуално изкарва някакви пари.

Въпроса е че в момента в който на някой от вашите сайтове се случи нещо такова ще спрат вашите пари.

Явно не си даваш сметка за това но тази статия е с цел да покаже как трябва да се прави.

Нещо което явно колегите от dir.bg са пропуснали.

А след случката с dir.bg според мен всеки технически екип трябва да изтества свойте бекъпи и да провери отново свойте процедури за реакция в катастрофи.

Наистина спестявани са пари от хостинг и от дата центрове в dir.bg и dnevnik.bg да се надяваме че вие няма да спестявате от подобни услуги.

Но за съжеление в България повечето собственици на сайтове не си дават сметка за това че 2-3 лв повече за хостинг на месец могат да гарантират това че сайта ви ще е онлайн малко повече време.

Аз лично като собственик на хостинг компания и занимаващ се с интернет в продължение на години съм изненадан от тази ситуация.

Просто с тази статия нашият технически екип се опитва да ви помогне споделяки опита си.

Кой както иска да разбира статията.

За мен важното е че моят технически екип е прегледал бекъп процедурите ни и в случей на нещо подобно може да реагираме своевременно.

Надяваме се че тази статия ще ви накара и вие да направите същото.

Защото поне при нас статистиките са че много малко от клиентите изобщо си правят бекъп.
 
От: Как да не правим като dir.bg

Имат бекъпи, сега ще им отнеме малко време за импортване. Що се отнася до статията, ако не е cpanel панела? А знаете ли че DNS сървърите се обновяват от 2 до 24 часа? Не всеки е с OpenDNS-и. Така че даунтайма в такива моменти е неизбежен. Да не говорим че бТК (тей де ВиваКОМ) са с толкова бързи DNS че с месеци още получавам трафик от тях на сайтове които отдавна са преместени (под отдавна имам предвид МЕСЕЦИ). Така че браво на Дир.БГ че са помислили за бекъпи :) Пък нещата ще се нормализират до няколко дена - дано :)
 
От: Как да не правим като dir.bg

въпроса е защо дейтацентъра им няма защита от пожар.....
явно не са го помислили.....
 
От: Как да не правим като dir.bg

Relax каза:
Имат бекъпи, сега ще им отнеме малко време за импортване. Що се отнася до статията, ако не е cpanel панела? А знаете ли че DNS сървърите се обновяват от 2 до 24 часа? Не всеки е с OpenDNS-и. Така че даунтайма в такива моменти е неизбежен. Да не говорим че бТК (тей де ВиваКОМ) са с толкова бързи DNS че с месеци още получавам трафик от тях на сайтове които отдавна са преместени (под отдавна имам предвид МЕСЕЦИ). Така че браво на Дир.БГ че са помислили за бекъпи :) Пък нещата ще се нормализират до няколко дена - дано :)
Увеличете...

Това в статията е просто пример. Имейте предвид че при dir.bg трябва да има и поща и други файлове където много по-приложим начин за beckup e ежедневен rsync на целият сървър на резервен такъв.

Иначе казно ползването на standby машина. Някъде в друг дата център.

Естествено ползването на такъв тип бекъп вдига разходите за поддръжка на сайта двойно.

Но при сайт с приходи от няколко милиона годишно едва ли това е проблем.

Странно е защо не е било направено.

За обновяването на dns-ите сте прави но наши тестове показват че времето обикновено е много по-малко.

И дори с обновяване на dns и цялата процедура не трябва да отнема повече от ден.
 
От: Как да не правим като dir.bg

kuzmanin каза:
въпроса е защо дейтацентъра им няма защита от пожар.....
явно не са го помислили.....
Увеличете...

Ако видиш повечето помещения за colocation в България ще разбереш че такова нещо като защита от пожар е напълно глупаво да го очакваш. Единствената защита от пожар в тези помещения е sys admin дето си прави редовни beckups.
 
От: Как да не правим като dir.bg

Пич, явно смяташ участниците в този форум за доста тъпи, като гледам с какви "методи" си подходил към тях.

1. НАУЧИ СЕ ДА ПИШЕШ НА БЪЛГАРСКИ БЕЗ ГРЕШКИ!
Не виждам какъв професионалист можеш да бъдеш в каквото и да е, ако не знаеш майчиния си език.
"недопостимо", "сръвнение", "съжеление" ?

2. Кого залъгваш с "добрите" си намерения?
Надраскал си една статия набързо - вижда се, че си я писал ти, пълна е със същите правописни грешки като постовете ти тук.
Като толкова "съчувстваш" на дир.бг, обади ли им се да ги попиташ дали може да им помогнеш с нещо? Едва ли, просто защото си лицемер, и съм сигурен, че вътрешно злорадстваш, че дир-а са се скапали. Съответно, драскаш набързо "статия", и почваш да спамиш по форумите, та белким дръпнеш някой клиент. Лицемерие.

"техническият ми екип" - какъв екип бе пич! От сто километра се вижда, че си one-man company, и се занимаваш с хостинг между другото.

3. За самата статия: "правете си бакъп всеки ден със скрипт от форумите на cpanel, и като се скапе хоста, отворете си хостинг другаде и си качете сайта там"
NO SHIT!
Наистина ли мислиш, че даваш някаква полезна информация?

Статията ти също е пълна с правописни грешни, за какъв професионализъм говориш? Имаш ли идея какво е професионализъм?

4. Какво били пропуснали тези от дир-а.
Пич, сигурен съм, че си нямаш идея какво значи disaster recovery plan, нито как се пише, нито как се изпълнява.
Предполагам няма смисъл да те питам какъв ти е disaster recovery plan-а при 0-day remote kernel exploit.

Ако лежиш на кълката "лоша реклама няма", да ти кажа, че си много в грешка, и че с тази "статия" и форумния ти спам си правиш ИЗКЛЮЧИТЕЛНО лоша услуга.

И да знаеш, че колкото повече пишеш тук да ми отговаряш, толкова по-лоша услуга си правиш.
 
От: Как да не правим като dir.bg

Ако наистина мислиш така толкова по-зле за теб.

Надявам се да не ти се налага да се запалва сървър с твоя сайт.

Просто защото дори и този метод за бекъп е по-добър от никакъв бекъп.

Именно заради хора като теб dir.bg са в това полужение. И там техническият екип си е мислил че няма смисъл да чете статии за бекъп еми не ги четете но поне не ги и коментирайте.

От друга страна ако статията беше в личният ми блог нямаше да предизвика толкова скандали защото нямаше да е реклама така ли ?

В крайна сметка важното е че в момента в България не се подхожда професионално към изготвянето на Бекъп.

Към това да се подхожда малко по-професионално се опитвам да привлека вниманието.

Както казах поне в skyhost сме изтествали бекъп процедурите си. Надявам се и в другите хостинг компании да направят същото за да не се повтаря случката с dir.bg.

А на теб успех. В правенето на сайтове и изхранването от тях.

Само гледаи да не се самозабравиш че туковиш пламне някой сървър.
 
От: Как да не правим като dir.bg

"полужение" "туковиш" ОМГ!
Явно имаш голямо желание да продължаваш да се излагаш. Ходил ли си на училище всъщност? Чувал ли си какво е spellcheck?
Как някой да се хоства при тебе, ами ако кодът по сървъра ти е писан по същия начин?

Ако искаш да помогнеш на някой, а не просто да напсуваш dir.bg, трябваше да напишеш нещо от рода:
Избирайте внимателно хостинг доставчика си.
1. Разгледайте сайта му, вижте дали е обявил къде му се колокират сървърите. Ако не е, то най-вероятно мястото на колокация не е за показване.
2. Като разберете мястото на колокация, проучете и него. Кога е създаден, какви проблеми е имало в миналото. Какви security и противопожарни методи се ползват. Не ползвайте colo център, в който противопожарната система не е с интертен газ.
3. Проверете дали има SLA и DRP на сайта си. Разгледайте ги внимателно.
4. Чак тук идва мястото на off-site backups. Дали ги има и къде се правят.

... мога да пиша още много по темата как да избираме доставчик. Но едно знам: форумен спамер, one-man company, с полусайт - за хостинг доставчик НЕ СТАВА.

За моите сайтове не се притеснявай. Тези, които са ми важни ползват mirroring services + replication + разни технологии, които ти вероятно не си чувал все още.
 
От: Как да не правим като dir.bg

Истината е че дори когато избираме доставчик на услуги дори най-добрите в света се дънят виж The Planet виж повечето дата центрове в Paul Auto миналият месец когато незначителна катастрофа на самолет остави целият град без ток.

Въпроса е че когато най-добрите се дънят не трябва да се дъним с тях.

Колкото за технологии който не си чувал занимавам се с high-availability през последните три години и именно това е причината да съм крайно изненадан от това което се случи с dir.bg.

Пак казвам че дори да вярвам на доставчиците си на услуги предпочитам да имам резервен вариант който да зависи само от мен.

Много от клиентите с който работя ще ти кажат същото че винаги ги предопреждавам че им правим пълен ежедневен бекъп но въпреки това трябва да си правят бекъп и те.

Като дори ги съветваме как да правят това.

Много по-малко проблеми стават по този начин.

Радвам се че си конструктивен в темата.

Тъй като най-малкото имам желание да се заяждам.

А и статии как да си избираме хостинг и дата център има писани писани и писани.

И виж резултатите.

За съжеление липсват качествени статии за изготвяне на пълни бекъп решения и когато някой споделя такъв опит аз го приемам като ценно нещо.
 
От: Как да не правим като dir.bg

Dude, явно няма да мога да ти покажа колко си зле всъщност.
Paul Alto? (Palo Alto)?
Какво точно са се издънили the planet?
С това, че градът е останал без ток?
Това издънка на the planet ли е?
Колко outage са имали the planet миналия месец? Или го бъркаш със случка от 2008? Или четеш google results прекалено бързо?

И да, конструктивен съм - хората трябва да стоят далече въздухари, които нямат идея как да се рекламират.

===
"предопреждавам"???
===

Извинявам се на всички за тона си, както и на модераторите, че темата отиде в различна посока. Но според мен всички трябва да са наясно с целта на този пост, както и какво да очакват, ако решат да си купят хостинг от този момък.
 
От: Как да не правим като dir.bg

Не мога да разбера как може да плюеш услуга която не си ползвал.

От друга страна за да не съм крайно оффтопик пак мисля че статията сама по себе си е полезна а който не иска спокойно може да не я чете както и тази тема между другото.

А историята с града без ток беше много интересно разказана от един колега VCP http://technodrone.blogspot.com/2010/02/so-how-up-to-date-is-your-bcp-plan.html

И на мен лично ми беше доста интересно как той е реагирал в тази ситуация.
 
От: Как да не правим като dir.bg

Бреее Хич много брутално сече :lol: .
Грам не разбирам за какво говорят и не ме интересува, но сеирът е качествен и заслужава печат "Noke Approved!"
 
От: Как да не правим като dir.bg

Не съм ползвал компанията skyhost, но плюя това което виждам:
- използване на чуждия проблем за собствени дивиденти, и то по доста куц начин
- неграмотност
- лицемерие
Сори, ама това ми е достачно.

Ако аз бях хостинг доставчик, особено ако уважавам себе си, първо бих се свързал с дир.бг да ги питам с какво мога да им помогна - свободен коло спейс, свободен хардуер (да не мислите че свестните сървъри могат да се купят на момента от ресет, не става въпрос за пари), свободен human power, или каквото мога. В крайна сметка има един куп хора дето са афектнати, и бруталната конкуренция на пазара не е извинение за се злорадства, че дир.бг са се издънили. Те клиентите им ще им "оценят" издънката.
Като приключи disaster issue-то и съм направил каквото мога, тогава мога да тръгна да пиша статии какво-що било, и от това ми поведение ще извлека много повече дивиденти, отколкото от бясното плюене по форуми колко съм "очуден", че това е станало с дир.бг. Ама това на 20 годишните неграмотници едва ли ще им дойде на акъла...
 
От: Как да не правим като dir.bg

А издънки винаги могат да се случат. Колкото и бакъпи да правиш, утре ще излезе някой root exploit, някой гад ще ти налази сървърите, ще ти наслага разни backdoors, ще изчака backdoors да идат backupа (било то и чрез скрипта от "статията"), ще разгледа откъде си mount-ваш бакъпите, ще те издебне като ги правиш, и ще мине и ще ти затрие ВСИЧКО. Да не би да си подготвен за това и да можеш да гарантираш 100%, че такова нещо не може да се случи? И да не мислиш, че това е единствения подобен сценарий?

Дано да си разбрал, че имаш още много да учиш за хостинга...
 
От: Как да не правим като dir.bg

Hitch каза:
А издънки винаги могат да се случат. Колкото и бакъпи да правиш, утре ще излезе някой root exploit, някой гад ще ти налази сървърите, ще ти наслага разни backdoors, ще изчака backdoors да идат backupа (било то и чрез скрипта от "статията"), ще разгледа откъде си mount-ваш бакъпите, ще те издебне като ги правиш, и ще мине и ще ти затрие ВСИЧКО. Да не би да си подготвен за това и да можеш да гарантираш 100%, че такова нещо не може да се случи? И да не мислиш, че това е единствения подобен сценарий?

Дано да си разбрал, че имаш още много да учиш за хостинга...
Увеличете...

Напълно съм съгласен с изложената от теб позиция.

Всеки има какво да научи технологиите особено в хостинга са променята светкавично. Особено в момента с всички cloud решения и така нататък.

Прав си и че можеше да се помогне на dir.bg с каквото можем.

Това което остава в сянката на този случей е че освен dir.bg има и много други фирми и сайтове на който оборудването е било в точно този дата център. Тези компании може да нямат бекъп.

Може дори твоята хостинг компания с твоят сървър да е там.

Това да видим какво може да направим за нашите сайтове след тази случка според мен е много по-важно.

Изводите са ясни сигурен съм че dir.bg ще направят всичко по силите си за да въстановят бизнесът си.

Просто за един два месеца това е третият подобен случей на голям сайт в България.

Първо беше dnevnik.bg после zamunda.net а сега и dir.bg.

Хубаво е че на сайта на dir.bg се появи информация че работят сериозно по проблема и че имат всички данни около 40 TB което наистина е огромен масив с инфромация и ще отнеме време за възстановяване след като данните са били архивирани.

Харесва ми че се опитваш да си конструктивен но от критиката ти ми е любопитно какво ти направи за да се променят нещата с dir.bg ?

И поне опита ли се да напишеш една такава статия или твоето know how си е твое know how защо да го споделяш по форумите с някакви 20 годишни деца ?
 
От: Как да не правим като dir.bg

Не опитвай да изместваш темата от себе си. Не аз пуснах тема "Как да не правим като dir.bg". Както казах, ако бях доставчик, или ако имах възможност да им помогна, бих го направил. Поне не се опитвам да им вредя с безмислени полу-хейт-полу-рекламни половинчати статии.

А за моето know how - да, мое си е, и си вадя хляба с него. А ти не се оплаквай, защото днес научи доста неща от "моето know how", които със сигурност ще ти помогнат в бъдеще.

===
Предупредих те, че си правиш лоша услуга с тази тема.
===
"случей" ???
 
От: Как да не правим като dir.bg

Готина тема се получи. Hitch определено води по точки и си заслужи репутацията, да не говорим, че вече окончателно затвърди убеждението ми да не припарвам до бг "хостинг компании". Продължавам да следя темата с голям интерес и ако се развива в същото направление дори смятам да я направя достояние на читателите на блога си - малко но от сърце

Не исках да ви прекъсвам - давайте все едно, че ме няма
 
От: От: Как да не правим като dir.bg

Hitch каза:
Не опитвай да изместваш темата от себе си. Не аз пуснах тема "Как да не правим като dir.bg". Както казах, ако бях доставчик, или ако имах възможност да им помогна, бих го направил. Поне не се опитвам да им вредя с безмислени полу-хейт-полу-рекламни половинчати статии.

А за моето know how - да, мое си е, и си вадя хляба с него. А ти не се оплаквай, защото днес научи доста неща от "моето know how", които със сигурност ще ти помогнат в бъдеще.

===
Предупредих те, че си правиш лоша услуга с тази тема.
===
"случей" ???
Увеличете...

Освен забележките ти за правопис нищо конструктивно не видях от теб до момента. И ще те помоля да спреш да ми спамиш темата.

Ако имаш конструктивен диалог или статии по темата бих се радвал да ги споделиш.

За разлика от повечето аз смятам че know howto не прави един бизнес успешен прави го отношението към клиента.

Ето защо аз се опитвам да споделям опита си. В крайна сметка така се движи светът на пред.

Пък ти си го дръж твоя опит.

Ако съм искал съвети по правопис щях да ги търся във някой форум за Български език не тук.

Тук темата е Хостинг и как да се грижим за хостингът си.

И ако искаш да обсъдим нещо по темата.

Как да не правим като dir.bg


Хубаво. Но целенасоченото ти заяждане е безсмислено.


Аз ще се повторя за незнаен брой пъти днес.

Но все някой ще го разбере.

Правете бекъпи и се старайте времето за възстановяване от тези бекъпи да е по-малко от критичното време за вашата услуга.
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе