Pull to refresh

Comments 90

UFO just landed and posted this here
И кто знает что хуже. Эти по крайней мере битые жизнью.
Жесть какая то. Прям девяностые(благо я их пропустил в закрытом военном городке).
Не хватает только предъяв к клиентам которые срулили прямо перед проблемами(как случаи с выводом денег из банка прямо перед его разорением).

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

UFO just landed and posted this here

3-ю категорию гугл потерял, после многочисленных копи-пасте этого афоризма. "А раз тебя не знает гугл, значит ты не существуешь" :)

UFO just landed and posted this here
Это уже четвёртая категория.
Потому что третья, Судя по упоминанию «огромного количества запросов бэкапов», это которые уже бэкапят, но ещё хранят бэкап там же, где и основные данные.
Надеюсь, теперь они будут делать резервные копии, руководствуясь правилом 3-2-1
Да бекап у многих был, как и у меня) А вот невозможность 2 дня перебить ns сервера сводило всё наличие бекапа к полной бесполезности… Сейчас массово тащу оттуда домены. Сервера лежат на другом vps, а толку)
невозможность 2 дня перебить ns сервера сводило всё наличие бекапа к полной бесполезности… Сейчас массово тащу оттуда домены.
а где домены будут в наибольшей безопасности для таких случаев?
Да в целом нигде, наверное. Просто у меня есть опыт проблем у текущего провайдера, когда их дц накрыло одной из мощнейших атак в Европе и они в телеге держали всех в курсе каждые полчаса и помогали уносить сервера пострадавшим и МХ, которые день молчали ссылаясь на «проблемы сети», запрещая комменты в группах и лишь на исходе второго дня признались, что это передел собственности. Накрыться могут все, а вот реальные ценности отношений к клиентам познаются только в проблемах.
Спасибо за ответ!
реальные ценности отношений к клиентам познаются только в проблемах.
а еще бывает бизнес, построенный так, что только на этом и держится. Это я про банк Тинькова, который не имеет офисов вообще.
При этом кое-кто другие пытались повторить сей успешный опыт — но не смогли: даже здесь все непросто…
Домен у регистратора, ns сторонние (например, Cloudflare). Тогда если что-то случится со сторонним ns, то вы всегда сможете сменить ns у регистратора, если что-то случится с регистратором (и их ns), то сторонний ns никуда не денется и сайт продолжит работу. Конечно, может одновременно навернуться и регистратор, и сторонний ns, но тогда вам вероятно не до сайтов будет, т.к. произошло нечто экстраординарное.
У меня с доменом зарегистрированным у них и на их DNS все намного хуже.
03.03 около 17:00 мы развернулись на другой площадке и сменили DNS записи в их панели.
4, 5 и 6 марта я с удивлением наблюдал как NS Мастерхоста периодически погибают, потом оживают и какое-то время отдают старые A, MX, SPF записи, и так более 48 часов, это при TTL 900c.

Забрать у них домен я не могу до сих пор, заявки на получение кода AuthInfo они не обрабатывают. Телефон включили только сегодня, но там заглушка «все операторы заняты, перезвоните позднее».
Прописать свои DNS сервера для домена тоже нельзя, можно добавить еще NS записей, но учитывая что Мастерхост прописывает 4 своих NS сервера, и каждый из них резолвится по 4-м ip адресам эффективность от своего резервного DNS отдающего правильные записи очень мала. Для себя сделал выводы, что держать домены в России у кого-то кроме nic.ru очень плохая идея.

Нда. Сочувствую. Мне auth коды пришли через 2 дня, а по рабочим проектам они их тоже выслали, но от двух доменов не дошли по причине «у нас сейчас проблемы с почтой». После угрозы жалобы в координационный центр они перевыслали мгновенно все коды на почту и смс. Мне кажется, сейчас они боятся только потери аккредитации в КЦ…
у Nic.ru, к сожалению, совершенно конские цены нв продление доменов. Хотя 800р разницы при таком раскладе, конечно, мало что решают. Но и nic тоже были проблемы с почтой и остальным…

Нельзя делигировать на другие днсы? В масле не прописать больше ns записей и не сменить регистратора, а именно делегировать, сделав основными другие днс серверы?

UFO just landed and posted this here

