Да собственно и за 30 отдам
alex2kg, распечатал Ваш пост и повесил на стенку в рамке :)
У меня и у всех знакомых было снято делегирование доменов (итого примерно 80 D-аккаунтов, находящихся под 4 разными партнерками). Если брать статистику по отдельно взятому Волгограду, то цифра в 4% выглядит более правдоподобно, если не выше.
А мне сдается, что у него в DNS запись для www прописана, а A-запись для @ нет.
londonetz, сравните вывод
nslookup mysite.ru и
nslookup www.mysite.ru
Если одинаковы - копать в апаче, если на первое ничего не выдает, значит DNS недописали. Либо для @ вкрячили CNAME вместо A.
Ну если рассматривать гипотетическую ситуацию, когда рухнуло на уровне ошибок софта, т.е. не физическая поломка, то около 20 минут для запуска минимального количества звеньев, а потом спокойно реплицируются остальные.
Забыл написать - diff бэкап баз раз в час, полный снапшот вообще всего раз в сутки (4 утра, когда минимальная нагрузка). Данные в базах хранятся за год (объем примерно 10 Тер), все что раньше - пакуется и хранится в лучших традициях и правилах бэкапов.
Золотые слова.
Из своего опыта - биллинг провайдера. 3 сервера только с базой (оракл), пишется одновременно на все 3 сервера, физически находятся в разных концах города. При отказе одного из серверов он в спокойном режиме оживляется и база потихоньку реплицируется с оставшихся двух. Ядро биллинга - 2 сервера так же дублирующихся, работают через round-robin в днс. При выходе одного из них все продолжает работать (маршрутизатор начинает валить все на оставшийся). Физически находятся на разных этажах и в разных краях здания (на случай пожара). Системные логи со всех серверов пишутся еще на один (второй потушенный в резерве). Вебморда так же на 2 серверах по аналогии с ядром (на отдельных естессно). Питается все от гарантийки 48 вольт через инвертора + резерв 3 ввода с разных подстанций + дизель-генератор (запас солярки на неделю).
За примерно 8 лет система не останавливалась ни на секунду, хотя и сервера дохли, и SANы летели и питание пропадало и т.д.
p.s. Я не хвастаюсь, я описываю "идеальную" по моему мнению систему резервирования. По крайней мере железа. Софтовые ошибки и ошибки "блондинок" это отдельная песня.
Это называется когда лень читать маны, начинаем спрашивать на форумах. http://httpd.apache.org/docs/1.3/vhosts/mass.html и все. По аналогии делаем для 3-го уровня.
Естессно в бинде *.вашдомен.тлд на ваш хостинг, все остальное разруливается единственным виртуалхостом с модреврайтом, прописанным в нем же.
Отписалься в ЛС по поводу домена
Разумно. Вы считаете, что сервера не нуждаются в постоянном контроле, обновлениях и т.д.? Проблему лучше предупредить, чем потом ее решать. Ведь при определенных обстоятельствах (тфу 3 раза) может и вообще не стать "проекта 1-2К".
p.s. Паранои много не бывает :)
Халатное отношение к резервированию приводит предсказуемым проблемам. Любой проект должен рисоваться с резервированием. И делать это должен специалист, а не "Вася". Это помоему аксиома.