Guía 3-2-1 de backups para empresas

¿Por qué una guía de backups?

Si te dedicas a la informática, seguro que has oído la regla del 3-2-1 cientos de veces.

Tres copias. Dos soportes. Una fuera del sitio.

Suena sencillo. De hecho, suena tan sencillo que mucha gente cree que lo tiene cubierto. Hasta que llega el desastre.

Un ransomware. Un fallo de disco. Un borrado accidental. Una actualización que rompe una base de datos. Un usuario que elimina una carpeta compartida. Un NAS que falla. Una cuenta cloud comprometida. Un incendio. Un robo. O simplemente ese backup que llevaba meses “terminando correctamente” y el día que lo necesitas no restaura.

Ahí es cuando descubres la verdad incómoda:

No tienes backup hasta que has restaurado.

Este artículo no pretende ser teoría de relleno. Es una guía práctica para entender cómo organizar copias de seguridad de forma seria, tanto en una pequeña empresa como en un entorno más grande.

No necesitas la herramienta más cara. Necesitas una estrategia que funcione, que esté aislada, que se pruebe y que no dependa de la suerte.

Nota de alcance: esta guía presenta principios generales sobre copias de seguridad y recuperación. No describe la estrategia, los procedimientos, los sistemas ni los controles de ninguna organización concreta.

---

Qué es la regla 3-2-1

La regla 3-2-1 es una de las bases clásicas de cualquier estrategia de backup:

• 3 copias de los datos.
• En al menos 2 soportes diferentes.
• Con al menos 1 copia fuera del sitio.

La idea es muy simple: no confiarlo todo a un único sistema, a una única ubicación ni a un único soporte.

Pero hay que entender bien cada punto, porque muchas empresas creen cumplir la regla y en realidad solo tienen una copia bonita en el mismo sitio donde está el problema.

3 copias

No basta con tener el dato original y una copia.

Si el original falla y la copia está corrupta, incompleta o cifrada por ransomware, te quedas sin nada.

Un ejemplo razonable:

• Copia 1: datos originales en el servidor, NAS o plataforma de producción.
• Copia 2: backup local en NAS, repositorio de backup o almacenamiento dedicado.
• Copia 3: backup externo en cloud, segunda sede o almacenamiento fuera de la oficina.

La tercera copia es la que muchas veces marca la diferencia entre una incidencia y una catástrofe.

2 soportes diferentes

Si todas tus copias están en el mismo servidor, en el mismo NAS o en la misma cabina, no estás diversificando demasiado.

La idea es usar soportes o sistemas distintos:

• Servidor + NAS.
• NAS + almacenamiento cloud.
• Disco local + repositorio inmutable.
• Cabina + cinta.
• NAS local + segunda ubicación física.

No se trata de coleccionar copias sin sentido. Se trata de evitar que un único fallo físico, lógico o humano se lleve todo por delante.

1 copia off-site

La copia fuera del sitio es la que te salva cuando el problema afecta a tu ubicación principal.

Ejemplos:

• Incendio.
• Robo.
• Inundación.
• Ransomware que afecta a toda la red.
• Fallo eléctrico grave.
• Desastre físico en la oficina.

Esa copia puede estar en la nube, en otra sede, en un centro de datos o en un soporte que se rota físicamente.

Lo importante es que no dependa del mismo edificio, de la misma red y de las mismas credenciales que el entorno de producción.

---

La evolución: 3-2-1-1-0

La regla 3-2-1 sigue siendo válida, pero hoy se queda corta si hablamos de ransomware.

Por eso muchas estrategias modernas hablan de 3-2-1-1-0:

• 3 copias de los datos.
• 2 soportes diferentes.
• 1 copia fuera del sitio.
• 1 copia offline, inmutable o aislada.
• 0 errores en las pruebas de recuperación.

Ese “1” adicional es crítico.

Porque el ransomware moderno no solo cifra servidores. También busca backups. Busca NAS. Busca repositorios accesibles por red. Busca credenciales guardadas. Busca snapshots. Busca cualquier cosa que pueda destruir tu capacidad de recuperación.

Por eso, si tus backups están siempre conectados, siempre accesibles y siempre montados desde producción, no están tan protegidos como crees.

Necesitas al menos una copia que el atacante no pueda modificar fácilmente:

• Repositorio inmutable.
• Object Lock en almacenamiento compatible S3.
• Backup offline.
• Cinta.
• Disco rotado y desconectado.
• Repositorio endurecido con permisos muy limitados.

Y el “0” tampoco es decoración. Significa cero errores de verificación. No basta con que el job de backup acabe en verde. Hay que comprobar que se puede restaurar.

Un backup que no se prueba es una promesa. No una garantía.

---

