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

Почему бэкапы замедляют систему

В плане бэкапы выглядят безобидно. В продакшене они конкурируют за тот же диск, CPU, память и сеть, которыми пользуется ваше приложение, чтобы обслуживать пользователей.

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

Первое узкое место часто — исходящая полоса. У многих команд скорость загрузки заметно меньше скорости скачивания. Для обычной офисной работы это нормально. Для бэкапов — плохо, потому что бэкапы в основном «толкают» данные наружу. Большая база может заполнить этот узкий канал на часы, и тогда всё, что требует исходящего трафика, замедляется: ответы приложения, администрирование, мониторинг, синхронизация файлов и развёртывания.

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

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

• запросы, которые вчера выполнялись нормально, начинают таймаутиться в часы бэкапа
• реплики отстают и не догоняют
• ночные задания переносятся на рабочие часы
• удалённое администрирование и развёртывания становятся медленными
• задания бэкапа заканчиваются в случайное время или не укладываются в окно

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

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

Что измерить в первую очередь

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

Первое число — объём изменений в день. Команды часто берут общий размер базы, потому что это кажется очевидной метрикой. Но это не всегда полезная величина. База 3 ТБ звучит дорого, но если в ней изменяется только 40 ГБ в день, ваши ежедневные передачи и потребности в хранилище существенно меньше, чем подсказывает полный размер.

Второе число — реальная скорость загрузки, измеренная в разные моменты времени. Не доверяйте цифре в счёте. Протестируйте канал в пиковые часы и в спокойное время. Соединение, которое тянет 250 Мбит/с ночью, может падать до 70 Мбит/с, когда сотрудники, приложения и клиенты конкурируют за ту же полосу.

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

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

Вам также нужны цели по восстановлению перед сравнением классов хранения. Задайте два простых вопроса: сколько данных вы можете позволить себе потерять и как быстро нужно вернуть систему в рабочее состояние? Эти ответы сильнее влияют на стоимость, чем многие ожидают. Дешёвое архивное хранилище может выглядеть хорошо в таблице, но оказаться плохим выбором, если вам нужны быстрые восстановления.

Небольшой пример: база 1.5 ТБ, ежедневные изменения 55 ГБ и логи ещё 10 ГБ в день. Если реальная ночная скорость загрузки 120 Мбит/с, можно понять, входят ли ночные передачи в окно. Если цель восстановления — четыре часа, очень холодное хранилище может экономить деньги ежемесячно, но провалиться в момент реального инцидента.

Хорошее планирование начинается с короткой рабочей таблицы, а не с листа покупок. Измерьте размер, скорость изменений, реальную пропускную способность, расписание и требования к восстановлению. После этого цены легче сравнивать, а сюрпризы редки.

Оценка окна передачи

Начните с простой математики. Возьмите объём данных, которые собираетесь передать, и разделите на устойчивую пропускную способность, а не на скорость, написанную на порту.

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

Используйте это как основу:

transfer window = backup size / real throughput

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

Полезная оценка требует четырёх входных данных: размер бэкапа, средняя пропускная способность в период бэкапа, дополнительное время на сжатие и шифрование и запас пропускной способности для обычного трафика. Последнее важнее, чем многие думают. Если офис, приложение или клиенты уже используют 30–40% канала в рабочие часы, эта полоса недоступна. Планирование, как будто она свободна — вот как окно бэкапа превращается в outage.

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

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

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

Выбор классов хранения без сюрпризов

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

Помогает разделять недавшее восстановление и долгосрочное хранение как две разные задачи. Одна копия нужна для быстрого отката после неудачного деплоя, повреждённой миграции или удалённой таблицы. Другая — для ретенции, где важнее цена, потому что к данным можно не обращаться месяцами.

Две ступени для двух задач

Разумный подход прост: держите недавние бэкапы в горячем слое короткий срок (обычно 7–30 дней), затем переводите старые копии в холодный слой. Это делает обычные восстановления быстрыми и снижает расходы на долгосрочное хранение.

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

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

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

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

Построение плана

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

Начните с определения минимального набора бэкапов, который всё ещё позволяет восстановиться с уверенностью. Многие команды копируют все базы, все логи каждый день. Это быстро съедает бюджет. Оставьте только полные бэкапы, инкременталы и журналы, которые вам действительно нужны, и исключите старые тестовые базы, устаревшие реплики и данные, которые можно пересобрать.

Дальше установите жёсткий лимит на пропускную способность бэкапа в рабочие часы. Более медленный бэкап терпимее, чем медленные запросы, зависшие админ-экраны или упавшие чеки́. Большинство инструментов резервного копирования позволяют ограничить скорость передачи, параллелизм или скорость чтения с диска.

Перемещайте самые тяжёлые передачи в самое спокойное время. Для одной компании это ночь, для другой — раннее утро или выходные. Опираться нужно на реальные паттерны трафика, а не на офисное расписание в презентации.

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

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

