Las copias suelen archivarse bajo el epígrafe de la fiabilidad. Son igualmente una medida de seguridad, porque la respuesta a una intrusión, a un secuestro de datos y a un despliegue fallido es la misma: volver a una copia que sabes buena. Lo que decide si eso es posible es dónde está la copia y quién puede llegar a ella.

La prueba que importa

Supón que un atacante tiene tu servidor y todas las credenciales que hay en él. ¿Qué copias sobreviven? Si la respuesta es ninguna, no tienes una copia de seguridad: tienes una segunda copia del mismo riesgo.

Qué sobrevive

  • Fuera del sitio, en otro proveedor: consulta Una copia que vive en otra parte.
  • Solo escritura desde el servidor. El servidor puede añadir una copia y no puede listarlas ni borrarlas.
  • Con versiones o inmutable, para que sobrescribir con datos corruptos no destruya la copia buena.
  • Conservada el tiempo suficiente para cubrir una intrusión que no notaste durante un mes.
# a push-only key: the server can write, and nothing else
restic -r s3:s3.example.com/backups backup /var/www /var/lib/mysql
# the credential used here has PutObject and no DeleteObject

La conservación gana a la frecuencia

Copias cada hora conservadas dos días no sirven de nada contra algo que empezó hace tres semanas. Guarda las diarias un mes y las mensuales un año: consulta Conservación: cuánto tiempo basta.

Restaurar un sitio comprometido no es una restauración

Si la copia se tomó después de la intrusión, restaurarla vuelve a instalar al atacante. Averigua en los registros cuándo empezó, restaura desde antes de esa fecha y cierra la vía de entrada antes de que el sitio vuelva a ser público.
Una copia sin probar es una creencia, no una medida. Restaura una en otra máquina, con un calendario: consulta Comprobar que una copia se restaura.