Расчет окна бэкапа по сети: формулы и пример на ночь

Почему бэкап не укладывается в ночь

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

Проблема обычно не в том, что "мало мегабит". Цифра скорости канала на бумаге редко совпадает с реальной скоростью передачи бэкапа. На нее влияют накладные расходы протоколов, шифрование, конкурирующий трафик, задержки и потери, а еще то, как именно бэкап-система читает данные и пишет их в хранилище. Даже если линк 1 Гбит/с, реальная полезная скорость для бэкапа может быть в 2-5 раз ниже.

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

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

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

Пример из практики: филиал выгружает ночной бэкап в центральный ЦОД. Канал формально 200 Мбит/с, но днем он занят бизнес-трафиком, а ночью скорость проседает из-за шифрования и перегруженного хранилища. В итоге бэкап "влезает" только по отчетам, а по факту постоянно опаздывает. Здесь решает не удача, а расчет и проверка допущений.

Что такое окно бэкапа и какие есть ограничения

Окно бэкапа - это промежуток времени, когда вы можете гонять резервные копии так, чтобы не мешать работе. Обычно это ночь, но важно не просто сказать "с 23:00 до 06:00", а зафиксировать точки старта и дедлайны: когда заканчиваются бизнес-операции, когда начинается утренний пик, когда запускаются регламентные задания, отчеты или обновления.

Окно всегда связано с двумя целями. RPO отвечает на вопрос, сколько данных вы готовы потерять, если что-то сломается (например, максимум 1 час изменений). RTO - сколько времени у вас есть, чтобы восстановиться и снова работать (например, сервис должен подняться за 2 часа). Если RPO маленький, нужны более частые бэкапы. Если RTO маленький, важно не только успеть сделать копию, но и чтобы она быстро восстанавливалась.

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

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

Простой пример: если ночью у вас есть 6 часов, но с 02:00 до 03:00 идут обмены с банком, то "реальное" окно уже 5 часов или меньше. И его нельзя занимать полностью: нужен запас на ретраи, проверки и неожиданные пики.

Какие исходные данные нужно собрать

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

Сначала определите, сколько данных вы реально защищаете. Важен не только общий объем (например, 80 ТБ на файловых шарах и виртуалках), но и ежедневные изменения: у баз данных и почтовых систем это может быть 5-20% в сутки, а у архивов почти ноль. Если нет статистики, возьмите логи бэкап-системы или измерьте прирост за 7-14 дней.

Дальше опишите источники и их особенности. Один большой сервер и двадцать небольших виртуалок ведут себя по-разному: есть накладные расходы на запуск заданий, параллелизм, узкие места на хранилище. Отдельно выделите базы данных, файловые шары, VM, физические серверы и критичные сервисы.

Полезно собрать данные в короткую таблицу: объем и средний дневной прирост по каждому источнику, тип нагрузки (файлы, VM, база) и время пиков бизнеса, какие задания могут идти параллельно, а какие только по очереди, где стоят агенты/прокси и через какие сегменты сети идет трафик, включены ли дедупликация, сжатие, шифрование и верификация после записи.

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

Пропускная способность сети: как получить реальную цифру

Номинальные 1 Гбит/с на порту почти никогда не превращаются в 1 Гбит/с полезной передачи для бэкапа. Для расчета окна бэкапа по сети нужна именно рабочая скорость, которую вы стабильно видите ночью, а не цифра в спецификации.

Самая простая оценка начинается так: переведите скорость канала в мегабайты в секунду и заложите потери на оверхед. Быстрая конверсия: 1 Гбит/с = 1000 Мбит/с = 125 МБ/с (в идеале). Дальше примените поправки.

Полезная скорость (МБ/с) = Номинал (МБ/с) x Kреал x (1 - Оверхед)

Где Kреал - доля, которую реально можно занять бэкапом (например, 0,6 если вы ограничили трафик до 60%), а оверхед включает TCP/IP, VPN, шифрование и потери на работе с множеством мелких файлов. Для VPN и шифрования часто разумно закладывать 10-30% потерь, а при большом количестве мелких объектов - еще больше.

