← Todas las funciones

Copia de seguridad de Microsoft 365 e IMAP

Por Lucas Flores, IT Systeme Flores UG. Última actualización: 2026-10-29

Restow respalda buzones de Exchange Online (correo, calendario y contactos), OneDrive y, desde la 0.4.0, sitios de SharePoint Online, de forma incremental a través de la API de Microsoft Graph, y cualquier buzón IMAP por IMAP, hoy con autenticación por contraseña (OAuth2 para fuentes IMAP aún no está implementado; previsto). Desde la 0.4.5 también copia, si usted lo activa, el calendario y las conversaciones de los grupos de Microsoft 365. Cada restauración extraída de esa copia queda escrita, en todas las ediciones, en el registro de auditoría con cadena de hashes: quién la ejecutó, cuándo, para quién y desde dónde. El visor del registro de auditoría (búsqueda, filtros, detalles, verificación de la cadena) forma parte de Business y Service Provider, y desde la 0.3.1 también la exportación del registro, como CSV y como JSON con hashes.

Cómo funciona el lado de Microsoft 365

La copia de seguridad se ejecuta de forma incremental mediante el mecanismo de consultas delta de Microsoft Graph, de modo que una ejecución normal solo obtiene lo que cambió desde la anterior, en lugar de rastrear de nuevo todo un buzón u OneDrive. Los usuarios, buzones y OneDrives entran automáticamente mediante la sincronización de directorio de Entra ID (Graph users/delta), con el alcance protegido controlado por cliente: todos, un grupo concreto o una lista de exclusión. Microsoft limita la velocidad de la API de Graph, especialmente en la primera copia de seguridad de un cliente grande. Restow muestra esa espera en lugar de ocultarla, la misma norma de honestidad que se aplica a cualquier otro progreso o límite del producto. Una copia que Graph o el almacenamiento sigue reteniendo tras todos sus reintentos figura en ámbar como «Retenida por el servicio, se reintenta», no en rojo como «Fallida», y no genera ninguna alerta de fallo ni ningún webhook de fallo; la siguiente ejecución programada lo intenta de nuevo (desde la 0.4.7). Un trabajo en segundo plano respeta ahora un Retry-After de hasta 5 minutos (antes, aproximadamente un minuto), porque Exchange rechaza un reintento antes de que termine su penalización por demasiadas solicitudes en paralelo. Microsoft empezó a desactivar Exchange Web Services (EWS) para Exchange Online el 1 de octubre de 2026 (definitivamente, el 1 de abril de 2027); Restow nunca lo usó y se comunica con Microsoft únicamente a través de Microsoft Graph.

Desde la 0.3.5, una primera copia que tarda días puede continuar tras una interrupción. Si una copia se interrumpe por su límite de tiempo de 23 horas o por un reinicio del worker, después de guardar un punto de control, continúa sin gastar uno de sus reintentos, hasta 21 días después de su primer inicio, y la vista de la ejecución muestra la interrupción como información, no como un error. Una solicitud de Microsoft Graph que no recibe respuesta en 5 minutos se reintenta, en lugar de quedarse colgada hasta el límite de tiempo del trabajo; las solicitudes y las esperas por limitación terminan con el trabajo.

La primera copia de un buzón grande muestra «Primera copia: X de Y elementos» sumando todos los intentos, con una estimación del tiempo restante, y un OneDrive muestra «X elementos hasta ahora» hasta que está listado por completo.

Más información: copia de seguridad de OneDrive.

Objetos que ya no se copian

