Compression

This page describes how to configure compression for Backup resources.

Compression

It is possible to enable compression for backups. This will reduce the size of the backup data, but will also increase CPU and memory usage, depending on the compression algorithm used.

The default algorithm is set to none, so no compression is done by default.

To enable compression, set the .spec.compression.algorithm field to the desired algorithm.

It is also possible to configure the compression quality using .spec.compression.quality.

Caution

Note that enabling compression will not cause older data to be recompressed. This means that if you enable compression for an existing backup, only new data will be compressed.

apiVersion: kannika.io/v1alpha
kind: Backup
metadata:
  name: backup
spec:
  sink: "sink"
  source: "source"
  compression:
    algorithm: zstd
    quality: 3 # Optional

Supported compression algorithms are:

• none (default)
• zstd
• gzip
• deflate
• bzip2
• brotli
• zlib
• lzma
• xz

To give you an idea of the compression ratio and performance of the different algorithms, here are some example benchmarks we ran on a backup of a 366 MiB, using messages of 1 KiB of text each, for some of the algorithms:

Compression	None	Zstd	Gzip	Lzma	Xz	Bzip2
Size	366M	44M	47M	18M	18M	40M
Size %	100%	12%	12.8%	4.9%	4.9%	10.9%
Backup time	11s	11s	11s	31s	33s	11s

Of course, the compression ratio and performance will vary depending on the data being backed up, so these numbers are just meant to give you an idea of the differences, and may differ significantly from your own benchmarks.

Looking at the numbers, algorithms like xz and lzma seem to compress the best, but they are also the slowest to compress and decompress. The zstd, gzip and bzip2 algorithm seems to be a good compromise between compression ratio and performance.

This page describes how to configure additional properties for a Backup.