Даже при высокой скорости канала задержка и потери могут сильно снизить фактическую скорость TCP. На длинных линиях и между площадками одна и та же полоса дает разный результат: рост RTT и даже 0,1-1% потерь приводят к падению передачи и "пилообразной" скорости.

Чтобы получить реальную цифру, лучше измерять, а не угадывать:

• Прогоните тест iperf между источником и приемником (в то же время, когда идут бэкапы).
• Посмотрите статистику портов на коммутаторах и маршрутизаторах: загрузка, ошибки, дропы.
• Снимите среднюю скорость бэкап-джобов за несколько ночей (минимум 3).
• Проверьте RTT и потери (ping/мониторинг), особенно для межфилиальных VPN.
• Отдельно оцените влияние лимитов QoS или rate-limit на пути.

Небольшой пример: канал 1 Гбит/с (125 МБ/с), ограничение для бэкапа 50% (Kреал = 0,5), оверхед 20%. Тогда полезная скорость: 125 x 0,5 x 0,8 = 50 МБ/с. Именно от этой цифры дальше считают, сколько гигабайт реально успеет уйти за ночь.

Дедупликация и сжатие: как они меняют объем передачи

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

Сжатие уменьшает размер передаваемого блока. Оно хорошо работает на текстах, логах, офисных документах, некоторых образах виртуальных машин. Но на уже сжатых данных выигрыш почти нулевой: видео, JPEG/PNG, ZIP/RAR, многие резервные копии баз, которые уже пишутся в сжатом виде.

Дедупликация убирает повторы. Критично, где она считается:

• На источнике (client-side): по сети чаще уходят только уникальные блоки, окно бэкапа реально сокращается.
• На приемнике (target-side): по сети уходит полный поток, а экономия появляется уже в хранилище.

Для сети важно именно первое. Поэтому в расчетах уточняйте, на каком этапе применяется дедупликация и сжатие, и в каком порядке.

Удобная практика - считать эффективный объем передачи:

V_сеть = V_изменений / (K_dedupe x K_comp)

Где K_dedupe и K_comp - во сколько раз уменьшается поток (например, 2 означает "в 2 раза меньше"). Если эффекта нет, коэффициент равен 1. Если дедупликация только на приемнике, для сети берите K_dedupe = 1.

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

Не закладывайте одну "магическую" цифру. Реальность плавает: в одни дни больше изменений в базах, в другие - массовые обновления ОС. Лучше считать диапазон и проверять, помещается ли худший сценарий в ночное окно.

Приоритет трафика и лимиты: как не мешать бизнесу

Если отдать резервному копированию всю полосу, пострадают обычные сервисы: почта, телефония, видеозвонки, доступ к базам, терминальные сессии. Даже ночью часть систем работает: обновления, мониторинг, обмен с филиалами, задачи безопасности. Поэтому при расчете окна бэкапа по сети важно сразу закладывать, что бэкап - это гость в сети, а не хозяин.

Самый понятный способ защитить бизнес - лимитирование скорости бэкапа. Оно бывает простым (cap на клиенте или на прокси/медиасервере) и более гибким (расписание, разные окна для разных подразделений, отдельные лимиты для филиалов). Это помогает избежать ситуации, когда один большой сервер "забивает" канал и срывает бэкап другим.

QoS простыми словами

QoS - это правила в сети, которые решают, кому ехать первым, когда дорога загружена. Трафик делят на классы, ставят в разные очереди и задают приоритет.

Обычно хватает 3-4 классов: критичный (голос/видео, транзакции), важный (бизнес-приложения), обычный (веб), фоновый (бэкап). Бэкап лучше отправлять в фоновую очередь с ограничением по скорости, чтобы при появлении бизнес-трафика он сразу уступал полосу.

Как выбрать безопасный лимит и проверить

Начните с консервативного лимита и уточните его пилотом на 2-3 ночи:

• Выделите ночную долю канала под бэкап (часто 20-40% от реальной доступной полосы).
• Задайте cap и включите QoS для класса бэкапа.
• Проверьте утром метрики: задержки, потери, жалобы пользователей, время выполнения бэкапа.
• Увеличивайте лимит шагами (например, +10%) до первого заметного влияния.
• Зафиксируйте результат и отдельно настройте исключения для критичных систем.

