Cómo hacer copias de seguridad que realmente funcionen
La historia se repite: la empresa tiene backups. El software dice Success. Pero el día que necesitan restaurar, falla. Esto pasó con tres clientes nuestros en los últimos 12 meses. En uno, los backups estaban en un NAS conectado al mismo dominio que se cifró con ransomware. En otro, el backup "funcionaba" pero nadie había probado restaurar en dos años. Cuando lo hicieron, el 40% de los archivos estaban corruptos. Acá va cómo hacerlo bien.
La regla 3-2-1 explicada sin vendor-speak
Es la regla más repetida en la industria. También la más ignorada. Dice:
- Tres copias de sus datos. La original más dos backups.
- En dos medios distintos. No dos discos externos iguales conectados al mismo USB. Medios distintos: disco + cinta, disco + nube, NAS + cloud inmutable.
- Una copia fuera de sitio y offline. Offline significa que no está conectada a nada que pueda alcanzar un ransomware. Fuera de sitio significa que si se incendia la oficina o se inunda el server room, esa copia sobrevive.
En la práctica, para una PyME esto se traduce en: servidor principal → backup diario a un NAS local (rápido de restaurar) → backup semanal a un disco externo que se guarda bajo llave (offline) O backup continuo a un cloud con immutable storage. La nube es más cara a largo plazo pero más fácil de automatizar. El disco rotado es más barato pero requiere disciplina humana. Elija su veneno.
Por qué su Veeam en el mismo dominio no sirve
Esto pasó literalmente dos veces en 2025. El cliente tenía Veeam Backup & Replication perfectamente configurado. El Veeam corría en una VM dentro del mismo dominio de Active Directory. El ransomware entró por RDP, escaló a domain admin, y desde ahí simplemente accedió al repositorio de backups y lo formateó. Después cifró los servidores. Sin backups. Sin recuperación. Game over.
Un backup que se puede borrar desde el mismo panel que cifró el atacante no es un backup. Es un delay. Reglas de oro:
- El servidor de backups NUNCA debe estar unido al mismo dominio que respalda. Si es Windows, que sea un workgroup aparte o un dominio separado con zero trust entre ambos.
- La cuenta que usa el software de backup para escribir NO debe ser domain admin. Debe tener permisos mínimos: leer lo que respalda, escribir en el destino. Nada más.
- El repositorio de backups debe ser inmutable por un período mínimo de 7 días. Inmutable significa que ni el admin puede borrarlo. Veeam tiene esta función si usás un Linux repository con XFS. AWS S3 tiene Object Lock. Wasabi tiene Compliance Mode. No es ciencia espacial — es una casilla que hay que marcar.
No basta con que el software diga Success
Una empresa de logística en Querétaro nos contrató post-incidente. Tenían backups con Veeam. Todos los jobs marcaban Success. Pero el backup era incremental desde hacía 8 meses. Lo que nadie notó es que el full backup original de hacía 8 meses se había corrupto silenciosamente por un error de disco. Los incrementales no sirven sin un full sano. Resultado: 8 meses de backups inservibles.
Programe un restore test trimestral. No es opcional:
- Tome 10 archivos aleatorios de fechas distintas. Restáurelos a una ubicación alternativa. Verifique que abran.
- Una vez al año, haga un restore completo de un servidor (puede ser a un entorno aislado, no a producción). Mida cuánto tarda.
- Documente el proceso. Si la persona que sabe restaurar renuncia o está de vacaciones y hay un incidente, ¿alguien más puede hacerlo?
Si no probó restaurar, no tiene backup
Tiene esperanza. Y la esperanza no es una estrategia de recuperación de desastres.
Qué respaldar (y qué no vale la pena)
Regla simple: respalde todo lo que no pueda reconstruir desde cero en menos de 24 horas. Bases de datos, archivos compartidos, correos, configuraciones de sistema, máquinas virtuales completas. No respalde la carpeta de Descargas de los usuarios ni las películas que alguien guardó en el servidor. Sea quirúrgico: cada GB innecesario que respalda es tiempo de recuperación extra durante un incidente real.
Destino de backups: opciones de barato a caro
- Disco externo rotado. Dos discos USB de 4TB. Uno conectado al servidor de backup, otro guardado en una caja fuerte fuera de la oficina. Cada viernes, los intercambia. Costo: $2,000 MXN una vez. Riesgo: depende de que alguien recuerde rotarlos. Si no lo hacen por tres semanas, tres semanas de backups están en riesgo.
- NAS dedicado con snapshots inmutables. Un Synology o QNAP básico, en una VLAN separada, con snapshots programados y bloqueo de borrado. Costo: $8,000-$15,000 MXN una vez. Mejor que los discos rotados porque es automático. Asegúrese de que el NAS no esté en el mismo dominio.
- Nube con immutable storage. Wasabi, Backblaze B2, o AWS S3 con Object Lock. Costo: ~$6 USD por TB al mes. La ventaja es que es verdaderamente externo y verdaderamente inmutable. La desventaja es que restaurar 2 TB desde la nube puede tomar horas o días dependiendo de su conexión. Para archivos críticos, combine: NAS local para recuperación rápida + nube para disaster recovery.
El plan de los 15 minutos
Escriba en una hoja: (1) qué respaldamos, (2) dónde están las copias, (3) quién tiene las contraseñas de los backups, (4) cómo se restaura el sistema crítico (ERP, nómina, correo), (5) cuánto tiempo toma. Si no puede escribir esto en 15 minutos, su plan de backup tiene agujeros. Y los agujeros en los backups solo se descubren cuando ya es tarde.