Есть же ещё beget есть. Они сами регистраторы, и вроде клиентов своих очень ценят. А не так, как многие...

UFO just landed and posted this here
UFO just landed and posted this here

Будет так, как прописано в договоре. Это не форс-мажор, сл-но компенсация согласно договора с провайдером услуги.

Это не форс-мажор
а определение форс-мажора(ФМ) — это только то, что прописано в договоре? Но кто же в договоре будет прописывать такие события?
Если же ФМ прописывается в еще более общих Законах, то там тем более такое не пропишут — в результате открывается такой большой простор для маневров!..

Ну вот и можно сваливать!


Вопрос, как можно было в ДЦ пропустить людей, который ДЦ и отжали, и потом в сообщении для клиентов обещать неповторения такого в будущем, остается открыт. Получается, что и от остальных атак ДЦ годами был открыт?

UFO just landed and posted this here

Угу. Так и есть. Мы довольны, что перенесли серверы к другим (не буду тут, рекламой запишут, если надо — в личке обсудим), но МХ попроще с доступом было, чем сейчас.


Да, когда-то в МХ радовались, что на входе не сильно напрягают. Сейчас понимаем, что лучше полчаса потратить на вход, но атака «на бардак» захлебнётся, и серверы и ДЦ хозяина не сменят «случайно».


Меня возмутило, как, потеряв буквально контроль над ДЦ и всеми сервисами, данными и пр., люди пишут «теперь-то точно не потеряем, мы договорились!»

более сложный вход не панацея, если будет откровенно силовой способ проникновения, то разобраться росгвардия, «компания с холодным серцем» ломиться или кто-то похожий, а если еще (да наверняка) все будет происходить ночью, плюс рейдеры не брезгуют использовать всякие глушилки и т.п… повторение подобного кавардака с серверами очень вероятно, и перенос за рубеж не обязательно защитит, а в некоторых проектах он и затруднен… и получается конечные клиенты практически незащищены. А возможные компенсации за простой сервера могут быть уже и некому не нужны, если только так минимизировать издержки при закрытии проекта

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

Тут же «бывшей собственник» проблемой стал — что если крыши и стены как раз на него завязаны были?

У вас странная логика.
Если тех, кто "захватил ДЦ" не смогла сразу же выдворить ни собственная охрана, ни, уверен, вызванная полиция, то почему вы считаете, что усложнение процедуры входа чем-то могло помочь?
Вы же не считаете, что они забаррикадировались на территории и все эти дни ни полиция ни какая-нибудь группа антитеррора не могла их выкурить оттуда? ;))

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

А в чём, собственно, проблема проникнуть на территорию ДЦ?
Был в нескольких ДЦ, не вижу вообще никаких сложностей — нигде не было ни колючей проволоки под напряжением, ни пулемётных вышек ни даже снайперов на крышах.


А значит, компания из 5+ крепких ребят элементарно проходит на территорию и делает всё, что посчитает нужным. Приехавшая на место полиция и даже нанятая охрана мгновенно утихает, увидив документы на владение территорией и отправляется восвояси. Одно дело, когда они "пресекают проникновение на охраняемый объект" и совсем другое, когда они "незаконно, с умыслом, совместно с группой лиц по предварительному сговору препятствуют законному собственнику находиться на территории своей собственности".


Как говорится, свечку не держал, но команда для проникновения могла состоять из 5-10 просто крепких ребят, 2-3 инженеров (для выполнения задач по отключению чего-либо) и группы из 2-5 адвокатов/юристов с бумажками, от вида которых приехавшая охрана сразу потеряет желание что-либо делать.


p.s. Это ещё хорошо, а если "проникновение на объект" осуществляли маски-шоу, либо "судебные приставы при исполнении", то в "команде проникновения" могло быть всего 3 человека — пристав, юрист и инженер.

проходит на территорию и делает всё, что посчитает нужным

