Непроверенные бэкапы и растущие счета за облако: два риска работающей системы

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

КОРОТКО

Два риска, которых не видно на экране

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

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

По расходам есть рыночные данные. В отчёте State of the Cloud 2026, опубликованном 18 марта 2026 года, Flexera оценила долю впустую потраченных денег на облако в 29%, и это первый рост за пять лет. Отчёт основан на глобальном опросе более 750 специалистов, которые принимают решения об облаке и пользуются им; 85% из них назвали управление расходами на облако одной из главных проблем. Цифра потерь складывается из оценок самих респондентов, но направление понятно: по их собственной оценке, почти треть денег, которые компании платят за облако, не приносит пользы.

Бэкап, который никто не восстанавливал, это надежда по расписанию.

ВОССТАНОВЛЕНИЕ

Бэкап доказывается восстановлением

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

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

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

Американское агентство по кибербезопасности и защите инфраструктуры CISA требует того же в своём руководстве #StopRansomware Guide: хранить офлайн зашифрованные резервные копии критичных данных и регулярно проверять их доступность и целостность в сценарии аварийного восстановления. Причина практическая: многие программы-вымогатели ищут доступные им бэкапы и удаляют или шифруют их.

Первое восстановление должно пройти в спокойный вторник, а не во время аварии.

ЧТО КОПИРОВАТЬ

База, файлы, настройки и секреты

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

• База данных. Заказы, клиенты, заявки, товары, цены и контент на всех языках. В активном магазине она меняется каждую минуту, поэтому её копируют чаще всего.
• Загруженные файлы. Фото товаров, документы клиентов, сформированные счета. Они лежат вне базы, и о них забывают чаще всего.
• Настройки. Параметры веб-сервера и PHP, нужные коду расширения PHP, задачи по расписанию, переменные окружения и DNS-записи. Большей части этого нет в репозитории, поэтому заново собранный сервер может запускать тот же код и вести себя иначе.
• Секреты. Пароли к базе, API-ключи платёжных систем и служб доставки, доступы к почте, ключи шифрования. Их должно быть можно восстановить, но они никогда не лежат открытым текстом рядом с бэкапами или в коде: их место в менеджере паролей или в хранилище секретов, например Vault или менеджере секретов облачного провайдера.

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

Где лежат копии, так же важно, как и что в них. Копия на том же сервере защищает от случайного удаления и почти ни от чего больше. Правило, которое цитируют чаще всего, взято из работы, подготовленной Университетом Карнеги-Меллон для US-CERT, сейчас части CISA: храните три копии любого важного файла, одну основную и две резервные; держите их на двух разных типах носителей; одну копию храните вне офиса. Для сайта в 2026 году это значит рабочие данные, копию у другого провайдера или в отдельном аккаунте хранилища и третью копию, которую не могут удалить даже доступы рабочего сервера. Руководство CISA добавляет современную половину правила: копии должны быть офлайн и зашифрованы, чтобы пережить злоумышленника, который уже добрался до сервера.

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

RPO И RTO

Сколько можно потерять и сколько ждать

Два числа определяют, как часто делать бэкапы и сколько стоит вся схема. NIST в руководстве по планированию непрерывности SP 800-34 определяет целевую точку восстановления (RPO) как момент времени, на который данные должны быть восстановлены после сбоя, а целевое время восстановления (RTO) как срок, который система может находиться в восстановлении, прежде чем сбой начнёт вредить бизнесу.

Если говорить проще, RPO отвечает на вопрос «сколько работы мы можем позволить себе потерять?», а RTO на вопрос «сколько мы можем позволить себе простоять?». Если бэкап делается в 2 часа ночи, а сервер падает в 6 вечера, пропадают шестнадцать часов заказов, заявок и изменений в админке. Для корпоративного сайта, который меняется раз в неделю, потеря небольшая. Для магазина, который принимает заказы весь день, это значит обзванивать клиентов и спрашивать, что они купили.

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

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

RPO и RTO это решения бизнеса, которые просто записаны в часах.

СЧЁТ ЗА ОБЛАКО

Расходы, которые никто не утверждал

