"restic forget y prune: cuántas copias se conservan y cuánto espacio se libera"

2026-10-18

Una copia diaria con restic crea un snapshot por día, y el repositorio no deja de crecer hasta que decides qué snapshots borrar. Esta prueba comprueba qué conserva una política de retención de 7 diarias, 4 semanales y 3 mensuales, cuánto espacio libera y qué pasa si ejecutas forget sin --prune. Se hizo con restic 0.16.4 en Linux, en un servidor de pruebas. Si aún no tienes copias, empieza por la guía 3-2-1 con restic.

Cómo se preparó la prueba

Datos sintéticos: 10 ficheros aleatorios de 100 KB que no cambian, más un fichero diario.bin de 100 KB que se sustituye por contenido nuevo cada día. Así cada snapshot aporta datos que solo él contiene, que es lo que permite ver espacio liberado.
90 snapshots del equipo servidor-a, uno al día entre el 2026-07-01 y el 2026-09-28, creados con --time para fijar la fecha.
10 snapshots más de un segundo equipo, servidor-b, entre el 2026-09-19 y el 2026-09-28.
Total: 100 snapshots. Contraseña desechable en una variable de entorno, repositorio en una carpeta temporal.
El script completo está en el repositorio del sitio: tools/test-restic-retention.sh.

Cada copia se creó así (<CONTRASEÑA> es un marcador; en la prueba se usó una contraseña desechable):

export RESTIC_PASSWORD='<CONTRASEÑA>'
restic -r /tmp/restic-test/repo backup /tmp/restic-test/data \
  --host servidor-a --time "2026-07-01 03:00:00"

Estado inicial: 100 snapshots, restic stats --mode raw-data indicó 10,899 MiB y du midió 13.676 KiB.

Paso 1: simular con --dry-run

restic -r /tmp/restic-test/repo forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --dry-run

--dry-run no borra nada y lista qué conservaría y qué eliminaría, con el motivo de cada snapshot conservado. Resultado:

Equipo	Conserva	Elimina
servidor-a	11	79
servidor-b	9	1

Para servidor-a conservó:

los 7 últimos días, del 22 al 28 de septiembre (daily snapshot);
los domingos 13 y 20 de septiembre como semanales, y el 27 y el 28, que además cuentan como semana;
el último snapshot de cada mes: 31 de julio, 31 de agosto y 28 de septiembre (monthly snapshot).

Un mismo snapshot puede cumplir varias reglas a la vez. Por eso 7 + 4 + 3 = 14 no da 14 snapshots: dieron 11.

Paso 2: forget sin --prune

Esta parte se hizo sobre una copia del repositorio, para poder comparar después:

restic -r /tmp/restic-test/repo-sin-prune forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 3

Restic informó de 80 ficheros de snapshot eliminados y restic snapshots pasó de 100 a 20. Pero el tamaño del repositorio en disco casi no cambió:

	Snapshots	`du`
Antes	100	13.676 KiB
Tras `forget` sin `--prune`	20	13.352 KiB

Se liberó un 2,4 %. forget borra la referencia al snapshot, pero los datos que solo usaba siguen en los ficheros del repositorio hasta que se ejecuta prune.

Hay una segunda trampa en esta tabla. restic stats --mode raw-data tras el forget sin --prune ya mostraba 2,961 MiB, aunque el disco seguía ocupando más de 13 MB. Ese comando cuenta los datos que siguen referenciados, no lo que hay en disco. Para saber cuánto ocupa de verdad el repositorio local, usa du.

Paso 3: forget --prune

restic -r /tmp/restic-test/repo forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 3 --prune

El resumen de prune en la salida:

to repack:           100 blobs / 1.990 MiB
to delete:           399 blobs / 7.840 MiB
remaining:           111 blobs / 3.059 MiB
unused size after prune: 100.043 KiB (3.19% of remaining size)

Resultado:

	Snapshots	`du`
Antes	100	13.676 KiB
Tras `forget --prune`	20	4.312 KiB

El repositorio pasó de 13.676 KiB a 4.312 KiB, un 68,5 % menos, con los mismos 20 snapshots que en el paso anterior. Con este conjunto de datos aleatorios, que no se comprimen ni se deduplican entre días, el ahorro es mayor que con una carpeta de documentos reales; el orden de magnitud depende de cuánto cambie tu información.

Paso 4: comprobar el repositorio

restic -r /tmp/restic-test/repo check

Resultado: no errors were found, con 20 snapshots revisados. Esto confirma que el repositorio quedó coherente tras borrar. Recuerda lo que se vio en la prueba de restauración: check a secas no lee el contenido de los ficheros de datos; para eso hay que añadir --read-data.

La otra trampa: la retención se aplica por equipo y ruta

El repositorio tenía dos equipos y la política conservó snapshots para ambos: 11 de servidor-a y 9 de servidor-b. Restic agrupa por equipo y ruta (--group-by host,paths por defecto) y aplica la política a cada grupo por separado. Dos consecuencias que se ven en los números:

Un equipo nuevo con pocos snapshots no se ve afectado por los de otro. servidor-b tiene solo 10 días de historia y perdió únicamente el snapshot del 21 de septiembre.
Si cambias la ruta que copias o el nombre del equipo, los snapshots antiguos pasan a otro grupo y la política los cuenta aparte. En la prueba no se probó cambiar de ruta; solo se observó el agrupamiento por equipo.

Pauta de uso

Ejecuta siempre primero con --dry-run y lee la lista de eliminados.
Usa --prune en el mismo comando, o ejecuta restic prune después. Sin él, el disco no se libera.
Mide con du en repositorios locales.
Termina con restic check.
prune reescribe ficheros del repositorio. Haz primero la copia fuera de casa de la regla 3-2-1 y no interrumpas el proceso.

La prueba no incluye repositorios en la nube ni conjuntos de cientos de GB. En esos casos prune tarda más y transfiere datos; mide con tus propios datos antes de automatizarlo. Para elegir la herramienta de copia, mira la comparativa restic vs Borg.

Este artículo no contiene enlaces de afiliado.