Cómo implementar un sistema de backups y recuperación ante desastres en tu aplicación web a medida

Te voy a contar algo que no quieres oír: el 60 % de las pequeñas y medianas empresas que sufren una pérdida de datos significativa cierran en los seis meses siguientes, según un informe de Boston Computing Network. Y lo peor es que la mayoría no cae por un ciberataque de película. Cae porque alguien ejecutó un DROP TABLE sin WHERE en la migración del viernes, porque una actualización corrompió registros en silencio, o porque el disco de un nodo del proveedor cloud decidió jubilarse anticipadamente.

Cuando tienes una aplicación web a medida, no hay un proveedor SaaS detrás que gestione los backups por ti. Esa responsabilidad es tuya. Toda tuya. Y he visto demasiadas veces la diferencia entre el equipo que tenía un plan de recuperación y el que improvisó a las tres de la madrugada con café frío y sudores fríos. Los primeros recuperan el servicio en horas. Los segundos pierden semanas de datos, clientes y sueño.

Por qué los backups de tu proveedor cloud no bastan

AWS, Google Cloud, Azure... todos te ofrecen snapshots automáticos y redundancia geográfica. Y muchos equipos de desarrollo se quedan ahí, convencidos de que con eso van cubiertos. Hasta que no van cubiertos.

Los snapshots del proveedor cloud te protegen contra fallos de infraestructura — un disco que muere, un rack que se cae. Pero no te protegen contra errores lógicos. Si un bug en tu código borra registros de la base de datos y no lo detectas en 48 horas, el snapshot más reciente ya contiene la base de datos corrupta. Necesitas backups con retención suficiente para rebobinar hasta un punto anterior al desastre.

Y hay otro problema que la gente olvida: esos backups del proveedor suelen estar en la misma región y la misma cuenta. Un problema de facturación, una suspensión de cuenta por error (sí, pasa) o un ataque que comprometa tus credenciales de administrador te deja sin acceso a la aplicación y a sus backups al mismo tiempo. Enhorabuena, has perdido el original y la copia.

La regla 3-2-1 lleva décadas funcionando porque es simple y efectiva: tres copias de tus datos, en dos tipos de almacenamiento diferentes, con al menos una copia fuera del sitio principal. No la reinventes. Aplícala.

Qué componentes necesitan backup (spoiler: más de los que crees)

Una aplicación web a medida tiene piezas móviles. Muchas. Olvidarte de cualquiera de ellas convierte tu recuperación en un puzle al que le faltan piezas.

Base de datos. El órgano vital. Según el motor que uses (PostgreSQL, MySQL, MongoDB), necesitas combinar backups completos periódicos con incrementales o log de transacciones para minimizar la ventana de pérdida.

Si trabajas con PostgreSQL — y lo recomiendo — la combinación de pg_basebackup para backups físicos completos y WAL archiving para point-in-time recovery es la opción más sólida. Te permite recuperar la base de datos a cualquier instante concreto, no solo al último backup completo. Esa diferencia puede ser la que separa "perdimos los pedidos de las últimas dos horas" de "no perdimos nada".

Archivos de usuario y media. Todo lo que los usuarios suben a tu aplicación. Si usas S3 o GCS, activa la replicación entre regiones y el versionado de objetos. Si los guardas en disco local, monta un proceso de sincronización regular hacia almacenamiento externo.

Código fuente y configuración. Tu repositorio Git es un backup en sí mismo si vive en GitHub o GitLab. Pero las configuraciones de despliegue, variables de entorno, certificados SSL y secretos suelen vivir fuera del repositorio. ¿Sabes dónde está cada pieza? He visto recuperaciones que tardaron tres días extra porque nadie sabía dónde estaban las variables de entorno de producción.

Infraestructura como código. Tus ficheros de Terraform, Ansible, Docker Compose o Kubernetes manifests son la receta para reconstruir todo desde cero. Sin ellos, la recuperación pasa de horas a días porque toca reconfigurarlo todo de memoria. Y la memoria a las tres de la madrugada no es fiable.

Cuánto tiempo guardar cada backup

No todos los backups necesitan la misma retención. Guardar todo para siempre es caro y no aporta. La clave está en equilibrar coste de almacenamiento con capacidad de recuperación ante distintos escenarios.

Un esquema que funciona bien para la mayoría de aplicaciones web a medida:

Tipo de backup	Frecuencia	Retención
Base de datos completo	Diario	30 días
Base de datos incremental/WAL	Continuo o cada hora	7 días
Archivos de usuario	Diario	30 días
Código y configuración	Cada commit (Git)	Indefinido
Infraestructura como código	Cada cambio (Git)	Indefinido
Backup offsite completo	Semanal	90 días

Si tu aplicación maneja datos con requisitos regulatorios — financieros, sanitarios, RGPD — la retención puede extenderse a años. Habla con tu asesor legal antes de fijar estos plazos, no después.

Automatiza o llora: herramientas para backup

Un backup manual es un backup que se olvidará. No "que puede olvidarse". Que se olvidará. La automatización no es un nice-to-have; es la línea que separa un plan real de una ilusión.

Las herramientas que uso y que he visto funcionar en producción:

• pgBackRest o Barman para PostgreSQL: gestionan backups completos e incrementales, compresión, cifrado y envío a almacenamiento remoto. Si usas Postgres y no usas alguna de estas, estás haciendo las cosas a mano innecesariamente.
• restic o Borg para backups de ficheros: deduplicación, cifrado y soporte para múltiples backends de almacenamiento (S3, SFTP, Azure Blob). Borg lleva años siendo el caballo de batalla silencioso de muchos equipos.
• Velero para entornos Kubernetes: backup y restauración de recursos del cluster y volúmenes persistentes. Si corres en K8s y no tienes Velero o equivalente, tienes un problema que aún no sabes que tienes.
• AWS Backup o equivalentes cloud-native: orquestación centralizada para servicios gestionados. Cómodo, pero recuerda: es una pata, no todo el plan.

Cada proceso de backup debe incluir verificación automática. Un backup que no se ha verificado no es un backup. La verificación mínima: comprobar que el fichero tiene un tamaño razonable, que se descomprime sin errores y que los checksums coinciden.

El runbook que esperas no usar nunca (pero que necesitas ya)

Un plan de disaster recovery (DR) no es un PDF bonito que vive en Confluence acumulando polvo. Es un runbook operativo que cualquier persona del equipo técnico debe poder ejecutar bajo presión, con medio cerebro dormido y la adrenalina por las nubes.

Tu plan DR tiene que responder estas preguntas con total claridad:

¿Cuál es tu RTO (Recovery Time Objective)? Cuánto tiempo puede estar tu aplicación caída antes de que el impacto en el negocio sea inaceptable. Para un e-commerce, hablamos de minutos. Para una herramienta interna, quizá horas. Tu arquitectura de backup debe respaldar ese número, no al revés.

¿Cuál es tu RPO (Recovery Point Objective)? Cuántos datos puedes permitirte perder. Si tu RPO es cero, necesitas replicación síncrona en tiempo real. Si puedes asumir una hora de pérdida, backups incrementales cada hora serán suficientes. Define esto con negocio, no solo con tecnología.

¿Quién ejecuta la recuperación? Nombres y teléfonos concretos. Incluye contactos de emergencia del proveedor cloud, del equipo de desarrollo y de los stakeholders de negocio que necesitan ser informados. Si la respuesta es "ya lo veremos cuando pase", no tienes un plan.

¿En qué orden se recuperan los componentes? Primero la base de datos, luego la aplicación, luego los servicios auxiliares. O puede ser diferente según tu arquitectura. Da igual cuál sea el orden, pero tiene que estar escrito y probado. No quieres estar debatiendo la secuencia durante el incidente.

¿Cómo se verifica que la recuperación fue exitosa? Define checks específicos: la aplicación responde en la URL correcta, los últimos N registros de la base de datos están presentes, los archivos de usuario son accesibles. Si no puedes verificarlo, no has terminado.

Pruebas de DR: el simulacro que nadie quiere hacer

El 23 % de las empresas nunca ha probado su plan de disaster recovery, según una encuesta de Zerto. Y de las que lo han probado, casi la mitad encontró problemas que habrían impedido una recuperación exitosa en un escenario real. Lee eso otra vez.

Prueba tu plan al menos cada trimestre. Y que las pruebas incluyan:

• Restauración completa en un entorno aislado. Nunca pruebes sobre producción, que bastante drama hay ya. Levanta infraestructura temporal, restaura los backups y verifica que la aplicación funciona de verdad, no solo que arranca.
• Cronometraje real. Mide cuánto tarda la recuperación completa y compáralo con tu RTO. Si te pasas del objetivo, tienes trabajo que hacer. Mejor enterarte ahora que durante el incidente.
• Rotación de responsables. Si solo María sabe restaurar la aplicación y María está de vacaciones cuando llega el desastre, tienes un single point of failure humano.

Documenta los resultados de cada prueba y las acciones correctivas. Este historial vale oro en auditorías y para mejorar el proceso con cada iteración.

Cumplimiento normativo: el RGPD también se aplica a tus backups

El RGPD exige medidas técnicas y organizativas para proteger los datos personales, incluyendo la capacidad de restaurar la disponibilidad y el acceso a los datos de forma rápida en caso de incidente. Un sistema de backup que no cumple esto expone a tu empresa a sanciones que pueden alcanzar el 4 % de la facturación anual. No es una cifra teórica; es lo que dice la ley.

Lo que no puedes ignorar:

• Cifrado de backups. Cifrados en tránsito y en reposo. AES-256 como mínimo.
• Control de acceso. Limita quién puede acceder a los backups y registra todos los accesos. Contienen toda tu base de datos en un fichero descargable.
• Derecho al olvido. Si un usuario ejerce su derecho a la supresión bajo el RGPD, debes poder eliminar sus datos también de los backups, o al menos documentar que los backups con datos suprimidos tienen retención limitada y que esos datos no se restaurarán en caso de recuperación. Sí, es un lío. Pero es tu lío.

La semana que puede salvarte el negocio

Montar un sistema de backup y DR decente no es un proyecto de meses. Con una semana de trabajo enfocado puedes cubrir lo fundamental: backups automatizados de base de datos y ficheros, almacenamiento offsite cifrado y un runbook de recuperación documentado y probado por primera vez.

Si tu aplicación web a medida maneja datos críticos de negocio y no tienes un plan de recuperación probado, la pregunta no es si algo fallará, sino cuándo. Y "cuándo" tiene la mala costumbre de llegar a las tres de la madrugada de un viernes. En Tangram Consulting diseñamos e implementamos estrategias de backup y disaster recovery adaptadas a la arquitectura específica de cada aplicación. Cuéntanos qué tienes y te decimos qué necesitas — mejor tener esta conversación ahora que con el servidor en llamas.