Backups empresariales: qué guardar, cada cuánto y dónde

La empresa cree que está respaldada. Hay un disco externo en un cajón, una carpeta compartida con “copia” en el nombre y, a veces, una captura de pantalla vieja que muestra un backup “exitoso”. El día del incidente —un ransomware, un borrado accidental, un servidor que no vuelve— descubren otra cosa: la copia no restaura, está incompleta o nunca se probó.

Esa distancia entre “tenemos backup” y “podemos recuperar el negocio” es más común de lo que parece. El respaldo deja de ser un archivo técnico y se vuelve continuidad: facturación, stock, correo, contratos y la capacidad de atender clientes al día siguiente.

Sin embargo, muchas pymes todavía diseñan el respaldo por costumbre: copiar lo visible, guardar cerca y asumir que “algún día” se va a necesitar. Ese enfoque suele fallar justo cuando más importa.

También conviene mirarlo con calma. Un buen esquema de backups no exige paranoia ni un presupuesto de gran corporación. Exige inventario, frecuencia alineada al negocio, una copia fuera del alcance del incidente y pruebas reales de restauración.

En esta nota repasamos qué es un backup útil, qué conviene guardar, cómo pensar RPO y RTO en lenguaje simple, la regla 3-2-1, opciones onsite/offsite/cloud/offline, retención, cifrado, pruebas de restore, errores frecuentes y escenarios locales. Al final, una checklist para ordenar el plan.

Qué es un backup útil (y qué no lo es)

Un backup útil es una copia recuperable de la información 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.

No alcanza con “tener archivos en otro lado”. Una carpeta sincronizada en la misma cuenta comprometida, un disco conectado todo el día al mismo equipo o un export olvidado de hace ocho meses pueden generar falsa seguridad.

Un respaldo sólido suele cumplir al menos esto:

Se sabe qué incluye y qué queda afuera.
Tiene dueño y calendario (no depende de “cuando alguien se acuerde”).
Está protegido de borrados masivos, ransomware y errores humanos.
Se puede restaurar en un tiempo aceptable para el negocio.
Se documenta lo suficiente para que no dependa de una sola persona.

CISA, en su guía para pequeñas y medianas empresas sobre respaldar datos de negocio, insiste en inventariar lo crítico, aplicar la regla 3-2-1 y probar las restauraciones. Eso es más útil que acumular terabytes sin criterio.

Inventario: qué conviene guardar

Antes de elegir software o nube, hace falta listar qué perdería la empresa si mañana no pudiera abrir sus sistemas. El inventario no es un excel infinito: es un mapa de lo que sostiene la operación.

Datos de negocio y archivos de trabajo

Incluye propuestas, contratos, planos, carpetas de clientes, documentación contable digitalizada y archivos de proyectos. Si viven en notebooks dispersos, el riesgo crece: el “backup” de un solo puesto no cubre al equipo.

Bases de datos y sistemas de gestión

ERP, CRM, stock, facturación y cualquier base que alimente reportes. Aquí no alcanza con copiar una carpeta a ojo: hace falta un método coherente con el motor (dump consistente, snapshot coordinado, backup de aplicación).

Correo y comunicación

Muchas empresas todavía subestiman el correo como activo. Cotizaciones, hilos con proveedores y aprobaciones viven ahí. Si el correo es Microsoft 365, Google Workspace u otro servicio, conviene entender qué retienen ellos y qué hay que exportar o archivar aparte.

Sitios web, tiendas y entornos

Sitio institucional, e-commerce, staging y configuraciones del hosting. Una tienda sin backup reciente puede perder catálogo, pedidos o personalizaciones en el peor momento de una campaña.

Configuraciones, automatizaciones e integraciones

Reglas de firewall, DNS, scripts de integración, conectores entre sistemas y “esa automatización que nadie toca”. Restaurar datos sin la configuración que los hace útiles puede dejar la empresa a medias.

Credenciales y secretos (con cuidado)

Contraseñas de servicio, tokens y certificados no deberían vivir en un Word compartido. Un gestor o vault con su propio esquema de respaldo y acceso controlado suele ser más seguro que incluir secretos en el mismo paquete que el resto de archivos.

Una lista inicial razonable para muchas pymes:

Carpetas compartidas y repositorios de documentos.
Bases de ERP/CRM y exportaciones contables.
Buzones o archivo de correo crítico.
Sitio web / tienda y base asociada.
Configuración de servidores o panel de hosting.
Inventario de integraciones (qué habla con qué).
Copias cifradas o procedimientos del vault de credenciales.
Plantillas, diseños y activos de marca que cuestan reproducir.

RPO y RTO en lenguaje de negocio