Проходит до поста охраны и наталкивается на шлюзовые двери или шлюзовой турникет. Который блокируется охранником при любой странной ситуации (как то явление 5-10 крепких ребят).
Видел всего пару дата-центров и одну закрытую территорию, в которых были подобные турникеты. Там сделано ровно так, как вы сказали, только ещё через турникет-вертушку даже вдвоём не пройти.
Всё круто,… НО для въезда автотранспорта есть отдельные ворота без шлюзового модуля (наверное потому, что в ДЦ может въезжать фура максимальной длины и экономят место). При желании проникнуть можно дождаться въезда/выезда автомобиля и пробраться через ворота.
Тут уже охрана ничем не поможет.
Имхо бэкапов недостаточно, они должны храниться на отдельном сервере с возможностью быстрого разворачивания (с одновременной арендой дополнительных серверов). А иначе это детский сад.
Вот кто бы мог подумать, что придётся в докер уносить сайт с шареда. А сейчас вот сижу и пишу compose как раз для этого.
Никогда этого не было, и вот опять. Оверсан, mchost, кого я забыл?

ihor можно сказать «на днях», по крайней мере свежо предание

Драма с Максхостом была самой эпичной, наверное, за всё время.

Там были проблемы не связанные с переделом прав собственности.
У Макхоста с Оверсаном, на комментарий о которых я ответил, тоже не было проблем с переделом прав собственности.
UFO just landed and posted this here
Растут из того, что методы ведения бизнеса не эволюционировали с 90-х, а лишь приобрели небольшой фасадик, который очень легко падает, когда что-то идет не так.
UFO just landed and posted this here
не понимаю что сейчас пошло не так?
Так вот для чего НЛО работает…
1. Народ повалил в облака. 2. Интересные личности заметили наличие бабла в IT.

Район проклят, похоже. ) Айхор на угрешской был, эти, насколько я понял, тоже недалеко ))

Удивительность этой ситуации не то, что это произошло. Куча народу, зная, что есть подобные риски на примере не так уж и давнишних аналогичных историй в других конторах вопила о том, что у них нет бекапов. Спрашивается — если у тебя есть интернет-магазин, который делает твой доход или фирма, которая завязана на сайт\почту и ты после пары дней простоя отправляешь сотрудников в отпуск — почему ты не побеспокоился о резервном варианте? Речь даже не о том, чтобы организовать, например, ежедневное полноценное зеркало сайта на другом хостинге, чтобы потом при необходимости переключить на него ns записи домена. Что мешало хотя бы раз в неделю бэкап сайта и базы делать и отправлять его себе на комп или другой хостинг. Делать надо это самому. Хоть руками, хоть скриптом в cron'е.

В наше время вообще существует опасная тенденция к тому, что люди априори считают, что «сервис должен работать». Это и правильно, особенно когда деньги платишь. Но неправильно быть не готовым к сбоям. Сейчас вообще не думают об оценке рисков. Выходит из строя сервер или смартфон — имей бекапы. Летишь на самолёте — приходи с запасом, а не впритык к закрытию регистрации. Взломали сервис с твоей привязанной картой — имей отдельную карту, на которой немного денег. На почте нет интернета — обслуживайте по старинке. Пришёл в больницу по записи — будь морально готов к тому, что вместо 15 минут пройдёт час.
То, что подобное отношение у «обычных» людей — это одно. Но печалит то, что подобный подход закладывается при разработке госсервисов и на уровне крупного бизнеса. Доживём когда-нибудь до глобального блэкаута)
Это как с оптимизацией налогообложения. Можно же не делать всяких схем, рисков будет меньше. Однако в этом случае начинаем проигрывать в конкуренции тем, кто данными схемами пользуется. Даже экономия на 2% может очень хорошо сыграть на нынешнем конкурентном рынке.

Бэкапы — это тоже затраты. Даже в случае какого-нибудь простого магазина на вордпрессе нужно тратить ресурсы хотя бы на проверку того, что все скрипты работают, все бэкапы нормально восстанавливаются и т.д. Даже в самом примитивном случае могут быть факапы, например перенесли базу в другое место, забыли обновить конфиг бэкапа, и скрипт фигачит бэкапы с уже необновляемой базы. Когда объем сайта исчисляется уже терабайтами — простенькие скрипты уже не помогут, нужно заморачиваться с AWS и прочим. А многие бизнесы вообще живут без IT-специалистов. Им сделали в конторе сайт, первоначально настроили, выложили на хостинг и всё. Компания просто следит за тем, чтобы на хостинге были деньги.

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

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

