Aplica 3-2-1-1-0 sin contar una cuarta copia por error. Prueba versiones protegidas, claves, RPO/RTO reales y la vuelta segura del negocio.
Autor
Anichur Rahaman
El trabajo está en verde. La dueña pregunta: «¿podemos operar desde esa copia en otro servidor?». En un ensayo, la base abre, pero faltan archivos de facturas y nadie encuentra la clave. Es una escena ficticia, no un incidente de cliente.
Se copió algo; el negocio no se recuperó. El ransomware agrava esa distancia: el atacante puede comprometer copias accesibles, identidades y controles de restauración. Los respaldos tampoco deshacen robo de datos ni expulsan intrusos.
El plan útil termina con un servicio validado y alguien responsable de decidir.3-2-1-1-0 ayuda a organizarlo, no lo garantiza.
La guía 3-2-1-1-0 indica tres copias, dos medios, una externa, una offline/aislada/inmutable y cero errores de verificación. Producción normalmente cuenta entre las tres.
Ejemplo: producción, respaldo local separado y respaldo externo protegido. El tercero puede cumplir externo y protegido; no exige automáticamente una cuarta copia. El destino temporal del ensayo no sustituye historia retenida.
Carpetas distintas del mismo disco no son independientes. Revisa login, proveedor de identidad, ubicación, clave, facturación y retención compartidos. RAID y replicación mejoran disponibilidad mientras pueden reproducir borrado o corrupción; no completan el plan.
El soporte offline debe estar desconectado y protegido entre usos controlados. Un servidor conectado que extrae copias separa funciones, pero no crea automáticamente un aislamiento físico ni inmunidad. Prueba límites, no etiquetas.
AWS Object Lock protege versiones concretas; pueden existir versiones nuevas y marcadores de borrado. Compliance y governance permiten controles distintos. La versión visible no es la única recuperable.
AWS advierte sobre pérdida de claves: objetos bloqueados pueden resultar ilegibles sin ellas. Inmutabilidad protege retención, no toda dependencia de recuperación.
Pregunta por protección, acortar plazos, excepciones privilegiadas, cierre de cuenta y restaurar versiones antiguas. Prueba objetos desechables antes de bloquear datos valiosos irreversiblemente. Compatibilidad S3 no demuestra idéntica semántica.
Separa escritor habitual, administrador de almacenamiento y lector de recuperación. Da permisos reales para verificación/multipart cuando proceda; «solo escritura»no es un conjunto mágico universal. El escritor puede subir basura o consumir capacidad. Usa identidades controladas y autenticación fuerte; alerta por trabajos ausentes, errores, cambios de retención/claves y crecimiento.
Los objetivos de recuperación separan antigüedad tolerable de datos perdidos(RPO) y duración tolerable de interrupción(RTO). Acuérdalos con responsables y dependencias, no copies una tabla.
Ensayo ilustrativo: interrupción 09:12, datos recuperables hasta 08:45, servicio acordado validado 11:05. Son 27 minutos de distancia y 113 de recuperación. Para RPO 15/RTO 120, se incumple el primero por 12 minutos y se cumple el segundo con 7 de margen.
Subir a 09:10 una copia con datos de 08:45 no cambia el punto. Arrancar la base a 10:00 tampoco termina el reloj si faltan facturas o conciliación. Registra inicio, punto, alcance de validación y fin.
La frecuencia debe sostener el compromiso: una copia mensual sola no da RPO semanal de datos cambiantes. Para PostgreSQL PITR, la documentación exige base física adecuada y WAL continuo necesario. pg_dump lógico no sirve de base para reproducir WAL. Verifica cadena y procedimiento por versión.
Un punto seguro frente a ransomware puede ser anterior al último disponible. Evalúa compromiso; antes del cifrado no significa antes de la intrusión. Explica la pérdida y conciliación resultantes.
| Medida | Objetivo ilustrativo | Resultado | Interpretación |
|---|---|---|---|
| Distancia de datos(RPO) | 15 minutos | 09:12−08:45=27 minutos | Incumple por 12 minutos |
| Recuperación(RTO) | 120 minutos | 09:12→11:05=113 minutos | Cumple con 7 minutos de margen |
| Validación | Flujos críticos definidos | Archivos, claves, acceso y conciliación externa | Arrancar la base no basta |
Inventaría bases, facturas/medios, versiones de objetos, configuración, software, trabajos, integraciones y reconstrucción. Selecciona conjunto coherente; mezclar momentos puede perder o confundir adjuntos. Copiar archivos de base activa no crea automáticamente un respaldo consistente.
Protege tránsito y reposo según amenazas. Custodia aparte las claves necesarias, con acceso de emergencia probado. Conserva claves históricas para copias y registros retenidos. No cambies a ciegas la clave de cifrado de aplicación: puede requerir migración y claves anteriores.
Prueba sin administrador habitual, bóveda, identidad o región principal. Un archivo cifrado no sirve si su único desbloqueo desaparece con producción. Guarda runbook/contactos offline protegidos, sin imprimir secretos utilizables en un manual general.
Elige retención según negocio, ley, descubrimiento, diversidad de puntos y coste.30/90/365 días no son norma universal. Alerta por antigüedad del punto recuperable, no nombre nuevo. El checksum detecta alteraciones, no demuestra limpieza, integridad funcional ni utilidad.
Usa destino aislado y restringido, bloqueando o sustituyendo pagos, email, transportistas, trabajos y webhooks antes de arrancar. Los datos restaurados mantienen exigencias de privacidad y eliminación segura. No conectes el ensayo a integraciones reales.
Verifica registros/saldos del punto, abre adjuntos, prueba descifrado, permisos y flujos críticos con identidades seguras. Cronometra aprovisionamiento, descarga, reproducción, configuración, autenticación y validación. Comparar filas actuales con copia antigua puede dar falsa alarma.
Concilia lo externo: un proveedor pudo cobrar después del punto y el transportista tener ya un paquete. No reproduzcas colas, cobres ni envíes otra vez a ciegas. Asigna excepciones y usa referencias estables/protección de duplicados.
Programa verificaciones ligeras, restauraciones completas representativas y ejercicios según riesgo. Prueba versión anterior, clave ausente, cadena rota, administrador ausente y trabajos restaurados. Registra fallos, responsables y plazos. Cero errores describe ese alcance, no garantiza futuros incidentes.
Nombra líder y aprobador, con contactos limpios fuera de banda. Aislamiento, pruebas, protección y respuesta especialista empiezan pronto; no esperes a perder todas las copias. El playbook del Cyber Centre canadiense separa respuesta y recuperación y advierte de cambios de credenciales que impidan restaurar.
Contén sistemas/accesos con los especialistas. Evita un «nunca apagar»universal: el equipo equilibra evidencia volátil y daño activo. Elige destinos limpios, atiende persistencia/vía de entrada y aprueba reconexión gradual validada.
Rota accesos comprometidos desde contexto limpio conservando descifrado/recuperación controlados. Protege copias y evidencia. No destruyas capacidad de restaurar con «cambia todas las claves ya».
Evalúa robo, contratos, seguro y notificaciones con asesores responsables. Recuperar operación no termina automáticamente el incidente ni revierte divulgación. Registra acciones y revisa el plan.
Elige un servicio importante y otra persona distinta del mantenedor para seguir el runbook. Muestra versión protegida, claves, destino limpio, flujo validado y RPO/RTO. Registra y financia brechas antes de prometer plazos.
El recorrido de interfaz existente es una demostración, no prueba de tus copias inmutables u objetivos. Mantén una aceptación específica del entorno.
El trabajo verde es una señal; la evidencia más fuerte es recuperar de forma repetible y explicar los límites.
Revisado 5 noviembre 2026. Anichur Rahaman es el creador de StoreConsole. Escenas, objetivos y tiempos son ilustrativos; verifica proveedor y obligaciones propias.
Sobre el autor
Anichur Rahaman
Seguir Leyendo
