В 2026 году «бэкап есть» уже не считается ответом. Вопросы стали конкретнее: какой RPO мы реально держим, сколько займёт восстановление (RTO), переживёт ли резервная копия шифровальщик, проверяли ли мы restore хотя бы раз за квартал. Ниже — практичный каркас стратегии: типы копий (full/incremental/differential), ротация GFS, дисциплина проверок и неизменяемость.
База терминов: что именно защищаем
Перед тем как выбирать инструменты и расписание, зафиксируйте объекты резервного копирования. В админской реальности это почти всегда несколько слоёв:
- Данные приложения: база данных, загрузки пользователей, медиа, очереди, вложения.
- Конфигурация: конфиги веб-сервера, unit-файлы systemd, переменные окружения, секреты (по отдельной политике).
- Системный слой: пакеты и их версии, список сервисов, параметры ядра, сетевые настройки.
- Инфраструктурный слой: DNS-записи, правила фаервола, репозитории Terraform/Ansible, манифесты Kubernetes (если есть).
Так вы заранее отвечаете на ключевой вопрос: будете ли вы восстанавливать «весь сервер как был» или «сервис поднимаем заново из IaC, а данные возвращаем из бэкапа». От этого напрямую зависят RTO, стоимость хранения и сложность регламентов.
Full, incremental, differential: не теория, а последствия
Типы копий отличаются не тем, «как красиво звучит», а тем, сколько места вы платите, сколько времени тратите на окно резервного копирования и насколько сложным будет восстановление.
Full backup (полный бэкап)
Full — это снимок всего набора данных на конкретный момент времени. Плюсы: самый простой restore (обычно нужна одна точка). Минусы: максимум места и трафика, иногда слишком длинное окно.
Практический вывод: full удобен как «якорь» для последующих копий и как регулярная контрольная точка. Но делать full каждый час редко разумно.
Incremental backup (инкрементальный)
Incremental хранит изменения с момента предыдущего бэкапа (будь то full или incremental). Плюсы: экономия места и быстрый ежедневный прогон. Минусы: восстановление требует цепочки (full + все инкременты до нужной даты). Это увеличивает RTO и повышает риск: один битый элемент цепи — и restore может сорваться.
Практический вывод: incremental хорош, когда важны узкие окна и экономия, но дисциплина проверок целостности и регулярные тесты восстановления становятся обязательными.
Differential backup (дифференциальный)
Differential хранит изменения с момента последнего full. Плюсы: восстановление проще, чем с incremental (обычно full + один differential). Минусы: размер differential растёт каждый день до следующего full.
Практический вывод: differential часто выбирают там, где restore должен быть максимально предсказуемым, но место под бэкапы всё же ограничено.
Если важнее скорость восстановления и простота — чаще выигрывает связка full + differential. Если важнее узкие окна и экономия — full + incremental, но только при регулярной проверке цепочек и понятной политике хранения.
Если вы держите прод на VDS, планируйте бэкапы как отдельный контур, а не как «каталог на том же диске»: это проще масштабировать, легче контролировать права и проще пережить инцидент уровня сервера.
Как типы копий влияют на RPO и RTO
RPO (Recovery Point Objective) — сколько данных вы готовы потерять во времени. RTO (Recovery Time Objective) — сколько времени вы готовы быть недоступны.
Именно здесь многие стратегии ломаются: расписание ставят «по привычке», а затем выясняется, что RTO не сходится из‑за долгой распаковки/скачивания/проверки или из‑за необходимости склеивать длинную цепочку incremental.
Быстрые прикидки, которые реально работают
- RPO почти всегда равен шагу между точками данных. Если база бэкапится раз в 24 часа — RPO не лучше суток (если нет журналов/репликации/PITR).
- RTO — это не «скачать архив», а сумма: скачать + расшифровать + проверить + развернуть + прогреть кэши + прогнать миграции + сделать минимальные проверки работоспособности.
- Длинные цепочки incremental увеличивают RTO, особенно при восстановлении из удалённого хранилища (много мелких объектов, сетевые задержки, повторные попытки).
Типовые комбинации
- Full weekly + incremental daily — хороший компромисс по месту и времени, но требует контроля цепочек и регулярного restore test.
- Full weekly + differential daily — чуть дороже по месту, зато восстановление более линейное и часто быстрее.
- Частые точки для БД отдельно: для баз критично делать отдельную стратегию (например, dump чаще или PITR), чтобы RPO не определялся «архивом всего сервера раз в сутки».
Если у вас PostgreSQL и нужен честный RPO меньше суток, посмотрите разбор PITR и WAL-архивации: PITR в PostgreSQL: WAL backup и восстановление.
GFS rotation: зачем в 2026 всё ещё нужна «дедовская» схема
GFS rotation (Grandfather-Father-Son) — это способ хранить копии с разной «ценностью» и горизонтом: ежедневные, недельные, месячные (иногда ещё годовые). В современном виде это просто удобная модель для retention policy.
Как мыслить GFS на практике
Смысл GFS — покрыть разные сценарии восстановления, которые отличаются «давностью» проблемы:
- «Откатить удалённый файл» — нужны частые короткие точки (дни).
- «Поймали баг релиза неделю назад» — нужны недельные точки.
- «Инцидент заметили через два месяца» — нужны месячные точки.
Пример разумной retention policy (ориентир, не догма)
- Daily: хранить 14–30 дней (часто достаточно 14).
- Weekly: хранить 8–12 недель.
- Monthly: хранить 12–18 месяцев.
Эта сетка помогает пережить «медленные» инциденты: незаметные повреждения, постепенную порчу данных, скрытую компрометацию, ошибочные массовые операции.
Immutable backups: защита от шифровальщиков и «случайно удалил»
Immutable backups — это неизменяемые резервные копии: даже если злоумышленник получил доступ к системе, он не сможет удалить или перезаписать уже созданные бэкапы до истечения срока удержания. В 2026 это must-have хотя бы для одного уровня хранения.
Почему это важно: большинство атак на инфраструктуру заканчивается попыткой уничтожить бэкапы. Если ваши копии доступны по тем же ключам/учёткам, что и сервер, «бэкап есть» превращается в «бэкап был».
Практические правила неизменяемости
- Разделение прав: аккаунт, который пишет бэкапы, не должен уметь удалять историю.
- Отдельные ключи: ключи для бэкапа не совпадают с ключами админов/CI.
- Отдельная площадка: хотя бы один слой хранения должен быть вне контура (другая учётка/проект/тенант).
- Окно immutability выбирайте под сценарии: например, 14–30 дней для daily-копий критичных данных.
Правило 3-2-1 в 2026: как адаптировать под облака и VDS
3-2-1 всё ещё актуально, просто трактуется современнее:
- 3 копии: прод + минимум две независимые копии.
- 2 разных среды хранения: например, локальный диск/снапшоты + объектное хранилище; или объектное хранилище + архивная полка (если есть).
- 1 вне площадки: другой регион/другая учётка/отдельный провайдер.
Ключевой момент: «вне площадки» — это не «другая директория на том же сервере». И даже не «другой диск в том же гипервизоре», если вы рассматриваете риски уровня узла/провайдера.
Про практичную настройку бэкапов на S3-совместимое хранилище (и почему это удобно для 3-2-1) — в отдельной статье: S3-бэкапы с restic и borg: схема, шифрование, ротация.
Отдельно проверьте доступ к панелям управления бэкапами и хранилищам: закрывайте их TLS и нормальными политиками доступа. Если публичная админка или API доступны извне, базовая гигиена начинается с корректного сертификата и цепочки доверия — под это подходят SSL-сертификаты.
Backup verification и restore test: без этого всё остальное — декорации
Проверка бэкапа в 2026 должна быть двухступенчатой: backup verification (мы убедились, что копия технически целая) и restore test (мы восстановили и убедились, что сервис/данные корректны).
Что такое «проверка», а что — «тест восстановления»
- Backup verification: проверка хэшей, чтение части данных, проверка индексов репозитория, сверка размеров/количества объектов, контроль ошибок.
- Restore test: восстановление в песочницу/стейджинг, поднятие сервиса, smoke-тесты (логин, чтение данных, ключевые отчёты), проверка консистентности БД.
Минимальный регламент, который реально выдерживают команды
- Ежедневно: автоматический отчёт об успешности задач + алерты по сбоям.
- Еженедельно: выборочный restore небольшого набора (например, одна БД или один проект) в изолированную среду.
- Ежеквартально: полноценная репетиция аварийного восстановления под ваш целевой RTO.
Если restore test не делался ни разу — ваш реальный RTO неизвестен. Если проверки целостности нет — ваш реальный шанс восстановиться неизвестен.
Как выбрать стратегию под тип проекта
Ниже — несколько «шаблонов мышления», а не универсальные рецепты. Сначала фиксируем RPO/RTO, потом подбираем комбинацию копий и ретенцию.
Небольшой сайт/лендинг с редкими изменениями
- Часто достаточно full (или full + differential).
- Фокус на простоте восстановления, а не на экономии места.
- GFS можно сделать коротким, но месячные точки полезны от человеческих ошибок.
Интернет-магазин/CRM: данные меняются постоянно
- Решайте RPO отдельно для БД и файлов.
- Частые точки (или PITR) важнее, чем «бэкап всего сервера раз в сутки».
- Immutable-слой обязателен: атаки и массовые ошибки здесь особенно болезненны.
SaaS/мультисервис
- Разделяйте по доменам ответственности: конфиги/секреты/данные.
- RTO часто упирается в автоматизацию: IaC + быстрый restore данных.
- Тест восстановления делайте как сценарий (runbook), а не как разовую «акцию».
Частые ошибки, которые ломают backup strategy
- Одинаковые права на прод и бэкапы: компрометировали сервер — потеряли и историю.
- Одна копия «где-то в облаке» без второго независимого слоя.
- Окно хранения слишком короткое: заметили проблему поздно — восстановиться не из чего.
- Непроверенные цепочки incremental: задача «зелёная», но восстановление падает на 17-м шаге.
- RTO считают только как «скачать архив», забывая про развёртывание, прогрев, миграции и проверку работоспособности.
Чек-лист: что зафиксировать в документации (и обновлять)
Чтобы бэкапы не зависели от конкретного человека, держите короткий runbook, который отвечает на вопросы:
- Какой целевой RPO/RTO для каждого сервиса и каждого типа данных?
- Какая схема копий: full/incremental/differential (и как часто делаем full)?
- Какая GFS-ротация и retention policy?
- Где immutable-слой и кто имеет права на удаление?
- Как выполняется backup verification и где смотреть отчёты?
- Как запускается restore test и какие критерии «успеха»?
- Что делаем при инциденте: последовательность действий и ответственные.
Итог: что делать прямо сейчас
Бэкапы стали частью киберустойчивости: без неизменяемости, контроля прав и регулярных тестов восстановление перестало быть «по умолчанию». Практический выигрыш даёт не «самая модная» схема, а та, где честно посчитаны RPO/RTO, настроена понятная GFS-ретенция, есть хотя бы один immutable-слой и восстановление регулярно репетируется.
Если выбирать с чего начать: зафиксируйте RPO/RTO, внедрите 3-2-1 (минимум один слой вне площадки), добавьте immutable для критичных копий и поставьте restore test в календарь как обязательную операцию.
