Zstandard vs gzip для бэкапов: скорость, размер и нагрузка на CPU

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

Сжатие бэкапов — одна из тех задач, которые незаметно «едят» ресурсы. Ночью крутится cron, всё выглядит нормально, но утром пользователи жалуются на тормоза, а в графиках CPU — странные пики. Часто причина банальна: выбранный алгоритм или уровень сжатия не соответствует реальной цели.

В бытовом восприятии компрессия — это «сделать файл меньше». В админском мире у компрессии минимум три измерения:

• Размер архива (экономия места и трафика).
• Throughput (скорость упаковки и распаковки, то есть время окна бэкапа и восстановления).
• CPU usage (насколько компрессия конкурирует с прод-нагрузкой).

И вот тут начинается самое интересное: gzip исторически «по умолчанию», но zstd во многих сценариях даёт лучшее соотношение скорости и степени сжатия. Однако «лучше» не означает «всегда» — важно понимать, как именно вы делаете резервные копии и где узкое место: CPU, диск или сеть.

Zstandard (zstd) и gzip: базовые отличия без маркетинга

gzip — классика на базе DEFLATE: очень широко поддерживается, предсказуем, но при попытке сильнее сжать начинает резко «кушать» CPU, а выигрыши по размеру не всегда оправдывают потраченное время.

zstd (Zstandard) — более современный алгоритм, который проектировался как «быстро распаковывать» и при этом уметь сжимать лучше gzip на сопоставимых скоростях. Практически это означает: часто вы получаете меньший архив быстрее, или архив такого же размера заметно быстрее.

Компрессия для бэкапа — это не соревнование «кто сильнее сжал», а выбор баланса между временем окна бэкапа, временем восстановления и допустимой нагрузкой на CPU.

Что реально влияет на результат: данные важнее алгоритма

Одинаковые уровни сжатия дают разные эффекты на разных данных. Самые частые типы в бэкапах:

• Текст/SQL-дампы/JSON/логи — хорошо сжимаются, и тут высокие уровни могут дать заметный выигрыш по размеру.
• Бинарные форматы (часть изображений, медиаконтент) — уже сжаты; дополнительная компрессия малоэффективна.
• Смешанные каталоги (типичный /var/www с uploads/vendor/node_modules) — результат зависит от доли уже-сжатого контента.

Практический вывод: прежде чем «подкручивать уровень», полезно измерить на реальном срезе данных (хотя бы 1–5 ГБ из типичного бэкапа), а не на синтетическом примере.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Compression level: почему «выше» почти всегда означает «дороже»

И у gzip, и у zstd есть уровни сжатия. Механика похожая: выше уровень — больше времени на анализ и поиск повторов, обычно меньше выходной размер, но с падающей отдачей (diminishing returns).

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

• увеличением времени окна бэкапа (он мешает ночным задачам, репликациям, пересборкам индексов);
• скачками CPU и просадками по latency у прод-сервисов;
• ростом времени восстановления (а RTO обычно важнее экономии десятка процентов места).

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

CPU usage и throughput: где zstd обычно выигрывает

Если упрощать, то в бэкапах есть два контура:

• Создание архива: чтение данных с диска → компрессия → запись.
• Восстановление: чтение → декомпрессия → запись на диск.

gzip часто «упирается» в CPU на средних и высоких уровнях, а zstd на низких уровнях может быть настолько быстрым, что вы упрётесь уже в диск или сеть. Это особенно заметно на быстрых NVMe: компрессор успевает быстрее, чем диск отдаёт данные, и дальнейшее ускорение компрессии почти не влияет на общий throughput архивации.

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

Если вы делаете бэкапы в облако или на отдельный сервер, проверьте весь путь «упаковка → отправка → хранение». В некоторых инфраструктурах проще и дешевле добавить CPU на VDS, чем постоянно платить временем и рисками за слишком медленные окна бэкапа.

tar + zstd: правильные команды и частые грабли

В Linux файловые бэкапы чаще всего упаковывают через tar, а компрессию добавляют «сверху». Для zstd есть два рабочих подхода: использовать внешний компрессор через tar или сделать пайп.

Вариант 1: tar с внешним компрессором через -I

Это гибкий и предсказуемый способ: tar вызывает компрессор, а вы явно задаёте параметры zstd.

tar -I 'zstd -3 -T0' -cpf backup.tar.zst /var/www

Разбор:

• -3 — компромиссный уровень (часто хорош для больших каталогов).
• -T0 — использовать все доступные CPU-потоки (актуально для zstd; gzip исторически хуже масштабируется).
• -c — создать архив, -p — сохранить права, -f — файл.