Облачный провайдер берёт деньги за всё, что запущено, независимо от того, пользуется ли этим кто-нибудь. Сервер, который выдержал запуск два года назад и теперь простаивает, стоит каждый час ровно столько же. Поэтому счета за облако растут быстрее трафика: ресурсы легко создавать, а удалять их не входит в чьи-либо обязанности.

Источники роста почти на всех счетах одни и те же:

• Простаивающие и слишком большие серверы. Машины, рассчитанные на пик, который больше не повторился. Сервер базы данных, выбранный «с запасом на рост» несколько лет назад, часто оказывается самой большой строкой счёта.
• Забытые тестовые окружения. Полная копия рабочей системы, собранная под один проект и так и не выключенная, нередко с реальными данными клиентов на сервере, который никто не обновляет.
• Логи и снимки, которые хранятся вечно. В Amazon CloudWatch Logs логи по умолчанию хранятся бессрочно, пока кто-нибудь не задаст срок хранения для каждой группы логов. В собственных примерах цен AWS использует $0,05 за ГБ в месяц для стандартного хранения снимков EBS, и политика снимков, которая ничего не удаляет, увеличивает эту строку каждый день.
• Мелкие платежи, которые множатся. Каждый публичный IPv4-адрес в AWS стоит $0,005 в час, используется он или нет, то есть около $3,65 в месяц. NAT-шлюз стоит $0,045 в час в регионе US East (Ohio), около $33 в месяц, плюс $0,045 за каждый обработанный гигабайт.
• Исходящий трафик. AWS даёт 100 ГБ исходящего трафика в интернет бесплатно каждый месяц по всем сервисам вместе; дальше оплачивается каждый гигабайт, и это заметно для сайтов с большими файлами или при копировании бэкапов к другому провайдеру. (Цифры AWS проверены в октябре 2026 года.)

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

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

Настройка часто обходится дешевле железа. В проекте на Laravel 7, о котором речь ниже, тариф хостинга уже включал OPcache, кеш скомпилированного PHP-кода, но его никто не включил. После включения ответ сервера ускорился примерно с 55 до 21 миллисекунды, за несколько долларов в месяц и без более мощного сервера.

ПРОВЕРКИ

Что проверять и как часто

Такой режим мы рекомендуем для сайта, магазина или веб-приложения, которое приносит деньги; в активном магазине часть интервалов стоит сократить.

Последнюю строку легко планировать, потому что даты публичны. По состоянию на октябрь 2026 года PHP 8.2 получает исправления безопасности до 31 декабря 2026 года, PHP 8.3 до 31 декабря 2027 года, PHP 8.4 до 31 декабря 2028 года; Laravel 12 до 24 февраля 2027 года, Laravel 13 до 17 марта 2028 года.

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

МОНИТОРИНГ

Уведомления, которые приходят раньше клиентов

Проверка доступности, которая сообщает, что главная страница отвечает, пропускает большинство сбоев, стоящих денег, потому что на экране они ничем себя не выдают. Форма может показывать сообщение с благодарностью, а письмо так и не придёт. Переезд на новый хостинг может потерять записи SPF и DKIM, и заявки начнут попадать в спам. В одном из недавних проектов новый хостинг по собственной инициативе закрыл в robots.txt доступ для GPTBot и краулеров Meta.

Поэтому мониторинг бизнес-системы следит не только за сервером, но и за процессами, которые приносят деньги:

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

Инструменты бывают разными, от Prometheus и Grafana или Datadog до внешнего сервиса проверки доступности для небольшого сайта, но маршрутизация важнее инструмента. Каждое уведомление приходит тому, кто может по нему действовать, вместе с короткой подсказкой, что делать первым делом, а уведомление, которое срабатывает каждый день и не требует действий, исправляют или убирают, потому что оно приучает команду игнорировать следующее.

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

БЕЗОПАСНЫЕ ОБНОВЛЕНИЯ

Тестовая копия, команды деплоя и путь назад

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

Это был трёхъязычный корпоративный сайт со своей админкой, системой заявок и многолетним контентом, работавший на Laravel 7 и PHP 7.4; PHP 7.4 перестал получать исправления безопасности в ноябре 2022 года. Мы перевели его на Laravel 13 и PHP 8.4: шесть мажорных версий, около трёх дней разработки, один день приёмочного тестирования и пять минут запланированного простоя. Подробно эта история описана в статье Шесть версий Laravel за три дня; здесь только то, что применимо к любому обновлению.