Мини-сценарий: филиал на 100 Мбит/с, ночью идет обмен с центральной базой. Ставите бэкап на 30 Мбит/с и QoS в фон. Если утром видите рост задержек у базы, снижаете cap до 20 Мбит/с или переносите часть задач на другое окно.

Пошаговый расчет окна бэкапа: простые формулы

Чтобы бэкапы стабильно укладывались в ночь, полезно считать не общий размер хранилища, а реальный объем данных, который нужно передать за окно.

Шаги расчета

1. Определите объем изменений за период бэкапа. Для инкрементальных копий это обычно дневной прирост (или прирост за 8-10 часов). Обозначим его как Vизмен (в ГБ).

2. Примените эффекты дедупликации и сжатия. Они уменьшают именно передаваемый объем. Пусть Kdedup - во сколько раз дедупликация уменьшает поток (2:1 значит Kdedup = 2), а Kcomp - во сколько раз уменьшает поток сжатие (1,5:1 значит Kcomp = 1,5). Тогда объем к передаче:

Vперед = Vизмен / (Kdedup x Kcomp)

3. Посчитайте полезную скорость канала, а не номинал. Номинальная пропускная способность падает из-за TCP, шифрования и служебных заголовков, плюс часто есть лимит по QoS. Обозначим:

Sполез = Sном x Koverhead x Klimit

где Koverhead обычно 0,7-0,9 (после накладных расходов), а Klimit - доля канала, которую вы реально отдаете под бэкап (например, 0,3 если разрешено до 30%).

Перед тем как делить, проверьте единицы:

• 1 байт = 8 бит
• 1 МБ/с = 8 Мбит/с
• 1 ГБ = 1024 МБ

4. Добавьте запас на пики и сюрпризы: ретраи при ошибках сети, верификацию, параллельные задания, конкуренцию за диск на источнике/приемнике. Практичный запас - 20-40%.

Общая формула времени

Время (сек) = (Vперед (в МБ) / Sполез (в МБ/с)) x Kзапас

Такой расчет окна бэкапа по сети быстро показывает, что именно упирается в потолок: объем изменений, слабая дедупликация, слишком жесткий лимит по трафику или недостаточная полезная скорость.

Пример расчета: чтобы бэкап реально помещался в ночь

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

Предположим, у вас 12 ТБ данных на файловом сервере. Полный бэкап делаете редко, а каждую ночь - инкрементальный. Окно бэкапа 9 часов (с 22:00 до 07:00). Чтобы не мешать бизнесу, на бэкап поставили лимит QoS: 300 Мбит/с.

Сначала переводим лимит в полезную скорость. На практике часть пропускной способности съедают накладные расходы (TCP, шифрование, подтверждения, "пустые" блоки). Возьмем коэффициент эффективности 0,85.

Полезная скорость:

Sпол = Slim x 0,85 = 300 x 0,85 = 255 Мбит/с

В мегабайтах в секунду это примерно 255 / 8 = 31,9 МБ/с.

Теперь объем ночной передачи. Если ежедневные изменения 5%, то инкремент за сутки:

Δ = 12 ТБ x 5% = 0,6 ТБ = 600 ГБ

Время передачи без дедупликации и сжатия:

T = Объем / Скорость = 600 ГБ / 31,9 МБ/с ≈ 5,3 часа

В 9-часовое окно вы укладываетесь, даже с запасом на небольшие просадки.

Вариант с дедупликацией и сжатием. Допустим, вместе они дают коэффициент 2,5 (то есть по сети уходит в 2,5 раза меньше):

Объемпо_сети = 600 ГБ / 2,5 = 240 ГБ

T = 240 ГБ / 31,9 МБ/с ≈ 2,1 часа

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

