Backup Window (Окно резервного копирования)

Backup Window — это то самое выделенное «окно», когда системе официально разрешают жужжать дисками и заливать данные в хранилище. В этот промежуток запускаются задачи резервного копирования: серверов, VM, баз, приложений. И да, это сильно влияет и на производительность, и на SLA, и на то, насколько вы будете мешать пользователям работать.

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

От чего зависит длина backup window #

• Объём данных — чем больше копируем, тем дольше всё будет крутиться, тут магии нет.
• Тип бэкапа — full, incremental, differential: у каждого свой след по времени.
• Скорость сети и дисков — узкое место тут часто важнее мощности CPU.
• Мощность backup-сервера и агентов — чем слабее железо, тем дольше гоняет.
• Число систем, которые бэкапятся параллельно — все дерутся за одни и те же ресурсы.
• Дедупликация, сжатие, мультистрим — могут радикально сократить время, если правильно настроены.

Живой пример #

Картина из мира Windows Server:

• Каждую ночь с 01:00 до 04:00 крутятся инкрементальные бэкапы.
• Раз в неделю, в ночь с субботы на воскресенье, делается полный бэкап.
• Хранение — в облаке: тот же Azure Backup или Veeam Cloud Connect.

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

Зачем вообще планировать backup window #

• Производительность — если запускать тяжёлые бэкапы в час пик, они начнут отъедать CPU, I/O и сеть у боевых сервисов.
• RTO (Recovery Time Objective) — неправильно распиханные задачи бэкапа могут, наоборот, мешать восстановлению, когда оно реально нужно.
• Регламенты — во многих компаниях расписание бэкапов чётко прописано в SLA/политике ИБ, и его нарушение — уже формальная проблема.
• Мониторинг — когда окно понятно, можно отслеживать, укладываются ли задачи в него, искать узкие места и оптимизировать.

Как можно ускорить бэкапы #

• Перейти на инкрементальные копии + использовать change block tracking, чтобы не гонять одни и те же блоки по сто раз.
• Включить адекватную дедупликацию, чтобы реально уменьшить объём передаваемых данных.
• Разбить задачи на несколько параллельных потоков, если инфраструктура это выдерживает.
• Часть задач отправить в облако или на вторичное хранилище, разгрузив основную систему.
• Пробросить отдельный сетевой интерфейс для бэкапного трафика, чтобы не душить продакшн-сеть.
• Хотя бы минимальный QoS, чтобы бэкап не мог одним махом забить весь канал.

В нормальной инфраструктуре backup window — это уже не «ну, ночью же никто не работает», а аккуратно рассчитанный процесс, завязанный на политику непрерывности бизнеса и безопасность. От того, как вы его настроите, зависит и стабильность системы, и то, насколько быстро вы сможете подняться после проблем.

Недельный график бэкапов (пример) #

Можно представить это как таблицу расписания, примерно в таком духе:

• Пн–Пт, 01:00–03:00 — инкрементальные копии файловых серверов на локальный NAS.
• Сб, 02:00–06:00 — полный бэкап всех серверов в S3 или аналогичное облако.
• Вс, 04:00–05:00 — дифференциальный бэкап баз данных в SAN.
• Ежедневно, 23:00–23:30 — конфиги и манифесты Kubernetes в Git или S3.

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

YAML: расписание backup в Kubernetes (Velero) #

apiVersion: velero.io/v1
kind: Schedule
metadata:
name: daily-backup
namespace: velero
spec:
schedule: "0 2 * * *" # Ежедневно в 2:00 ночи
template:
ttl: 240h0m0s # Хранить 10 дней
includedNamespaces:
- default
snapshotVolumes: true
storageLocation: aws-s3

Этот ресурс создаёт ежедневный бэкап всего, что лежит в namespace default, включая снапшоты томов. Срок хранения — 10 дней.

Пример плана в AWS Backup (JSON) #

{
"BackupPlanName": "ProductionBackup",
"Rules": [
{
"RuleName": "DailyIncremental",
"TargetBackupVaultName": "default",
"ScheduleExpression": "cron(0 2 * * ? *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 180,
"Lifecycle": {
"DeleteAfterDays": 14
}
},
{
"RuleName": "WeeklyFull",
"TargetBackupVaultName": "archive",
"ScheduleExpression": "cron(0 3 ? * 7 *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 480,
"Lifecycle": {
"DeleteAfterDays": 90
}
}
]
}

Здесь один набор правил описывает ежедневные инкрементальные бэкапы, второй — еженедельные полные. У каждого своё окно выполнения и срок хранения (от 14 до 90 дней).

Типы резервного копирования — коротко #

• Full — копируется всё. Восстанавливаться удобно и быстро, но окно большое и диска ест много.
• Incremental — только изменения с момента последнего бэкапа (любого типа). Копируется быстро, но для восстановления нужна вся цепочка.
• Differential — изменения с последнего полного бэкапа. Восстанавливать проще, чем из чистых инкрементов, но размер диффа растёт со временем.
• Synthetic Full — полный бэкап собирается на стороне хранилища из набора инкрементов, источник почти не трогают.
• Snapshot — снимок состояния в момент времени (том, VM и т.д.). Очень быстро, но свои нюансы с консистентностью при сбоях.

Мониторинг backup window: Prometheus + Grafana #

Откуда брать метрики #

• Veeam — через Prometheus Exporter, который вытягивает данные по REST API.
• Velero — отдаёт метрики по эндпоинту /metrics, можно сразу скрести Prometheus’ом.

Пример метрики:

velero_backup_last_successful_timestamp{schedule="daily-backup"} 1719938400

Пример алерта в PromQL #

time() - velero_backup_last_successful_timestamp{schedule="daily-backup"} > 86400

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

Alert в Grafana (v9+) #

• Триггер — запрос к Prometheus, как выше.
• Условие — порог > 86400 секунд (24 часа).
• Оповещения — Slack / Email / Telegram, на вкус команды.
• Метаданные — например, severity=critical, team=infra, чтобы было понятно, кому бежать.

Итог #

Когда у вас:

• адекватно подобран тип бэкапа,
• грамотно рассчитано backup window,
• и всё это ещё и мониторится автоматически,

получается система защиты данных, которая не только «где‑то там что‑то копирует», но и реально выдерживает аудит и SLA, и даёт шанс нормально пережить серьёзный инцидент.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Арендовать VPS