RPO y RTO: las dos preguntas que negocio sí entiende

Antes de elegir herramientas, hay dos conceptos que conviene explicar bien:

• RPO: cuántos datos puedes permitirte perder.
• RTO: cuánto tiempo puedes estar parado.

Ejemplo sencillo:

Si haces backup una vez al día, tu RPO puede ser de hasta 24 horas. Si el servidor cae a las 19:00 y el último backup bueno es de las 02:00, todo lo que pasó entre medias puede perderse.

Si tardas ocho horas en restaurar el sistema, tu RTO real son ocho horas, aunque en el PowerPoint ponga dos.

Por eso los backups no son solo una decisión técnica. Son una conversación con negocio.

Hay que preguntar:

• ¿Cuánto dato podemos perder?
• ¿Cuánto tiempo podemos estar sin este sistema?
• ¿Qué sistemas son críticos de verdad?
• ¿Qué se restaura primero?
• ¿Quién decide en una emergencia?
• ¿Tenemos documentación para restaurar sin depender de una sola persona?

Sin esas respuestas, puedes tener una herramienta carísima y aun así una estrategia mala.

---

Cómo implementarlo según el tamaño de la empresa

No es lo mismo proteger los datos de un autónomo que los de una empresa con 200 empleados.

La regla es la misma, pero la implementación cambia.

Autónomos y pequeños negocios

Objetivo: algo sencillo, barato y que se pueda mantener.

• Datos originales: ordenador principal, NAS pequeño o servidor local.
• Copia local: disco externo, NAS o segundo equipo.
• Copia off-site: almacenamiento cloud o backup externo cifrado.
• Copia aislada: disco externo rotado y desconectado, o cloud con versionado/inmutabilidad.
• Herramientas: software del NAS, Veeam Agent, BorgBackup, restic, Duplicati, Kopia o soluciones similares.

Mi recomendación aquí: no te compliques tanto que luego no lo mantengas.

Un backup sencillo que se ejecuta y se prueba vale más que una arquitectura perfecta que abandonas al mes.

Pymes

Objetivo: automatización, monitorización y recuperación documentada.

• Datos originales: servidores, NAS, máquinas virtuales, SaaS y endpoints críticos.
• Copia local: repositorio de backup dedicado o NAS secundario.
• Copia off-site: cloud object storage, segunda sede o proveedor gestionado.
• Copia inmutable: repositorio Linux endurecido, Object Lock, almacenamiento inmutable o rotación offline.
• Herramientas: Veeam Community/Essentials, Synology Active Backup, Nakivo, Acronis, BorgBackup, restic o soluciones equivalentes.

Aquí ya no basta con “el backup corre por la noche”. Necesitas:

• Alertas si falla.
• Retención definida.
• Pruebas de restauración.
• Documentación.
• Separación de credenciales.
• Backups de Microsoft 365/Google Workspace si los usas.

Este último punto se olvida mucho: tener correo y documentos en SaaS no significa que tu proveedor esté haciendo backup empresarial a tu medida. Hay retención, papelera, versionado y mecanismos de recuperación, sí, pero eso no sustituye necesariamente una estrategia propia de backup si esos datos son críticos.

Empresas medianas y grandes

Objetivo: resiliencia, gobierno y recuperación medible.

• Datos originales: almacenamiento principal, bases de datos, virtualización, SaaS, endpoints y aplicaciones críticas.
• Copia local: repositorios dedicados, cabinas o appliances de backup.
• Copia off-site: segunda ubicación, cloud provider o proveedor BaaS/DRaaS.
• Copia inmutable/offline: object storage con inmutabilidad, cinta, repositorios endurecidos o almacenamiento aislado.
• Herramientas: Veeam Backup & Replication, Commvault, Rubrik, Cohesity, Acronis, Nakivo u otras soluciones empresariales.

En empresas grandes, además del backup, importa mucho el proceso:

• Clasificación de sistemas por criticidad.
• RPO/RTO definidos por servicio.
• Pruebas periódicas de restauración.
• Simulacros de desastre.
• Control de accesos.
• Separación de funciones.
• Retención legal y cumplimiento normativo.
• Planes de continuidad y recuperación.

El backup técnico es solo una parte. La recuperación real es organizativa.

---

Lo que casi nadie hace y debería

1. Probar restauraciones

Este es el punto más importante de todo el artículo.

Un backup que no se ha restaurado nunca no es un backup. Es una ilusión.

Como mínimo, deberías probar:

• Restaurar un archivo suelto.
• Restaurar una carpeta completa.
• Restaurar una base de datos.
• Restaurar una máquina virtual.
• Restaurar en un entorno distinto al original.

Y no una vez en la vida. De forma periódica.

Para una pyme, una prueba trimestral me parece razonable. Para sistemas críticos, incluso más frecuente.