Если расчет сходится, но в реальности медленнее, сеть может быть не главным узким местом. Быстро проверить это помогают признаки: источник не читает данные достаточно быстро (диск/СХД загружены), репозиторий бэкапов медленно пишет (особенно на пике), CPU на сервере бэкапа уходит в 100% из-за шифрования или сжатия, бэкап идет рывками из-за большого числа мелких файлов, параллельных задач слишком много для одного сервера или хранилища.

Идея простая: время бэкапа определяется самым медленным звеном. Поэтому полезно смотреть не только на сеть, но и на реальные скорости чтения и записи вашей инфраструктуры, будь то отдельный сервер или стойка на базе серверов уровня S200 Series.

Как валидировать расчеты и настроить стабильный результат

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

Практичный подход: выберите одну типовую группу (например, 10-20 ВМ или один файловый сервер), запустите бэкап на 2-3 ночи подряд и сравните факты с расчетом. Одна ночь может "повезти", а стабильность видно только серией.

Вот что стоит смотреть в отчетах бэкап-системы и хранилища, чтобы понять, где съедается время:

• Средняя и пиковая скорость передачи (по задаче и суммарно по всем задачам).
• Фактический объем до и после сжатия и дедупликации (лучше в ГБ за ночь).
• Время на подготовку и завершение (сканирование, синтетика, проверка, индексация).
• Ретраи, таймауты, повторные чтения, ошибки доступа.
• Узкие места по источнику или приемнику (CPU, диск, очередь задач).

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

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

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

Типичные ошибки, из-за которых расчеты не сходятся

Самая частая причина провала - ошибки в единицах. Если в формуле смешать Мбит/с и МБ/с, окно "внезапно" увеличивается в 8 раз. Выберите один стандарт (например, все считать в МБ/с) и перед подстановкой всегда приводите цифры к нему.

Вторая ловушка - брать скорость порта вместо полезной скорости. Линия 1 Гбит/с на бумаге почти никогда не означает 125 МБ/с в бэкапе: есть накладные расходы протоколов, пики нагрузки, ограничения на стороне хранилища и сервера. Поэтому расчет окна бэкапа по сети должен опираться на измеренную реальную пропускную способность в нужные часы, а не на паспорт.

Еще одна причина - забытые параллельные узкие места. Даже если сеть выдерживает, бэкап может упереться в диск, CPU (особенно при шифровании и сжатии) или лимиты на самом репозитории. Часто это выглядит так: первые 10 минут скорость высокая, затем падает и держится низкой до конца.

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

Проверьте, заложили ли вы накладные расходы, которые обычно вспоминают в последний момент: ретраи при потерях пакетов и кратких обрывах, верификацию/проверку целостности, конкуренцию с другими ночными задачами (сканирование, обновления, ETL), рост данных (хотя бы 10-20% запас).

Простой пример: расчет показывает 6 часов, но вы не учли проверку после копирования (еще 45 минут) и периодические ретраи (плюс 10%). В итоге получается уже около 7,5 часов, и бэкап стабильно вылезает за окно.

Чеклист и следующие шаги

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

Мини-чеклист перед запуском ночного окна:

• Уточните объем данных именно на ночной бэкап: инкремент, полный, журналы, плюс служебные накладные расходы.
• Проверьте окно по времени: когда стартует, когда должно закончиться, и оставьте запас минимум 15-30%.
• Зафиксируйте лимиты и приоритет: какой максимум вы разрешаете бэкапам (Мбит/с) и какие сервисы всегда важнее.
• Сверьте коэффициенты дедупликации и сжатия на ваших данных, а не по паспорту.
• Убедитесь, что хранилище и сервер бэкапа успевают принимать поток (иначе сеть ни при чем).

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

План на 30 дней:

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

Инфраструктуру стоит пересмотреть, если даже при разумных лимитах и реальных коэффициентах вы не укладываетесь в окно или бэкапы мешают бизнесу. Частые причины: недостаточная пропускная способность между площадками, медленное хранилище, слабые серверы под дедупликацию.

Если нужна помощь с подбором серверов и построением схемы бэкапа, имеет смысл подключать системного интегратора. GSE.kz (gse.kz) как раз занимается системной интеграцией и поставляет серверы собственного производства, а также обеспечивает поддержку 24/7 через сервисную сеть по Казахстану.