Причём не обязательно иметь в штате постоянного сотрудника. Можно запускать ноутбук ночью раз в неделю (в BIOS запуск настраивается) + скрипт на архивацию и дамп БД, который будет отправлять архивы на этот включенный ноут. Раз-два в год привлекаешь человека для аудита работоспособности своей доморощенной системы бэкапов. Ну хотя бы так — это всё равно лучше, чем остаться с голым задом в случае факапа. И нет тут никаких 2%.
Вот и идея для стартапа — бесплатный бэкап базы, но выдача такого бэкапа — платная.
На том же Амазоне есть опции, где аплоад данных и хранение стоят очень дёшево, зато загрузка этих данных назад довольно дорогая.
Боюсь, что для того, чтобы такая модель была экономически обоснована ценник выдачи бекапа должен будет быть просто диким) Плюс ещё не очень радует, что постоянный доступ к сайту и базе будет у непойми кого.
UFO just landed and posted this here
Power On by RTC или Wake Up RTC.
Кстати, насчёт ноута, наверное, я поторопился. В материнских платах «обычных» ПК такие настройки норма. А вот в ноутбуках они не всегда есть — зависит от марки и модели.
Бэкапы — это тоже затраты

Копеечные затраты. Резервный (в другом ЦОДе, в другой стране) хостинг для бэкапов стоит 5 баксов в месяц. Bash-скрипт c mysqldump-ом и копированием папки /var/www пишется любым фрилансером за 10 минут и стоит 10 баксов.
Нужно как минимум ещё проверять чтобы всё работало. Плюс начиная с определённого объёма mysqldump начнёт выполняться несколько часов и тормозить систему, а копирование папки /var/www когда она начнёт занимать с пару сотен мегабайт встанет в копеечку по траффику. Нужно будет переходить на более сложные скрипты.
Пара сотен мег трафика — это ни о чём. Mysqldump кушает гиговую базу за пару минут (на хорошем сервере с SSD). И у 90% арендаторов — мелкие интернет-магазинчки, рекламные лэндинги, а то и вообще сайты-визитки с прайсом в экселе.
Опечатался, не мегабайт, а гигабайт конечно.
Окей, есть бэкап, а что дальше? Если домен поддерживается сломавшимся первичным DNS-сервером, как на нём записи поменять после подъёма сайта из бэкапа на другом хостинге?
Я не понимаю логики вашего вашего вопроса. А ещё прилетевший на землю крупный астероид положит конец всему IT направлению человечества… типа, окей, и где брать другой хостинг?
Ну вот он по сути для кого-то прилетел. А у кого-то из специалистов вовремя появилась идея раскидать яйца по разным корзинам, а у их заказчиков — деньги на эти корзины. И что, тем, кто «выжил», можно обвинять остальных в инфантилизме и немощности?
А, вот вы про что. Я подумал, что о том, что, дескать, какой смысл в бекапе, если DNS лёг. Поэтому мой ответ был в стиле: «И что — теперь бэкапы не делать?» )

Можно обвинять? А почему нельзя? Когда я давал рекомендации своим знакомым, то они реально не понимали зачем этим заниматься. На вопрос «что ты будешь делать, когда завтра твой сайт перестанет открываться», люди просто пожимали плечами. Это пофигизм. Не косяк специалистов или нехватка денег — подобный вопрос должен задавать владелец прежде всего сам себе. Дальше всё зависит от ответа на этот вопрос.
Бэкап — дело хорошее и нужное. Но слишком много есть людей, которые переходят в категорию «уже делает». И ничего с этим не сделаешь, хоть тысячу раз их порицай. Ну и, опять же, бэкапы не спасают от всех отказов, и при неучтённом отказе тот, кто в белом пальто всех порицал, но попал под такой отказ, сам будет раскритикован в т. ч. теми, кто не уделяет внимания проблемам, но кого отказ не затронул.
И да. На уровне архитектуры многие отказы можно предусмотреть вместе с возможностью их избежать, но сразу строить отказоустойчивую систему — удовольствие очень недешёвое, а проект может и не пойти, и тогда всё созданное улетит в трубу вместе с кучей потраченных на это денег. Спрашивается: как сделать одновременно идеально и разумно по затратам?
удовольствие очень недешёвое
Почему?
Спрашивается: как сделать одновременно идеально и разумно по затратам?