RPO (Recovery Point Objective) responde: ¿cuánta información 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ía de carga.

RTO (Recovery Time Objective) responde: ¿en cuánto tiempo necesitamos volver a operar? No es lo mismo restaurar un archivo suelto que reconstruir un servidor de facturación un lunes a la mañana.

Para aterrizarlos sin jerga:

Si facturan todo el día y no pueden rehacer pedidos a mano, el RPO suele pedirse en horas, no en semanas.
Si el sitio es vitrina y el canal real es WhatsApp, el RTO del sitio puede ser más flexible que el del correo o del stock.
Si hay obligaciones legales o de clientes sobre retención, el diseño del backup también hereda esas restricciones.

NIST, en SP 800-34 Rev. 1 sobre planificación de contingencia, enmarca backups y recuperación dentro de un plan más amplio: entender impactos, roles y procedimientos. No hace falta adoptar el documento entero; sí conviene usar la lógica de “qué tan grave es no tener X disponible”.

La regla 3-2-1 (y por qué sigue vigente)

La regla 3-2-1 se resume así: tres copias de los datos (producción + dos respaldos), en dos tipos de medio distintos, con al menos una copia fuera del sitio (offsite).

CISA la explica con claridad en su material de opciones de backup de datos: no poner todas las copias en el mismo lugar físico ni en el mismo tipo de almacenamiento vulnerable al mismo fallo.

En la práctica para una pyme:

Copia 1: el sistema en uso.
Copia 2: backup local rápido (NAS, disco, snapshot del proveedor) para restaurar con agilidad.
Copia 3: backup offsite o en otra nube/cuenta, idealmente con retención y controles propios.

La versión 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én los respaldos conectados.

Según la página de CISA citada más arriba, el informe DBIR 2025 de Verizon indica que el ransomware estuvo presente en el 44% de las brechas investigadas. Eso no significa que “a todas las pymes les va a pasar”, pero sí que diseñar backups asumiendo solo fallas de disco es quedarse corto.

Onsite, offsite, cloud y offline: para qué sirve cada uno

Onsite (cerca, rápido)

Útil para recuperar rápido un archivo borrado o un servidor caído. El límite: un incendio, un robo, un corte prolongado o malware en la red local pueden alcanzar también esa copia.

Offsite (lejos del incidente local)

Puede ser otro edificio, otra ciudad o un proveedor externo. Sirve cuando el problema es físico o cuando la oficina entera queda fuera de juego.

Cloud / respaldo en la nube

Facilita offsite, versionado y acceso remoto. Conviene revisar: cifrado, retención, costos de salida (restore grande), identidad (quién puede borrar) y si la cuenta de backup está separada de la cuenta de producción.

Offline o inmutable

Cinta, disco desconectado, snapshot con retención inmutable o “object lock”. El objetivo es que un atacante con credenciales del día a día no pueda destruir todas las copias en minutos.

Una comparación simple:

Enfoque	Fortaleza principal	Riesgo típico si se usa solo
Recuperación local rápida	Baja latencia al restaurar	Incidente físico o lateral en la misma red
Offsite / otra ubicación	Sobrevive a problemas del sitio	Demora o costo si no se planifica el restore
Nube gestionada	Operación y versionado más simples	Cuenta mal protegida o retención insuficiente
Offline / inmutable	Mejor frente a ransomware destructivo	Más disciplina operativa y pruebas

El diseño sano combina velocidades: algo cerca para el día a día y algo fuera/inmutable para el peor día.

Cada cuánto respaldar: frecuencia por tipo de dato

La frecuencia no es un número mágico único. Depende de cuánto cambia el dato y de cuánto duele rehacerlo.

Orientación práctica:

Bases de facturación, pedidos y stock: varias veces al día o continuo, según volumen.
Archivos de trabajo compartidos: diario, como piso; más seguido si hay picos de proyecto.
Correo: según el proveedor y la criticidad; muchas empresas suman archivo o retención propia para lo histórico.
Sitio web / tienda: antes de cada cambio relevante y con backup periódico automático.
Configuraciones e integraciones: cada vez que se modifican, más un respaldo periódico del estado conocido bueno.
Notebooks individuales: si aún guardan información crítica local, el plan debería migrar eso a un lugar respaldado; si no, el riesgo queda personalizado por puesto.

Preguntas para fijar la frecuencia

Antes de clavar un número en el calendario:

¿Cuántas horas de carga manual toleramos rehacer?
¿Hay picos (cierres contables, campañas, liquidaciones) donde el RPO debe apretarse?
¿El backup es consistente (un instante coherente) o solo una copia parcial a mitad de proceso?

Un backup frecuente mal hecho puede ser peor que uno diario bien hecho: ocupa espacio, da sensación de control y igual no restaura limpio.

