Una copia protege de todo aquello con lo que no comparte destino. En el mismo disco sobrevive a un archivo borrado, pero no a un disco averiado. En el mismo servidor sobrevive a un disco averiado, pero no a una cuenta comprometida. La pregunta es siempre: ¿con qué comparte destino esta copia?

Tres, dos, uno, dicho claramente

  • Tres copias: la que está en servicio y dos de seguridad.
  • Dos tipos de almacenamiento: no dos carpetas en un mismo disco.
  • Una en otro sitio: otra máquina, e idealmente otro proveedor.

«Otro sitio», ordenado según cuánto protege

  • Otro disco del mismo servidor: de un disco averiado, y de nada más.
  • Otro servidor del mismo proveedor: de un servidor averiado. No de una suspensión de cuenta, ni de un error cometido con acceso a todo el proveedor.
  • Otro proveedor por completo: todo lo anterior, más el día en que el problema es la propia cuenta.
Si una intrusión en tu servidor también puede borrar las copias, esas copias no son una defensa contra una intrusión. El destino de las copias debe ser de solo escritura desde el servidor: puede añadir, no puede quitar.

La solo escritura en la práctica

# object storage with an append-only policy, or
# a pull model: the BACKUP server connects to the site and takes a copy,
# so the site never holds credentials that can delete anything

El modelo en que es el destino quien va a buscar es el más sólido y el menos usado: nada del servidor web alcanza las copias, así que nada de lo que ocurra allí puede tocarlas.

Cífrala y guarda la clave en otra parte

gpg --symmetric --cipher-algo AES256 backup.tar.gz
Una clave guardada solo en el servidor que murió no es una clave. Anótala y guárdala en un lugar que no tenga nada que ver con el servidor.
Prueba concretamente la copia remota. La local suele funcionar, y la remota es esa de la que nadie ha restaurado nunca.