Backup, continuidad y recuperación para startups: del 3-2-1 al plan de continuidad reducido

Por qué la continuidad es una decisión de arquitectura en una startup

En una startup o fintech, los datos son el producto: registros de clientes, ledgers de transacciones, modelos, integraciones con adquirentes y bancos. La pérdida o indisponibilidad de esos datos no es un incidente de TI aislado, es una interrupción directa de ingresos y, en un ambiente regulado, un problema de cumplimiento y de confianza con los socios.

El error común es tratar el backup como una tarea de infraestructura delegada al proveedor de nube. Los snapshots automáticos y la replicación entre zonas protegen contra fallas de hardware, pero no contra la eliminación accidental, la corrupción lógica, el compromiso de credenciales o el ransomware que cifra justamente los volúmenes y sus snapshots. La resiliencia exige decisiones deliberadas sobre dónde, cómo y con qué aislamiento viven las copias.

El NIST SP 800-34 (Contingency Planning) y la ISO 22301 (Business Continuity) organizan ese razonamiento en torno a un análisis de impacto: identificar los procesos críticos, cuánto tolera la empresa quedarse sin ellos y cuánto dato puede perder. Para una startup, esto no necesita convertirse en un proyecto de meses; necesita convertirse en un documento de una página que orienta las próximas elecciones de arquitectura.

La regla 3-2-1 y sus variaciones modernas

La base reconocida (presente en los CIS Controls, control de Data Recovery) es el 3-2-1: mantener tres copias de los datos, en dos tipos de medio o tecnología distintos, con al menos una copia fuera del ambiente principal. La producción cuenta como una copia; esto significa al menos dos backups adicionales, y nunca todos en el mismo proveedor, la misma cuenta o la misma región.

Las variaciones 3-2-1-1-0 endurecen la regla para la era del ransomware: el primer '1' extra exige una copia inmutable u offline (air-gapped), y el '0' exige cero errores en la verificación del backup. Para una startup en nube, esto se traduce en usar object lock en el almacenamiento de objetos, una cuenta o tenant separado para los backups y verificación automática de integridad después de cada job.

Separe también el plano de identidad: si la misma credencial que administra la producción también puede borrar o alterar los backups, tiene una copia, no un backup. Use cuentas dedicadas, con permisos mínimos y MFA, y mantenga las copias de retención larga fuera del alcance operacional del día a día.

Si durante ese diseño percibe que no tiene quién monitoree intentos de acceso indebido a los backups o quién responda cuando la alerta se dispara, ese es exactamente el tipo de brecha que Decripte cubre. Nuestro monitoreo continuo y la respuesta a incidentes funcionan como un equipo externo de seguridad para startups que aún no tienen un SOC propio, y hay un plan gratuito para empezar a tener visibilidad antes de necesitarla en una crisis.

RTO y RPO: midiendo lo que significa la continuidad

El RTO (Recovery Time Objective) es cuánto tiempo un sistema puede estar indisponible antes de que el impacto se vuelva inaceptable. El RPO (Recovery Point Objective) es cuánto dato, medido en tiempo, la empresa acepta perder, es decir, la distancia máxima entre el último backup válido y el momento de la falla. Esos dos números, definidos por sistema, son lo que separa la continuidad planificada de la improvisación.

Los valores no son uniformes. El ledger de transacciones de una fintech puede exigir un RPO de minutos y un RTO de pocas horas, justificando replicación continua y backups frecuentes. En cambio, un data warehouse analítico puede tolerar un RPO de 24 horas y un RTO de un día entero. Definir todo en el nivel más agresivo es caro e innecesario; definir todo en el más laxo es arriesgado.

El RPO gobierna directamente la frecuencia de los backups: si el RPO es de una hora, los backups diarios no alcanzan. El RTO gobierna la arquitectura de recuperación: metas cortas piden ambientes en precalentado o infraestructura como código lista para recrear todo rápidamente. Documente esos objetivos junto a cada sistema crítico y revíselos cuando la arquitectura cambie.

Backups inmutables y offline contra ransomware

El ransomware moderno apunta a los backups antes de cifrar la producción, porque un backup intacto neutraliza la extorsión. Por eso la propiedad decisiva de una copia no es la frecuencia, es la imposibilidad de ser alterada por quien comprometió el ambiente. La inmutabilidad y el aislamiento son lo que mantiene una copia confiable durante un ataque.

La inmutabilidad WORM (write once, read many) en almacenamiento de objetos, vía object lock en modo de cumplimiento, impide que incluso un administrador comprometido elimine o sobrescriba los datos durante el período de retención. Es el mecanismo más práctico para startups en nube, pues no exige hardware dedicado y se integra a pipelines existentes.

