Guía para evaluar backup de Microsoft 365 en MSP pequeños

Respuesta corta: Elige un servicio de backup para Microsoft 365 por las recuperaciones que tu MSP pueda demostrar. Primero define cargas, identidades, retención, destinos de restore, aislamiento administrativo, operación multitenant, costo total y ruta de salida. Después ejecuta las mismas pruebas contra cada finalista. Un precio bajo por usuario, una consola atractiva o una lista extensa de funciones no bastan si el servicio no puede recuperar los datos importantes bajo las fallas que prometes cubrir.

La comparación de productos no es la decisión real

Un MSP pequeño suele llegar a esta decisión con una pregunta práctica: ¿debe conservar un servicio económico que parece funcionar o cambiarse a la plataforma que otros operadores recomiendan?

Una discusión reciente en r/SmallMSP sobre iDrive frente a Afi.ai para backups de tenants de Microsoft 365 expuso los criterios reales: región de datos, almacenamiento incluido, mínimos de contrato, calidad de interfaz, operación multitenant, experiencia de restore y comportamiento al crecer la cartera. El detalle más importante era más sencillo: los backups actuales se veían saludables, pero todavía no se había realizado una recuperación.

Ese es el límite de esta guía. No es un ranking de vendors. Es una forma repetible de decidir si cualquier servicio de backup de Microsoft 365 encaja con la promesa de recuperación, la capacidad operativa y los márgenes de un MSP pequeño.

Usa el framework para elegir el stack cuando compares el lugar del backup dentro de todas tus herramientas. Usa la checklist de pruebas de restore después de la selección para producir evidencia recurrente. Esta guía cubre la decisión entre esos dos puntos.

Define la promesa de recuperación antes del producto

No empieces con “¿cuál backup es el mejor?”. Empieza con el incidente que el cliente espera que resuelvas.

Escribe los escenarios de recuperación importantes para cada cliente:

• Un usuario elimina un correo, carpeta o documento.
• Se borra la cuenta de una persona que salió antes de que el negocio identifique datos necesarios.
• Un administrador malicioso o comprometido elimina o sobrescribe contenido.
• Ransomware cifra o corrompe archivos sincronizados.
• Un sitio de SharePoint, cuenta de OneDrive o buzón necesita una recuperación a un punto anterior.
• El usuario, administrador, suscripción o tenant original no está disponible.
• El cliente necesita exportar datos por razones legales, continuidad, migración u offboarding.
• El negocio necesita recuperar el servicio dentro de un tiempo y punto de recuperación específicos.

Para cada escenario define objeto protegido, pérdida aceptable de datos, downtime aceptable, destino del restore, autoridad de aprobación y responsable de validación. Si el servicio solo puede restaurar sobre el objeto original, aclara si esa ruta todavía funciona cuando la identidad o el tenant forman parte del incidente.

Así conviertes una compra vaga de backup en una prueba de aceptación.

Construye un mapa de cargas y exclusiones

“Backup de Microsoft 365” no es un alcance preciso. El tenant puede contener varias cargas con comportamientos distintos de almacenamiento, identidad, retención y restore.

Crea un mapa de cobertura para:

• Buzones de Exchange Online, archivos, buzones compartidos, calendarios, contactos, tareas y carpetas públicas cuando apliquen.
• Cuentas de OneDrive, versiones, relaciones de uso compartido, permisos y datos de usuarios inactivos.
• Sitios, bibliotecas, listas, páginas, versiones, metadatos, permisos y sitios eliminados de SharePoint.
• Mensajes de Teams, contenido de canales, canales privados o compartidos, artefactos de reuniones y archivos almacenados mediante SharePoint o OneDrive.
• Grupos de Microsoft 365 y los servicios conectados a ellos.
• Usuarios, grupos, roles, registros de aplicaciones, políticas de Conditional Access y otras configuraciones de Entra ID.
• Planner, Forms, Power Platform, Loop, Project u otros datos que el cliente suponga incluidos.

No asumas que un servicio protege todo. Marca cada elemento como protegido por completo, protegido parcialmente, recuperable mediante otro control de Microsoft, excluido o todavía sin verificar.

