ESTT // IT с характером

Резервный дата-центр готов. А смогут ли пользователи получить доступ к сервисам?

Мы уже рассказывали о георезервировании и о том, почему одного резервного копирования недостаточно для восстановления IT-инфраструктуры. Но даже если резервная площадка полностью подготовлена, остаётся ещё один важный вопрос: как организована связь между дата-центрами и внешними сетями.

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

В новой статье блога ESTT разбираем, что влияет на надёжность сетевой связности, как работают BGP, пиринг и IP-транзит, чем М9 отличается от MSK-IX и почему при проектировании резервной инфраструктуры важно учитывать не только серверное оборудование, но и сеть.

Подробнее в статье «Одна линия на схеме: что на самом деле обеспечивает связность дата-центра»:
https://dcestt.ru/blog/datacenter-network-connectivity?utm_source=max&utm_medium=social&utm_campaign=network_connectivity_202610&utm_content=post

От магнитной ленты до резервного ЦОДа: как менялась защита данных

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

А сегодня решили обратиться к истории.
В начале 1950-х инженеры IBM разрабатывали ленточные накопители для хранения компьютерных данных. Но столкнулись с проблемой: при резких остановках магнитная лента могла растягиваться и рваться.

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

Появились жёсткие диски, резервное копирование, удалённая репликация и резервные дата-центры. А магнитные ленты, кстати, до сих пор используются в CERN для хранения научных данных.

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

В новой статье рассказываем, как развивались технологии хранения и резервирования за последние семь десятилетий.

👉 Читать статью: https://dcestt.ru/blog/backup-history?utm_source=max&utm_medium=social&utm_campaign=backup_history&utm_content=post

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

Это уже хороший первый уровень защиты: резерв находится на физически отдельной инфраструктуре и не зависит от той же площадки, где работает основной сервис.

Дальше всё зависит от задачи.
Для одного проекта достаточно регулярно выгружать данные во второй ЦОД.
Для другого нужен резервный VPS с подготовленным окружением.
А для критичных сервисов уже имеет смысл полноценная резервная площадка с заранее выделенными ресурсами и понятным сценарием переключения.

То есть идти можно поэтапно:
backup в другом ЦОД → резервный VPS → полноценная резервная площадка.

В ESTT виртуальный сервер можно создать самостоятельно за несколько минут.
Если нужен отдельный физический сервер или более серьёзный резервный контур, поможем подобрать ресурсы под конкретный сценарий.

Не обязательно сразу дублировать всю инфраструктуру.
Важно начать с того, что действительно критично для работы сервиса.

Создать виртуальный сервер:
https://dcestt.ru/cloud/individual-server-vps?utm_source=max&utm_medium=social&utm_campaign=geo_reserve_october_2026&utm_content=reserve_vps

Обсудить резервную площадку:
https://dcestt.ru/service-consulting?service_interest=Резервная%20площадка&utm_source=max&utm_medium=social&utm_campaign=geo_reserve_october_2026&utm_content=reserve_platform

В прошлой статье разбирали, как подготовить резервный контур на случай недоступности основной площадки:
https://dcestt.ru/blog/disaster-recovery-backup-site?utm_source=max&utm_medium=social&utm_campaign=critical_infrastructure&utm_content=previous_article

Теперь смотрим шире: что еще может стать точкой отказа, даже если серверы уже находятся в надежном ЦОД?

Потому что защищенное железо еще не означает защищенную инфраструктуру.

Проблема может оказаться в доступах или сетевом контуре. Резервные копии могут создаваться годами, но никто ни разу не проверял, получится ли из них восстановиться. А критичные знания, пароли и логика работы систем иногда по-прежнему зависят от одного специалиста.

Получается парадокс: оборудование уже находится в профессиональном дата-центре, а у бизнеса все еще остаются точки отказа, которые сам ЦОД устранить не может.

В новой статье разбираем, какие риски действительно снимает размещение в ЦОД, какие остаются и как связать доступы, сеть, backup, отказоустойчивость и резервную площадку в единый контур.

👉 Когда одного ЦОДа недостаточно: как защитить критичную инфраструктуру
https://dcestt.ru/blog/critical-infrastructure-protection?utm_source=max&utm_medium=social&utm_campaign=critical_infrastructure&utm_content=article

Что будет с сервисами компании, если дата-центр станет недоступен?

Как заранее подготовить резервную площадку, сохранить данные и сократить простой сервисов, разбираем в статье ESTT.

https://dcestt.ru/blog/disaster-recovery-backup-site?utm_source=max&utm_medium=clip&utm_campaign=geo_redundancy

