# ¿Tu copia de seguridad restaura? Solo una prueba lo dice > Tener copia de seguridad no prueba que te recuperes. La prueba de restauración mide cuántos datos pierdes, cuánto tiempo paras y en qué orden vuelve todo. - Autor: Marlon Trettin - Publicado: 2026-10-23 · Actualizado: 2026-10-23 - Idioma: es - Canonical: https://yowpi.com/es/blog/prueba-de-restauracion-de-copias-de-seguridad --- Una copia de seguridad es una copia. La recuperación es una capacidad, y solo existe después de probada. Mientras nadie haya restaurado la copia en un entorno limpio, cronometrado el proceso y comprobado el resultado, tu empresa tiene una suposición, no un plan. La prueba de restauración convierte una cosa en la otra. ## TL;DR - La [guía #StopRansomware de la CISA](https://www.cisa.gov/stopransomware/ransomware-guide) recomienda copias sin conexión y cifradas, con pruebas regulares de disponibilidad e integridad. El [NIST](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf) pide probar las copias para comprobar que los archivos vuelven sin errores ni pérdidas. - Un mensaje de "copia completada" prueba que se escribió una copia. No prueba que esté completa, que se pueda leer ni que sirva a quienes operan el negocio. - La prueba responde a tres preguntas de negocio: cuántos datos pierdes, cuánto tiempo queda parada la operación y en qué orden vuelven los sistemas. - Las respuestas dependen de decisiones de arquitectura tomadas antes del incidente, no de la herramienta que hace la copia. ## ¿Por qué tener copia de seguridad no es lo mismo que saber recuperar? Porque la copia prueba una sola cosa: que se escribió un archivo en algún lugar. No prueba que el archivo se abra, que esté completo, que contenga todo lo que la operación necesita ni que alguien sepa qué hacer con él a las tres de la tarde de un martes con el sistema caído. Los modos de fallo son corrientes. La tarea dejó de ejecutarse y nadie recibió aviso. La copia estaba en el mismo servidor que cayó. La clave de cifrado la tenía alguien que ya dejó la empresa. El panel que muestra "copia completada" no ve ninguno de ellos, porque mide si la copia se hizo, no si funciona. La copia en sí es infraestructura y tiene buenos manuales. Lo que cambia el resultado es la decisión que viene antes: qué debe estar en la copia, cuánto tiempo puede esperar la empresa y quién comprueba que el resultado es correcto. ## ¿Qué piden las normas además de la copia? Piden evidencia. La guía de la CISA recomienda mantener copias sin conexión y cifradas, y probar con regularidad su disponibilidad e integridad en un escenario de recuperación ante desastres. El motivo que da es que muchas variantes de ransomware buscan copias accesibles para borrarlas o cifrarlas. La guía de planificación de contingencia del NIST (SP 800-34) separa tres actividades: pruebas, formación y ejercicios. La prueba valida la capacidad de recuperación. El ejercicio deja al descubierto las lagunas del plan. El documento trata además la verificación de los soportes de copia como rutina, para que los archivos se recuperen sin errores ni pérdida de datos. Ninguno de los dos textos nombra una herramienta. Los dos exigen que alguien haya restaurado de verdad. Una consecuencia práctica: una política que dice "hacemos copias" no es evidencia, y tampoco lo es el informe de un proveedor que dice que la tarea terminó bien. La evidencia es una restauración que alguien cronometró y comprobó. ## ¿Qué señales parecen prueba y no lo son? Hay tres habituales. La primera es el mensaje de éxito, que confirma que la tarea se ejecutó. La segunda es la política escrita, que confirma la intención. La tercera es la confianza del equipo, sincera pero sin probar. Cada una es útil y ninguna sustituye a la restauración. La confianza merece un aviso aparte. Quienes configuraron la copia son quienes menos probabilidades tienen de encontrar sus lagunas, porque saben lo que pretendían incluir. Una restauración hecha por alguien que necesita el resultado, como la persona que cierra el mes o la que asigna las cuadrillas, encuentra las lagunas antes. ## ¿Qué decisiones obliga a tomar una prueba de restauración? Tres, y ninguna es técnica. La primera es qué sistema es la fuente de la verdad de cada dato. Si los precios viven en una hoja de cálculo, los clientes en el ERP y el estado de los pedidos en un hilo de chat, la copia del ERP restaura un tercio de la operación. La prueba muestra lo que quedó fuera porque nadie había decidido dónde vive ese dato. Mientras el dato crítico no tenga un lugar definido, ninguna rutina de copia lo alcanza. La segunda es cuántos datos y cuánto tiempo puede permitirse perder la operación. La literatura de contingencia llama a estos límites objetivo de punto de recuperación (RPO) y objetivo de tiempo de recuperación (RTO). Dicho en llano: hasta qué hora del día deben volver los registros y en cuántas horas debe estar en pie el sistema. Responde el dueño de la operación, no el proveedor de infraestructura. La tercera es el orden de retorno. La facturación depende del maestro de clientes, que depende de la base de datos, que depende de un acceso que solo tiene una persona. Sin ensayo, esa cadena aparece en mitad del incidente. En Colo Saúde, Yowpi empezó por una [auditoría](/es/cases/colo-saude) porque nadie sabía decir cuál era el estado real de seguridad de la plataforma. El patrón es el mismo: lo que no se verificó no tiene dueño, y lo que no tiene dueño aparece en el peor momento. ## ¿Cómo se ve esto en una pyme? Imagina, como hipótesis, una empresa de mantenimiento industrial de 40 personas. El ERP guarda las órdenes de trabajo. El calendario de las cuadrillas está en una hoja de cálculo que mantiene el coordinador en su portátil. La copia del ERP se ejecuta a las dos de la madrugada y el panel muestra éxito todos los días. Un martes a las tres de la tarde, falla el servidor del ERP. Las cifras que siguen son ilustrativas, no una medición. La copia más reciente tiene 13 horas, así que desaparecen las órdenes abiertas o cerradas desde la madrugada. La restauración, que todos esperaban de una hora, tarda seis porque nadie conoce la contraseña de la base de datos. Y el calendario de las cuadrillas nunca estuvo en la copia, de modo que organizar el día siguiente se convierte en una llamada a cada técnico. Nada de esto es un fallo de tecnología. La copia hizo exactamente lo que se configuró. Faltaron tres decisiones que la prueba habría forzado: si la hoja de cálculo entra en el alcance o deja de existir, si un hueco de 13 horas es aceptable y si la contraseña de la base de datos tiene más de un responsable. La [inspección mensual de sistemas internos](/es/blog/checklist-de-inspeccion-mensual-de-sistemas-internos) ya pide una restauración reciente. La prueba de restauración muestra lo que esa restauración revela. ## ¿Cómo hacer una primera prueba sin parar la operación? Elige un sistema, preferiblemente aquel cuya parada detiene la facturación. Restaura la copia más reciente en un entorno separado, nunca encima de producción, y cronometra de principio a fin, incluido el tiempo de encontrar contraseñas y claves. Pide a quienes operan el sistema que revisen algunos registros recientes y un informe ya cerrado. La pregunta es sencilla: ¿esto está bien? Anota tres cosas: cuánto tardó, qué antigüedad tenía el dato más reciente que volvió y qué faltaba. Nombra un responsable y fija la fecha de la próxima prueba. El primer resultado puede resultar incómodo, y para eso sirve. ## Preguntas frecuentes **No tenemos especialista en TI. ¿Podemos probar igualmente?** Sí. La parte técnica puede quedar en manos de quien mantiene el sistema, sea interno o externo. Lo que la empresa no puede delegar es la definición de "correcto": solo quien conoce la operación sabe decir si el informe restaurado coincide con la realidad. La primera prueba exige más conocimiento del negocio que de infraestructura. **¿Vale la pena si nunca hemos tenido un incidente?** Sin un incidente previo, la empresa no tiene forma de saber el tamaño de la pérdida que afrontaría. La prueba es la manera de averiguarlo sin esperar al incidente. Cuesta unas horas de alguien que conoce la operación y un entorno separado para restaurar. Si evitar la sorpresa compensa ese coste es decisión tuya, y la prueba es lo que aporta los números para decidirlo. **Nuestros datos están repartidos en varios sistemas y hojas de cálculo. ¿Por dónde empezamos?** Por el sistema cuya parada detiene la facturación. La prueba sacará a la luz dependencias que estaban fuera del mapa, y ese mapa ya es la primera ganancia. Después, repite con el siguiente de la lista. Si el mapa revela que datos críticos viven en lugares que ninguna rutina alcanza, la conversación deja de ser sobre copias y pasa a ser sobre dónde debería vivir cada dato. ## El siguiente paso Si la prueba muestra que tu operación depende de datos que ningún sistema controla, el Diagnóstico de Arquitectura Operacional, una conversación de 30 minutos, es el lugar para mapearlo: [habla con Yowpi](/es/contacto).