restic --compression off, auto o max: cuánto ocupa y cuánto tarda

Publicado el 29 de octubre de 2026Última revisión: 29 de octubre de 20264 min de lectura

Este artículo no contiene enlaces de afiliado.

Los repositorios de formato 2 de restic admiten compresión. Se midió qué cambia --compression off|auto|max en el tamaño del repositorio y en el tiempo de backup con tres tipos de datos.

Condiciones: restic 0.16.4 en Linux arm64 (2 CPUs), repositorio local creado con --repository-version 2, un repositorio nuevo por combinación, contraseña desechable. Tres conjuntos de unos 101 MiB, 101 MiB y 21,5 MiB, descritos abajo. Cada combinación se ejecutó una sola vez. No se probaron repositorios remotos (S3, rclone), otras CPUs, conjuntos más grandes ni muchos ficheros pequeños. Script completo al final.

Los datos

Tamaño del repositorio

Con el texto, auto dejó el repositorio en el 21,5 % del tamaño de off y max en el 20,2 %. Con datos aleatorios y con el gzip no hubo ganancia: la diferencia entre modos fue de menos de 4 KB, y off fue el más pequeño en ambos casos.

Tiempo de backup (segundos, una ejecución)

Con el texto, comprimir costó tiempo: auto tardó 3,03 s frente a 1,77 s de off, y max 6,59 s. En random, off salió más lento (4,64 s) que auto y max, lo cual no tiene explicación lógica: es muy probable que sea ruido de la primera lectura del disco o de la caché, y por eso no conviene sacar conclusiones de tiempos de una sola ejecución. En gz las diferencias (1,18 a 1,36 s) son pequeñas y tampoco se pueden distinguir del ruido con estos datos.

Qué se puede decir y qué no

• Medido: en texto repetitivo, auto ya consigue casi todo el ahorro de max (22,8 MB frente a 21,4 MB) con menos de la mitad del tiempo en esta máquina.
• Medido: en datos aleatorios o ya comprimidos, la compresión no ahorró espacio en esta prueba.
• No medido: el efecto en la restauración, en repositorios remotos (donde menos bytes subidos podría compensar el tiempo de CPU), en CPUs más rápidas o más lentas, o con datos reales mezclados. Los logs sintéticos son más compresibles que muchos logs reales.

Para ver cuánto ocupa lo que tienes, consulta restic stats; para excluir lo que no hace falta copiar, excluir node_modules y cachés.

Script completo

#!/bin/bash
# restic repository v2 compression: repo size and backup time per mode.
# Usage: test-restic-compression.sh WORKDIR
W=$1; rm -rf "$W"; mkdir -p "$W/text" "$W/random" "$W/gz"
export RESTIC_PASSWORD=prueba-desechable
RESTIC=/usr/bin/restic
# Dataset 1: synthetic log lines (~100 MiB) generated locally
awk 'BEGIN{srand(42); for(i=0;i<1100000;i++)
  printf "2026-11-%02d %02d:%02d:%02d host%d sshd[%d]: %s from 10.%d.%d.%d port %d\n",
  1+i%28, i%24, int(rand()*60), int(rand()*60), int(rand()*20), int(rand()*30000),
  (rand()<0.5?"Failed password for root":"Accepted publickey for deploy"),
  int(rand()*255), int(rand()*255), int(rand()*255), 1024+int(rand()*60000)}' > "$W/text/app.log"
# Dataset 2: random bytes, Dataset 3: gzip of the text (already compressed)
head -c "$(stat -c %s "$W/text/app.log")" /dev/urandom > "$W/random/random.bin"
gzip -6 -c "$W/text/app.log" > "$W/gz/app.log.gz"
for d in text random gz; do echo "dataset $d: $(du -sb "$W/$d" | cut -f1) bytes"; done
echo "dataset | mode | repo_bytes | backup_seconds"
for d in text random gz; do
  for m in off auto max; do
    R="$W/repo-$d-$m"
    $RESTIC init -r "$R" --repository-version 2 >/dev/null
    s=$(date +%s.%N)
    $RESTIC -r "$R" backup "$W/$d" --compression $m --quiet >/dev/null
    e=$(date +%s.%N)
    printf "%s | %s | %s | %.2f\n" $d $m "$(du -sb "$R" | cut -f1)" "$(awk "BEGIN{print $e - $s}")"
  done
done