Тендеры и лиды
Информация
В октябре за несколько дней были повреждены сразу несколько дата-центров «Яндекса». Для рынка это повод пересмотреть привычное отношение к резервным копиям.
До недавнего времени физическую потерю целой площадки легко было считать слишком редким сценарием. Обычно бизнес готовился к более знакомым проблемам, вроде сбоя сервера, ошибки администратора, неудачного обновления, или атаки. Сейчас стоит добавить еще один вопрос: что произойдет с проектом, если основной дата-центр станет недоступен целиком?
И здесь быстро выясняется, что наличие бэкапа само по себе мало о чем говорит.
В IT-агентстве «Фьюче» мы регулярно видим у небольших и средних компаний одну и ту же картину. Копии создаются, задача формально закрыта, но никто давно не проверял, где они физически лежат и получится ли вообще из них восстановиться. Поэтому сейчас следует смотреть на резервное копирование как на простой сценарий из четырех шагов.
Самый слабый вариант встречается до сих пор: сайт, база и резервная копия находятся на одном сервере.
Такая схема помогает, если случайно удалили файл или нужно откатить базу. При потере самого сервера резервная копия исчезнет вместе с ним.
Чуть лучше, когда под бэкапы выделяют отдельный сервер. Но здесь важно проверить, где он находится физически. Две машины могут быть заведены в одном аккаунте у одного провайдера и при этом стоять в одном дата-центре. Пока выходит из строя один сервер, схема работает. Если проблема затрагивает всю площадку, резервная копия оказывается под тем же риском.
Поэтому базовый вариант, который можно порекомендовать большинству проектов, выглядит так: основная инфраструктура работает в одном дата-центре, резервная копия хранится в другом.
Желательно заранее уточнить у провайдера физическое размещение обеих площадок и не ориентироваться только на названия тарифов или серверов.
Для небольшого и среднего проекта этого уже достаточно, чтобы сильно снизить риск полной потери данных. Можно арендовать обычный сервер в другом дата-центре и автоматически отправлять на него резервные копии.
Второй распространенный вариант — S3-совместимое объектное хранилище. Оно особенно удобно для бэкапов. Файлы можно загружать автоматически через API, объем хранения легко увеличивать по мере роста проекта, а команде не приходится самостоятельно обслуживать еще один файловый сервер.
При выборе S3-хранилища можно нужно на те же вещи, что и при выборе отдельного сервера. Где физически находятся данные, как провайдер обеспечивает отказоустойчивость и насколько резервное хранилище независимо от основной инфраструктуры. Для критичных проектов можно пойти еще дальше и держать дополнительную копию у второго провайдера.
Дополнительно следует защищать резервные копии от удаления. Для этого можно использовать отдельные доступы и хотя бы одну копию с запретом изменения и удаления на установленный срок.
Главный принцип здесь довольно простой: одна авария не должна одновременно лишить вас и рабочей системы, и возможности ее восстановить. Именно физическое разнесение данных является минимальным уровнем защиты в текущей ситуации.
Логика понятна. Если задача состоит в физическом разнесении инфраструктуры, хочется положить одну из копий максимально далеко. Но на деле для российских компаний такой вариант подходит далеко не всегда.
Если резервная копия содержит персональные данные граждан России, нужно учитывать требования к их локализации. С 1 июля 2025 года запись, систематизация, накопление, хранение, изменение и извлечение таких данных при их сборе должны осуществляться с использованием баз данных на территории России, кроме предусмотренных законом случаев. Трансграничная передача регулируется отдельно.
Поэтому базу с персональными данными нельзя просто отправить на иностранный сервер как еще один стандартный бэкап. Конкретную схему нужно оценивать с учетом состава данных и требований законодательства.
Для большинства российских проектов стоит начинать с двух нормальных рабочих вариантов: отдельный сервер в другом российском дата-центре или независимое S3-хранилище. А уже после этого, если проект действительно требует более сложной схемы, добавлять дополнительные уровни резервирования.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13789 тендеров
проведено за восемь лет работы нашего сайта.
Технической команде недостаточно задачи «делайте резервные копии». Ей нужны понятные ограничения со стороны бизнеса.
Первый вопрос: сколько времени сервис может оставаться недоступным?
Для небольшого корпоративного сайта несколько часов простоя могут пройти почти незаметно. Для интернет-магазина, финансового продукта или внутренней системы компании даже час уже может быть критичным.
Второй вопрос: сколько последних данных допустимо потерять?
Допустим, копия базы создается один раз в сутки. При аварии компания потенциально может потерять почти 24 часа изменений. Где-то такой риск приемлем. Если речь идет о заказах, платежах или действиях пользователей, скорее всего, потребуется более частое резервирование.
В технической практике для этого используются две метрики.
RTO показывает, за какое время систему нужно восстановить.
RPO показывает, за какой период перед аварией допустима потеря данных.
Запоминать сами аббревиатуры руководителю необязательно. Гораздо важнее сформулировать задачу понятным языком. Например:
При полной потере основной инфраструктуры мы должны снова запустить сервис максимум за два часа и потерять не больше 15 минут данных.
После такой постановки техническая команда уже может выбрать подходящую архитектуру, частоту копирования и способ восстановления. Это намного полезнее общего требования «сделайте надежные бэкапы».
Есть старая шутка, что администраторы делятся на тех, кто делает бэкапы, и тех, кто еще не делает.
Во Фьюче, мы предпочитаем добавлять к ней еще один уровень. После того как резервные копии появились, их нужно начать проверять.
Сам факт того, что архив успешно создается каждую ночь, еще не означает, что внутри находится все необходимое. На практике во время восстановления могут внезапно пропасть картинки, пользовательские файлы, часть базы или конфигурация проекта.
Поэтому резервную копию нужно периодически проверять в условиях, близких к реальной аварии. Важно оценить весь путь восстановления, включая получение новой инфраструктуры, перенос данных и возвращение сервиса в работу.
Проверка может включать следующие шаги:
обнаружить аварию и принять решение о восстановлении;
получить новые серверы и необходимые доступы;
скачать резервные копии и восстановить базу данных;
развернуть код проекта и запустить необходимые зависимости;
проверить пользовательские файлы и изображения;
переключить трафик на восстановленную инфраструктуру;
открыть основные страницы или разделы сервиса и пройти ключевые сценарии;
засечь полное время от обнаружения аварии до возвращения сервиса в рабочее состояние.
Именно последняя цифра особенно важна для бизнеса.
К примеру, если компания ожидает, что проект вернется в работу за четыре часа, техническая команда должна один раз попробовать это сделать и проверить, укладывается ли восстановление в четыре часа на практике. Если получилось двенадцать, процесс нужно улучшать заранее.
Пробовать восстанавливать бэкап впервые во время настоящей аварии — слишком поздно.
Одна успешная проверка тоже не дает гарантии навсегда.
Проект развивается. Добавляются интеграции, новые сервисы и хранилища. Меняется структура базы. Пользовательские файлы переезжают в другое место. Через несколько месяцев схема резервирования может перестать соответствовать реальному устройству проекта.
Поэтому у специалиста, который отвечает за инфраструктуру, должна быть регулярная задача на восстановление.
Для одного проекта достаточно делать это раз в квартал. Для другого разумнее раз в месяц. Частота зависит от критичности системы и скорости ее изменений.
При каждой проверке стоит смотреть как минимум на четыре вещи: целостность базы, код, контент и пользовательские файлы. Именно здесь чаще всего выясняется, что формально успешный бэкап оказался неполным. Такое восстановление лучше всего закрепить за техническим специалистом и повторять его по расписанию и после существенных изменений инфраструктуры.
Дополнительно полезно настроить уведомления об ошибках резервного копирования и контролировать возраст последней успешно доставленной копии.
Отдельного сотрудника ради этого обычно не требуется. Важно, чтобы ответственность была закреплена и результат проверки доходил до бизнеса в понятном виде.
Например: копия от 10 октября восстановлена успешно, все основные сценарии работают, полное восстановление заняло 1 час 40 минут.
Вот такая информация уже позволяет принимать решения.
На всю первичную проверку не нужен большой аудит. Можно начать с семи вопросов.
Где физически находится основная инфраструктура?
Где физически хранится резервная копия?
Может ли одна авария затронуть обе площадки?
Что именно входит в бэкап: база, код, файлы, изображения, конфигурация?
Когда проект в последний раз полностью восстанавливали из резервной копии?
Сколько времени заняло восстановление?
Сколько времени простоя и сколько потерянных данных бизнес считает допустимыми?
Если на часть вопросов ответа нет, уже понятно, куда смотреть дальше.
После этого стоит поставить технической команде еще одну задачу: провести тестовое восстановление, зафиксировать результат и повторять такую проверку раз в месяц или квартал.
Расходы на второй сервер или дополнительное хранилище обычно легко посчитать. Несколько дней простоя, восстановление потерянных данных и репутационные последствия считать гораздо неприятнее.
Поэтому сейчас не следует ограничивался вопросом «у нас есть бэкап?». Полезнее спросить команду иначе: если завтра исчезнет площадка, на которой работает проект, что мы потеряем и через сколько снова будем работать?
Если ответ подтвержден реальным тестовым восстановлением, значит, резервное копирование действительно выполняет свою задачу.
