[{"data":1,"prerenderedAt":267},["ShallowReactive",2],{"article-94-ru":3,"related-94":76,"ArticleBody_WIrSa6rLNDzO8kpXXE2NrX3JcRBnl1ZFhm8xfz5b0":262},{"id":4,"title":5,"slug":6,"content":7,"metaTitle":5,"metaDescription":5,"coverUrl":8,"views":9,"likes":10,"createdAt":11,"updatedAt":12,"category":13,"tags":23,"author":36,"tableOfContents":40,"locale":73,"translated":74,"indexable":75},94,"Вы удалили сервер. Что от вас осталось","vy-udalili-server-chto-ot-vas-ostalos","# Вы удалили сервер. Что от вас осталось\n---\n\nНажали «удалить». Или просто перестали платить, и хостер сам всё выключил. Списания прекратились, машина из панели пропала, вопрос закрыт.\n\nНе закрыт. За одной кнопкой стоит несколько независимых процессов, и заканчиваются они в разное время. Виртуалка исчезает мгновенно, диск освобождается когда-то потом, ваш адрес уходит новому владельцу через полчаса, снапшот от марта продолжает лежать и тихо оплачиваться, а ключ, который валялся на этом сервере, работает до сих пор, потому что ему никто не сообщил о вашем решении.\n\nРазберём по порядку: что происходит с данными физически, сколько времени они живут по договору, что переживает удаление и почему следующий владелец вашего адреса может месяцами получать письма, предназначенные вам.\n\n**Кому пригодится:** если удаляли серверы и не задумывались, что там осталось; если планируете переезд; или если просто интересно, что вам самому досталось в наследство вместе с новым адресом.\n\n---\n\n## Содержание\n\n1. [Кнопка «удалить» запускает не одно действие](#кнопка-удалить-запускает-не-одно-действие)\n2. [Два пути к одному финалу](#два-пути-к-одному-финалу)\n3. [Сколько на самом деле живут ваши данные](#сколько-на-самом-деле-живут-ваши-данные)\n4. [«Удалить» и «стереть» делают разное](#удалить-и-стереть-делают-разное)\n5. [Почему на SSD перезапись не работает](#почему-на-ssd-перезапись-не-работает)\n6. [Как это решают всерьёз: уничтожение ключа](#как-это-решают-всерьёз-уничтожение-ключа)\n7. [Что переживает удаление сервера](#что-переживает-удаление-сервера)\n8. [Ваш адрес уходит следующему через полчаса](#ваш-адрес-уходит-следующему-через-полчаса)\n9. [Что досталось вам от предыдущего жильца](#что-досталось-вам-от-предыдущего-жильца)\n10. [Порядок действий перед удалением](#порядок-действий-перед-удалением)\n11. [Частые ошибки](#частые-ошибки)\n12. [Короткий итог](#короткий-итог)\n\n[Источники](#источники)\n\n---\n\n## Кнопка «удалить» запускает не одно действие\n\nОсновная ошибка мышления тут вот какая. Вы видите одну кнопку и предполагаете за ней одно действие: было и не стало.\n\nНа деле за ней несколько отдельных процессов у разных подсистем, и у каждого свой срок:\n\n- **Виртуальная машина** останавливается и удаляется из гипервизора. Быстро, обычно мгновенно.\n- **Дисковое пространство** помечается свободным и возвращается в общий пул. Когда его перезапишут чужие данные, не знает никто, в том числе хостер.\n- **IP-адрес** уходит в пул свободных и выдаётся кому-то ещё. Часто это происходит **раньше**, чем что-либо сделают с диском.\n- **Снапшоты и резервные копии** живут отдельной жизнью, потому что это отдельные сущности со своей оплатой.\n- **Внутренние логи хостера** про вашу активность хранятся по своему регламенту, который к удалению сервера отношения не имеет.\n\nПять процессов, пять разных таймеров. «Сервер удалён» описывает только первый из них, а звучит так, будто описывает все пять. На это и расчёт.\n\n---\n\n## Два пути к одному финалу\n\nСценария два, и путают их постоянно.\n\n**Вы удаляете сами.** Тут всё быстро и в целом честно: сказали удалить, машину удалили. Опасность в другом, и она полностью на вашей стороне: удаляя машину, вы не удаляете то, что она успела наплодить снаружи. К этому вернёмся отдельным разделом.\n\n**Вы перестали платить.** Тут появляется лестница, и вот на ней людей и подстерегает неприятность:\n\n1. **Просрочка.** Списание не прошло, сервер работает, приходят напоминания.\n2. **Приостановка.** Машину выключают. Данные на месте, но вы к ним не подключитесь. Иногда за это время продолжает капать плата.\n3. **Отведённый срок.** Сколько-то дней всё лежит выключенным и ждёт оплаты.\n4. **Удаление.** Срок вышел, всё стирается, и с этого момента возврата нет.\n\nЗапомните эту разницу заранее: **приостановка и удаление это два разных события с разным запасом времени**. А сколько именно длится третий шаг, вы, скорее всего, не знаете. Проверять это в момент, когда карта уже не прошла, поздновато.\n\n---\n\n## Сколько на самом деле живут ваши данные\n\nЯ прошёлся по договорам нескольких хостеров, чтобы посмотреть на разброс. Он оказался приличный.\n\nОдна оговорка про формулировки: почти везде написано «услуга **может быть** прекращена», а не «будет». Это верхняя граница вашего запаса времени, а не обещание им воспользоваться.\n\n| Хостер | Что написано в договоре |\n|---|---|\n| Servhost | приостановка сразу, **полное удаление через 3 дня** |\n| Host4Geeks | приостановка через 3 дня после срока оплаты, **полное удаление через 5 дней** |\n| Hostxpeed | приостановка через 3 дня, прекращение услуги через 7 |\n| KnownHost | учётная запись переводится в неактивные при просрочке больше 5 дней |\n| Namecheap | 3 дня отсрочки для VPS, прекращение возможно после 14 дней приостановки |\n| RealHost | неоплаченный VPS хранится 2 недели, дальше удаляется полностью |\n| Ace Hosts | приостановка сразу, данные лежат месяц, потом стираются |\n\nРазброс от пяти дней до месяца. То есть у одного хостера вы уехали в отпуск, карта не прошла, и через пять дней от проекта ничего не осталось. У другого в той же ситуации есть четыре недели, чтобы заметить.\n\nОтпуск, замечу, у обоих длится две недели.\n\nРейтинга хороших и плохих тут нет: короткий срок хранения не жадность, а экономия на месте, которое иначе занимают мёртвые виртуалки. Но **знать свою цифру надо до того, как она понадобится**, и искать её надо не в рекламе, а в пользовательском соглашении, в разделе про неоплату.\n\nВторое, что стоит проверить там же: **удаляются ли резервные копии вместе с услугой**. У части хостеров прямо написано, что при прекращении услуги копии тоже стираются. Логично, но людей это регулярно застаёт врасплох, потому что бэкап воспринимается как страховка от всего, включая собственную забывчивость. От неоплаты он не страхует.\n>Для того чтобы намного быстрее получить эту информацию - вы можете обратится в поддержку хостинга, думаю на все ваши вопросы сможет ответить хостинг быстрее, чем вы сами найдете эту информацию.\n---\n\n## «Удалить» и «стереть» делают разное\n\nПереходим к физике, и тут начинается интересное.\n\nКогда вы удаляете файл на своём компьютере, данные никуда не деваются: файловая система просто помечает место как свободное. Все это знают. Гораздо реже задумываются, что на уровне облака работает та же логика, только этажей больше.\n\nУдаление виртуалки означает, что её диск возвращается в общее хранилище как свободное место. Данные в блоках физически остаются лежать, пока поверх них не запишут что-то другое. Когда это произойдёт, зависит от загрузки хранилища и не гарантируется никем.\n\nЕсть стандарт, который эти вещи разделяет, и на него удобно опираться, потому что он же лежит в основе большинства регламентов. Американский **NIST SP 800-88** описывает три уровня очистки:\n\n- **Clear.** Перезапись обычными командами. Спасает от восстановления бытовыми утилитами, от лаборатории не спасает.\n- **Purge.** Серьёзные методы: аппаратная команда очистки, уничтожение ключа шифрования, размагничивание. После этого восстановление считается неосуществимым даже современными средствами.\n- **Destroy.** Физическое уничтожение носителя: измельчение, сжигание, расплавление.\n\nТак вот. **Обычное удаление виртуалки не дотягивает даже до первого уровня.** Оно вообще не про очистку, оно про освобождение места. Это не обман со стороны хостера, просто слово «удалить» в интерфейсе означает не то, что вам кажется.\n\n---\n\n## Почему на SSD перезапись не работает\n\nХорошо, скажет читатель, значит надо перед удалением всё забить нулями. Совет из девяностых, и на жёстких дисках он работал.\n\nНа твердотельных накопителях он не работает, и вот почему.\n\nУ SSD между адресами, которые видит операционная система, и физическими ячейками памяти стоит переходный слой. Он существует потому, что ячейки изнашиваются от записи, и контроллер обязан размазывать нагрузку по всему объёму равномерно. Когда вы «перезаписываете» блок, контроллер **не трогает старую ячейку**. Он пишет в другую, свободную, и просто переставляет указатель. Старая ячейка со старыми данными остаётся лежать, пока до неё не дойдёт очередь на очистку.\n\nПлюс у любого SSD есть резервная область, которой в адресах ОС вообще не существует. Дотянуться до неё обычными командами нельзя, а данные там оседают.\n\nЭто не теория. В работе, представленной на конференции FAST в 2011 году, исследователи проверили методы очистки эмпирически: вычищали накопитель, а потом снимали данные напрямую с чипов памяти. Выводы такие:\n\n- Встроенные аппаратные команды очистки работают, **но производители местами реализуют их неправильно**.\n- Перезапись всего видимого адресного пространства **дважды** обычно достаточна, но не всегда.\n- **Ни один способ затирания отдельного файла на SSD не работает.**\n\nПоследний пункт стоит перечитать. Стереть один файл так, чтобы его нельзя было достать, на SSD нельзя в принципе. Можно вычистить накопитель целиком аппаратной командой, и на этом список заканчивается.\n\nА теперь наложите это на облако. У вас нет аппаратного доступа к накопителю: диск виртуальный, физический носитель общий и лежит под чужим управлением. Все ваши попытки что-то «затереть» изнутри виртуалки происходят на два этажа выше реальных ячеек.\n\n---\n\n## Как это решают всерьёз: уничтожение ключа\n\nХорошая новость есть, и она изящная.\n\nРаз надёжно стереть данные тяжело, задачу переворачивают: данные шифруют при записи, а при удалении уничтожают ключ. Носитель остаётся забитым шифротекстом, но без ключа это шум. В классификации NIST такой приём относится к уровню Purge, то есть считается полноценной очисткой наравне с аппаратным стиранием.\n\nПлюсы очевидны: мгновенно, не изнашивает ячейки, работает независимо от того, где физически разбросаны данные по накопителю.\n\nОтсюда следует практический вывод, который мне кажется главным во всей статье. **Если хотите контролировать удаление своих данных, шифруйте их своим ключом с самого начала.** Тогда вопрос «а стёрли ли на самом деле» перестаёт вас волновать: вы уничтожаете ключ у себя, и дальше неважно, сколько ещё месяцев блоки пролежат в чужом хранилище.\n\nЭто единственный способ получить гарантию, которая не зависит от чужой добросовестности. Всё остальное упирается в доверие: вам говорят, что стёрли, проверить вы это не можете никак.\n\nОговорюсь про цену. Ключ, который лежит на том же сервере, ничего не решает: он уедет вместе со всем остальным. Настоящая схема требует, чтобы ключ вводился извне, а это означает, что сервер не поднимется сам после перезагрузки. Безопасность тут покупается за удобство, и решать, нужна ли она вам по такой цене, надо осознанно.\n\n---\n\n## Что переживает удаление сервера\n\nРаздел, ради которого статью стоило писать, потому что тут теряют больше всего.\n\nМашины нет, а следующее живо:\n\n**Снапшоты и резервные копии.** Отдельные объекты с отдельной оплатой. Удалили сервер, а снапшот от марта остался, и за него продолжают списывать. Заодно в нём лежит вся ваша тогдашняя конфигурация, включая то, что вы потом посчитали секретом.\n\n**Образы и шаблоны.** То же самое: сделали свой образ, чтобы разворачивать копии, и он пережил все машины, созданные из него.\n\n**Ключи и токены, которые лежали на сервере.** Вот это самое важное. SSH-ключ для доступа к репозиторию, токен облачного API, ключ для отправки почты, пароль от базы на другой машине. **Удаление сервера не отзывает ни один из них.** Они продолжают работать, потому что вторая сторона про ваше удаление ничего не знает. Если содержимое диска кто-то потом достанет, все эти доступы окажутся у него живыми.\n\n**Доступы, которые сервер получал наружу.** Ключ развёртывания в репозитории, вебхук, подписка на уведомления, разрешение в чужом файрволе.\n\n**Записи DNS.** Про них дальше отдельный разговор, потому что тут выходит хуже всего.\n\n**Логи у хостера.** Кто подключался, откуда, когда, сколько трафика. Они относятся к вашей учётной записи, а не к машине, и хранятся по регламенту хостера.\n\nОбщее правило простое: **сервер удаляется, а всё, что он успел выдать наружу, остаётся действительным.** Отзывать это надо руками и заранее.\n\n---\n\n## Ваш адрес уходит следующему через полчаса\n\nТеперь самая недооценённая часть темы, и по ней, к счастью, есть нормальные исследования, а не догадки.\n\nВаш IP не уничтожается, он возвращается в пул и достаётся кому-то другому. Вопрос только в скорости. Исследователи развернули в одном из регионов крупного облака собственную наблюдательную сеть: больше трёх миллионов запусков серверов, около полутора миллионов уникальных адресов за 101 день, то есть примерно **56% всего доступного пула**. Выяснилось, что адрес там может **менять владельца каждые полчаса**.\n\nЧто получает следующий жилец, если вы не прибрали за собой:\n\n**Ваш трафик.** Если где-то остался DNS-запись, указывающая на этот адрес, всё, что по ней идёт, приезжает новому владельцу. Запросы приложений, вебхуки, служебные уведомления. Иногда с токенами внутри.\n\n**Возможность прикинуться вами.** Домен указывает на адрес, адрес теперь чужой, значит по вашему имени отвечает посторонний.\n\nМасштаб проблемы измерен. В другой работе собрали 130 миллионов доменов, указывающих на облачные адреса, и обнаружили, что **больше 700 тысяч доменов ведут на адреса, которые уже свободны** и доступны для захвата. Отдельное наблюдение на двенадцати облачных платформах зафиксировало почти 21 тысячу случаев, когда такой захват реально использовали для размещения вредоносного содержимого.\n\nСемьсот тысяч доменов. Списать такое на отдельных ротозеев не выйдет, это системная привычка целой индустрии: сервер убирают, а запись про него забывают. Причём убирают обычно аккуратно, с подтверждением в диалоговом окне, чтобы уж точно ничего не пропало.\n\nОтсюда правило, которое надо запомнить намертво: **сначала убираете записи DNS, потом освобождаете адрес.** Не наоборот. Между этими двумя действиями есть окно, и в облаке оно может измеряться минутами.\n>Нормальные регистраторы удаляют A записи за секунд 15.\n---\n\n## Что досталось вам от предыдущего жильца\n\nСимметричная половина той же истории, и о ней думают ещё реже.\n\nАдрес, который вам выдали, не новый. У него была жизнь, и её последствия теперь ваши.\n\n**Репутация.** Если предыдущий владелец рассылал спам или его сервер взломали, адрес мог уехать в чёрные списки. Ваша почта перестаёт доходить, а виноваты будете вы, потому что разбираться придётся вам. Про то, как из этого выбираться, у меня [есть отдельная статья](https://serv.host/articles/79).\n>Вообще в подобных случаях можно обратиться в поддержку хостинга и вам просто дадут другой IP.\n\n**Чужой трафик.** На ваш свежий сервер начинают приходить запросы, адресованные кому-то другому. Это ещё не атака, а остатки чужих настроек: где-то не почистили DNS, где-то в конфиге прописан адрес.\n\nТут стоит сказать прямо: **приходящий на ваш адрес чужой трафик разумно считать чужими данными и не трогать его**. Соблазн посмотреть, что там прилетает, понятен, но по ту сторону живые люди и их сведения, и правильная реакция это закрыть порт, а не изучать содержимое.\n\n**Внимание сканеров.** Если предыдущий владелец наследил, адрес может уже стоять в чьих-то списках интересного. Первые попытки к вам придут быстрее обычного, а обычное там и так около двадцати минут.\n\nПроверить наследство стоит в первый же день: репутацию адреса в списках и что вообще на него приходит. Если досталось плохое, нормальный хостер меняет адрес по запросу, и это самый простой выход.\n\n---\n\n## Порядок действий перед удалением\n\nТут порядок важнее содержания, потому что половина проблем возникает именно из-за очерёдности.\n\n1. **Заберите то, что нужно.** Данные, конфиги, история. После удаления взять будет неоткуда, и период ожидания, если вы попали в сценарий с неоплатой, может оказаться в пять дней.\n2. **Составьте список того, что этот сервер знал.** Какие ключи на нём лежали, какие токены он использовал, в какие сервисы ходил, что ему было разрешено.\n3. **Отзовите всё из этого списка.** Ключи развёртывания, токены API, доступы к базам, вебхуки, разрешения в чужих файрволах. Именно отозвать, а не понадеяться, что оно умрёт вместе с машиной.\n4. **Уберите записи DNS.** До освобождения адреса, а не после.\n5. **Удалите снапшоты, образы и копии явным образом.** Проверьте счёт через месяц: если что-то забылось, оно там всплывёт.\n6. **Только теперь удаляйте машину.**\n7. **Через месяц загляните в счёт ещё раз.** Забытые объекты обнаруживаются именно так.\n\nПункты со второго по третий занимают больше всего времени и пропускаются чаще всего. Если вы за всё время существования сервера не вели список выданных ему доступов, восстанавливать его придётся по памяти, и что-нибудь вы обязательно забудете. Вывод на будущее скучный: такой список проще вести сразу, чем собирать в конце.\n\n---\n\n## Где это держать\n\nОдна практическая мысль, раз уж весь текст про сроки и адреса.\n\nПри выборе хостера стоит посмотреть ровно два пункта, и оба лежат не в рекламе, а в пользовательском соглашении: **через сколько дней после неоплаты данные удаляются** и **что происходит с резервными копиями при прекращении услуги**. Разброс, как видно из таблицы выше, от трех дней до месяца, и это разница между «успел заметить» и «не успел».\n\nТретий пункт проверяется уже после подключения: какой адрес вам достался и не тянется ли за ним чужая история.\n\nУ меня для проектов [serv.host](https://serv.host/?from=22382) (промокод `promo22382`), и логика выбора была примерно такая же: понятные условия по срокам и чистые адреса, чтобы не разбираться с чужим наследством в первый же день. Плюс живая поддержка, которая по запросу меняет адрес, если тот оказался с прошлым.\n\n---\n\n## Частые ошибки\n\n- **Считать, что «удалено» значит «стёрто».** Удаление освобождает место, очистка это другая операция, и по классификации NIST обычное удаление не дотягивает даже до низшего уровня.\n- **Забивать диск нулями перед удалением.** На SSD это не работает так, как вы думаете: контроллер пишет в другие ячейки, а старые остаются. Отдельный файл на SSD затереть нельзя в принципе.\n- **Освобождать адрес раньше, чем убраны записи DNS.** Ровно так и получаются те самые сотни тысяч доменов, указывающих в никуда.\n- **Думать, что ключи умирают вместе с сервером.** Не умирают. Отзывать надо руками, и лучше до удаления.\n- **Забывать про снапшоты.** Они переживают машину и продолжают оплачиваться.\n- **Полагаться на бэкап в ситуации с неоплатой.** У части хостеров копии стираются вместе с услугой, и это прямо написано в договоре.\n- **Не знать своего срока хранения.** Выяснять его в момент, когда карта не прошла, поздно.\n- **Изучать чужой трафик, прилетевший на ваш новый адрес.** Это чужие данные. Закрыть, а не читать.\n\n---\n\n## Короткий итог\n\n- **За кнопкой «удалить» стоит пять процессов с разными сроками:** машина, диск, адрес, копии, логи хостера. Совпадают они только в вашем воображении.\n- **При неоплате есть лестница:** просрочка, приостановка, срок ожидания, удаление. У разных хостеров этот срок отличается **от пяти дней до месяца**.\n- **Удаление это освобождение места, а не очистка.** По классификации NIST существуют три уровня очистки, и обычное удаление виртуалки не относится ни к одному.\n- **На SSD перезапись работает не так, как ждут:** контроллер пишет в другую ячейку, а старая остаётся. По исследованию FAST 2011, затереть отдельный файл на SSD не удаётся ни одним способом.\n- **Работающее решение это шифрование с уничтожением ключа.** И единственная гарантия, не зависящая от чужой добросовестности, шифровать своим ключом с самого начала.\n- **Удаление сервера не отзывает ничего,** что он выдал наружу: ключи, токены, вебхуки, доступы. Они живут дальше.\n- **Адрес уходит следующему быстро,** в облаке он может менять владельца каждые полчаса. Больше 700 тысяч доменов сейчас указывают на уже освобождённые облачные адреса.\n- **Сначала DNS, потом освобождение адреса.** Обратный порядок и создаёт эту статистику.\n- **Вам тоже достался чужой адрес** со своей репутацией и чужим трафиком. Проверять стоит в первый день.\n\nОбщий смысл такой. Сервер это не коробка, которую можно выбросить целиком. Это узел, от которого за время жизни расходятся связи наружу: доступы, записи, копии, ссылки в чужих конфигах. Удаление обрывает сам узел и не трогает ни одну из связей. Убирать их приходится руками, и делать это надо до, а не после.\n\n---\n\n**Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему**\n\n**Сторонний мой проект: [Zapret2UI.](https://github.com/Asterlike/zapret2UI)**\n>ПОСТАВЬ ЗВЕЗДУ ПЖ\n---\n\n## Источники\n\n- [NIST SP 800-88 - руководство по очистке носителей, уровни Clear, Purge, Destroy](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf)\n- [Reliably Erasing Data from Flash-Based Solid State Drives (FAST 2011)](https://www.usenix.org/conference/fast11/reliably-erasing-data-flash-based-solid-state-drives)\n- [Measuring and Mitigating the Risk of IP Reuse on Public Clouds - исследование повторной выдачи адресов](https://arxiv.org/pdf/2204.05122)\n- [Cloudy with a Chance of Cyberattacks - про брошенные DNS-записи и захваты](https://arxiv.org/pdf/2403.19368)\n- [Разбор темы брошенных DNS-записей в блоге APNIC](https://blog.apnic.net/2024/04/04/abuse-of-dangling-dns-records-on-cloud-platforms/)\n","/uploads/5d46cee1-c72a-4b83-aceb-6e2951e1335f.png",1,0,"2026-09-06T14:07:30.457Z","2026-09-11T14:27:27.000Z",{"id":14,"value":15,"content":16,"sortOrder":17,"parent":18},10,"security","Security",4,{"id":19,"value":20,"content":21,"sortOrder":22},6,"admin","Администрирование",3,[24,28,32],{"id":25,"value":26,"content":27},18,"gayd","Гайд",{"id":29,"value":30,"content":31},114,"bezopasnost","Безопасность",{"id":33,"value":34,"content":35},130,"blog","Блог",{"id":37,"name":38,"slug":39},105,"Aster.","aster",[41,42,45,47,49,51,53,55,57,59,61,63,65,67,69,71],{"level":9,"text":5},{"level":43,"text":44},2,"Содержание",{"level":43,"text":46},"Кнопка «удалить» запускает не одно действие",{"level":43,"text":48},"Два пути к одному финалу",{"level":43,"text":50},"Сколько на самом деле живут ваши данные",{"level":43,"text":52},"«Удалить» и «стереть» делают разное",{"level":43,"text":54},"Почему на SSD перезапись не работает",{"level":43,"text":56},"Как это решают всерьёз: уничтожение ключа",{"level":43,"text":58},"Что переживает удаление сервера",{"level":43,"text":60},"Ваш адрес уходит следующему через полчаса",{"level":43,"text":62},"Что досталось вам от предыдущего жильца",{"level":43,"text":64},"Порядок действий перед удалением",{"level":43,"text":66},"Где это держать",{"level":43,"text":68},"Частые ошибки",{"level":43,"text":70},"Короткий итог",{"level":43,"text":72},"Источники",null,false,true,[77,99,107,152,165,180,199,221,236,250],{"id":78,"title":79,"slug":80,"content":79,"description":79,"coverUrl":81,"views":9,"likes":10,"createdAt":82,"category":83,"tags":87,"author":98},95,"«Мы не храним логи»: чего стоит эта фраза","my-ne-hranim-logi-chego-stoit-eta-fraza","/uploads/fdaab330-8bfc-4a49-9aec-9effcf319d8c.png","2026-09-06T14:20:58.317Z",{"id":84,"value":85,"content":86,"sortOrder":17,"parent":73},11,"db","Базы данных",[88,92,96,97],{"id":89,"value":90,"content":91},14,"migrations","Миграции",{"id":93,"value":94,"content":95},80,"backup","Backup",{"id":29,"value":30,"content":31},{"id":33,"value":34,"content":35},{"id":37,"name":38,"slug":39},{"id":4,"title":5,"slug":6,"content":5,"description":5,"coverUrl":8,"views":9,"likes":10,"createdAt":11,"category":100,"tags":102,"author":106},{"id":14,"value":15,"content":16,"sortOrder":17,"parent":101},{"id":19,"value":20,"content":21,"sortOrder":22},[103,104,105],{"id":25,"value":26,"content":27},{"id":29,"value":30,"content":31},{"id":33,"value":34,"content":35},{"id":37,"name":38,"slug":39},{"id":108,"title":109,"slug":110,"content":111,"description":111,"coverUrl":73,"views":112,"likes":10,"createdAt":113,"category":114,"tags":122,"author":149},89,"Что такое uptime VPS и почему 99,9% - это не 100%","chto-takoe-uptime-vps","Что такое uptime VPS и почему 99,9% - это не 100% == Когда выбирают VPS, одним из первых показателей, на который обращают внимание, становится uptime. Провайдер",191,"2026-08-17T14:22:17.023Z",{"id":115,"value":116,"content":117,"sortOrder":10,"parent":118},24,"gaydy","Гайды",{"id":119,"value":120,"content":121,"sortOrder":10},23,"obshchee","Общее",[123,124,128,129,133,137,141,145],{"id":25,"value":26,"content":27},{"id":125,"value":126,"content":127},19,"pravila","Правила",{"id":29,"value":30,"content":31},{"id":130,"value":131,"content":132},115,"rukovodstvo","Руководство",{"id":134,"value":135,"content":136},116,"instrukciya","Инструкция",{"id":138,"value":139,"content":140},117,"tutorial","Туториал",{"id":142,"value":143,"content":144},119,"ustanovka","Установка",{"id":146,"value":147,"content":148},120,"sovety","Советы",{"id":150,"name":151,"slug":73},109,"serv.host",{"id":153,"title":154,"slug":155,"content":156,"description":156,"coverUrl":73,"views":157,"likes":43,"createdAt":158,"category":159,"tags":161,"author":164},87,"Хостинг API и бэкенд-приложений на VPS","hosting-api-i-bekend-prilojeniy-na-vps","Хостинг API и бэкенд-приложений на VPS == Если вы разрабатываете сайт, мобильное приложение или собственный сервис, рано или поздно возникает вопрос - где разме",195,"2026-08-17T13:52:11.777Z",{"id":115,"value":116,"content":117,"sortOrder":10,"parent":160},{"id":119,"value":120,"content":121,"sortOrder":10},[162,163],{"id":25,"value":26,"content":27},{"id":138,"value":139,"content":140},{"id":150,"name":151,"slug":73},{"id":166,"title":167,"slug":168,"content":169,"description":169,"coverUrl":73,"views":170,"likes":9,"createdAt":171,"category":172,"tags":174,"author":179},86,"ИИ в технической работе: где помогает, а где нельзя доверять","ii-v-tehnicheskoy-rabote-gde-pomogaet-a-gde-nelzya-doveryat","ИИ в технической работе: где помогает, а где нельзя доверять Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой прое",207,"2026-08-09T09:26:13.317Z",{"id":115,"value":116,"content":117,"sortOrder":10,"parent":173},{"id":119,"value":120,"content":121,"sortOrder":10},[175,176,177,178],{"id":25,"value":26,"content":27},{"id":125,"value":126,"content":127},{"id":130,"value":131,"content":132},{"id":146,"value":147,"content":148},{"id":37,"name":38,"slug":39},{"id":181,"title":182,"slug":183,"content":184,"description":184,"coverUrl":73,"views":185,"likes":10,"createdAt":186,"category":187,"tags":189,"author":198},84,"Почему пинг ничего не говорит: jitter, потери пакетов и bufferbloat","pochemu-ping-nichego-ne-govorit-jitter-poteri-paketov-i-bufferbloat","Почему пинг ничего не говорит: jitter, потери пакетов и bufferbloat Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний м",192,"2026-08-09T05:55:28.579Z",{"id":115,"value":116,"content":117,"sortOrder":10,"parent":188},{"id":119,"value":120,"content":121,"sortOrder":10},[190,191,195,196,197],{"id":125,"value":126,"content":127},{"id":192,"value":193,"content":194},113,"monitoring","Мониторинг",{"id":29,"value":30,"content":31},{"id":130,"value":131,"content":132},{"id":134,"value":135,"content":136},{"id":37,"name":38,"slug":39},{"id":200,"title":201,"slug":202,"content":203,"description":203,"coverUrl":73,"views":157,"likes":9,"createdAt":204,"category":205,"tags":207,"author":220},83,"Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере","svoy-monitoring-uptime-kuma-ili-prometheus-s-grafana-i-pochemu-on-obyazan-jit-na-otdelnom-servere","Свой мониторинг: Uptime Kuma или Prometheus с Grafana, и почему он обязан жить на отдельном сервере Вообще я микроразработчик, со мной можно связаться как угодн","2026-08-09T05:54:48.670Z",{"id":115,"value":116,"content":117,"sortOrder":10,"parent":206},{"id":119,"value":120,"content":121,"sortOrder":10},[208,209,210,211,212,213,214,215,219],{"id":25,"value":26,"content":27},{"id":125,"value":126,"content":127},{"id":192,"value":193,"content":194},{"id":29,"value":30,"content":31},{"id":130,"value":131,"content":132},{"id":134,"value":135,"content":136},{"id":138,"value":139,"content":140},{"id":216,"value":217,"content":218},118,"nastroyka","Настройка",{"id":146,"value":147,"content":148},{"id":37,"name":38,"slug":39},{"id":222,"title":223,"slug":224,"content":225,"description":225,"coverUrl":73,"views":226,"likes":9,"createdAt":227,"category":228,"tags":230,"author":235},82,"TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS)","tls-fingerprinting-kak-server-uznaet-tvoy-klient-ja3ja4-utls","TLS-фингерпринтинг: как сервер узнаёт твой клиент (JA3/JA4, uTLS) Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой",162,"2026-08-07T21:34:46.778Z",{"id":115,"value":116,"content":117,"sortOrder":10,"parent":229},{"id":119,"value":120,"content":121,"sortOrder":10},[231,232,233,234],{"id":25,"value":26,"content":27},{"id":125,"value":126,"content":127},{"id":130,"value":131,"content":132},{"id":146,"value":147,"content":148},{"id":37,"name":38,"slug":39},{"id":237,"title":238,"slug":239,"content":240,"description":240,"coverUrl":73,"views":241,"likes":9,"createdAt":242,"category":243,"tags":245,"author":249},81,"Whois-приватность: кто на самом деле видит твои данные при регистрации домена","whois-privatnost-kto-na-samom-dele-vidit-tvoi-dannye-pri-registracii-domena","Whois-приватность: кто на самом деле видит твои данные при регистрации домена Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему С",152,"2026-08-07T21:03:10.184Z",{"id":115,"value":116,"content":117,"sortOrder":10,"parent":244},{"id":119,"value":120,"content":121,"sortOrder":10},[246,247,248],{"id":125,"value":126,"content":127},{"id":29,"value":30,"content":31},{"id":130,"value":131,"content":132},{"id":37,"name":38,"slug":39},{"id":93,"title":251,"slug":252,"content":253,"description":253,"coverUrl":73,"views":254,"likes":9,"createdAt":255,"category":256,"tags":258,"author":261},"Domain fronting: как работал обход SNI-фильтрации и почему умер","domain-fronting-kak-rabotal-obhod-sni-filtracii-i-pochemu-umer","Domain fronting: как работал обход SNI-фильтрации и почему умер Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему Сторонний мой п",156,"2026-08-07T20:39:32.556Z",{"id":115,"value":116,"content":117,"sortOrder":10,"parent":257},{"id":119,"value":120,"content":121,"sortOrder":10},[259,260],{"id":29,"value":30,"content":31},{"id":130,"value":131,"content":132},{"id":37,"name":38,"slug":39},["Island",263],{"key":264,"result":265},"ArticleBody_WIrSa6rLNDzO8kpXXE2NrX3JcRBnl1ZFhm8xfz5b0",{"head":266},{},1789171251428]