Un marco para decidir qué información respaldar, con qué frecuencia y cómo verificar que los respaldos realmente funcionan cuando se necesitan.
Los respaldos son una de esas cosas en las que nadie piensa hasta que las necesita. Y cuando se necesitan, ya es tarde para empezar a pensar. La pregunta "¿tenemos backup?" suele hacerse después de que algo salió mal: un disco que murió, un ataque que cifró los datos, un error humano que borró información crítica, un incendio o una inundación que dejó el servidor inaccesible.
Pero la pregunta correcta no es solo si hay backups. Es qué se está respaldando, cada cuánto, dónde se guardan esas copias y —quizás lo más importante— si alguien probó restaurarlas alguna vez. Porque un backup que nunca se probó no es un backup: es una historia que nos contamos para dormir tranquilos.
Este artículo propone un marco de razonamiento para decidir qué respaldar y cómo verificar que los respaldos cumplen su función. No recomienda proveedores ni herramientas específicas —eso depende del tipo de infraestructura que uses y del presupuesto disponible— sino criterios que aplican independientemente de la tecnología que elijas.
No toda la información de una empresa necesita el mismo nivel de respaldo. Pretender que todo se respalde con la misma frecuencia, en el mismo lugar y con la misma prioridad de recuperación es caro e innecesario. Conviene pensar en tres niveles:
Es la información sin la cual la empresa no puede operar: no facturar, no entregar pedidos, no atender clientes. Si esta información desaparece, la operación se detiene en horas o minutos, no en días.
Qué suele estar en este nivel: bases de datos transaccionales —pedidos, facturas, pagos, inventario—, sistemas de gestión interna, información de clientes activos, configuraciones de los servidores que sostienen la operación.
Cuánto tiempo podés permitirte perder: minutos u horas. Si se cae la base de datos de facturación a las tres de la tarde, ¿podés darte el lujo de perder todo lo facturado desde la mañana? La respuesta a esa pregunta define la frecuencia del respaldo.
Es información cuya pérdida genera un costo —horas de trabajo, molestia para clientes, tiempo de reconstrucción— pero no detiene la operación inmediatamente. La empresa puede seguir funcionando mientras se recupera.
Qué suele estar en este nivel: documentos internos, archivos de proyectos terminados, correos electrónicos antiguos, versiones anteriores de archivos de trabajo, materiales de marketing, código fuente —si está en un repositorio con su propio respaldo, quizás no necesite un respaldo adicional—.
Cuánto tiempo podés permitirte perder: días. Si se pierde la carpeta compartida con los manuales de procedimiento, va a llevar tiempo reconstruirla, pero mientras tanto la operación no se frena.
Es información cuya pérdida es una molestia sin consecuencias operativas. Reconstruirla toma tiempo pero no afecta a clientes ni a ingresos.
Qué suele estar en este nivel: versiones intermedias de archivos de trabajo, descargas de software que pueden volver a obtenerse, capturas de pantalla, datos de prueba y entornos de desarrollo, borradores que ya fueron reemplazados por versiones finales.
Cuánto tiempo podés permitirte perder: semanas o más. Si se pierde, molesta, pero no justifica el costo de un respaldo frecuente.
Para cada tipo de información, preguntá: si esto desapareciera por completo ahora mismo, ¿cuánto tiempo me tomaría volver a tener la operación funcionando? ¿Cuánto me costaría en horas de trabajo, ingresos perdidos o clientes insatisfechos? La respuesta define el nivel de protección que esa información necesita.
No todos los backups son iguales. Los tres tipos más comunes —completo, incremental y diferencial— tienen lógicas distintas y conviene entenderlas para decidir cuál aplica en cada caso.
Respaldo completo: una copia exacta de todos los datos en un momento dado. Es el más simple de restaurar —todo está en un solo lugar— pero también el más lento de hacer y el que más espacio ocupa. Conviene para el Nivel 1, con frecuencia diaria o incluso horaria según la criticidad.
Respaldo incremental: copia solo lo que cambió desde el último respaldo —completo o incremental—. Es más rápido de hacer y ocupa menos espacio, pero la restauración es más lenta y compleja: hay que reconstruir el estado final a partir del último respaldo completo más todos los incrementales posteriores. Si falla un incremental en la cadena, todo lo que viene después es irrecuperable.
Respaldo diferencial: copia todo lo que cambió desde el último respaldo completo. Es un punto intermedio: más rápido de hacer que un completo, más simple de restaurar que un incremental. Cada diferencial es independiente de los demás —solo depende del completo—, así que si uno falla no compromete al resto.
En la práctica, muchas empresas combinan: un respaldo completo semanal los fines de semana, incrementales o diferenciales diarios entre semana, y retención de varios completos hacia atrás —por ejemplo, los últimos cuatro completos— para poder volver a un punto anterior si un problema tarda en detectarse.
En respaldos, existe una regla ampliamente recomendada conocida como "tres-dos-uno" que ayuda a dimensionar cuánta redundancia es razonable:
Esta regla no es obligatoria ni universal: su aplicación depende del volumen de datos, del presupuesto y de la criticidad de la información. Pero es un buen punto de partida para la conversación con quien administre la infraestructura.
Un error frecuente es respaldar la base de datos de producción en el mismo servidor donde corre la base de datos. Si el servidor falla —disco dañado, ataque, error de configuración—, los datos originales y el backup desaparecen juntos. El backup debe estar separado físicamente de los datos que respalda.
La frecuencia del respaldo se define por una sola variable: cuántos datos te podés permitir perder. Ese número tiene un nombre técnico —RPO, por recovery point objective— pero la idea es simple: es la cantidad máxima de información que estás dispuesto a resignar en caso de una falla.
Si tu RPO es de una hora, necesitás respaldos cada hora —o menos—. Si es de un día, un respaldo diario alcanza. Si es de quince minutos, necesitás una estrategia de respaldo casi en tiempo real, que suele ser más cara y compleja.
Algunas preguntas para definir el RPO de cada sistema:
No todos los sistemas necesitan el mismo RPO. La base de datos de facturación puede necesitar respaldo cada hora; la carpeta de manuales de procedimiento, una vez por semana.
Acá está la diferencia entre tener una política de respaldos y tener respaldos que funcionan: la prueba de restauración.
Un respaldo puede fallar de muchas formas silenciosas. El archivo se corrompió y nadie lo notó. El script que hace el backup dejó de funcionar hace tres semanas pero como no mandó un error tampoco mandó una alerta. El backup está completo pero la base de datos cambió de versión y el formato del respaldo ya no es compatible con la versión actual. El backup existe pero la persona que sabía cómo restaurarlo ya no trabaja en la empresa.
La única forma de saber si un respaldo funciona es restaurarlo. No alcanza con verificar que el archivo existe y tiene un tamaño razonable. Hay que hacer el proceso completo: tomar el respaldo, restaurarlo en un entorno separado del de producción y verificar que los datos son íntegros y que el sistema arranca y funciona correctamente.
Para respaldos de Nivel 1 —información crítica—, la prueba de restauración debería hacerse al menos una vez por trimestre. Para Nivel 2, una vez cada seis meses. Para Nivel 3, una vez al año. La prueba debería ser un procedimiento documentado que cualquier persona del equipo técnico pueda ejecutar, no algo que solo sabe hacer una persona.
Relacionado: un respaldo no probado es uno de esos riesgos técnicos que nadie revisa hasta que es tarde. Como ocurre con otros riesgos invisibles, el problema no es que existan —todo sistema tiene riesgos— sino que no se gestionen activamente.
Si tu software está desarrollado y mantenido por un proveedor externo —agencia, freelancer, equipo tercerizado—, la responsabilidad de los respaldos debería estar definida en el contrato o en el acuerdo de nivel de servicio. Algunas preguntas que conviene tener respondidas:
Estas preguntas deberían ser parte de la conversación inicial con el proveedor, no una ocurrencia después de un incidente. El artículo sobre qué preguntar sobre seguridad a tu proveedor cubre en detalle la dimensión de respaldos y recuperación, incluyendo preguntas específicas sobre RPO, RTO —recovery time objective, o cuánto tiempo toma restaurar el servicio— y pruebas de restauración.
No toda la información de una empresa vive en servidores. Las computadoras de los empleados, los teléfonos, las tablets, las cuentas de correo y las herramientas en la nube también contienen información que puede ser crítica. Algunos puntos que suelen pasarse por alto:
Los proveedores de servicios en la nube suelen garantizar alta disponibilidad —que el servicio no se caiga— y durabilidad —que los datos no se corrompan—, pero eso no es un backup. La durabilidad protege contra fallas de infraestructura del proveedor; no contra errores humanos —borrar algo sin querer—, ataques —alguien que accede a tu cuenta y elimina datos— o problemas legales —una suspensión de cuenta—. El backup es responsabilidad tuya, no del proveedor de infraestructura.
Si tu empresa no tiene una política de respaldos definida, el volumen de cosas por hacer puede ser abrumador. Un orden razonable para empezar:
La perfección no es el objetivo. Un respaldo semanal en un disco externo que se probó restaurar una vez es infinitamente mejor que la política de respaldos más sofisticada que nunca se implementó.
La pregunta no es si tu empresa necesita respaldos. La pregunta es si los respaldos que tenés —o que creés tener— van a funcionar el día que los necesites. Y ese día, como todos los días en que algo falla, no avisa.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →