Copias de seguridad
Copias de seguridad de las que realmente se restaura: instantáneas cifradas según la regla 3-2-1, nube, verificación de la restauración. Las claves y los accesos siguen siendo tuyos.
Qué incluye el servicio
Configuramos copias de seguridad automáticas de modo que la pérdida del servidor, un ataque o un borrado accidental no se conviertan en la pérdida del negocio. El trabajo incluye una estrategia según la regla 3-2-1, instantáneas cifradas y automáticas de los datos según un calendario, la subida de las copias a un almacenamiento en la nube, una política de retención de versiones y —de forma obligatoria— la verificación de la restauración, no solo de la creación de las copias. Analizamos qué datos son exactamente críticos: la base de datos, los archivos de los usuarios, la configuración del servidor, e incluimos en las copias todo lo necesario para un levantamiento completo desde cero. El cifrado se configura de modo que ni siquiera el propietario del almacenamiento pueda leer el contenido sin tu clave. El resultado no es la promesa de que «se hacen copias», sino un procedimiento verificado con el que el servicio se levanta en minutos.
Cómo funciona en esencia
Las copias de seguridad se construyen sobre instantáneas incrementales: tras la primera copia completa, el sistema guarda solo los bloques que han cambiado, por lo que las copias diarias ocupan poco y se hacen rápido. La deduplicación elimina los fragmentos de datos repetidos entre instantáneas, y el cifrado se ejecuta de tu lado antes del envío a la nube, de modo que al exterior sale ya un conjunto de bytes ilegible. Cada instantánea se versiona y es posible restaurar a cualquier punto guardado, no solo al último. La regla 3-2-1 define el esquema de almacenamiento: tres copias de los datos, en dos soportes distintos, una de ellas fuera de la ubicación, para que un incendio o un fallo del hosting no lo destruyan todo de golpe. El paso clave es el desempaquetado de prueba periódico de la copia, porque una copia de la que nunca se ha restaurado no puede considerarse una copia.
De dónde viene la cultura de las copias de seguridad
Conviene distinguir dos mecanismos distintos. La tolerancia a fallos de los discos la describió el equipo de la Universidad de California en Berkeley —David Patterson, Garth Gibson y Randy Katz— en un artículo sobre RAID en junio de 1988; RAID protege frente a la avería de un disco, pero no es una copia de seguridad y no salva de un borrado ni de un ransomware. La herramienta de copiado propiamente dicha durante décadas fue rsync: Andrew Tridgell y Paul Mackerras presentaron su algoritmo y utilidad el 19 de junio de 1996, convirtiendo por primera vez en práctica masiva la transferencia solo de las partes cambiadas de los archivos. La propia fórmula de fiabilidad —la regla 3-2-1— la formuló el fotógrafo Peter Krogh en un libro sobre almacenamiento digital, generalizando la experiencia de proteger archivos irremplazables. De estas tres ideas —redundancia, transferencia incremental y almacenamiento distribuido— surgió la cultura moderna de las copias en la que nos apoyamos.
Por qué es crítica la precisión de la configuración
Las copias de seguridad son ese ámbito en el que el error se descubre en el peor momento posible: cuando los datos ya se han perdido y la copia resulta estar incompleta o corrupta. La trampa clásica es que las copias se crean durante años pero la restauración no se comprueba ni una vez, y en la hora de la avería resulta que en la copia no está la base de datos o se ha perdido la clave de cifrado. Por eso el valor de ingeniería del servicio no está en «activar la copia», sino en un procedimiento verificable: qué se copia exactamente, con qué frecuencia, adónde, cuántas versiones se conservan y con qué rapidez se levanta todo de vuelta. Una protección aparte son las copias inmutables, que un ransomware no podrá sobrescribir aunque obtenga acceso al servidor. Configuramos y documentamos todo el ciclo y comprobamos la restauración en la práctica, en lugar de creer que funcionará.
Con qué stack trabajamos
La herramienta principal es restic: un sistema de copias de seguridad con instantáneas incrementales, deduplicación y cifrado de extremo a extremo, capaz de guardar las copias en almacenamientos en la nube mediante el protocolo S3. Para parte de las tareas usamos borg, un archivador con deduplicación de modelo similar, y para la sincronización simple de archivos empleamos el veterano rsync. Las copias las subimos a un almacenamiento de objetos compatible con S3 (por ejemplo, una nube con pago por volumen y sin cargo por tráfico de salida), con claves de acceso separadas por tarea. El cifrado se configura del lado del cliente, por lo que el contenido de las copias es inaccesible incluso para el proveedor del almacenamiento. El stack es abierto y portable: el procedimiento de restauración no depende de un proveedor concreto y se queda contigo junto con las claves.
Cuándo aparecieron las herramientas clave
Las herramientas de copias de seguridad se han forjado durante más de una década. La idea de la redundancia de discos RAID se expuso en el artículo de la Universidad de Berkeley en junio de 1988. La utilidad rsync, que durante mucho tiempo fue el estándar de la transferencia incremental, salió el 19 de junio de 1996. Los sistemas modernos de deduplicación son más jóvenes: restic, nuestra herramienta principal, lo publicó su autor Alexander Neumann como versión 0.1.0 en 2015, y borg se separó del proyecto Attic ese mismo año 2015. Estas fechas muestran que el copiado cifrado y fiable con deduplicación es una práctica de ingeniería madura pero relativamente reciente, que hay que saber configurar para cada infraestructura concreta. Trabajamos con versiones actuales y conocemos las limitaciones de cada herramienta, en lugar de fiarlo todo a un único botón universal.
Por qué puedes confiárnoslo
La experiencia acumulada de nuestro equipo en TI supera los 45 años, y las copias de seguridad las gestionamos sobre nuestra propia práctica: nuestros datos de producción se guardan cifrados como instantáneas incrementales de restic en un almacenamiento en la nube, y tenemos el procedimiento de restauración probado. Abordamos la tarea como ingenieros: identificamos los datos críticos, construimos el esquema 3-2-1, configuramos el cifrado y la retención y ejecutamos siempre una restauración de prueba antes de declarar la copia operativa. Las claves de cifrado y los accesos se quedan contigo: no mantenemos tus datos como rehenes de nuestra cuenta. Te advertiremos con franqueza dónde el ahorro en copias genera un riesgo real y dónde la redundancia sobra. Como resultado no obtienes una línea que diga «copia activada», sino la posibilidad verificada de levantar el servicio en minutos tras una avería, un ataque o un error.
Qué incluye
Cómo trabajamos
La posibilidad verificada de levantar el servicio en minutos tras una avería, un ataque o un borrado. No un «copia activada», sino un procedimiento operativo.
Preguntas frecuentes
¿Comprobáis que la copia funciona?+
Sí: la restauración de prueba es una parte obligatoria del servicio, no solo la creación de las copias.
¿Quién guarda las claves de cifrado?+
Solo tú. El contenido de las copias es inaccesible incluso para el proveedor del almacenamiento.
¿Hay protección frente a ransomware?+
Configuramos copias inmutables y almacenamiento fuera de la ubicación para que un virus no sobrescriba las copias.