— регистратор и хостинг не должны быть одним лицом;
— ресурс должен бекапиться скриптами на какой-нибудь комп у себя дома (комп включается и отключается по расписанию), либо в облако;
— все пароли для поддержки ресурса нужно собирать в единый файл;
— раз в год последняя копия бэкапа должна записываться на CD\DVD болванку, а файл с паролями распечатываться, время хранения — 5 лет.
Никаких тут больших денег нет, но спокойному сну очень сильно способствует)

Надо учитывать специфику. Одно дело сайт-визитка физлица. Другое — когда бизнес только-только начинается и сайт либо ещё не играет сильной роли, либо на него сразу завязывается всё. И совсем иное когда уже сложившийся бизнес выходит в интернет. Критичность отказа для себя должен и может определять только сам владелец. Сайт-визитку можно размещать на лоукостере и бэкапить раз в год, а то и реже. А крупный бизнес уже может себе и round robin позволить.

Есть, правда, один момент чисто психологический. Когда человек начинает бизнес всё строилось по остаточному принципу и это было в какой-то степени оправдано. Потом у него всё разрастается, модель рисков уже не та, но так как оно всегда работало и работает это выпадает из поля зрения. И тут вдруг прилетает астероид, а оказывается что к этому никто не готов. Се ля ви) Вот это я могу понять. Но когда внимание акцентируешь на это или звучат первые звоночки в виде недоступности сайта на пару часов и потом у человека годами ничего не меняется… тут уж владелец сам себе буратино.
Ну вообще да, но не на все случаи ложится. Вспоминаю себя трёхлетней давности.

— платный сервис
— user generated content (тысячи пользователей, которые генерили тогда в сумме гигов по 10 в день, сейчас значительно больше)
— инфа важна, если откат на сутки назад они ещё могут пережить, то если откат будет на более далёкую дату — все разбегутся и хорошо если не засудят
— сервис держится исключительно на мне, а я программист, а не сисадмин.

Решение в лоб (mysqldump и заливать все файлы на FTP) уже не работает, времени настраивать более сложные решения с инкрементными бэкапами нет (понимаю, что не слишком долго, но когда у тебя нет ни минуты свободной — нужно преодолеть порог, чтобы со всем этим разобраться), искать фрилансера и давать ему доступ на прод не хотелось.

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

Если бы в то время упал метеорит — мой сервис бы это не пережил. С тех пор мы развились, и рабочие руки настроить всё как надо появились.

Я понимаю, что стратегия была неверной, я сам себе ЗБ, и хорошо, что пронесло. Но вот рассказываю как так может получиться. Когда отлично знаешь, что без бэкапов нельзя, а бэкапов нет.
тысячи пользователей, которые генерили тогда в сумме гигов по 10 в день, сейчас значительно больше

Ну это вы мою методичку уже явно переросли) Тут и на оптические диски «холодную копию» записывать смысла нет, если бэкапы капитально устаревают уже послезавтра)) Бэкапить терабайтные сервисы — это уже совсем другой уровень. И в результате как у вас сейчас организовано резервирование? Полная рабочая копия с распределённой синхронизацией?
Да не, по-прежнему дедовское решение. БД разнесены по разным виртуалкам, на одну виртуалку получается примерно 30 Гб -> ~4 Гб в gzip, по объёму получается сносно. По картинкам и прочим файлам (именно они дают основной объём) просто пробегаемся скриптом, и все новые бэкапим в облако, благо у каждого нового файла уникальное имя, поэтому можно не отслеживать актуальность файлов.

Потом надо будет сделать нормально… когда-нибудь… когда будет время…
tcapb1 Если бы в то время упал метеорит — мой сервис бы это не пережил.
Зачем метеорит? Достаточно было прихода «старого собственника/налоговой/etc» — и ваша компания накрылась бы медным тазом. Вы эту мысль до директора донесли?

tcapb1 Потом надо будет сделать нормально… когда-нибудь… когда будет время…
Что, на рынке есть дефицит в простых и надежных технологиях резервирования?
На тот момент ещё не было никакого директора, это был чисто мой пет-проджект, который управлялся в одни руки. Перейти порог один человек -> полноценная компания у меня очень долго не получалось.
tcapb1 На тот момент ещё не было никакого директора, это был чисто мой пет-проджект, который управлялся в одни руки. Перейти порог один человек -> полноценная компания у меня очень долго не получалось.
То есть вы могли потерять все за один день и вас это не беспокоило, главное развитие?