La pregunta no es “¿hay backup?”. La pregunta es:

¿Cuándo fue la última vez que restauramos algo y funcionó?

2. Cifrar las copias

Los backups suelen contener lo más sensible de una organización.

Datos de clientes. Nóminas. Correos. Bases de datos. Documentos internos. Configuraciones. A veces incluso secretos que no deberían estar ahí.

Por eso deben ir cifrados:

• En tránsito: cuando viajan hacia el destino.
• En reposo: cuando quedan almacenados.

Y aquí hay otro punto importante: gestiona bien las claves.

Un backup cifrado cuya clave se pierde es tan inútil como no tener backup. Y un backup cifrado cuya clave está guardada en el mismo servidor comprometido pierde mucha gracia.

3. Retención de versiones

No basta con tener “la última copia”.

El ransomware no siempre se detecta en el minuto uno. Un borrado accidental puede descubrirse semanas después. Una corrupción silenciosa puede replicarse durante días.

Necesitas retención.

Ejemplo orientativo:

• Copias diarias durante 30 días.
• Copias semanales durante 3 meses.
• Copias mensuales durante 1 año.

No es una receta universal. Depende de tus datos, normativa, costes y necesidades. Pero la idea es clara: necesitas poder volver atrás.

4. Aislar los backups de producción

Muchos ransomware buscan precisamente los backups.

Si tu repositorio de backup está unido al dominio, accesible con las mismas credenciales y montado desde los servidores de producción, estás facilitando mucho el trabajo al atacante.

Buenas prácticas:

• Credenciales separadas para backup.
• Repositorio no unido al dominio si es posible.
• VLAN o segmento separado.
• Acceso mínimo desde producción.
• Inmutabilidad donde sea posible.
• MFA en consolas de backup.
• Sin usuarios compartidos ni contraseñas reutilizadas.

No hace falta montar una arquitectura de película. Pero sí hay que evitar que el backup sea “otra carpeta compartida más”.

5. Monitorizar los jobs

Un backup que falla en silencio es casi peor que no tener backup, porque te da falsa tranquilidad.

Necesitas alertas:

• Job fallido.
• Backup incompleto.
• Repositorio sin espacio.
• Retención que no se aplica.
• Copia off-site que no sincroniza.
• Errores de verificación.

No hace falta un NOC. Pero sí necesitas enterarte cuando algo falla.

---

Errores comunes que he visto en empresas

“El RAID ya me protege”

No. El RAID no es backup.

El RAID puede protegerte frente al fallo de un disco, y ni siquiera siempre. Pero no te protege frente a:

• Ransomware.
• Borrado accidental.
• Corrupción lógica.
• Incendio.
• Robo.
• Error humano.
• Credenciales comprometidas.

RAID es disponibilidad. Backup es recuperación. No son lo mismo.

“Tenemos backup en el mismo servidor”

Eso no es una estrategia. Es una copia cómoda.

Si el servidor se rompe, se cifra o se borra, probablemente esa copia se va con él.

“La nube ya hace backup por mí”

Depende de qué entiendas por backup.

Google Drive, Dropbox, OneDrive o iCloud pueden tener versionado, papelera y recuperación durante un tiempo. Pero son principalmente sincronización y almacenamiento colaborativo.

Si un usuario borra datos, si una cuenta se compromete o si un ransomware cifra archivos sincronizados, esos cambios pueden propagarse.

Si esos datos son críticos para tu negocio, necesitas una estrategia de backup específica para SaaS.

“Hacemos backup, pero no lo probamos”

Este es el clásico.

El job sale en verde. Todo parece bien. Nadie mira más.

Hasta que hay que restaurar y aparecen los problemas:

• Credenciales caducadas.
• Repositorio corrupto.
• Backup incompleto.
• Base de datos inconsistente.
• Versión que no arranca.
• No se sabe el orden de restauración.

La restauración hay que probarla cuando no hay presión. No el día del incendio.

“El backup lo lleva una persona”

Si solo una persona sabe cómo restaurar, no tienes un proceso. Tienes dependencia.

Documenta:

• Qué se copia.
• Dónde se guarda.
• Cómo se restaura.
• Quién tiene acceso.
• Qué hacer si esa persona no está.

---

Herramientas que tienen sentido

No hay una herramienta perfecta para todos. Depende de tu entorno, presupuesto, tamaño y capacidad de mantenimiento.