Retención: cuánto tiempo guardar versiones

Retención es la historia: no solo “la última copia”, sino cuántas versiones hacia atrás existen. Sirve para recuperar un archivo corrupto descubierto tarde o un error de carga que nadie vio el mismo día.

Esquemas habituales en pymes:

Diarios por 7–14 días.
Semanales por 1–3 meses.
Mensuales por 6–12 meses (o más, si hay obligación o estacionalidad fuerte).

No hay una sola respuesta correcta. Sí hay una mala: guardar una sola copia que se sobrescribe todas las noches. Un ransomware silencioso o un borrado que se detecta a la semana pueden haber contaminado también “el backup de ayer”.

En Argentina, el marco de protección de datos personales incluye deberes de seguridad. La Ley 25.326, artículo 9, establece que el responsable debe adoptar medidas técnicas y organizativas para garantizar seguridad y confidencialidad, y evitar adulteraciones, pérdidas o accesos no autorizados. La Resolución 47/2018 de la AAIP detalla medidas de seguridad que contemplan, entre otras, aspectos de respaldo y recuperación. Eso no reemplaza un diseño técnico, pero deja claro que “no tener cómo recuperar” también es un problema de cumplimiento y de responsabilidad hacia titulares de datos.

Cifrado, acceso y separación de privilegios

Un backup sin control de acceso es una copia extra lista para filtrarse. Un backup cifrado con la única clave guardada en el mismo servidor comprometido tampoco ayuda.

Buenas prácticas sobrias:

Cifrar respaldos en tránsito y en reposo cuando salen del perímetro confiable.
Separar la cuenta o rol que administra backups de las cuentas cotidianas de oficina.
Evitar que el mismo usuario “ Dominguez-admin ” pueda borrar producción y todas las retenciones.
Documentar quién puede pedir un restore y cómo se registra.
Proteger el repositorio offsite con MFA y alertas de borrado masivo, si el proveedor lo permite.

La pregunta útil no es solo “¿está cifrado?”. Es “si mañana alguien tiene la laptop del administrador, ¿puede destruir o llevarse toda la historia de backups?”.

Probar la restauración (el paso que más se saltea)

El backup que no se restauró es una hipótesis. La prueba convierte esa hipótesis en evidencia.

CISA lo marca con claridad: hay que verificar que los respaldos funcionan mediante pruebas de restore, no solo mirar un tilde verde de “job completed”.

Rutina mínima de prueba

Una rutina mínima viable:

Elegir un activo crítico (base, carpeta o sitio).
Restaurar en un entorno aislado o a una ubicación de prueba.
Comprobar que abre, que las tablas/archivos están, que las credenciales de aplicación siguen el procedimiento previsto.
Medir cuánto tardó y qué faltó.
Anotar el resultado y corregir el job o la documentación.

No hace falta restaurar toda la empresa cada semana. Sí hace falta rotar pruebas: un mes la base, otro el correo exportado, otro el sitio, otro un restore “de desastre” más completo si el negocio lo justifica.

Señales de que las pruebas están fallando en silencio

Algunas pistas típicas:

Nadie recuerda la última vez que se restauró algo de verdad.
El único que sabe hacerlo está de vacaciones.
El restore “funciona” pero tarda tres días y el RTO del negocio era de horas.
Se restaura la base y faltan archivos adjuntos, media del sitio o configuraciones.

Errores frecuentes que dejan a la empresa a oscuras

Algunos se repiten casi textuales:

Confiar solo en sincronización tipo espejo (si se borra o cifra en origen, se refleja en destino).
Dejar el disco de backup conectado permanentemente al mismo equipo.
No tener copia offsite porque “la oficina es segura”.
Sobrescribir siempre la misma copia sin historial.
Excluir sin querer la carpeta más importante por una regla mal armada.
Guardar backups dentro de la misma máquina virtual o del mismo tenant sin controles distintos.
No respaldar antes de migraciones, updates o campañas grandes.
Tener backups, pero no infraestructura ni procedimiento para levantarlos rápido.
Mezclar datos personales sensibles en destinos sin cifrado ni control de acceso.
Celebrar el tilde verde del software y nunca abrir el restore.

La lista no busca asustar. Busca acortar el camino entre “creemos que estamos bien” y “podemos demostrarlo”.

Escenarios locales: cómo se ve en la práctica

Pyme en CABA con oficina híbrida

El riesgo típico: información repartida entre un servidor chico, Drive/OneDrive y notebooks. El plan suele empezar por centralizar lo crítico, backup diario versionado + offsite, y prueba trimestral de un restore de carpeta y de una base.

E-commerce con picos de campaña

