ruweb.net - лежит полностью весь дата-центр

LargoYou, свой, я пишу для десктопов на всём, где есть буквы :) (а вот *никс систем вообще не знаю, даже не пытаюсь вникать). Поэтому, на хостинге php код пакует всё в архив, а мой софт вытягивает этот архив.

При чём пакую я без крона, просто при каждом посещении юзера, идет пост запуск асинхронный php кода, который проверяет что уже допаковано, а что еще нужно - и пакует по несколько файлов с лимитом в 15 секунд работы php кода. И так пока все новые файлы не будут на текущий период расписания допакованы в архив (как правило стоит раз в сутки паковать у меня на всех сайтах таких).

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

Но сайтов, где есть много динамики у меня совсем чуток, основная часть сайтов без сторонних изменений, только добавляемые мною данные, которые я сам и пакую в архивы у себя на десктопе. Так что мне бэкапы на хостинге в принципе не нужны ни на каком.

---------- Добавлено 07.10.2017 в 15:56 ----------

treshnyuk, я в последнее время даже у самых-самых тормозных регистраторов (по смене днс записей) не видел таймаута более 10-ти часов. И это еще с моими медленными магистральными обновлениями в РБ.

Может там до Гонолулу какого и дойдет смена такая через 3 дня - но у меня нет посетителей из Гонолулу :)

Смена NS - 4-о суток и ничего не поделать.

IHC.RU. 345600 IN NS ns2.ihc.RU.

IHC.RU. 345600 IN NS ns1.ihc.RU.

;; Received 198 bytes from 193.232.156.17#53(193.232.156.17) in 122 ms

345600 секунд = 4 дня.

В соцсетях написали, поэтому уже готовую выжимку здесь выкладываю:

Вчера вечером мы сначала наблюдали проблему с доступностью наших серверов в Курчатовском ДЦ. Техподдержка датацентра ответила, что возможно проблема связана с ддосом и они работают над проблемой.

После того, как связь с датацентром восстановилось мы обнаружили, что отключалось гарантированное питание - аптайм всего оборудования нулевой. Когда питание появилось, выяснилось, что наш центральный маршрутизатор не отвечает на команды. Мы его начали менять на резервный, который стоял в этой же стойке.

Основной маршрутизатор заменили, и к трём часам ночи запустили большинство серверов (питание с них тоже пропадало и все они ушли в холодный ребут). К пяти утра прочекали оставшиеся девять серверов, которые после падения питания не смогли сами подняться и сейчас все сервисы работают в штатном режиме. Официальная рассылка будет опубликована чуть позднее, когда поступит вся информация об инциденте. Официальной информации от датацентра у нас пока нет. Приносим всем нашим клиентам глубочайшие извинения за случившееся. Если какие то вопросы остались нерешенными - обязательно напишите в нашу техническую поддержку https://ruweb.net/support

Сегодня с утра разбирались с juniper, который "исчез" ночью - конфиг девственно чистый, даже логов никаких нет. Как будто жуник только что с завода пришёл. Как его так угораздило - пока загадка.

Это что то архаичное.

Исключения есть везде, но как Вы видите даже форумчане говорят, что больше 10-ти часов никто не ждет.

Не стоит забывать об кэше на стороне провайдеров интернета. Всегда самые длительные задержки были именно в этом месте. Так и сегодня. Потому что многие из них не соблюдают никакие TTL, хранят кэш очень долго.

Можо и в hosts прописать новый айпишник...

Вопрос в другом. У вас прям каждый посетитель уникальный с суперсовременным провайдером без кэша?

Ну тут скорее сами пользователи виноваты но не без вины провайдера. Я понятия не имею сколько у моего провайдера TLL ибо использую пресловутый 8.8.8.8 Ничего не мешает любому пользователю использовать этот резолвер тоже.

smart2web, не все рождены технически грамотными. Нельзя винить пользователей в этом. На счет провайдера согласен.

Что за бред. Зачем это кому-то надо? Укажите хотя бы одного провайдера.

porutchik, не меня спрашивайте. Провайдеров.

Укртелеком, Бестлинк, Гроза, Ланет, Интертелеком. Это только те, которыми пользовался лично за последние 10 лет.

У двух их них были случаи когда DNS не обновлялись более 10 дней. На одном из них был случай, когда на DNS хранилась запись 3-х годовой давности.