Herramienta	Para qué encaja	Comentario
Veeam Backup & Replication	VMs, servidores, entornos virtualizados y empresas	Muy extendido. Community Edition puede ser suficiente para entornos pequeños.
Synology Active Backup	PCs, servidores, VMs y SaaS si ya tienes NAS Synology compatible	Muy cómodo para pymes y homelab serio.
Nakivo	VMware, Hyper-V, Nutanix, cloud y entornos mixtos	Alternativa interesante para pymes.
Acronis	Backup gestionado, endpoints, servidores y cloud	Útil si quieres una solución más empaquetada.
BorgBackup	Linux, servidores, backups cifrados y deduplicados	Muy potente si no te asusta la línea de comandos.
restic	Backups cifrados a múltiples destinos	Simple, moderno y muy flexible.
Kopia	Backups cifrados con GUI/CLI y varios destinos	Muy interesante para usuarios técnicos y homelab.
Duplicati	Backups cifrados con interfaz web	Cómodo, aunque conviene probar bien restauraciones antes de confiarle datos críticos.
Backblaze B2	Almacenamiento cloud para backups	Buena opción de object storage económico. Revisa siempre precios y costes de salida actuales.
Wasabi	Object storage cloud	Precio simple por capacidad, pero revisa condiciones, mínimos y políticas de retención.
AWS S3 / Glacier	Empresas, retención, archivo y object lock	Muy potente, pero hay que entender clases, costes, recuperación y salida de datos.

Mi consejo: no elijas herramienta solo por precio. Elige una que puedas operar, monitorizar y restaurar.

La mejor herramienta de backup es la que el día del desastre sabes usar sin improvisar.

---

Checklist rápido de implementación

✔️	Tarea
☐	Datos críticos identificados y priorizados.
☐	RPO y RTO definidos por sistema.
☐	3 copias de los datos críticos.
☐	Al menos 2 soportes o sistemas diferentes.
☐	1 copia off-site.
☐	1 copia offline, inmutable o aislada.
☐	Backups cifrados en tránsito y en reposo.
☐	Claves de cifrado custodiadas correctamente.
☐	Retención de versiones definida.
☐	Backups separados de la red de producción.
☐	Credenciales de backup separadas.
☐	MFA activo en consolas de backup y cloud.
☐	Monitorización y alertas si fallan los jobs.
☐	Prueba de restauración realizada en los últimos 3 meses.
☐	Procedimiento de restauración documentado.
☐	Persona suplente capaz de restaurar.

---

Un ejemplo práctico para una pyme

Supongamos una empresa pequeña con:

• Un servidor de archivos.
• Varias máquinas virtuales.
• Microsoft 365 o Google Workspace.
• Un NAS local.
• Datos críticos de clientes.

Una estrategia razonable podría ser:

• Backup local diario al NAS o repositorio dedicado.
• Backup off-site diario cifrado a object storage o segunda ubicación.
• Retención diaria/semanal/mensual según criticidad.
• Repositorio inmutable para proteger contra ransomware.
• Backup específico de SaaS para correo/documentos críticos.
• Prueba trimestral restaurando una VM, una carpeta y un buzón/documento.
• Alertas por correo/Telegram si falla cualquier job.

Esto no es ciencia ficción. Es sentido común bien aplicado.

Lo difícil no es diseñarlo. Lo difícil es mantenerlo, revisarlo y probarlo.

---

Backups y seguridad van juntos

Los backups son una parte fundamental de la seguridad, pero no son toda la seguridad.

Si tienes backups perfectos pero el servidor está mal configurado, sigues teniendo un problema. Si tienes backups pero no MFA en la consola cloud, sigues teniendo un problema. Si tienes copias pero cualquiera con credenciales de dominio puede borrarlas, sigues teniendo un problema.

Por eso conviene complementar la estrategia de backup con:

• Hardening básico de servidores Linux.
• Buenas prácticas de ciberseguridad.
• Un entorno de pruebas o homelab para validar restauraciones y procedimientos.

Backup y seguridad no compiten. Se necesitan.

---

En resumen

La regla 3-2-1 no es nueva, pero muchas empresas siguen sin aplicarla bien.

Y hoy, con ransomware, sincronización cloud, SaaS, credenciales comprometidas y ataques dirigidos a backups, conviene ir un paso más allá:

3 copias
2 soportes
1 copia off-site
1 copia offline o inmutable
0 errores de verificación

No necesitas empezar con la solución más cara. Necesitas empezar con una estrategia que puedas cumplir.

Identifica tus datos críticos. Define RPO y RTO. Haz una copia fuera del sitio. Cifra. Aísla. Monitoriza. Y, sobre todo, restaura.

Porque el día que todo falla, no importa lo bonito que era tu dashboard.

Importa una sola cosa:

¿Puedes recuperar?

---

¿Cómo tienes organizados los backups en tu empresa o en tu homelab? ¿Has tenido alguna restauración que falló cuando más falta hacía? Cuéntalo en los comentarios — esas experiencias enseñan más que cualquier teoría.