Desde la 0.4.7, un buzón cuya cuenta está desactivada o no tiene licencia de Exchange Online, y un OneDrive o un sitio de SharePoint que Microsoft bloqueó (HTTP 423, algo que Microsoft hace con el OneDrive de una cuenta sin licencia), ya no fallan cada noche. La copia pregunta primero a Microsoft si el usuario existe pero no tiene buzón, o confirma el bloqueo con una única lectura barata. Solo entonces el objeto figura como «No se copia: cuenta desactivada», «No se copia: sin licencia» o «No se copia: bloqueado» (en la interfaz en inglés, «Not backed up: account disabled», «Not backed up: no licence» y «Not backed up: locked»), la ejecución termina de forma neutra y sin reintentos, las copias existentes se conservan y nada cuenta como fallido ni como atrasado. Solo cuenta la respuesta de Exchange: una cuenta desactivada cuyo buzón Microsoft sigue sirviendo, como un buzón compartido, se copia como antes, y un 401 o 403 nunca se interpreta así. La copia se reanuda sola tras la sincronización del directorio que encuentra la cuenta de nuevo activada o con licencia, o el bloqueo levantado.

Para que nada quede en silencio, todo objeto que Restow deja de copiar, también uno eliminado de su fuente, figura primero en ámbar como «Ya no se copia, confirme», con el motivo y la fecha. La preparación del inquilino queda al menos en amarillo, nunca en verde, y los proveedores lo ven entre las alertas del inquilino, hasta que un administrador confirma «Sí, es intencionado»: para un objeto o para una selección o una lista filtrada de hasta 1000. El objeto figura entonces en gris como «Ya no se copia a propósito», con quién lo confirmó y cuándo; cuando vuelve a estar activo, la confirmación se descarta, y si más tarde vuelve a detenerse, Restow vuelve a preguntar. Un aviso por objeto, o una advertencia por inquilino y día cuando muchos se detienen a la vez, pasa por la matriz de notificaciones. Los objetos que ya estaban huérfanos antes de la actualización cuentan como confirmados. Un objeto eliminado de su fuente se valora según si su copia conservada más reciente se restaura, no según su antigüedad.

Desde la 0.4.7 un error también cuesta menos: un 403 en calendarios o contactos hace fallar solo esa área y conserva el correo de la ejecución, un enlace delta que Graph rechaza lleva a una resincronización completa, un mensaje que Exchange no puede convertir a MIME se guarda como JSON con sus adjuntos, y un permiso que un administrador concede más tarde a la aplicación surte efecto sin un secreto de cliente nuevo.

Sitios de SharePoint Online

Desde la 0.4.0, cada sincronización del directorio encuentra también los sitios de SharePoint del inquilino, incluidos los de los grupos de Microsoft 365 y de Teams; los sitios personales se dejan al OneDrive de su propietario. Cada sitio es un objeto protegido propio en los trabajos de correo, como un buzón o un OneDrive, y las reglas de protección tienen un modo de sitios: todos los sitios (el valor por defecto) o solo los seleccionados. Una copia contiene cada biblioteca de documentos (con el motor de OneDrive: delta por biblioteca, versiones opcionales, puntos de control), cada lista con sus columnas y los valores de los campos de cada elemento de lista como JSON, y la descripción del sitio. Una biblioteca o lista que Graph rechaza se comunica y conserva su última copia. Un sitio nuevo recibe de inmediato su primera copia, y un sitio eliminado falla con una causa clara.

En el explorador de restauración, un sitio muestra sus bibliotecas, carpetas, archivos, listas y elementos. Puede descargarlos como ZIP; restaurar archivos y carpetas en la biblioteca original o en otra biblioteca de un sitio copiado de la misma fuente («Conservar ambos», «Sobrescribir», donde SharePoint conserva el archivo antiguo como versión, u «Omitir los existentes»); y restaurar elementos de lista como elementos nuevos en su lista original, solo los campos escribibles. Las comprobaciones de restauración toman muestras de archivos de las bibliotecas como las de un OneDrive.

Necesita un permiso añadido y un nuevo consentimiento. La aplicación de copia necesita el permiso de aplicación Sites.ReadWrite.All (Sites.Read.All basta para copiar, no para restaurar), y el administrador del cliente debe abrir de nuevo el enlace de consentimiento de la fuente. Hasta entonces el correo y OneDrive siguen funcionando, y la sincronización del directorio avisa de que los sitios no se encuentran ni se copian. No se copian los chats de Teams, los adjuntos de los elementos de lista, el diseño del sitio, la navegación ni los flujos de trabajo. Los permisos se guardan como información y nunca se restauran, un sitio o una biblioteca eliminados no se vuelven a crear, y los elementos de lista solo vuelven a su lista original.

