Qué es realmente una copia de seguridad
Publicado el 2026-09-12 por frfrand
Un archivo guardado no es un backup: lo es un procedimiento probado de recuperación. La regla 3-2-1, las dos preguntas que definen tu estrategia, y por qué un snapshot no siempre alcanza.
Casi todo el mundo tiene backups. Bastante menos gente tiene una restauración probada. La diferencia entre esas dos cosas es todo el tema.
Un archivo guardado no es una copia de seguridad. Es un archivo. Se convierte en copia de seguridad el día que comprobás que podés volver desde él.
Las dos preguntas que definen tu estrategia
Antes de elegir herramienta, hay que contestar dos cosas. Tienen nombres formales y son muy concretas:
¿Cuántos datos podés perder? Si hacés una copia por día y la falla ocurre a las 23:00, perdés casi un día de trabajo. Si eso es inaceptable, necesitás copias más frecuentes o registro continuo.
¿Cuánto podés estar caído? Restaurar una base grande desde un volcado puede llevar horas. Si tu negocio no tolera eso, necesitás una réplica lista para tomar el relevo, no sólo un archivo.
Las respuestas cambian por completo la solución. Y son decisiones de negocio, no técnicas: alguien tiene que decir cuánto cuesta perder cuatro horas de datos.
La regla 3-2-1
Tres copias del dato, en dos tipos de soporte distintos, una de ellas fuera del lugar.
No es superstición: cada parte cubre un modo de falla.
- Tres copias cubre que una se corrompa sin que nadie lo note.
- Dos soportes cubre que falle un disco, o un tipo de almacenamiento entero.
- Una afuera cubre lo que se lleva todo: un incendio, un borrado masivo, una cuenta comprometida.
Ese último punto merece énfasis: si tus backups están en la misma cuenta de nube que tu servidor, alguien que comprometa esa cuenta se lleva las dos cosas. "Afuera" significa otro lugar de verdad.
Completo, incremental y diferencial
Completo: todo, cada vez. Simple de restaurar, caro de almacenar.
Incremental: sólo lo que cambió desde la copia anterior. Barato. Para restaurar necesitás la completa más toda la cadena de incrementales; si falta una, no llegás.
Diferencial: lo que cambió desde la última completa. Punto medio: para restaurar necesitás sólo dos archivos.
El esquema habitual y sensato: una completa semanal, incrementales diarios, y retención de varias semanas.
Un snapshot no siempre es un backup
Los snapshots de disco son cómodos y tienen dos límites que conviene conocer.
Consistencia. Un snapshot toma el disco tal como está, y una base de datos puede tener escrituras a medias en ese instante. Los motores modernos suelen recuperarse, pero para bases lo correcto es usar su propia herramienta (pg_dump, o una copia física coordinada), que garantiza un estado consistente.
Ubicación. Un snapshot suele vivir en la misma infraestructura que el disco. Cubre "borré una tabla", no cubre "perdí la cuenta".
La parte que casi nadie hace
Probar la restauración. Completa, en un servidor limpio, con cronómetro.
La primera vez siempre falta algo: una extensión de la base que no estaba instalada, una variable de entorno, un permiso, un archivo subido por usuarios que no estaba en la copia porque nadie se acordó de incluirlo.
Es mucho mejor descubrir eso un martes tranquilo que durante un incidente.
Agendalo una vez por trimestre. Y escribí el procedimiento: quien tenga que restaurar puede no ser quien armó el sistema.
En ArduMaker cada VPS tiene copia completa periódica, en caliente, guardada en un host distinto al que corre el VPS y verificada con su hash, con instrucciones de restauración al lado. Pero la prueba de restauración sigue siendo una buena costumbre, siempre.