Что будет, если основная площадка станет недоступна?

Backup, резервные серверы и вторая площадка сами по себе ещё не гарантируют, что сервис продолжит работать.
Для этого нужен полноценный DR-сценарий: понимать, какие сервисы критичны, какие у них RPO и RTO, как будет происходить failover, что делать с данными и как потом вернуть нагрузку обратно.

В новой статье разбираем:
- чем backup отличается от disaster recovery;
- как выбрать между hot, warm и cold reserve;
- почему не всегда нужно полностью дублировать основную инфраструктуру;
- что важно учесть при failover и failback;
- как тестировать резервный контур до реального инцидента;
- как выбрать вторую площадку и ресурсы под конкретный сервис.

В ESTT резервный контур можно разместить в дата-центре в Москве: использовать colocation, выделенные серверы, VPS/VDS или облачные ресурсы.

Читать статью:
https://dcestt.ru/blog/disaster-recovery-backup-site?utm_source=max&utm_medium=social&utm_campaign=geo_redundancy_article

Наши уважаемые клиенты, коллеги и единомышленники, с Днём работника отрасли ЦОД! 🎉

Пусть каналы летают, DDoS проходит мимо, серверы не капризничают, резерв остаётся резервом, а каждая смена обходится без сакраментального: «Хьюстон, у нас проблемы» :)))

С праздником всех, кто держит инфраструктуру в строю 24/7!

🍁 Осенний ценопад в ESTT

Сентябрь заканчивается, листья начинают опадать, а у нас вместе с ними падают и цены на выделенные серверы :)

Мы запустили осенний аукцион серверов ESTT.

В акции участвуют 7 готовых конфигураций, по 10 серверов каждой. На странице видно текущую цену, остаток серверов и таймер до следующего снижения.

Следующую цену заранее не показываем. Можно подождать и попробовать забрать сервер дешевле, но нужную конфигурацию за это время могут разобрать.

Если цена устраивает, отправляйте заявку. Фиксируется именно та стоимость, которую вы видите в этот момент.

Акция действует до 31 октября или пока серверы есть в наличии.

🍂 Смотреть, как падают цены:
https://dcestt.ru/datacenter/server-auction?utm_source=max&utm_medium=social&utm_campaign=server_auction_autumn

ESTT на GP CONF 🎮

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

Для разработки и тестов можно начать с VPS.
Для multiplayer, backend и постоянной нагрузки подойдут выделенные серверы.
Для AI-функций и вычислительных задач можно подключать GPU.

А когда проект растёт, вместе с ним должна расти и инфраструктура.

Похоже, пора знакомиться с геймдевом поближе 🙂

Если вы разрабатываете игру, запускаете игровой сервер или ищете инфраструктуру под уже работающий проект, расскажите нам о задаче.

Подберём ресурсы, поможем с запуском и миграцией, а для игровых команд и разработчиков предложим специальные условия и скидку 🎉

Готовое техническое задание не обязательно. Достаточно рассказать, что за проект, на каком он этапе и какую нагрузку ожидаете.
С конфигурацией разберёмся вместе.

🎮 Серверы и инфраструктура для игровых проектов:
https://dcestt.ru/datacenter/game-development?utm_source=max&utm_medium=social&utm_campaign=gamepush_conf_2026

Как выбрать GPU для LLM, RAG и инференса

При выборе GPU для AI-проекта легко зацепиться за одну цифру: объём VRAM. Но на практике этого недостаточно.

На требования влияют сама модель, квантизация, длина контекста, KV-cache, количество одновременных запросов и сценарий работы.

Поэтому две GPU с похожим объёмом памяти могут заметно отличаться по тому, как поведёт себя сервис под нагрузкой.

В новой статье разобрали, чем отличаются V100, RTX 4090, RTX 5090 и A100, как оценивать запас видеопамяти и что проверить на пилоте до запуска в рабочую среду.

А если после всех этих VRAM, KV-cache и inference engine вопросов стало не меньше, приходите к нам 😁

В ESTT доступны GPU VPS на V100, RTX 4090, RTX 5090 и A100.
Наши инженеры помогут разобраться в задаче, подобрать GPU и остальные ресурсы и собрать конфигурацию под реальную нагрузку.

👉 Читать статью:
https://dcestt.ru/blog/how-to-choose-gpu-vps?utm_source=max&utm_medium=social&utm_campaign=gpu_vps&utm_content=full_article

GPU VPS: https://dcestt.ru/cloud/gpu-vps?utm_source=max&utm_medium=social&utm_campaign=gpu_vps&utm_content=full_article