Más información: copia de seguridad de SharePoint Online.

Grupos de Microsoft 365: calendario y conversaciones

Desde la 0.4.5, el calendario y las conversaciones de los grupos de Microsoft 365, y de los grupos que hay detrás de Teams, son objetos protegidos de un tipo propio. La sincronización del directorio lee los grupos como un segundo flujo delta junto a los usuarios y conserva solo los grupos de Microsoft 365 (los grupos de seguridad y de distribución no tienen buzón de grupo); un grupo eliminado queda huérfano y sus puntos de restauración permanecen. Los grupos son opcionales: las reglas de protección tienen un interruptor «Proteger todos los grupos de Microsoft 365», desactivado por defecto, y los grupos sueltos se pueden incluir en la lista de objetos protegidos. Un trabajo de correo con alcance «todos» cubre cada grupo protegido, y los buzones de grupo nunca cuentan como buzones protegidos. Tras la actualización no se copia ningún grupo hasta que usted lo active, y la primera sincronización del directorio lee una vez completos los grupos de cada fuente de Microsoft 365.

Una copia contiene el calendario del grupo (series con sus excepciones, leído por el mismo código que lee el calendario de un usuario) y cada publicación de cada conversación como mensaje de correo, con sus archivos adjuntos cuando Graph los entrega; si no, se anota la ausencia de los adjuntos. Si Graph niega a la aplicación el listado de eventos de un calendario de grupo, Restow recurre a la vista de calendario del grupo y lee cada serie una vez; un calendario que Graph niega por completo es una advertencia de la ejecución, no un fallo. Solo se vuelven a leer los hilos con publicaciones nuevas. No hace falta ningún permiso nuevo de Microsoft: Group.Read.All y Calendars.ReadWrite siempre fueron necesarios.

En el explorador de restauración, los grupos están en la sección «SharePoint y Teams» con las áreas «Calendario del grupo» y «Conversaciones». La descarga como ZIP (EML, JSON) y la exportación (EML, MBOX, PST) funcionan como en los buzones. Una restauración en el buzón de un usuario de la misma fuente recupera eventos y conversaciones (las conversaciones como correo). Una restauración en el propio grupo recupera solo eventos de calendario, porque Microsoft Graph no permite a ninguna aplicación publicar en una conversación de grupo; cada publicación se informa como no restaurable, con las vías que funcionan. Restaurar un grupo no es una suplantación, porque un grupo no pertenece a ninguna persona. No se copian los chats ni los mensajes de canal de Teams, ni los adjuntos de los eventos de calendario.

El índice de copias

Desde la 0.3.5, el índice de qué elementos contiene una copia se guarda como una fila por versión de un elemento y no como una copia de cada elemento para cada copia. Un elemento que no ha cambiado no cuesta nada en las copias posteriores. Tras la actualización, el worker convierte en segundo plano el índice de las copias existentes, una copia tras otra; las copias, la exploración y las restauraciones siguen funcionando mientras tanto. Desde la 0.3.6, cuando termina la conversión, la API devuelve por sí sola el espacio en disco de la tabla antigua, en unos 15 minutos; ya no hace falta el reinicio de la API que pedía la 0.3.5. En la propia 0.3.5, reinicie la API una vez después de la conversión.

Conectar una fuente de Microsoft 365

Una fuente se conecta a Microsoft 365 de una de tres formas:

• La invitación de consentimiento de la aplicación de copia compartida, que acepta el administrador del cliente.
• Una aplicación Graph propia para esa fuente (desde la 0.2.2): una aplicación que el cliente creó a mano en su propio inquilino. Usted introduce el ID de inquilino, el ID de aplicación y un secreto de cliente o un certificado. La credencial se guarda sellada en el almacén de secretos de la organización y nunca se vuelve a mostrar. La guía enumera cada permiso con un botón para copiarlo y indica que no hace falta ningún URI de redirección. Desde la 0.4.7 también puede introducir la fecha de caducidad del secreto («El secreto caduca el», opcional): Restow le avisa entonces 30 días antes, 7 días antes y una vez caducado, y la tarjeta de conexión muestra «Caduca».
• Para el inquilino en el que vive la propia aplicación de copia, una conexión directa sin enlace de consentimiento (solo propietarios del proveedor). Un token de aplicación válido para ese inquilino sirve de prueba, de modo que se omite el rodeo del consentimiento, que Entra rechaza para una aplicación no instalada allí. Necesita el ID de directorio (inquilino) de la aplicación en Ajustes, Microsoft 365.

Cómo funciona el lado IMAP

Cualquier buzón IMAP es una fuente de copia de seguridad válida, autenticada hoy por contraseña. Por cada fuente IMAP usted decide cómo inicia sesión Restow: un único inicio de sesión compartido con una contraseña para todos los buzones (el valor por defecto), una contraseña propia por buzón o una cuenta maestra que inicia sesión como cada buzón. OAuth2 para fuentes IMAP (Microsoft 365 o Google por IMAP) aún no está implementado; previsto. Los clientes que solo usan IMAP (sin un directorio de Entra ID del que sincronizar) se añaden mediante una lista manual de buzones o una importación CSV.

Más información: copia de seguridad de buzones IMAP.

Trabajos de copia, ejecuciones en vivo e historial

Un trabajo de copia define qué se copia, cuándo, en qué repositorio, durante cuánto tiempo y cada cuánto lo demuestra una comprobación de restauración, para muchos buzones, OneDrives, cuentas IMAP o equipos a la vez, con excepciones por objeto o equipo. Hay trabajos para correo y para servidores y equipos. Puede limitar el ancho de banda de una copia, dentro de una franja horaria que usted defina. Los trabajos en curso y las tablas se actualizan solos, sin recargar la página, y una ejecución abre un panel de detalle con gráficos de su caudal de datos. El historial lista cada ejecución, también las de los agentes en servidores y equipos, con filtros por tipo (copia, restauración, comprobación de restauración, exportación, importación, mantenimiento) y por trabajo. El directorio y las páginas de los trabajos indican qué trabajo copia un objeto.

Desde la 0.4.2 la primera pregunta de un trabajo de correo es qué debe hacer: copiar («Back up»: restaurar carpetas, calendario, contactos y buzones completos tal como estaban en un punto de restauración), archivar («Archive»: conservar cada correo con detección de manipulaciones, capturado antes de que los usuarios puedan cambiarlo o borrarlo) o ambos («Back up and archive»), que es el valor por defecto de un trabajo nuevo. Archivar captura el correo por las vías que el editor ofrece para cada tipo de buzón del trabajo: desde la 0.4.4 Microsoft Graph o el journaling de Exchange para Microsoft 365, y la sincronización IMAP o las copias que reenvía el proveedor de correo para las cuentas IMAP y de Google Workspace, cada una marcada como captura en el transporte o cercana al momento, con al menos una por tipo (los valores por defecto de un trabajo nuevo son Graph y la sincronización IMAP, cada una con una asunción única del correo que ya está en el buzón). La captura cercana al momento no es completa; el apartado del archivo dice lo que no promete. Las vías forman parte de Business y superiores; sin ellas la elección se conserva, pero no capturan nada. Los trabajos que ya archivaban antes de la 0.4.4 conservan solo el journaling, así que no arranca nada nuevo por sí solo. Un trabajo que solo archiva no hace copias programadas (una ejecución iniciada a mano sí copia). Cuando un trabajo archiva, el editor sugiere copiar cada 8 horas en lugar de más a menudo, solo como sugerencia: la programación sigue como usted la fijó. Cuando solo copia, el editor nombra el hueco entre dos ejecuciones, en el que un correo que llega y se borra no está en ninguna copia, y que las copias no tienen detección de manipulaciones. Desde la 0.4.7, «Crear el trabajo recomendado» y «Proteger todo lo que no tiene trabajo» también archivan cuando la instalación ofrece la captura desde el buzón: el nuevo trabajo de correo sobre todos los objetos copia y archiva, y un trabajo de correo sobre todos los objetos que todavía no archiva se cambia a archivar, conservando sus programaciones; un trabajo sobre objetos seleccionados no se cambia nunca.

