La empresa cree que est\u00e1 respaldada. Hay un disco externo en un caj\u00f3n, una carpeta compartida con \u201ccopia\u201d en el nombre y, a veces, una captura de pantalla vieja que muestra un backup \u201cexitoso\u201d. El d\u00eda del incidente \u2014un ransomware, un borrado accidental, un servidor que no vuelve\u2014 descubren otra cosa: la copia no restaura, est\u00e1 incompleta o nunca se prob\u00f3.<\/p>\n
Esa distancia entre \u201ctenemos backup\u201d y \u201cpodemos recuperar el negocio\u201d es m\u00e1s com\u00fan de lo que parece. El respaldo deja de ser un archivo t\u00e9cnico y se vuelve continuidad: facturaci\u00f3n, stock, correo, contratos y la capacidad de atender clientes al d\u00eda siguiente.<\/p>\n
Sin embargo, muchas pymes todav\u00eda dise\u00f1an el respaldo por costumbre: copiar lo visible, guardar cerca y asumir que \u201calg\u00fan d\u00eda\u201d se va a necesitar. Ese enfoque suele fallar justo cuando m\u00e1s importa.<\/p>\n
Tambi\u00e9n conviene mirarlo con calma. Un buen esquema de backups no exige paranoia ni un presupuesto de gran corporaci\u00f3n. Exige inventario, frecuencia alineada al negocio, una copia fuera del alcance del incidente y pruebas reales de restauraci\u00f3n.<\/p>\n
En esta nota repasamos qu\u00e9 es un backup \u00fatil, qu\u00e9 conviene guardar, c\u00f3mo pensar RPO y RTO en lenguaje simple, la regla 3-2-1, opciones onsite\/offsite\/cloud\/offline, retenci\u00f3n, cifrado, pruebas de restore, errores frecuentes y escenarios locales. Al final, una checklist para ordenar el plan.<\/p>\n
Un backup \u00fatil es una copia recuperable de la informaci\u00f3n que la empresa necesita para operar, tomada con una frecuencia definida, almacenada de forma que un solo incidente no la destruya junto con el original, y verificada con restauraciones de prueba.<\/p>\n
No alcanza con \u201ctener archivos en otro lado\u201d. Una carpeta sincronizada en la misma cuenta comprometida, un disco conectado todo el d\u00eda al mismo equipo o un export olvidado de hace ocho meses pueden generar falsa seguridad.<\/p>\n
Un respaldo s\u00f3lido suele cumplir al menos esto:<\/p>\n
CISA, en su gu\u00eda para peque\u00f1as y medianas empresas sobre respaldar datos de negocio<\/a>, insiste en inventariar lo cr\u00edtico, aplicar la regla 3-2-1 y probar las restauraciones. Eso es m\u00e1s \u00fatil que acumular terabytes sin criterio.<\/p>\n Antes de elegir software o nube, hace falta listar qu\u00e9 perder\u00eda la empresa si ma\u00f1ana no pudiera abrir sus sistemas. El inventario no es un excel infinito: es un mapa de lo que sostiene la operaci\u00f3n.<\/p>\n Incluye propuestas, contratos, planos, carpetas de clientes, documentaci\u00f3n contable digitalizada y archivos de proyectos. Si viven en notebooks dispersos, el riesgo crece: el \u201cbackup\u201d de un solo puesto no cubre al equipo.<\/p>\n ERP, CRM, stock, facturaci\u00f3n y cualquier base que alimente reportes. Aqu\u00ed no alcanza con copiar una carpeta a ojo: hace falta un m\u00e9todo coherente con el motor (dump consistente, snapshot coordinado, backup de aplicaci\u00f3n).<\/p>\n Muchas empresas todav\u00eda subestiman el correo como activo. Cotizaciones, hilos con proveedores y aprobaciones viven ah\u00ed. Si el correo es Microsoft 365, Google Workspace u otro servicio, conviene entender qu\u00e9 retienen ellos y qu\u00e9 hay que exportar o archivar aparte.<\/p>\n Sitio institucional, e-commerce, staging y configuraciones del hosting. Una tienda sin backup reciente puede perder cat\u00e1logo, pedidos o personalizaciones en el peor momento de una campa\u00f1a.<\/p>\n Reglas de firewall, DNS, scripts de integraci\u00f3n, conectores entre sistemas y \u201cesa automatizaci\u00f3n que nadie toca\u201d. Restaurar datos sin la configuraci\u00f3n que los hace \u00fatiles puede dejar la empresa a medias.<\/p>\n Contrase\u00f1as de servicio, tokens y certificados no deber\u00edan vivir en un Word compartido. Un gestor o vault con su propio esquema de respaldo y acceso controlado suele ser m\u00e1s seguro que incluir secretos en el mismo paquete que el resto de archivos.<\/p>\n Una lista inicial razonable para muchas pymes:<\/p>\n RPO (Recovery Point Objective) responde: \u00bfcu\u00e1nta informaci\u00f3n reciente podemos darnos el lujo de perder? Si el backup es diario a las 23:00 y el incidente ocurre a las 18:00, en el peor caso se pierde casi un d\u00eda de carga.<\/p>\n RTO (Recovery Time Objective) responde: \u00bfen cu\u00e1nto tiempo necesitamos volver a operar? No es lo mismo restaurar un archivo suelto que reconstruir un servidor de facturaci\u00f3n un lunes a la ma\u00f1ana.<\/p>\n Para aterrizarlos sin jerga:<\/p>\n NIST, en SP 800-34 Rev. 1<\/a> sobre planificaci\u00f3n de contingencia, enmarca backups y recuperaci\u00f3n dentro de un plan m\u00e1s amplio: entender impactos, roles y procedimientos. No hace falta adoptar el documento entero; s\u00ed conviene usar la l\u00f3gica de \u201cqu\u00e9 tan grave es no tener X disponible\u201d.<\/p>\n La regla 3-2-1 se resume as\u00ed: tres copias de los datos (producci\u00f3n + dos respaldos), en dos tipos de medio distintos, con al menos una copia fuera del sitio (offsite).<\/p>\n CISA la explica con claridad en su material de opciones de backup de datos<\/a>: no poner todas las copias en el mismo lugar f\u00edsico ni en el mismo tipo de almacenamiento vulnerable al mismo fallo.<\/p>\n En la pr\u00e1ctica para una pyme:<\/p>\n La versi\u00f3n moderna suele sumar una idea extra: que al menos una copia sea offline o inmutable el tiempo suficiente para sobrevivir a un ransomware que intente cifrar o borrar tambi\u00e9n los respaldos conectados.<\/p>\n Seg\u00fan la p\u00e1gina de CISA citada m\u00e1s arriba, el informe DBIR 2025 de Verizon indica que el ransomware estuvo presente en el 44% de las brechas investigadas. Eso no significa que \u201ca todas las pymes les va a pasar\u201d, pero s\u00ed que dise\u00f1ar backups asumiendo solo fallas de disco es quedarse corto.<\/p>\n \u00datil para recuperar r\u00e1pido un archivo borrado o un servidor ca\u00eddo. El l\u00edmite: un incendio, un robo, un corte prolongado o malware en la red local pueden alcanzar tambi\u00e9n esa copia.<\/p>\n Puede ser otro edificio, otra ciudad o un proveedor externo. Sirve cuando el problema es f\u00edsico o cuando la oficina entera queda fuera de juego.<\/p>\n Facilita offsite, versionado y acceso remoto. Conviene revisar: cifrado, retenci\u00f3n, costos de salida (restore grande), identidad (qui\u00e9n puede borrar) y si la cuenta de backup est\u00e1 separada de la cuenta de producci\u00f3n.<\/p>\n Cinta, disco desconectado, snapshot con retenci\u00f3n inmutable o \u201cobject lock\u201d. El objetivo es que un atacante con credenciales del d\u00eda a d\u00eda no pueda destruir todas las copias en minutos.<\/p>\n Una comparaci\u00f3n simple:<\/p>\nInventario: qu\u00e9 conviene guardar<\/h2>\n
Datos de negocio y archivos de trabajo<\/h3>\n
Bases de datos y sistemas de gesti\u00f3n<\/h3>\n
Correo y comunicaci\u00f3n<\/h3>\n
Sitios web, tiendas y entornos<\/h3>\n
Configuraciones, automatizaciones e integraciones<\/h3>\n
Credenciales y secretos (con cuidado)<\/h3>\n
\n
RPO y RTO en lenguaje de negocio<\/h2>\n
\n
La regla 3-2-1 (y por qu\u00e9 sigue vigente)<\/h2>\n
\n
Onsite, offsite, cloud y offline: para qu\u00e9 sirve cada uno<\/h2>\n
Onsite (cerca, r\u00e1pido)<\/h3>\n
Offsite (lejos del incidente local)<\/h3>\n
Cloud \/ respaldo en la nube<\/h3>\n
Offline o inmutable<\/h3>\n