До первого изменения. Мы создали отдельную ветку и записали точный коммит, который работал в продакшене. Подняли закрытую тестовую копию с базой и файлами, ограниченную на уровне сервера, а не просто помеченную noindex, и задокументировали расширения PHP, настройки, команды деплоя и процедуру отката. Дальше каждая версия Laravel шла отдельной миграцией, и после каждого шага мы проверяли публичный сайт, админку, формы и журнал ошибок.

Что поймала тестовая копия. В Laravel 11 изменилась настройка шифрования почты, и со старыми параметрами форма продолжала бы благодарить посетителей, хотя письма с заявками перестали бы уходить; мы отправили реальную тестовую заявку и дождались письма, прежде чем считать шаг завершённым. Кеширование маршрутов, обычная настройка скорости в Laravel, превратило каждую страницу в 404, потому что этот сайт строит языковые префиксы из базы данных. На отмену ушла примерно минута, а на рабочем сайте это была бы авария. Правило «никогда не кешировать маршруты в этом проекте» теперь записано в инструкциях проекта для разработчиков и ИИ-агентов, в том самом файле, о котором мы пишем в статье о руководстве к коду для ИИ.

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

Релиз и приёмка. Бэкап, слияние, установка новых зависимостей на PHP 8.4, переключение версии PHP в панели хостинга и очистка кешей. Единственным простоем было применение новой версии PHP хостингом, около пяти минут в спокойный час. Приёмка охватила 15 публичных страниц на трёх языках, 30 экранов админки, реальную тестовую заявку с подтверждённым письмом, журнал ошибок и 987 внутренних ссылок, из которых ни одна не оказалась битой.

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

КТО ЗА ЭТИМ СЛЕДИТ

Поддержка, DevOps или приём проекта

Какой формат подходит, зависит от того, в каком состоянии система сейчас, и мы часто советуем вариант поменьше.

Цены указаны по состоянию на октябрь 2026 года, все они есть на странице цен. Облако, хостинг и платные инструменты вы оплачиваете напрямую провайдерам. Стратегическая сессия, с которой начинается работа, стоит $500 и засчитывается в проект, который мы делаем для вас, в течение 30 дней.

Строка про приём проекта встречается чаще, чем ожидают владельцы. Один сайт, о котором мы рассказываем в статье Обновление старого сайта на Laravel или PHP в 2026 году, работал на PHP 5.6, аккаунт хостинга контролировал человек вне бизнеса, а письма из контактной формы отклонял почтовый сервер; на исправление ушло два вечера.

Для нас бэкапы, серверы и релизы входят в ту же систему, что и сайт, и строятся вокруг того, как зарабатывает ваш бизнес, а не продаются отдельным продуктом. Всё работает в аккаунтах, которые принадлежат вам, а при любой передаче вы получаете код, команды деплоя, требования к серверу, процедуру отката и файл AGENTS.md: простое описание структуры, правил и команд, по которому ваши разработчики, другой подрядчик или ИИ-агент для программирования продолжат работу без догадок. Когда кто-то уходит из проекта, включая нас, смените пароли и ключи, которыми он пользовался, в тот же день; почему это важно, мы объясняем в статье о том, что сайт ломается не в день ухода разработчика.

FAQ

Источники

• Flexera: Flexera Finds Cloud Value is Rising While AI Waste Grows (отчёт State of the Cloud 2026, 18 марта 2026 года)
• US-CERT, Университет Карнеги-Меллон: Data Backup Options (правило 3-2-1)
• CISA: #StopRansomware Guide
• Глоссарий NIST CSRC: Recovery point objective (SP 800-34 Rev. 1)
• Глоссарий NIST CSRC: Recovery time objective (SP 800-34 Rev. 1)
• AWS: цены Amazon VPC (публичные IPv4-адреса, NAT-шлюз)
• AWS: цены Amazon EBS (хранение снимков)
• AWS: цены Amazon EC2 On-Demand (исходящий трафик)
• AWS: CloudWatch Logs, группы логов и срок хранения
• PHP: поддерживаемые версии
• Laravel: примечания к релизам и политика поддержки