tcapb1 И когда все эти задачи расписаны на несколько лет вперёд очень сложно остановиться, отдышаться и например сделать качественные бэкапы. Неоптимально, но работает. Потом как-нибудь вернёмся. И так проходит месяц за месяцем.
А расписывают задачи кто — враги уборщицы?
Что, на рынке есть дефицит в простых и надежных технологиях резервирования?


Нет, нету конечно. Но постоянно есть конфликт по приоритетам.
1. Внедрение новых фич. Есть ключевые фичи, которые повышают конверсию продаж и понижают вероятность отказа от нас старых клиентов. Двигаемся в этом направлении: больше конверсия — больше денег — больше рабочих рук.
2. Доработка существующих фич. Система удобнее — лучше юзер-экспириенс — больше положительных отзывов — больше приходов по сарафану.
3. Снижение технического долга и переработка архитектуры. Пользователям на первый взгляд ничего не даёт, но повышает скорость разработки, снижает порог вхождения для новых сотрудников.

И когда все эти задачи расписаны на несколько лет вперёд очень сложно остановиться, отдышаться и например сделать качественные бэкапы. Неоптимально, но работает. Потом как-нибудь вернёмся. И так проходит месяц за месяцем.
Ну, скажем, round robin, установленный ДО поломки первичного DNS-сервера.

На «другом хостинге» держится запасная VDS с запасным IP-адресом.

РаундРонбин требует не запасной, а полной рабочей копии, которая работает одновременно и параллельно.


И когда сайт требует базы, я бы поглядел на решение полной отдельной копии за $5-10 под раундробином.

РаундРонбин требует не запасной, а полной рабочей копии

Если нужна высокая отказоустойчивость, близкий к нулю downtime, то делается полная рабочая копия.

Если высокая отказоустойчивость не нужна, можно ограничиться запасным IP-адресом, по которому находится запасной сервер (выключенный). После краха основного сервера, на запасной копируются забэкапленные данные, после чего сервер включается.

Это всё прекрасно.
Но тогда при чем тут раундробин?
У вас что, посетителя зашедшего на второй ИП будет встречать мёртвый хост? Это прикол такой?

Остаётся только понадеяться, что пострадавшие сделали верные выводы о том, что "регистратор доменов" и "хостер" должны быть разными сущностями. А лучше ещё и DNS хранить где-то в третьем месте, чтобы в случае подобных проблем была как минимум одна живая точка, в которой можно сделать перенаправление сайта.


Да, вариант с умершим регистратором будет самым жестоким, но и там наиболее вероятный сценарий — данные о доменах сохранятся, но настройки будут заморожены.

Очень важно резервировать DNS. У нас было падение на Хецнере, в результате которого оказалась в том числе недоступна панель управления DNS записями.

Если упала панель управления DNS, то это вообще не проблема — у регистратора меняете данные DNS и продолжаете работать.
Главное, чтоб бекапы были.


А если у вас как минимум VPS (а не просто shared хостинг за $10/мес и всё), то есть смысл запустить собственный "dns хостинг" для своих сайтов (благо можно в докере поставить парой кликов), а secondary dns запустить на VPS другого провайдера.

И как bulletproof — взять халявные ns у Hurricane Electric и их тоже сделать репликой.

и предотвращает возможные сбои в будущем
Видимо штат доукомплектовали гадалками.
UFO just landed and posted this here
Может я что-то не понимаю, но почему нельзя было привлечь полицию? Это же разбой и бандитизм. А если она была привлечена, то почему не смогла справится? Вроде как у нас не 90е на дворе. То есть все знают об акте правонарушения, но силовые структуры бездействуют, как так?
Спасибо огромное минуснувшему! Теперь всё, конечно, понятно. Как я мог так заблуждаться! (sarcasm)

А если серьёзно, то у меня вроде как адекватный вопрос и мне интересно почему так. И я его задаю из любопытства, а не из разжигания ненависти.
Споры хозяйствующих субъектов, если они не сопровождаются общественно опасными деяниями, не являются сферой деятельности полиции. Для этого есть переговоры и арбитражный суд с приставами.
Sign up to leave a comment.

Other news