Малый пилот обычно экономит времени больше, чем дни работы со spreadsheet. Если 2 ТБ база чисто бэкапится с дневным лимитом и ночным подъёмом, у вас появляется шаблон для повторного использования.

Разворачивайте постепенно. Одна база может вести себя хорошо, а десять, запущенных одновременно, могут забить узкий uplink или нагрузить общее хранилище. Добавляйте системы партиями, следите за числами и продолжайте тонкую настройку, пока трафик бэкапов не сольётся с фоном.

Простой пример с реальными числами

Возьмём базу 4 ТБ, которая меняется на 5% в день. Это примерно 200 ГБ новых или изменённых данных каждые 24 часа. На uplink 200 Мбит/с в идеальных условиях вы сможете передавать около 25 МБ/с, то есть примерно 90 ГБ в час.

Ночной инкрементальный бэкап 200 ГБ вмещается, но с небольшим запасом. На полной скорости это займёт чуть более 2.2 часа. В реальности задания идут медленнее из‑за шифрования, контрольных сумм, ретраев и офисного трафика. На практике то же задание может занять 2.5–3 часа.

Проблема — еженедельный полный бэкап. Передача 4 ТБ по тому же каналу 200 Мбит/с в теории займёт около 44 часов. С учётом накладных расходов безопаснее рассчитывать 46–50 часов. Это не укладывается в обычное восьмичасовое окно и не всегда помещается в тихую ночную смену в выходные. Оно залезет в рабочие часы и начнёт конкурировать с базой.

Выбор хранилища быстро меняет месячный счёт. Если хранить четыре еженедельных полного и 30 ежедневных инкрементальных копий, в месяце набирается около 22 ТБ данных бэкапов.

• Всё на быстром слое по $20 за ТБ·мес: примерно $440 в месяц.
• Разделение: 5.4 ТБ на быстром слое и 16.6 ТБ в архиве.
• По цене $20 для быстрого и $4 для архива: около $175 в месяц.

Такой смешанный подход сокращает счёт за хранение более чем вдвое. Цена — скорость восстановления. Быстрое хранение для последних копий, архив — для старых, к которым вы надеетесь не обращаться, потому что их извлечение занимает больше времени и может стоит дороже.

Именно поэтому стоит считать заранее. В этом примере ежедневные инкременталы управляемы, еженедельные полные — нет, а двухуровневый план экономит деньги, не превращая каждое восстановление в медленную процедуру.

Ошибки, которые тратят полосу и деньги впустую

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

Первая ошибка — ориентироваться только на сырой размер базы. 4 ТБ не всегда означают передачу 4 ТБ по сети. Сжатие может сильно уменьшить объём, или почти не помочь, если данные уже сжаты. Скорость изменений тоже важна. Если меняется 3% данных в день, ночные полные бэкапы обычно излишни.

Ещё одна распространённая ошибка — верить цифрам провайдера по полосе, не проверив свой путь. Реальным лимитом могут быть скорость чтения диска, накладные шифрования, задержки VPN или занятый офисный uplink. Если провайдер обещает 1 Гбит/с, а ваш сервер тянет лишь 180 Мбит/с в рабочие часы, учитывайте низшую цифру.

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

Дешёвое хранилище может стать дорогой ошибкой при инциденте. Архивные уровни часто берут плату за извлечение и могут требовать часы до доступности. Для старых месячных копий это нормально. Для копии прошлой ночи с жёсткой целью восстановления — плохой выбор.

Расписание вызывает больше проблем, чем многие думают. Если бэкапы стартуют одновременно с отчётами и ночными заданиями, все они борются за диск и сеть. Пользователи почувствуют это утром. Смещение старта бэкапа на 60–90 минут часто решает ситуацию.

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

Проверки перед финализацией

Таблица — только первый черновик. План закончен, когда живая система ведёт себя так, как предсказала оценка.

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

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

Небольшой тест восстановления стоит затраченных усилий. Восстановите один недавний бэкап, один старый и один объект из дешёвого архива, если он есть. Засеките время и запишите полную стоимость.

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

Что делать дальше

Выпишите план на одной странице и держите его скучным. Если кто‑то в команде не может прочитать его за две минуты и объяснить расписание — он ещё слишком запутан.

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

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

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

Если хотите получить второе мнение перед покупкой дополнительного хранилища или полосы, держите запрос прагматичным. Oleg Sotnikov из oleg.is работает как fractional CTO и консультирует стартапы и небольшие компании; он помогает разбирать компромиссы: трафик бэкапов, ограничения инфраструктуры, время работы и контроль затрат.

План резервного копирования можно считать завершённым, когда на два вопроса можно ответить без догадок: сколько займёт сегодняшний бэкап и как быстро мы сможем восстановиться при сбое?