La descripción de Microsoft 365 Backup documenta cargas y comportamientos de restore específicos para el servicio de Microsoft. Trata igual a cada proveedor: compara su documentación vigente contra una prueba real, porque el nombre del producto no define por sí mismo la cobertura.

Los usuarios y sitios nuevos también necesitan una regla de enrollment. Verifica si entran a protección de forma automática, por política, por licencia o manualmente. Una solución que funciona para los diez usuarios de hoy puede omitir silenciosamente al número once si el onboarding no está conectado con la cobertura de backup.

Separa retención, disponibilidad y backup

Microsoft 365 incluye papeleras, historial de versiones, elementos recuperables, políticas y etiquetas de retención, holds y resiliencia del servicio. Son controles valiosos, pero no resuelven el mismo escenario.

Microsoft explica que las políticas y etiquetas de retención de Purview administran cuánto tiempo se conserva o elimina contenido por razones de ciclo de vida y registros. El contenido normalmente se conserva dentro del entorno de Microsoft 365. Un servicio de backup responde otra pregunta operativa: qué copia recuperable existe, quién puede alcanzarla, qué punto se puede elegir, dónde puede restaurarse y si sobrevive al incidente planeado.

No vendas la frase “Microsoft no respalda tus datos” como sustituto de discovery. Construye una matriz de escenarios y registra el control nativo, la capacidad requerida del backup y el resultado probado para cada caso:

• Eliminación accidental: mapea la papelera, versión o ruta de elementos recuperables; después prueba búsqueda y restore granular tras la ventana nativa o fuera del objeto original.
• Sobrescritura maliciosa: documenta si versiones o retención ayudan; después demuestra un punto limpio conocido, administración protegida y rollback utilizable.
• Empleado eliminado: registra la política nativa de ciclo de vida y retención; después prueba protección, búsqueda, restore y cobro tras retirar la licencia.
• Compromiso de tenant o identidad: identifica cuáles rutas nativas dependen del plano afectado; después demuestra autoridad separada y el destino alterno o la exportación prometida.
• Retención de cumplimiento: asigna la responsabilidad a Purview y los controles de registros cuando corresponda; usa backup solo cuando la necesidad de recuperación sea distinta y registra la evidencia.

La respuesta puede combinar controles nativos y backup. El objetivo no es comprar más herramientas, sino saber cuál control es dueño de cada falla y demostrar que la ruta combinada funciona.

Califica el restore antes que la interfaz

Una consola limpia ahorra tiempo técnico, pero la ruta de restore sostiene la promesa del servicio.

Califica a cada finalista por:

1. Velocidad y precisión de búsqueda entre tenants, usuarios, fechas y tipos de elemento.
2. Puntos disponibles y cómo cambia su granularidad con el tiempo.
3. Opciones para recuperar elementos, carpetas, buzones, OneDrive, SharePoint y conjuntos grandes.
4. Restore a la ubicación original, una alterna, otro usuario u otro tenant.
5. Formatos de exportación y si las exportaciones grandes siguen siendo prácticas.
6. Conservación de versiones, permisos, metadatos, uso compartido, etiquetas y estructura de carpetas.
7. Tratamiento de usuarios y recursos inactivos, sin licencia, eliminados o compartidos.
8. Throttling, límites, velocidad esperada y escalación con el vendor durante incidentes grandes.
9. Qué ocurre cuando tenant, dominio, identidad o suscripción original no están disponibles.
10. Evidencia producida: job, operador, tiempos, objetos, resultado, errores y audit trail.

La documentación de restore de Microsoft 365 Backup demuestra por qué importan los detalles: frecuencia de puntos, destinos soportados, historial y condiciones de prueba pueden ser específicos de cada carga y servicio. No copies esos supuestos a otro producto. Haz que cada vendor pruebe su propio comportamiento.

Evalúa el plano de control del MSP

El servicio debe proteger clientes sin convertir una sola cuenta del MSP en una ruta sin control hacia todos los tenants.

Verifica:

