Cómo elegir una herramienta de backup cloud
Un backup no vale por existir; vale cuando permite restaurar a tiempo, con datos completos y sin depender de suposiciones.
Antes de elegir Veeam, Druva, servicios nativos cloud o protección para Microsoft 365, hay que definir RPO, RTO, inmutabilidad, costes y pruebas reales de restore.
Define que significa recuperar
Antes de comparar proveedores, define RPO y RTO por sistema. No todos los datos necesitan el mismo tiempo de recuperacion ni la misma frecuencia de copia.
RPO, RTO e inmutabilidad antes que almacenamiento barato
- Backups inmutables.
- Restauracion granular.
- Cifrado y gestión de claves.
- Cobertura de SaaS, endpoints, servidores y bases de datos.
- Pruebas automaticas de restore.
- Retencion por política.
- Coste de almacenamiento y recuperacion.
Preguntas incomodas para Veeam, Druva o proveedores cloud
- Como se protege el backup si comprometen el admin.
- Cuanto tarda restaurar un entorno completo.
- Que auditorias o certificaciones tiene.
- Como se exportan los datos si se cancela.
- Que limites existen en restores masivos.
La compra empieza con un restore real
Compra solo despues de restaurar una muestra real. La ficha comercial puede prometer continuidad; el restore demuestra si existe.
Ejemplo real: restaurar Microsoft 365 no es restaurar una VM
Una empresa puede tener snapshots de servidores y aun asi perder correos, Teams o SharePoint si no cubre Microsoft 365. Druva, Veeam o soluciones cloud-native deben evaluarse por restore real de cada sistema, no por una lista de plataformas compatibles.
La decisión de compra no debe depender de la demo
La compra deberia avanzar solo si el equipo puede defender tres puntos: que problema economico resuelve, que coste operativo introduce y que salida existe si la herramienta o arquitectura deja de encajar. En cloud, una comparativa util no busca un ganador absoluto; busca reducir arrepentimiento despues de firmar.
La restauración manda sobre la copia
La decisión debe empezar por un restore real: cuánto tarda, qué permisos necesita, qué datos quedan fuera y quién valida que la recuperación sirve al negocio.
En Microsoft 365, Google Workspace, bases de datos o almacenamiento cloud, cada proveedor protege cosas distintas. La letra pequeña sobre retención, inmutabilidad y granularidad suele decidir más que el precio por GB.
- Define RPO y RTO por sistema, no de forma global.
- Comprueba restauración granular y restauración completa.
- Exige informes de prueba y alertas de backup fallido.
Criterios de decisión: restore antes que copia
Elegir backup cloud empieza por una pregunta incómoda: qué necesitas recuperar, en cuánto tiempo y con cuánta pérdida aceptable. Sin RPO y RTO por sistema, cualquier comparativa queda incompleta. No es lo mismo proteger Microsoft 365, una base PostgreSQL, buckets de S3, máquinas virtuales o portátiles de empleados.
| Criterio | Qué revisar | Riesgo si se ignora |
| --- | --- | --- |
| RPO | Cuántos datos se pueden perder | Copias demasiado espaciadas |
| RTO | Cuánto tarda volver a operar | Restauraciones lentas e inútiles |
| Inmutabilidad | Protección contra borrado o ransomware | El atacante borra también los backups |
| Granularidad | Fichero, buzón, tabla, VM o tenant completo | Se restaura demasiado o demasiado poco |
| Coste total | Almacenamiento, egress, retención y soporte | Factura inesperada al restaurar |
Ejemplo concreto: Microsoft 365 no es una VM
Muchas empresas creen que Microsoft 365 queda cubierto por defecto. En realidad, retención y disponibilidad del servicio no equivalen a backup operativo para errores humanos, borrados maliciosos o restauraciones granulares. Recuperar un buzón, un SharePoint, una carpeta de OneDrive o un Teams completo requiere entender límites del proveedor y de la herramienta elegida.
Un piloto serio debe restaurar elementos reales: un correo borrado hace semanas, una carpeta compartida, permisos de SharePoint y un usuario eliminado. Si el equipo no puede completar esa prueba sin soporte externo, la herramienta todavía no está validada.
Errores comunes al comprar backup cloud
El primer error es comprar por precio por GB. La restauración puede tener costes de salida, tiempos largos o limitaciones de granularidad. Un backup barato que no restaura a tiempo es caro.
El segundo error es no aislar credenciales. Si las mismas cuentas administran producción y backup, un atacante con privilegios puede cifrar o borrar ambas capas. La inmutabilidad y la separación de permisos son críticas.
El tercero es no probar restores. Muchos planes de backup parecen correctos hasta el primer incidente. La prueba debe hacerse con reloj, responsable y validación del área de negocio.
El cuarto error es no revisar retención legal y cumplimiento. Sectores regulados pueden necesitar conservar datos durante años, demostrar integridad o limitar regiones de almacenamiento.
Preguntas para Veeam, Druva o proveedores cloud
Antes de elegir, pregunta cómo se protegen credenciales, qué retención soporta, si hay inmutabilidad real, cuánto tarda un restore completo, qué ocurre con egress, cómo se auditan restauraciones y si existe soporte 24/7 durante incidente.
También conviene preguntar por APIs, alertas, informes de cumplimiento y exportación. Si la herramienta se convierte en una caja cerrada, el equipo dependerá del proveedor justo cuando menos margen tenga.
Decisión práctica
Elige una herramienta que permita restaurar el sistema que más daño causaría al negocio. Para una pyme, puede ser Microsoft 365. Para un SaaS, quizá PostgreSQL, objetos en S3 y secretos de configuración. Para una consultora, repositorios, documentos y endpoints.
La señal de compra no es que el panel muestre copias verdes. Es completar un restore real, documentarlo y repetirlo de forma periódica.
Casos de uso que conviene separar
No todas las copias tienen el mismo objetivo. Un backup de Microsoft 365 busca recuperar buzones, ficheros y permisos. Un backup de PostgreSQL busca consistencia, punto en el tiempo y validación de datos. Una copia de máquinas virtuales busca volver a levantar servicios completos. Mezclar todos esos casos en una sola promesa comercial suele crear falsas expectativas.
Para cada sistema, define propietario, frecuencia, retención, ubicación, cifrado y prueba de restauración. La herramienta puede ser la misma, pero el criterio de éxito no lo es.
Señales de que una solución no está madura
Desconfía si el proveedor no puede explicar tiempos de restore, costes de egress, límites de API, protección contra borrado malicioso o procedimiento durante ransomware. También es mala señal si todos los informes son verdes pero nadie ha restaurado nada en los últimos seis meses.
Una solución madura genera alertas cuando falla una copia, permite auditoría de restauraciones, separa permisos y facilita pruebas periódicas. El panel importa menos que la capacidad de recuperar un lunes por la mañana sin improvisar.
Plan de prueba antes de comprar
El piloto debería incluir una restauración granular, una restauración completa y una prueba con permisos. Documenta tiempos, pasos manuales, errores y dependencia del soporte. Si la restauración exige abrir ticket para una operación básica, ese dato debe entrar en la comparativa.
Checklist mínimo para revisión humana
Antes de aprobar una herramienta, el equipo debería tener una tabla con sistemas protegidos, frecuencia de copia, retención, propietario, ubicación, cifrado y fecha del último restore probado. Esa tabla revela huecos rápidamente: sistemas sin dueño, copias sin prueba o retenciones que no cubren obligaciones legales.
También conviene documentar quién puede iniciar una restauración y quién debe aprobarla. Durante un incidente, dar permisos improvisados puede ser tan peligroso como no tener backup.
Señal de aprobación
La aprobación debería depender de una prueba documentada, no de una promesa comercial. Si el equipo puede restaurar datos críticos, explicar costes y repetir el proceso sin improvisar, la herramienta empieza a estar lista para producción.
En esa revisión final también conviene comprobar quién recibe alertas de copia fallida, quién valida restauraciones y qué sistemas quedan fuera del contrato. Los huecos no documentados suelen aparecer justo durante el incidente.