Alertas, advertencias y correo de notificaciones

Las reglas de alerta envían un correo, un aviso en la campana de notificaciones o un webhook firmado cuando falla una copia, no se supera una comprobación de restauración o el almacenamiento está dañado, y cada envío queda registrado. Un webhook puede publicar un mensaje de chat en su lugar: Discord, Slack o Microsoft Teams, elegido a partir de la URL del webhook, junto al sobre firmado de Restow. Una respuesta 4xx de un servicio de chat termina un envío de inmediato en lugar de reintentarlo.

El evento backup.overdue abarca buzones, OneDrives, cuentas IMAP, equipos e invitados de Proxmox, tiene en cuenta las programaciones de los trabajos de copia, y una regla de alerta puede fijar su propio plazo, de 24 a 720 horas. Las advertencias indican por qué no se copiaron elementos concretos (carpeta, asunto, fecha, causa y qué hacer) y se pueden confirmar con una nota. La campana lleva a la causa y una página Notificaciones guarda el historial.

Desde la 0.4.0, la matriz de notificaciones, en Integraciones, Notificaciones, muestra los eventos como filas, agrupados y marcados por gravedad, y la campana, cada webhook y cada destinatario de notificaciones como columnas, cada una con las opciones rápidas «Solo errores», «Errores y advertencias» y «Todo». Una regla de alerta ya no envía un evento a un canal cuya columna lo tiene desactivado. Nada cambió al actualizar, porque la migración rellenó cada columna con lo que el canal recibía antes. Un webhook creado después empieza con los valores por defecto de su formato: Discord, Slack y Teams reciben errores y advertencias, un webhook JSON firmado lo recibe todo. Guardar la matriz queda en el registro de auditoría.

Desde la 0.4.7 Restow le avisa además antes de que caduque el secreto de cliente o el certificado del registro de aplicación central de Microsoft 365, o de la aplicación propia de una fuente: 30 días antes, de nuevo 7 días antes y una vez caducado (los eventos installation.app_secret_expiring para los administradores del proveedor y source.app_secret_expiring, que también pueden elegir los administradores del inquilino). La fecha se introduce, o es el fin del propio certificado; Restow no la lee de Microsoft. Los objetos que dejan de copiarse generan object.inactive (un aviso por objeto) u object.inactive_many (una advertencia por inquilino y día).

El correo de notificaciones sale mediante SMTP, mediante Microsoft 365 (una aplicación propia con Mail.Send, o la aplicación de copia) o mediante Google Workspace (una cuenta de servicio con gmail.send), con guías y mensajes de error claros.

Servidores, equipos, recursos compartidos, Proxmox VE y archivos de correo

Microsoft 365 e IMAP no son las únicas fuentes. En todas las ediciones, un agente para Linux y macOS respalda servidores y equipos en su propio Restow, solo con conexiones salientes por HTTPS y solo anexando: el equipo puede añadir copias, pero nunca borrarlas. Véase copia de servidores y equipos. Los recursos SMB y las exportaciones NFS se copian desde el servidor de Restow, sin agente en el servidor de archivos, véase recursos compartidos. Las máquinas virtuales y los contenedores de Proxmox VE 8.4 y posteriores se respaldan como vista previa, también en todas las ediciones, véase copia de Proxmox VE. Los buzones que solo existen como archivos (EML, MSG, MBOX, una exportación de MailStore) se pueden importar como buzón heredado y volver a exportar, véase importación y exportación de correo.

Cuando una copia de seguridad falla