• Cuentas técnicas nominativas, MFA obligatorio y acceso por roles.
• Separación de roles para cobro, políticas, restore, eliminación y administración global.
• Logs de inicio de sesión, cambios de política, restores, exportaciones, onboarding de tenants y acciones destructivas.
• Alertas de fallas, autorizaciones vencidas, objetos omitidos, umbrales de capacidad y cambios de política.
• Separación de clientes en búsquedas, reportes, exportaciones y acceso delegado.
• Acceso de emergencia y recuperación de cuentas sin depender de una sola persona propietaria del MSP.
• Verificación de identidad del soporte del vendor antes de recibir ayuda privilegiada.
• Cifrado en tránsito y reposo, modelo de llaves, residencia de datos, subprocesadores y notificación de brechas.
• Protección para que la misma identidad comprometida que administra producción no pueda eliminar los backups.

Microsoft documenta por separado privacidad, seguridad, retención y residencia de datos para su servicio. Exige claridad equivalente a cualquier proveedor. “Está en la nube” no aporta suficiente detalle para una decisión de riesgo.

CISA recomienda mantener backups protegidos y probar su disponibilidad e integridad en un escenario de recuperación. Para datos SaaS, traduce ese principio en aislamiento administrativo explícito, resistencia al borrado, autoridad de recuperación y evidencia de restore; no asumas que una segunda consola web crea independencia.

Prueba la carga operativa semanal

Un MSP pequeño puede perder margen por administración invisible aunque la licencia sea barata.

Durante el piloto mide:

• Tiempo para crear y autorizar un tenant.
• Tiempo para confirmar que cada usuario, sitio, buzón y recurso compartido esperado está protegido.
• Cómo entran o salen de política los objetos nuevos y eliminados.
• Si las fallas crean tickets con responsable o solo otra bandeja que revisar.
• Tiempo para investigar una alerta y distinguir ruido de pérdida real de cobertura.
• Tiempo para producir un reporte útil para el cliente.
• Tiempo y nivel técnico necesarios para restores comunes.
• Respuesta del soporte y calidad de la escalación.
• Pasos cuando un cliente cambia de MSP o abandona el servicio.

Prueba con roles técnicos de menor privilegio, no solo con la cuenta global del setup. El producto no está listo cuando la persona dueña puede restaurar, pero el service desk no puede seguir un runbook controlado.

Calcula el costo total por tenant

No compares solo la tarifa anunciada por usuario.

Construye el costo interno mensual:

```text

Mínimo por tenant o contrato

+ licencias de usuarios y recursos protegidos

+ almacenamiento, consumo, excedentes o retención

+ tarifas de distribuidor o plataforma

+ labor de revisión de alertas y administración

+ labor de pruebas de restore y reportes

+ tiempo esperado de soporte y excepciones

+ exposición por offboarding y conservación de datos

= costo mensual total de entrega

```

Después prueba los casos límite de cobro:

• Buzones compartidos, archivos, salas y cuentas de servicio.
• Usuarios sin licencia y eliminados.
• Sitios grandes de SharePoint y usuarios por encima del almacenamiento promedio.
• Almacenamiento agrupado por usuarios, clientes o todo el MSP.
• Asientos mínimos, gasto mínimo, términos anuales y niveles de precio.
• Cargos durante legal hold, retención extendida o acceso posterior al offboarding.
• Costos de exportación, egress, restore, API o soporte.

Usa un mínimo por cliente cuando el trabajo fijo sea material. Diez usuarios no generan solo diez unidades de costo; el tenant todavía requiere implementación, revisión de política, alertas, evidencia, reporte y salida. Conecta el resultado con la guía de precios de servicios administrados en vez de ocultar la labor de backup dentro de un paquete que no la financia.

Ejecuta el mismo piloto de 30 días contra cada finalista

Usa un tenant interno o un cliente de bajo riesgo con autorización. Prepara datos de prueba conocidos y documéntalos antes de iniciar la protección.

El piloto debe incluir:

