Fundada para ofrecer soluciones integrales de software y marketing digital, Partnerfy es el socio tecnológico de confianza de agencias y marcas.
¿Le gustaría programar el futuro con nosotros?
“¿Tiene copias de seguridad?”: la respuesta debe ser sí, pero no basta. La verdadera pregunta es: “¿Podemos restaurar de verdad, en cuánto tiempo y con cuánta pérdida de datos?”. Copias de seguridad cifradas cada hora, tres copias en dos soportes con una externa, almacenamiento WORM inmutable, simulacros de restauración reales cada tres meses y objetivos explícitos de RPO y RTO: eso es lo único que importa el día malo.
Una restauración sin probar no es una copia de seguridad, es una esperanza. No vendemos esperanza: entregamos tiempos de recuperación medibles e informes de restauración comprobados.
Cuando el sistema primario falla, el secundario toma el relevo automáticamente: comprobado en simulacros reales.
Primera verdad incómoda: la gran mayoría de las copias de seguridad nunca se prueban. El cron se ejecuta cada noche, el registro dice “OK”, el panel de supervisión está en verde, pero cuando intenta restaurar esa copia descubre que los archivos están dañados, falta la clave de descifrado o la versión del esquema es incompatible. Una copia no es una copia hasta que se ha restaurado: hasta entonces es solo una esperanza. Con cada cliente exigimos un simulacro de restauración completa al menos cada tres meses y documentamos el resultado.
Segundo problema: mucho de lo que se llama “copia de seguridad” es en realidad una instantánea (snapshot) guardada en el propio servidor de producción. Una copia que comparte el mismo disco, que la misma cuenta puede modificar y que ardería en el mismo incendio no es una copia de seguridad, sino un segundo nombre para los mismos datos. Ante un fallo de hardware, un ataque de ransomware o una tabla eliminada por error, esa “copia” desaparece junto con los datos de producción. Una copia de seguridad real debe estar en un sistema separado, bajo una identidad separada y preferiblemente en otra ubicación geográfica.
Tercer problema: no hay copia externa. Una copia de seguridad guardada en un solo centro de datos o en una sola región de nube queda inaccesible si esa región se cae, sufre un desastre natural o la cuenta se suspende. AWS puede dejar fuera de servicio una región entera, Microsoft puede bloquear una cuenta en cuestión de horas y el incendio de un centro de datos puede durar horas: en esos escenarios, una copia externa es lo único que separa la continuidad del negocio de la quiebra. El “1” de la regla 3-2-1 no es negociable.
Cuarto problema: copias de seguridad sin cifrar. Un archivo de copia de seguridad es una réplica completa de su base de datos de producción: todos los registros de clientes, los rastros de tarjetas de crédito, los hashes de contraseñas y la correspondencia interna están dentro de un único tar.gz. Si ese archivo se roba, una brecha sigue siendo una brecha: ni el Reglamento General de Protección de Datos (RGPD) ni la KVKK, Ley turca n.º 6698 de Protección de Datos Personales, hacen una excepción por tratarse de una copia de seguridad. Todas las copias deben cifrarse tanto en reposo (AES-256) como en tránsito (TLS 1.3), con las claves guardadas en un KMS separado del propio sistema de copias; de lo contrario, la copia es una superficie de ataque, no una defensa.
Quinto problema: falta de inmutabilidad. El ransomware moderno no se limita a cifrar los datos de producción: el atacante primero entra en su sistema de copias de seguridad, elimina o invalida las copias de los últimos tres meses y solo entonces cifra la producción. Si las cuentas de copia de seguridad comparten el mismo directorio, la misma VPN y el mismo SSO que producción, el ransomware también las encontrará. La solución: almacenamiento WORM (write-once-read-many), S3 Object Lock, un Veeam Hardened Repository, una copia sin conexión aislada físicamente (air-gapped); en resumen, una capa en la que eliminar datos es matemáticamente imposible, incluso con credenciales de administrador.
Una línea de tiempo de restauración, una simulación de limpieza de ransomware y un panel comparativo de RPO y RTO: hacen que las decisiones posteriores al desastre se puedan medir de antemano.
Instantáneas cada hora + copias completas diarias + consolidación semanal + archivo mensual. Punto de restauración seleccionable con precisión de segundos.
Datos cifrados → restauración desde copia inmutable → datos limpios señalados con una marca verde.
Vea de un vistazo la diferencia entre “sin copia de seguridad” y nuestra arquitectura.
Una hora de pérdida de datos equivale a cientos de pedidos, miles de movimientos de stock y la conciliación de pagos descuadrada.
Restaurar toda la tabla no es una opción para recuperar los datos de un solo inquilino.
Los historiales de pacientes deben conservarse durante años de forma auditable; cualquier pérdida es una infracción de la KVKK o la HIPAA.
Los registros exigidos por BDDK, SPK y MASAK (reguladores financieros turcos) deben conservarse durante años sin borrarse ni modificarse.
Si pierde archivos de diseño, proyectos de video o repositorios de código, tendrá que llamar a sus clientes uno por uno.
Petabytes de material en bruto y contenido histórico irrepetible: hace falta una arquitectura específica.
Si se pierde la configuración de un solo controlador, la línea de producción se detiene durante horas.
Títulos, certificados de notas y registros de asistencia deben ser continuos, duraderos y auditables.
Del diseño de la estrategia al procedimiento operativo (runbook), diez capas en un solo paquete: sin omitir ninguna y sin inflar ninguna.
Análisis de impacto en el negocio, inventario de activos, matriz de RPO/RTO y objetivos contractuales.
Dispositivo físico o virtual de copia de seguridad en sus instalaciones para restauraciones más rápidas.
Replicación asíncrona o síncrona a otro centro de datos o región de nube.
Copias optimizadas en costos con políticas de ciclo de vida en S3, Blob y GCS.
S3 Object Lock, Wasabi Compliance, Veeam Hardened: la capa que no se puede borrar.
PostgreSQL WAL, MySQL binlog, MongoDB oplog, registro de transacciones de MSSQL.
VSS, fsfreeze y hooks pre/post para imágenes de disco coherentes durante la escritura.
Restauraciones periódicas en sandbox + verificación de integridad + informe.
Plan escrito paso a paso: quién hace qué, quién aprueba y quién registra.
Activación → aislamiento → análisis forense → restauración → imagen limpia según el análisis forense.
Se determina cuán crítico es cada sistema, la pérdida de datos aceptable y el tiempo de recuperación; se realiza el análisis de impacto en el negocio.
Tres copias, dos soportes, una capa externa; se documentan la inmutabilidad, el cifrado y el modelo de acceso.
Se ponen en marcha el appliance local, la cuenta en la nube, el aislamiento de red, la supervisión y las alertas.
Ciclo por hora, diario, semanal y mensual; AES-256 en reposo, TLS en tránsito y claves separadas en KMS.
Restauraciones con escenarios reales; el RPO y el RTO medidos se comparan con los objetivos contractuales y se corrigen las desviaciones.
Éxito de las copias, tendencia de almacenamiento y tiempo de restauración en paneles; informe mensual + revisión anual de la arquitectura.
No vendemos ninguna herramienta por sí sola. Diseñamos su arquitectura, explicamos qué herramienta corresponde a cada capa y mostramos el costo total de propiedad con transparencia.
Una tienda con 250 000 SKU fue cifrada un viernes a las 03:14; la producción completa se restauró en 38 minutos desde la copia inmutable de Wasabi, sin perder ningún pedido.
Un desarrollador eliminó una tabla en producción; PostgreSQL PITR logró una restauración totalmente coherente en 4 minutos.
Un hospital superó su auditoría de PHI de 7 años; la integridad de los registros en el archivo inmutable quedó demostrada matemáticamente.
Robaron el equipo portátil de un diseñador sénior; los 2 TB de entregables para clientes se copiaban cada hora a una ubicación externa con Restic.
El archivo de material en bruto de una emisora pasó a almacenamiento por niveles; S3 activo + Glacier Deep Archive generaron un ahorro anual del 63 %.
Interrupción de AWS eu-central-1; failover automático de DNS + base de datos a eu-west-1 en 11 minutos, sin corte del tráfico de clientes.
No, una instantánea por sí sola no es una copia de seguridad. Una instantánea es una “fotografía” de un disco o volumen en un momento dado, y la gran mayoría se guarda en el mismo sistema de almacenamiento que los datos de producción, a menudo en el mismo disco. Por eso, cuando se pierden los datos de producción, la instantánea se pierde con ellos. Un fallo de hardware, la caída del sistema de almacenamiento, el ransomware o un error de administración también afectan a la instantánea. Las instantáneas son una excelente primera capa para restauraciones muy rápidas (puede volver en cuestión de segundos), pero para tener una copia de seguridad real hay que copiarlas a un sistema separado, bajo una identidad separada y preferiblemente en otra ubicación geográfica. En nuestra arquitectura, la instantánea siempre es un escalón: después vienen la copia externa, el archivo inmutable y la réplica de recuperación ante desastres.
La regla 3-2-1 es la estrategia mínima de copias de seguridad probada en el sector desde hace años: tres (3) copias de los datos, en dos (2) tipos de soporte distintos y con una (1) copia externa. Una de las tres copias es la propia producción y dos son copias de seguridad, de modo que, si una se daña, queda la otra. Dos tipos de soporte protegen frente a un fallo sistémico de una sola tecnología (por ejemplo, que todos los SSD fallen por un error de firmware): disco + cinta, disco + almacenamiento de objetos, NAS + nube. La copia externa protege frente a incendios, inundaciones, robos, interrupciones regionales o la suspensión de la cuenta; una copia en el mismo edificio, o incluso en la misma ciudad, no cuenta como externa. La extensión moderna es “3-2-1-1-0”: una copia debe ser inmutable (1) y las pruebas de restauración deben arrojar cero (0) errores.
Solo si están bien diseñadas. El ransomware moderno permanece semanas en la red antes de cifrar la producción: descubre el sistema de copias de seguridad, elimina o invalida las copias existentes y luego cifra la producción, de modo que no queda nada que restaurar. Por eso, las cuentas de copia de seguridad deben ser independientes del directorio de producción, del SSO de producción e incluso de la red de producción. La solución es el almacenamiento WORM (write-once-read-many): S3 Object Lock en modo Compliance, Wasabi Compliance, Veeam Hardened Repository y cinta aislada físicamente (air-gapped). En estas capas, eliminar datos es matemáticamente imposible incluso con permisos de administrador: los datos quedan “congelados” durante todo el periodo de retención. En nuestra arquitectura, cada cliente tiene al menos una capa WORM y el playbook de recuperación ante ransomware se valida con simulacros.
Recomendamos hacerlo al menos cada tres meses, una vez al mes en sistemas críticos y con pruebas automáticas semanales en entornos regulados. La restauración de prueba es la única evidencia de que su arquitectura de copias de seguridad funciona de verdad: que el registro diga “OK” no basta. Un simulacro completo incluye restaurar en un sandbox aislado, poner en marcha la aplicación, verificar la integridad de la base de datos y las sumas de comprobación, y comparar el RPO y el RTO medidos con los objetivos contractuales. Las pruebas automatizadas, por su parte, crean una copia virtual con “instant recovery” después de cada copia de seguridad, ejecutan análisis inteligentes e informan del resultado. Con cada cliente realizamos tanto verificaciones automáticas semanales como simulacros manuales trimestrales; los resultados se guardan en un informe firmado, útil para auditorías, seguros y renovaciones de contrato.
Si está bien diseñada, no; si está mal diseñada, puede resultar muy cara. El costo tiene tres ejes principales: almacenamiento (por GB al mes), egress (descarga durante la restauración) y llamadas a la API (cobro por cada operación de archivo). El enfoque ingenuo de “subir todo completo a S3 cada día” puede costar decenas de miles de dólares estadounidenses al año. El enfoque correcto es por niveles: los últimos 14 días, de uso frecuente, en S3 Standard; los últimos 90 días en S3 Standard-IA; el último año en S3 Glacier Instant y lo más antiguo en Glacier Deep Archive. Para los mismos datos, el costo varía entre 10 y 20 veces. Si se suman políticas de ciclo de vida, compresión, deduplicación y una estrategia incremental permanente (incremental forever), el costo típico de nuestros clientes en la nube ronda unos pocos cientos de dólares al mes. Conocer sus escenarios de restauración es la clave para dimensionar bien: Glacier Deep puede ser ideal para quien restaura una vez al mes, pero resulta ruinoso para quien restaura 5 veces al día.
El RPO (Recovery Point Objective) responde a “¿cuánta pérdida de datos podemos aceptar?” y el RTO (Recovery Time Objective), a “¿en cuánto tiempo debemos volver a funcionar?”. Ambas cifras salen del análisis de impacto en el negocio: si ese sistema se detiene una hora o se pierde un día de datos, ¿cuál es el costo real en ingresos, clientes y cumplimiento normativo? En e-commerce, los ingresos por hora suelen llevar el RTO a minutos: para un sistema que recibe pedidos, un RTO de 1 hora es demasiado largo. Para un CRM de uso interno, un RTO de 8 horas puede ser razonable. En cuanto al RPO: ¿cuántos minutos de actividad del negocio puede permitirse perder? Las instantáneas cada hora sitúan el RPO en 60 minutos; la replicación del registro de transacciones lo reduce a segundos. Estos objetivos se fijan por contrato y se demuestran midiéndolos en cada simulacro: no son cifras arbitrarias, sino decisiones de negocio.
Sí, nuestra arquitectura cumple plenamente con el RGPD, la KVKK, ISO 27001 Anexo A.12.3, SOC 2 CC9 y PCI-DSS 9.5/12.10. Esto significa que todas las copias de seguridad se cifran en reposo (AES-256) y en tránsito (TLS 1.3); las claves se guardan en un KMS (AWS KMS, Azure Key Vault, HSM) con autorización independiente del sistema de copias de seguridad; los plazos de conservación coinciden con los requisitos legales y, una vez superados, se realiza una eliminación demostrable; existe un procedimiento de búsqueda en las copias y anonimización selectiva para las solicitudes de “derecho al olvido”; la ubicación de los datos (Turquía/UE) se puede elegir, y todos los accesos, restauraciones y cambios de configuración quedan en un registro de auditoría inmutable. El paquete de preparación para auditorías incluye diagramas de arquitectura, documentos de políticas, la matriz RACI y los últimos informes de simulacros: la respuesta a cualquier pregunta del auditor ya está lista.
Sí, podemos hacernos cargo de su instalación actual de Veeam (o Rubrik, Cohesity, Commvault, Acronis) tal como está: su licencia no cambia y el equipamiento sigue siendo el mismo. En la primera semana realizamos una auditoría completa: tasa de éxito de las copias, fecha de la última restauración, políticas de retención, estado de inmutabilidad, modelo de acceso, gestión de claves, supervisión y alertas. Documentamos todo e informamos los riesgos en rojo, amarillo y verde. En los 30 días siguientes se revisa la arquitectura y, si es necesario, se agregan nuevas capas en modo puente (lo antiguo y lo nuevo en paralelo); no se migran datos, sino que se agregan nuevos destinos de copia. Al final del tercer mes se realiza un simulacro de restauración completa y se fija la línea base. Contamos con ingenieros certificados en Veeam VMCE y Rubrik RCSA; no necesita cambiar de proveedor: aportamos la configuración correcta y la disciplina operativa.
En una llamada gratuita de 30 minutos revisamos juntos el estado actual de sus copias de seguridad: objetivos de RPO y RTO, carencias de inmutabilidad, fecha de la última restauración de prueba y pasos concretos para los próximos 90 días, todo entregado en un informe escrito.