Cada trabajo, elemento, sincronización y verificación fallidos dice qué ocurrió, por qué y qué hacer, en lugar de mostrar solo un mensaje de error sin más. Los fallos se clasifican con un código de causa estable: un permiso de Microsoft 365 que falta, con su nombre; falta de consentimiento del administrador; limitación de velocidad, con la espera que pidió Microsoft; un inicio de sesión IMAP fallido; almacenamiento lleno o que deniega el acceso; una discrepancia de hash. Una cuenta desactivada o sin licencia, y un OneDrive o un sitio que Microsoft bloqueó, ya no son un fallo desde la 0.4.7: figuran como «No se copia» con el motivo. Cada una trae pasos siguientes con enlace a la página de ajustes correspondiente, y los detalles técnicos (estado HTTP, código de error de Graph, identificadores de solicitud, sin secretos) quedan disponibles para un caso de soporte. Véanse, en inglés, las explicaciones de fallos en la documentación.

Límites indicados, no ocultos

• Los chats y los mensajes de canal de Microsoft Teams no forman parte del alcance por ahora. De un grupo de Microsoft 365, el calendario y las conversaciones se copian si usted lo activa; los adjuntos de los eventos de calendario, no.
• Las fuentes IMAP inician sesión solo con contraseña. OAuth2 para fuentes IMAP aún no está implementado; previsto.
• La copia de seguridad y la restauración de Microsoft 365, sitios de SharePoint y calendarios y conversaciones de grupo incluidos, todavía no se han ejecutado contra un inquilino real de Microsoft 365 en las comprobaciones de la versión. Están cubiertas por pruebas contra una API de Graph simulada. La primera copia de un cliente grande puede tardar días por la limitación de velocidad de Graph, y el trabajo muestra la espera. Antes de etiquetar la 0.3.5 no se usó ningún inquilino de Microsoft 365, de modo que ni la continuación de las primeras copias largas ni el reintento tras 5 minutos se han ejecutado contra un inquilino real. La detección de objetos desactivados, sin licencia y bloqueados se probó igual; una respuesta de Microsoft que Restow no reconoce sigue siendo un fallo contabilizado.
• La fecha de caducidad de un secreto de cliente se introduce, no se lee de Microsoft: sin fecha no hay aviso, y una fuente que se conectó mediante una aplicación propia antes de la 0.4.7 no tiene ninguna hasta que se anota en la página de la fuente.
• La conversión del índice de copias de una instalación existente se probó con historiales generados, todavía no con una base de datos de producción de 25 GB; cuánto tarda allí es una estimación.
• Una aplicación Graph propia para una fuente se probó solo con pruebas unitarias y las suites de CI, no contra un inquilino real de Microsoft 365. Los webhooks de chat y el correo de notificaciones mediante Microsoft 365 o Google Workspace se probaron solo con simulaciones.
• La copia de Proxmox VE es una vista previa y todavía no se recomienda como única copia. Detalles en la página de Proxmox VE.
• La copia de seguridad de Google Workspace (Gmail, Google Drive) está prevista. Los chats de Teams y las carpetas públicas de Exchange quedan deliberadamente fuera de alcance por ahora, y los sitios de SharePoint tienen los límites indicados arriba. La importación de PST y OST está prevista: hoy esos archivos se reconocen y se rechazan con una explicación, y los archivos de correo entran como EML, MSG, MBOX o ZIP. Véase la hoja de ruta para lo que está previsto después.
• La copia de servidores y equipos aún no tiene agente para Windows, ni imágenes de disco ni restauración completa del equipo todavía (trabaja a nivel de archivo; las imágenes están previstas), y todavía no hay instantáneas LVM, ZFS o btrfs ni mTLS. Detalles en la página copia de servidores y equipos.

Preguntas frecuentes

Vea a continuación cómo funciona la restauración →

Más en Aprender: ¿hace Microsoft 365 copia de seguridad de sus datos? →

Más en Aprender: RPO y RTO, cómo una planificación determina cuántos datos puede perder →