1. Inventariar buzones, cuentas de OneDrive, sitios de SharePoint, grupos y exclusiones esperadas.
2. Configurar roles, MFA, alertas, retención y acceso técnico como estarán en producción.
3. Confirmar la protección inicial y medir cuándo se vuelve utilizable.
4. Eliminar y restaurar un elemento de buzón con asunto y adjunto únicos.
5. Modificar y restaurar un archivo de OneDrive, incluida una versión anterior.
6. Eliminar y restaurar un objeto de SharePoint verificando metadatos y permisos importantes.
7. Eliminar la licencia o cuenta de un usuario de prueba y verificar protección, búsqueda, restore y cobro.
8. Probar destino alterno o exportación si forman parte de la promesa.
9. Ejecutar la recuperación práctica más grande que piensas incluir y medir el tiempo.
10. Provocar una autorización fallida o condición de objeto omitido y confirmar que se convierta en trabajo asignado.
11. Abrir un caso de soporte con la evidencia que tendría un técnico durante un incidente.
12. Exportar configuración, inventario, logs y datos necesarios para offboarding.

Registra cada resultado como aprobado, aprobado con excepción, fallido o no soportado. Un demo comercial no es resultado de piloto.

Define la salida antes de estandarizar

Pregunta qué ocurre cuando el MSP cambia de proveedor, el cliente cambia de MSP, el vendor es adquirido, suben los precios o la cuenta termina.

Documenta:

• Cuánto tiempo siguen disponibles los backups después de cancelar o retirar licencias.
• Si el cliente puede conservar, transferir o exportar el historial.
• Formato de exportación, fidelidad de metadatos, cifrado, límites de tamaño y velocidad práctica.
• Si otro proveedor puede importar la exportación.
• Tiempo y costo para mover tenants grandes.
• Propiedad de cuenta, políticas, llaves, reportes y autoridad de recuperación.
• Registros que conservará el MSP después de terminar el servicio y durante cuánto tiempo.
• Cómo se destruyen los datos protegidos y qué evidencia queda al finalizar la retención.

Un servicio que exige pago indefinido para conservar copias históricas crea dependencia comercial. Puede ser aceptable, pero debe quedar visible antes de incorporarlo a todos los contratos.

Conecta el handoff con la checklist de offboarding y recuperación de accesos. Los datos del cliente no deben quedar atrapados en una consola propiedad del MSP que nadie más pueda recuperar.

Errores comunes

El error más común es elegir según recomendaciones antes de escribir los escenarios de recuperación.

Otros fallos incluyen:

• Comparar precio de lista sin almacenamiento, usuarios inactivos, mínimos y labor técnica.
• Suponer que “todo Microsoft 365” incluye Teams, Entra ID, Power Platform, metadatos y configuración del tenant.
• Tratar retención, versiones, sincronización y backup como equivalentes.
• Proteger usuarios actuales y omitir recursos compartidos o sitios nuevos.
• Probar solo un archivo fácil y vender recuperación del tenant completo.
• Usar una sola identidad global del MSP para cobro, política, restore y eliminación.
• Ignorar el escenario donde tenant o administrador original no están disponibles.
• Aceptar una región de datos sin confirmar el alcance de backup, logs, soporte y subprocesadores.
• Estandarizar un vendor sin probar exportación y cancelación.
• Incluir labor de recuperación en un paquete barato que no puede financiarla.

Cuándo cambiar de nivel

Pasa a un diseño más fuerte cuando los clientes tengan SharePoint grande o cambiante, datos sensibles, deberes legales de retención, objetivos cortos, varias cargas de Microsoft 365, alto riesgo administrativo, recuperación entre tenants o requisitos de ciberseguro que el servicio actual no pueda demostrar.

Fortalece el proceso del MSP cuando las alertas se atiendan de memoria, los usuarios inactivos generen sorpresas de cobro, las pruebas dependan de la persona dueña, las exportaciones sean imprácticas, se omitan objetos nuevos o el trabajo mensual consuma más margen del calculado.

El servicio correcto no es el que tiene más menciones en la comunidad. Es el que tu equipo puede asegurar, operar, usar para recuperar, explicar al cliente y abandonar sin perder control de los datos.