Время резервного копирования: расчёт нагрузки

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

где T — время (сек), V — объём в байтах, S — скорость записи в байтах/с, N — количество файлов, t_overhead — задержка на один файл (обычно 0,05 с).

Для типичного случая (500 ГБ, 50 МБ/с, 100 000 файлов):

Если файлов много (миллионы), надбавка может превысить само чтение данных. Используйте Калькулятор времени резервного копирования, чтобы быстро подставить свои цифры.

Скорость S — не константа. Она зависит от:

• Тип накопителя: HDD (~150 МБ/с), SATA SSD (~500 МБ/с), NVMe (~3000 МБ/с), облако (~10–50 МБ/с по Wi-Fi).
• Размер файлов: много мелких файлов (1–10 КБ) дают просадку в 10 раз из-за задержек ввода-вывода.
• Сжатие данных: gzip ускоряет передачу, но нагружает CPU; для сжатых медиа (jpg, mp4) — бесполезно.
• Время суток: в пик (19:00–23:00) провайдеры ограничивают скорость, на облачных серверах — конкуренция.

Пример: копирование 10 000 файлов по 1 КБ на HDD даст S ~5 МБ/с, а один файл 10 ГБ — ~150 МБ/с. Реальная скорость может упасть в 30 раз.

Выбор типа резервирования кардинально меняет время. Рассмотрим на примере базы данных 100 ГБ, ежедневные изменения 5% (5 ГБ).

Инкрементальный выгоден для ежедневного быстрого бэкапа, но восстановление дольше. Дифференциальный — компромисс.

1. Исходные данные: 500 ГБ, 50 тыс. файлов, скорость записи на внешний SSD — 200 МБ/с, t_overhead = 0,05 с.
2. Расчёт передачи данных: V/S = 500 × 1024³ / (200 × 1024²) ≈ 2621 с ≈ 44 мин.
3. Расчёт накладных расходов: 50 000 × 0,05 = 2500 с ≈ 42 мин.
4. Итого: 2621 + 2500 = 5121 с ≈ 1 ч 25 мин.
5. Поправка на сжатие: если сжимать gzip, скорость записи упадёт до 50 МБ/с (из-за CPU), но объём уменьшится в 2 раза (250 ГБ). Новое время: V/S = 250 × 1024³ / (50 × 1024²) ≈ 5243 с + 2500 = 7743 с ≈ 2 ч 9 мин — дольше.

Без сжатия выгоднее! Используйте Калькулятор времени резервного копирования для быстрой оценки.

• Облачные сервисы (S3, Glacier): скорость лимитируется API токенами (обычно 5 ГБ/с на один объект, но для тысяч объектов — ограничение по запросам). Время = max(V/S_bandwidth, N/R_rate), где R_rate — количество запросов в секунду (обычно 1000/с).
• Базы данных (mysqldump): дамп генерирует один большой файл — overhead мал. Но если делать бэкап без блокировки (--single-transaction), процесс может длиться дольше из-за конкуренции.
• Сетевые диски (NFS, SMB): протоколы добавляют задержки. Пример: на gigabit Ethernet (125 МБ/с) реальная скорость 80–100 МБ/с из-за накладных расходов.

Облачный бэкап с миллионом мелких файлов может занять дни из-за ограничения по API. Лучше предварительно архивировать в один файл.

Эффект «много мелких файлов»: если считать только по объёму, время занижается в 10–100 раз. Реальная формула: T = max(V/S, N × t_overhead).

• Sparse-файлы: виртуальные диски (VMDK) могут показывать 100 ГБ, но реально занимать 10 ГБ. Неправильный расчёт по выделенному объёму.
• Неравномерная скорость: из-за тепловой дросселировки (NVMe после 5 мин падает до 1/3) или сетевых ретраев.
• Пустые директории и симлинки: учёт может добавить 10% времени на обход.

Отладка — всегда замеряйте реальный первый бэкап с помощью time rsync или Measure-Command. Потом подгоняйте коэффициенты.

Вместо ручного расчёта используйте готовые инструменты:

• Linux: time rsync -av /source /dest — покажет реальное время.
• Windows: Measure-Command { Copy-Item -Path C:\source -Destination D:\dest -Recurse }.
• Онлайн: Калькулятор времени резервного копирования — вставьте объём, количество файлов и скорость, получите оценку.

Для конвертации единиц времени (часы/минуты/секунды) пригодится Конвертер времени. А для оптимизации промежутков между бэкапами — Калькулятор времени.

Автоматизируйте замер с помощью bash-скрипта:

#!/bin/bash
START=$(date +%s)
rsync -av --progress /data/folder /backup/location
END=$(date +%s)
echo "Время: $((END - START)) секунд"
# Сохранить потом в лог

На Python (для сложной логики):

import time
import subprocess
start = time.time()
result = subprocess.run(['rsync', '-av', '/data/folder', '/backup/location'])
elapsed = time.time() - start
print(f"Время: {elapsed:.2f} с = {elapsed/3600:.2f} ч")

Замеры помогут уточнить t_overhead для вашей системы и скорректировать формулу.

• Архивируйте мелкие файлы в один tar или zip перед копированием — overhead падает с 0,05 с до 0,001 с на файл.
• Используйте инкрементальный бэкап в cron — ежедневно занимает минуты вместо часов.
• Планируйте на низкую нагрузку — 02:00–06:00, но проверьте, не запущены ли другие задачи.
• Отключите сжатие для медиа — только тратит CPU.
• Проверьте канал и диск — если скорость ниже ожидаемой, возможно, проблема в оборудовании.

После оптимизации ещё раз замерьте — и 4-часовой бэкап может стать 30-минутным.