Если нужно ограничить многопоточность, задайте -T2, -T4 и т.д. Это простой рычаг контроля CPU без изменения уровня сжатия.

Вариант 2: tar в stdout и zstd отдельным процессом

tar -cpf - /var/www | zstd -3 -T0 -o backup.tar.zst

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

Для сравнения: tar + gzip

tar -czpf backup.tar.gz /var/www

Или более явно с уровнем:

tar -cpf - /var/www | gzip -6 > backup.tar.gz

У gzip уровни 1–9, где 6 обычно «дефолтный баланс».

Как выбирать уровень: практичные пресеты под типичные сценарии

Ниже — не «истина», а удобные отправные точки. Дальше вы измеряете на своей нагрузке и корректируете.

Сценарий A: бэкап мешает прод-нагрузке (CPU важнее размера)

• zstd: уровень 1–3, потоки ограничить (например, -T2 или -T4).
• gzip: уровень 1–3, но будьте готовы, что размер вырастет заметнее, чем у zstd на тех же «быстрых» настройках.

Смысл: вы покупаете предсказуемо низкий CPU и хороший throughput. Обычно это лучший выбор для ежедневных бэкапов.

Сценарий B: бэкап уходит по сети (throughput сети важнее CPU)

Если архив потом грузится в удалённое хранилище, степень сжатия начинает напрямую экономить время передачи. Но «выкручивать максимум» всё равно опасно: вы можете упереться в CPU и не выиграть ничего по времени.

• zstd: уровень 5–10 как зона эксперимента, но сначала измерьте общий пайплайн «архивация + отправка».
• gzip: уровень 6–9 имеет смысл только если совместимость критична и zstd недоступен на принимающей стороне.

Сценарий C: архив «в долгую» (холодное хранение, редко распаковываем)

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

• zstd: более высокие уровни обычно разумнее, чем у gzip, потому что распаковка остаётся быстрой.
• gzip: максимум имеет смысл только при строгих требованиях по совместимости.

Совместимость: когда gzip остаётся «по умолчанию»

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

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

Нюансы, которые часто портят замеры

Чтобы честно сравнить zstd и gzip по throughput и CPU, важно не попасть в ловушки:

• Кэш файловой системы: второй прогон может быть быстрее просто потому, что данные уже в page cache.
• Параллельность: zstd с -T0 и gzip в один поток — нечестное сравнение. Сравнивайте осознанно: «один поток vs один поток» и «все потоки vs все потоки», если поддерживается.
• Мелкие файлы: tar упаковывает их последовательно, и вы можете упереться в метаданные/IOPS раньше, чем в компрессию.
• Проверка целостности: добавление хэшей, шифрования и отправки в хранилище меняет профиль нагрузки сильнее, чем выбор алгоритма.

Мини-бенч своими руками: измеряем размер, время и CPU

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

mkdir -p /tmp/bench-compress
cd /tmp/bench-compress

time tar -I 'zstd -3 -T0' -cpf backup-zstd-3.tar.zst /var/www
ls -lh backup-zstd-3.tar.zst

time tar -czpf backup-gzip-6.tar.gz /var/www
ls -lh backup-gzip-6.tar.gz

Что смотреть:

• real во выводе time — грубая оценка throughput всего пайплайна.
• размеры архивов — практическая экономия диска и трафика.
• параллельно полезно мониторить CPU (например, top или pidstat), чтобы понимать, за счёт чего получена скорость.

Если нужно глубже разобраться в архитектуре хранения (ретеншены, offsite-копии, дедупликация), полезно посмотреть материал про бэкапы в S3-совместимое хранилище (restic и borg).

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Что выбрать в итоге: короткая памятка

• Для большинства серверных бэкапов сегодня zstd на низких/средних уровнях — хороший дефолт: высокий throughput при умеренной нагрузке на CPU.
• gzip имеет смысл оставлять там, где критична «распаковка где угодно» или есть наследованные процессы/окружения, которые не готовы принимать zstd.
• Не выбирайте алгоритм «по привычке» — выбирайте под узкое место: CPU, диск, сеть, окно бэкапа и требования к восстановлению.

Самый правильный следующий шаг: взять один типичный бэкап, прогнать 2–3 профиля (например, zstd -1/-3/-6 и gzip -3/-6), измерить итоговый размер и время. Эти цифры обычно за 30 минут дают больше пользы, чем любые общие сравнения.