"restic: restaurar un solo fichero o carpeta de una copia (find, ls, restore --include, dump)"
2026-10-18
Casi nunca se necesita restaurar toda la copia. Lo habitual es haber borrado o estropeado un fichero y querer la versión de hace unos días. Esta prueba recorre los comandos de restic para ese caso: find, ls, restore --include y dump. Se hizo con restic 0.16.4 en Linux, en un servidor de pruebas. Si aún no tienes repositorio, empieza por la guía 3-2-1 con restic. Para qué pasa cuando la propia copia está dañada, mira la prueba de restauración.
Cómo se preparó la prueba
- 20 ficheros aleatorios de 1 MiB en
fotos/y tres ficheros de texto endocs/. - 4 snapshots con fechas fijadas con
--time: el 1 de octubre se creacontrato.txt(versión 1); el 2 cambia a la versión 2 y apareceinforme.txt; el 3 se modificapresupuesto.txt; el 4 se ha borradocontrato.txt. - Contraseña desechable en la variable
RESTIC_PASSWORD, repositorio en un directorio temporal.
El script completo está en tools/test-restic-restore-single.sh del repositorio del sitio. Los tiempos son de una sola ejecución con datos pequeños (unos 20 MiB), así que sirven de orden de magnitud, no de referencia.
1. Encontrar el fichero borrado: restic find
No hace falta saber en qué snapshot estaba:
restic -r repo find contrato.txt
Salida (ejecución de 732 ms): restic lista los snapshots que contienen el fichero, con su ruta original.
Found matching entries in snapshot a2885361 from 2026-10-01 03:00:00
/tmp/restic-test2/data/docs/contrato.txt
Found matching entries in snapshot 9a88df3e from 2026-10-02 03:00:00
...
Found matching entries in snapshot ec51fe88 from 2026-10-03 03:00:00
Aparece en los tres primeros snapshots y no en el cuarto, que es el posterior al borrado. El último con el fichero es ec51fe88.
2. Ver el contenido de un snapshot: restic ls
Para comprobar qué había en una carpeta concreta:
restic -r repo ls latest /ruta/original/docs
restic -r repo ls ec51fe88 /ruta/original/docs
Con latest (524 ms) salen informe.txt y presupuesto.txt: el contrato ya no está. Con ec51fe88 salen los tres. ls sirve para confirmar que eliges el snapshot correcto antes de restaurar.
3. Restaurar solo ese fichero: restore --include
restic -r repo restore ec51fe88 --target out --include /tmp/restic-test2/data/docs/contrato.txt
Resultado en 721 ms: Summary: Restored 5 / 1 files/dirs (28 B / 28 B). Se restauró un solo fichero de 28 bytes (el "5" cuenta también los directorios intermedios). Comprobación con sha256sum contra la copia local hecha antes de borrarlo:
sha256 original : 4fe6064b4425169f5a68e1bede67f5b276a35a0d7d489a499bea30d9cbd21b17
sha256 restaurado: 4fe6064b4425169f5a68e1bede67f5b276a35a0d7d489a499bea30d9cbd21b17
Coinciden. Un restore completo del mismo snapshot (20 MiB) tardó 783 ms, apenas más que el de un fichero: con datos tan pequeños el tiempo lo domina abrir el repositorio, no copiar. La diferencia aparece con repositorios grandes o remotos, donde restaurar solo lo necesario evita descargar el resto.
Fallo observado: la ruta completa se recrea dentro de --target
El fichero no quedó en out/contrato.txt. Quedó en:
out/tmp/restic-test2/data/docs/contrato.txt
restic recrea la ruta original completa bajo el directorio de destino. Si buscas el fichero en out/ no lo verás. Con find out -type f lo localizas y luego lo mueves a su sitio.
Fallo observado: un patrón que no coincide no da error
Se probaron varios patrones contra el mismo snapshot:
--include |
Ficheros restaurados |
|---|---|
/tmp/restic-test2/data/docs/contrato.txt (ruta original completa) |
1 |
*/contrato.txt |
1 |
docs/contrato.txt (relativa) |
1 |
/docs/contrato.txt (absoluta, pero no es la ruta original) |
0 |
contrato (sin extensión) |
0 |
Los dos últimos terminaron con Summary: Restored 0 files/dirs (0 B) y sin mensaje de error. Si no miras el resumen, creerás que la restauración funcionó. Compara siempre el número de ficheros restaurados con lo que esperabas.
Para una carpeta entera, el mismo comando con la ruta de la carpeta (--include /tmp/restic-test2/data/docs) restauró los 3 ficheros de docs/ (79 bytes) y nada de fotos/.
4. Sin crear ficheros en disco: restic dump
restic -r repo dump ec51fe88 /tmp/restic-test2/data/docs/contrato.txt > contrato.txt
Tardó 725 ms, escribe el contenido por la salida estándar y el sha256sum del resultado fue idéntico (4fe6064b...). Aquí la ruta sí se indica completa y no se recrean directorios, así que es más cómodo para un solo fichero. Para una carpeta, dump genera un tar.
5. Montar el repositorio: restic mount
restic mount expone los snapshots como un sistema de ficheros para navegar con el explorador. No se pudo probar: el servidor de pruebas no tiene dispositivo FUSE y restic respondió fusermount: fuse device not found, try 'modprobe fuse' first. En un equipo de escritorio con FUSE suele funcionar, pero aquí no hay datos propios.
Qué usar en cada caso
- No sabes cuándo se perdió el fichero:
find, luegolspara confirmar. - Quieres el fichero de vuelta junto con su ruta original:
restore --include. - Quieres una sola versión sin tocar el sistema de ficheros:
dump. - Practícalo ahora, no el día del fallo: restaurar un fichero cada mes forma parte de la rutina de la prueba de restauración. Si tu repositorio crece, la retención con forget y prune decide hasta qué fecha puedes recuperar versiones antiguas.
Este artículo no contiene enlaces de afiliado.