El riesgo típico: perder pedidos, stock o la tienda en Hot Sale / Cyber. Conviene backup automatizado de tienda+base, snapshot antes de cambios, retención que cubra al menos el ciclo de campaña y un ensayo de restore antes del pico — no durante.

Estudio contable o profesional con mucha documentación

El riesgo típico: archivos de clientes, obligaciones de confidencialidad y poca paciencia del calendario impositivo. Aquí pesan cifrado, control de acceso, retención más larga y un inventario claro de qué carpetas son “cliente” versus “interno”.

En los tres casos la pregunta de cierre es la misma: si el lunes a las 9 no está el sistema principal, ¿qué se restaura primero y quién lo ejecuta?

Cómo armar un plan mínimo sin eternizar el proyecto

Un orden de trabajo que suele funcionar:

Inventariar sistemas y datos críticos en una página.
Definir RPO/RTO burdos por sistema (horas/días, no perfección).
Asegurar al menos una copia offsite o inmutable.
Separar privilegios de administración de backups.
Documentar el restore en pasos que otra persona pueda seguir.
Agendar la primera prueba y la siguiente en el calendario real del equipo.
Revisar el diseño cuando aparezca un sistema nuevo, una migración o un proveedor distinto.

Si el equipo es chico, externalizar la operación (monitoreo de jobs, alertas, pruebas asistidas) puede ser más barato que descubrir el hueco en medio de un incidente. Outsourcing de operaciones no reemplaza al dueño del negocio en las decisiones de RPO/RTO; sí puede sostener la disciplina diaria.

Checklist de verificación

Antes de dar por cerrado el esquema de backups de tu empresa, revisá:

Existe un inventario escrito de qué sistemas y datos son críticos.
Sabés qué queda explícitamente fuera del backup y por qué.
Cada sistema crítico tiene un RPO y un RTO entendibles para el negocio.
Hay al menos tres copias relevantes pensando en 3-2-1 (producción + respaldos).
Hay una copia offsite o equivalente fuera del sitio principal.
Al menos una copia tiene protección offline o inmutable por un tiempo útil.
La frecuencia de backup coincide con cuánto duele rehacer el trabajo.
Hay retención con historial, no una sola copia que se pisa todas las noches.
Los jobs avisan cuando fallan y alguien mira esas alertas.
El repositorio de backup no usa la misma cuenta cotidiana del equipo.
Los respaldos sensibles viajan y reposan cifrados cuando corresponde.
Probaste un restore real en los últimos 90 días (como piso).
El procedimiento de restore lo puede ejecutar más de una persona.
Está definido el orden de recuperación (qué se levanta primero).
Hay backup antes de migraciones, updates grandes y campañas.
Notebooks no son el único hogar de información irremplazable.
Correo, web/tienda y bases están contemplados, no solo “la carpeta de documentos”.
Revisaste proveedores cloud: retención, borrado, MFA y costos de restore.
Documentaste contactos (interno/proveedor) para el día del incidente.
El plan se revisa cuando cambia el stack, no “alguna vez al año si sobra tiempo”.

Si varios ítems quedan en duda, ya tenés el alcance del próximo sprint de continuidad.

Recuperar el negocio es el verdadero objetivo

Los backups no existen para llenar discos ni para cumplir una casilla en una auditoría improvisada. Existen para que, cuando falle un equipo, un humano o un atacante, la empresa pueda volver a atender, facturar y cumplir.

La diferencia entre un tilde verde y una recuperación real se construye antes: inventario, 3-2-1, retención con historia, privilegios separados y pruebas. Ninguno de esos pasos es glamuroso. Todos son más baratos que reconstruir desde cero con clientes esperando.

No hace falta un esquema perfecto el primer mes. Hace falta un esquema honesto: saber qué se puede perder, qué se puede recuperar y en cuánto tiempo, con evidencia de que el restore funciona.

En Soup IT ayudamos a empresas a diseñar y operar esquemas de backup y continuidad: inventario de activos críticos, política 3-2-1, respaldos onsite/offsite/cloud, hardening de repositorios, pruebas de restore y acompañamiento operativo. Podemos relevar el estado actual, proponer un plan realista para pyme y convertirlo en jobs monitoreados con responsabilidades claras.

Si hoy dependen de un disco externo, de una carpeta sincronizada sin historial o de un backup que nunca se restauró, podemos revisar qué están guardando, cada cuánto y dónde, y armar un plan de recuperación concreto. Escribinos por WhatsApp o a contacto@soupit.ar.

Además, podés visitar Soup IT y seguirnos en LinkedIn e Instagram para encontrar más contenidos sobre infraestructura, continuidad, desarrollo de software, sitios web, e-commerce, automatización y tecnología aplicada a empresas.