El aislamiento offline o air-gapped, lógico o físico, complementa la inmutabilidad: una copia que solo es accesible por un canal separado, con credenciales distintas, y que queda desconectada de la red operacional la mayor parte del tiempo. Combine retención larga inmutable con copias offline periódicas para los datos más críticos, y mantenga al menos un conjunto de backups fuera de la nube o de la cuenta donde corre la producción.

Prueba de restore: el backup que nadie restauró no existe

La falla más cara en continuidad no es no tener backup, es descubrir en el momento del incidente que el backup está corrupto, incompleto o que nadie sabe restaurarlo dentro del RTO prometido. El NIST SP 800-34 trata la prueba del plan como parte indisociable de él; un backup nunca restaurado es una hipótesis, no una garantía.

Pruebe el restore con regularidad y en un ambiente aislado, no en producción. Restaure una base completa, levante la aplicación contra ella, valide la integridad referencial y cronometre el proceso de punta a punta. El tiempo medido es su RTO real; si excede el objetivo, ajuste la arquitectura o la meta antes de que la realidad lo ajuste por usted.

Documente cada prueba: qué se restauró, cuánto tiempo tomó, qué falló y qué cambió desde entonces. Esa pista se convierte en evidencia de cumplimiento y, más importante, en el guión que el equipo seguirá bajo presión. Incluya escenarios adversos en la prueba, como restaurar a partir de la copia inmutable asumiendo que la cuenta de producción está comprometida.

Plan de continuidad (BCP/DRP) reducido para quien tiene poca gente

El BCP (Business Continuity Plan) describe cómo el negocio continúa operando durante una interrupción; el DRP (Disaster Recovery Plan) detalla cómo la tecnología vuelve a funcionar. Para una startup, ambos deben ser cortos y ejecutables: pocas páginas que responden quién decide, quién ejecuta, en qué orden vuelven los sistemas y a quién comunicar, incluyendo clientes y reguladores cuando corresponda.

Estructure en torno a escenarios concretos, no a la teoría: pérdida de la región de nube principal, compromiso de credenciales, eliminación accidental de base de datos, ransomware. Para cada uno, registre los pasos de recuperación, el RTO/RPO objetivo, los responsables y los contactos de escalamiento, incluyendo el socio externo de respuesta a incidentes. Mantenga una copia del plan fuera de los sistemas que protege.

La ISO 22301 trata la continuidad como un ciclo: planificar, ejercitar, revisar y mejorar. Para una startup, esto significa revisar el plan a cada cambio relevante de arquitectura y ejercitarlo al menos con una simulación de mesa por período. Un plan reducido que se lee, prueba y actualiza supera, en todo escenario real, al manual extenso que nadie abrió desde la auditoría.

Checklist práctico

1. 1

   1. Inventaríe datos y defina criticidad

   Liste los sistemas y conjuntos de datos, marque los críticos para los ingresos y el cumplimiento y registre dónde viven. Sin inventario, cualquier estrategia de backup tiene puntos ciegos.

2. 2

   2. Defina RTO y RPO por sistema

   Para cada sistema crítico, determine el tiempo máximo de indisponibilidad tolerable (RTO) y la pérdida máxima de datos aceptable (RPO). Esos números orientan la frecuencia de backup y la arquitectura de recuperación.

3. 3

   3. Implemente el 3-2-1 con aislamiento

   Garantice tres copias, dos medios, una externa, siempre en una cuenta o proveedor separado de la producción y con credenciales dedicadas y MFA para acceder a los backups.

4. 4

   4. Agregue una copia inmutable u offline

   Active object lock WORM en el almacenamiento de backup y mantenga al menos una copia air-gapped de los datos más críticos, fuera del alcance de las credenciales operacionales.

5. 5

   5. Automatice la verificación de integridad

   Configure la verificación automática después de cada job de backup y alertas para fallas. Un backup que falla silenciosamente es peor que ninguno, porque crea una falsa seguridad.

6. 6

   6. Pruebe y cronometre el restore

   Restaure periódicamente en un ambiente aislado, valide la integridad y mida el tiempo total. Compare con el RTO objetivo y ajuste la arquitectura o la meta según el resultado real.

7. 7

   7. Documente y ejercite el BCP/DRP

   Escriba un plan corto con roles, orden de recuperación y contactos de escalamiento, guarde una copia fuera de los sistemas que protege y ejercítelo con simulaciones periódicas.

Preguntas frecuentes