Nube

rclone copy y ransomware: --immutable, --ignore-existing y --backup-dir

Publicado el 1 de noviembre de 2026Última revisión: 1 de noviembre de 20263 min de lectura

Resultado de la prueba

rclone copy por defecto sobrescribe la copia buena con el fichero cifrado (exit 0); --immutable la conserva y sale con exit 6; --ignore-existing la conserva con exit 0; --backup-dir sobrescribe pero deja la versión buena en otra carpeta.

Contenido

Resultado
Qué implica
Script completo

Este artículo no contiene enlaces de afiliado.

Si subes tus ficheros a la nube con rclone copy cada noche y un día un programa malicioso cifra los originales, la siguiente copia sube los ficheros cifrados encima de los buenos. Se probó qué hace cada opción de rclone en ese caso.

Condiciones: rclone 1.60.1 en Linux arm64, un directorio local como destino (con un remoto en la nube el comportamiento de estas opciones es el mismo, pero no se probó), dos ficheros de texto sintéticos. Se simula el ataque sobrescribiendo a.txt con otro contenido y una fecha nueva. Script completo al final.

Resultado

Comando	Exit	`a.txt` en el destino
`rclone copy`	0	contenido cifrado (copia buena perdida)
`rclone copy --immutable`	6	contenido bueno
`rclone copy --ignore-existing`	0	contenido bueno
`rclone copy --backup-dir DIR`	0	contenido cifrado; el bueno está en `DIR/a.txt`

Qué implica

Por defecto no protege. rclone copy no copia solo lo nuevo: también reemplaza lo que cambió. Para rclone, un fichero cifrado es un fichero modificado.
--immutable se niega a modificar un fichero que ya existe en el destino. Muestra ERROR : a.txt: Source and destination exist but do not match: immutable file modified y sale con exit 6. Un script de copia nocturna que compruebe el código de salida avisa. El coste: tampoco aceptará tus ediciones legítimas, así que sirve para ficheros que no deberían cambiar (fotos, escaneos, archivos), no para documentos que editas.
--ignore-existing salta en silencio lo que ya existe y sale con 0. Protege igual, pero no avisa de nada, y las ediciones legítimas tampoco se suben nunca.
--backup-dir deja que la copia se actualice, pero mueve la versión anterior a otra carpeta. Sirve para documentos que sí editas. Hay que usar un directorio dentro del mismo remoto y vaciarlo con criterio, porque crece.
Ninguna sustituye a una copia con histórico de versiones, como las que hace restic, ni a comprobar la copia. Sobre la diferencia entre copy y sync, ver rclone sync o rclone copy.

Script completo

#!/bin/bash
# rclone copy: what happens to the good backup when the source file is overwritten by garbage (ransomware-like)? Usage: test-rclone-immutable.sh WORKDIR. Synthetic data, local directory as the "cloud".
W=$1; rm -rf "$W"; mkdir -p "$W"
setup() { rm -rf "$W/src" "$W/dst" "$W/old"; mkdir -p "$W/src" "$W/dst"; echo "datos buenos" > "$W/src/a.txt"; echo "otro" > "$W/src/b.txt"; rclone copy "$W/src" "$W/dst"; sleep 1; echo "CIFRADO-POR-RANSOMWARE" > "$W/src/a.txt"; }
run() { echo "== $1"; setup; shift; rclone copy "$W/src" "$W/dst" "$@" >"$W/out" 2>&1; echo "salida: $?"; grep -E "ERROR|Copied \(replaced" "$W/out" | head -3; echo "destino a.txt: $(cat "$W/dst/a.txt")"; [ -d "$W/old" ] && echo "old/a.txt: $(cat "$W/old/a.txt")"; true; }
run "rclone copy (por defecto)"
run "rclone copy --immutable" --immutable
run "rclone copy --ignore-existing" --ignore-existing
run "rclone copy --backup-dir" --backup-dir "$W/old"