Primero, una precisión terminológica de la que dependen todas las cifras siguientes. Microsoft cuenta el límite de sincronización en elementos: archivos y carpetas juntos. Nuestra biblioteca de prueba tenía 997 392 elementos, de los cuales 890 191 eran archivos y los 107 201 restantes, carpetas. Cuando en este artículo se habla de «un millón de archivos», se trata de elementos en el sentido de Microsoft.
La respuesta corta
- 997 392elementos en la biblioteca de prueba de SharePoint
- 52 minsincronización inicial desde cero
- 351/svelocidad media, con un pico de 590 elementos/s
- 3,6 GBuso máximo de RAM
- 20,6 GBespacio en disco necesario en el pico
- 5,9 %de un enlace de 99 Mbps utilizado
- 238 minla comprobación de cambios más larga tras volver a iniciar sesión
- 44 de 45intentos de abrir un archivo en esa fase acabaron en tiempo de espera
La pregunta ya no es si OneDrive puede sincronizar un millón de elementos. Puede. La pregunta es cuán manejable resulta esa biblioteca una vez terminada la sincronización.
La sincronización inicial fue más rápida de lo que esperábamos y nada en el equipo se resintió: la CPU trabajó a 2,1 núcleos de 16, la red al 5,9 % del enlace y la cola de disco nunca se acumuló. El problema empezó después de cerrar la sesión de Windows y volver a entrar — es decir, lo que hace cualquier usuario cada mañana.
Cada afirmación del artículo está etiquetada por tipo:
Microsoft dice — confirmado por la documentación oficial.
Hemos medido — un dato de nuestros registros, con los CSV en bruto.
Hemos observado — lo que ocurrió, sin explicar por qué.
Nuestra interpretación — nuestra conclusión, no un hecho.
Declaración de interés: desarrollamos OneMount, una herramienta que monta bibliotecas de SharePoint como unidad de Windows sin sincronizar, así que tenemos un conflicto de interés evidente. Por eso las cifras y el método van primero, y el producto solo después de las conclusiones. No hemos encontrado ninguna prueba independiente publicada de esta configuración con un millón de elementos reales; si existe, envíenosla y compararemos metodologías.
¿Admite OneDrive realmente 1 000 000 de archivos?
Sí. Microsoft dice: en versión preliminar pública el cliente de sincronización de OneDrive admite hasta 1 000 000 de elementos por instancia de sincronización y dispositivo (documentación de Microsoft). Microsoft está activando la función de forma gradual para los participantes del programa Insider.
¿El límite de OneDrive es 300 000 o 1 000 000 de elementos?
Es la confusión más habitual. Microsoft dice: 300 000 elementos siguen siendo la recomendación para un rendimiento óptimo. Una cifra no ha sustituido a la otra: ambas se aplican a la vez y significan cosas distintas.
| Cifra | Qué significa |
|---|---|
| hasta 300 000 elementos | Recomendación de Microsoft para un rendimiento óptimo. La cifra con la que planificar. |
| hasta 1 000 000 de elementos | Límite superior de soporte en versión preliminar pública, no una garantía de rendimiento. |
Requisitos de Windows y de hardware
Microsoft dice — requisitos para la versión preliminar de 1 000 000 de elementos:
- Windows 11 o Windows Server 2022 y posteriores;
- al menos 16 GB de RAM, 32 GB recomendados;
- un SSD, no un disco duro;
- procesador de la clase Intel Core i5 / AMD Ryzen 5 o superior;
- el cliente de OneDrive con la opción de compilaciones preliminares activada;
- VDI no es compatible.
Este último punto merece atención aparte: si su infraestructura se basa en escritorios virtuales, el límite de 1 000 000 aún no le afecta. Por eso nuestra prueba se hizo en una máquina física.
Cómo probamos OneDrive con 1 millón de archivos
La biblioteca de prueba de SharePoint
La biblioteca es real y está en uso diario, no generada: documentos, exportaciones, escaneos y carpetas de proyecto acumulados durante años, con los nombres largos y la anidación profunda propios de un corpus así.
Hemos medido: el recuento exacto salió de la API REST de la biblioteca antes de empezar la sincronización — 997 392. Hay dos cifras de tamaño que no coinciden, y es normal: el centro de administración informa de 1,38 TB (todo el almacenamiento del sitio, incluidos el historial de versiones y la papelera), mientras que la base de datos del motor de sincronización contabilizó 995 GB de tamaño lógico — las versiones actuales de los archivos, que es lo que realmente se sincroniza.
La máquina de prueba
| CPU | Intel Core i9-11900K, 8 núcleos / 16 hilos |
|---|---|
| Memoria | 32 GB — la recomendación superior de Microsoft |
| Disco | SSD NVMe con el perfil de usuario |
| Sistema | Windows 11 Pro 25H2, compilación 26200.9457 |
| OneDrive | 26.168.0830.0004, compilaciones preliminares activadas |
| Conexión | 99/100 Mbps contratados; medidos antes de la prueba: 98,57 / 99,63 Mbps, 2 ms de ping |
| Perfil | Una cuenta de Windows limpia e independiente |
No medimos configuraciones más modestas, así que todas las cifras siguientes valen solo para este banco de pruebas. Que una máquina con menos memoria y un disco más lento vaya peor es una suposición nuestra, no una medición.
Cómo medimos
Recorrer el árbol de archivos durante la sincronización no es una opción: el propio recorrido
toca el estado de los archivos y distorsionaría lo que se pretende medir. Así que no lo hicimos.
El progreso se lee directamente de la base de datos del motor de sincronización de OneDrive
(SyncEngineDatabase.db, SQLite), en vivo y en modo solo lectura. De ahí salen el
recuento de elementos, el reparto entre «solo en la nube» y «descargado localmente», los
segundos de limitación por parte del servicio y los códigos de respuesta. Los datos de carga se
toman por CIM, donde los nombres de las propiedades no dependen del idioma del sistema.
En paralelo corre una sonda de hidratación: el script intenta periódicamente abrir un archivo pequeño en la nube desde la biblioteca con un tiempo límite estricto, registra el resultado y la duración, y después devuelve el archivo a su estado en la nube. Esa sonda dio los datos más interesantes de toda la prueba.
Nuestra interpretación: damos por hecho que son los registros de esa base de datos los que cuentan para el límite de 300 000 / 1 000 000, pero Microsoft no publica su método de recuento, así que es una suposición.
¿Cuánto tarda en sincronizar 1 000 000 de archivos?
52 minutos y 1 013 795 elementos
El reloj empieza cuando arrancó la monitorización, con la biblioteca aún sin conectar. Sync se pulsó a los cinco minutos y el contador de elementos empezó a moverse 25 segundos después. El elemento un millón se superó en el minuto 51,8, y el contador dejó de crecer en el 52,9.
900,000 items at 46.3 min y
1,000,000 items at 51.7 min, con el contador en 1 013 795. El icono de la bandeja
marca Backed up and synced.
| Elementos en el dispositivo | 1 013 795 (905 313 archivos + 108 482 carpetas) |
|---|---|
| Añadidos en esta prueba | 997 379 — la biblioteca de SharePoint |
| Presentes antes de empezar | 16 418 — el OneDrive personal de la misma cuenta |
| Solo en la nube | 905 310 de 905 313 archivos (99,9997 %) |
| Descargados localmente | 3 archivos |
El cliente hizo exactamente lo prometido: construyó un árbol completo de casi un millón de elementos sin descargar contenido. Lo que aterrizó en el disco fueron marcadores de posición, no archivos. La diferencia entre los 997 379 añadidos y los 997 392 de referencia es de 13 elementos: aritmética entre dos recuentos tomados en momentos distintos sobre una biblioteca viva, no una lista de archivos que hayamos buscado.
Velocidad de sincronización de OneDrive
| Hito | Min desde el inicio | Velocidad del tramo |
|---|---|---|
| 100 000 | 8,8 | — |
| 300 000 | 16,5 | 402 elementos/s |
| 500 000 | 23,1 | 469 elementos/s |
| 700 000 | 34,2 | 297 elementos/s |
| 900 000 | 46,3 | 296 elementos/s |
| 1 000 000 | 51,8 | 297 elementos/s |
Hemos medido: en los dos primeros tramos el cliente mantuvo 402 y 469 elementos/s; después la velocidad bajó a 297 elementos/s y se quedó ahí hasta el final: 297,1, luego 296,5, luego 297,4. No es una degradación gradual, sino un escalón hacia una meseta plana hacia la mitad de la biblioteca. La media de la fase activa fue de 351 elementos/s, con un pico de 590.
Nuestra interpretación: no podemos señalar la causa. No hubo ninguna limitación por parte del servicio — cero ventanas, cero segundos, 1 156 llamadas y cero errores. La red, el disco y la CPU no estuvieron más ocupados en la segunda mitad que en la primera. Lo plana que es la meseta apunta más a un techo fijo — el tamaño del lote de peticiones o el número de flujos en paralelo — que a un coste acumulativo.
¿Cuánta RAM, CPU y disco usa OneDrive?
| Recurso | Medido |
|---|---|
| RAM, pico | 3 579 MB |
| RAM al terminar | 2 790 MB |
| CPU, media en la fase activa | 2,1 de 16 núcleos (13,1 %) |
| CPU, pico | 2,35 núcleos (14,7 %) |
| Red, descargado | unos 2 GB |
| Disco, leído / escrito | 69,3 GB / 79,3 GB |
| Cola de disco, percentil 95 | 1 (pico de 4) |
| Base de datos del motor | 2 036 MB final, 2 318 MB en el pico |
| Disco ocupado, final | 6,57 GB |
| Espacio libre necesario en el pico | 20,62 GB |
| Limitación del servicio | 0 ventanas, 0 segundos |
Una base de datos de 2 GB. Hemos medido: el motor gasta alrededor de 2,1 KB de su propia base de datos por elemento. Esa base vive en el perfil del usuario y se lee y se escribe en cada comprobación de cambios.
149 GB de E/S de disco para 2 GB de tráfico. Nuestra interpretación: eso es una amplificación de escritura de unas 75 veces respecto a lo que llegó por la red. En NVMe pasa desapercibido; en un SSD SATA de gama de entrada, o en un disco duro, es otra historia — y por eso Microsoft exige un SSD.
20,62 GB en el pico frente a 6,57 GB al final. Hemos medido: el espacio libre cayó de 253,93 GB a 233,31 GB en el minuto 51,6. La demanda transitoria fue 3,1 veces mayor que lo que quedó ocupado al terminar. Consecuencia práctica: un equipo con unos 10 GB libres se quedará sin disco a media sincronización, aunque el estado final habría cabido de sobra.
¿Hace falta internet rápido para OneDrive?
Hicimos la prueba con una conexión de 99 Mbps precisamente para responder a esto. Hemos medido:
| Velocidad media de descarga | 5,87 Mbps — 5,9 % del enlace |
|---|---|
| Percentil 95 | 12,34 Mbps — 12,5 % del enlace |
| Muestras con el enlace al ≥ 80 % | 0 |
| Muestras de la fase activa por debajo de 0,1 Mbps | 45,1 % |
| Tiempo puro de transferencia de todo el tráfico | unos 3 minutos |
Durante casi la mitad de la fase activa la red estuvo prácticamente en silencio, y todo lo que el cliente descargó cruzaría este enlace en menos de tres minutos — frente a una prueba que duró 52.
En nuestra prueba la conexión no fue el cuello de botella. Una línea más rápida no habría acortado esta sincronización.
Nuestra interpretación: la restricción no es el ancho de banda, sino la latencia de ida y vuelta al servicio y el procesamiento de metadatos. Un millón de elementos significa un millón de registros que hay que pedir, interpretar y escribir en una base de datos local, y una tubería más ancha no reduce cuántas operaciones son.
Para planificar: si ya tiene 100 Mbps estables, ampliar la línea para acelerar la sincronización no se amortiza — ese dinero rinde más en RAM y NVMe. Por debajo de 100 Mbps no hemos medido.
Qué ocurre después de la sincronización
238 minutos en «Looking for changes»
Con la sincronización terminada, cerramos la sesión de Windows y volvimos a entrar. Sin cambios en la biblioteca y sin reiniciar.
Hemos medido: el proceso de OneDrive arrancó a las 18:18:03 y «Backed up and synced» apareció a las 22:15:39.
14 255 segundos = 237,6 minutos = 3 horas y 58 minutos comprobando cambios en una biblioteca donde nada había cambiado. Es 4,6 veces más que la propia sincronización.
Una advertencia importante de entrada: esos 238 minutos no se repitieron. Tres ciclos posteriores de inicio de sesión en la misma máquina con la misma biblioteca duraron entre 20,7 y 36,6 segundos, y todas las sondas de apertura de archivos tuvieron éxito — los detalles están en la sección sobre los ciclos repetidos, más abajo.
Las mediciones detalladas de carga cubren 116,9 de esos 237,6 minutos: el script de monitorización no se lanzó desde el primer segundo. La duración completa se mide desde el arranque del proceso de OneDrive hasta el cambio de estado; ambos puntos están registrados con fiabilidad.
| Llamadas al servicio | 14 — dos de ellas EnumChanges; cero errores |
|---|---|
| Descargado | unos 22 MB (un límite superior para toda la máquina) |
| Disco, proceso de OneDrive | 0,50 GB leídos / 0,17 GB escritos |
| Base de datos del motor | sin cambios |
| Variación del recuento | cero — ni un solo registro |
| CPU | 1,03 núcleos de media, pico de 1,79 |
| RAM | creció de 936 MB a 2 501 MB |
Hemos medido: el contador de elementos no se movió ni una vez en toda la fase observada — 1 013 795 en cada muestra. Dos elementos nuevos aparecieron 33 segundos después de que lo hiciera el estado «Backed up and synced». De las 19 llamadas EnumChanges, solo 2 cayeron dentro de la fase; las otras 17, en el cuarto de hora posterior.
Nuestra interpretación: esto no parece una descarga de datos, ni siquiera un diálogo activo con el servicio. Parece un trabajo interno prolongado contra el propio estado del cliente — la misma base de datos de 2 GB. No podemos confirmarlo: Microsoft no publica qué hace el cliente durante esta fase.
Hemos observado: desde fuera la fase parece normal. El icono de la bandeja marca «Looking for changes», lo mismo que muestra durante la comprobación de cinco segundos tras un arranque cualquiera por la mañana. No vimos ningún indicador de progreso, ninguna estimación de tiempo y ninguna advertencia. En la interfaz estándar del cliente no encontramos nada que distinga «espere 20 segundos» de «espere 4 horas».
Los archivos no se abrían durante la comprobación
Esto está medido, no visto a ojo: la sonda de hidratación estuvo funcionando todo el rato.
| Cuándo | Intentos | Fallidos | Proporción |
|---|---|---|---|
| Durante la comprobación de cambios | 45 | 44 | 98 % |
| Tras alcanzar el estado de trabajo | 9 | 0 | 0 % |
Hemos medido: de 45 intentos de abrir un archivo durante la fase, uno tuvo éxito, y tardó 49 342 ms — casi 50 segundos para un archivo de unos cientos de kilobytes. Una vez que el cliente llegó a su estado de trabajo, esas mismas sondas tardaban entre 305 y 645 ms.
Error 0x800701AA de OneDrive
Aquí conviene ser precisos. La sonda automática aborta a los 60 segundos y registra
timeout, es decir, corta la llamada antes de que Windows devuelva un código de
error. Hemos observado: el código apareció al abrir un archivo a
mano al principio de esa misma fase:
0x800701AA — The cloud operation was not completed before the time-out period
expired.
Hemos observado: Excel respondió dos veces a esto con «file format or file extension is not valid» — la aplicación recibió un flujo parcial o vacío y sacó su propia conclusión equivocada. Nuestra interpretación: así nacen las copias en conflicto y los documentos «dañados». El usuario ve un error de formato, guarda el archivo con otro nombre, y la cadena continúa ya sin intervención de OneDrive.
¿Ocurre esto después de cada reinicio?
Convertir esos 238 minutos en una regla sería deshonesto. Hicimos una tercera prueba: ciclos de reinicio e inicio de sesión en la misma máquina con la misma biblioteca. Se registraron cuatro ejecuciones; tres capturaron un ciclo completo.
| Ciclo | Disparador | Hasta «Backed up and synced» |
|---|---|---|
| 1 | Reinicio limpio | 36,6 s (129,6 s desde el arranque) |
| 2 | Inicio de sesión, equipo encendido 11 horas | 20,7 s |
| 3 | Inicio de sesión, 74 minutos tras el arranque | 35,8 s |
Hemos medido: sobre una base homogénea la horquilla fue de 20,7 a 36,6 segundos. La sonda de hidratación se ejecutó 12 veces con 12 éxitos, y seis de esas sondas cayeron justo en el estado «Looking for changes», todas con éxito, entre 707 y 2 572 ms. En reposo el proceso mantenía entre 1 507 y 2 187 MB de memoria: en una biblioteca de un millón de elementos hay entre uno y medio y dos gigabytes de RAM ocupados de forma permanente.
[11:20:31] state -> LookingForChanges con tres sondas consecutivas correctas
(2 212, 707 y 1 062 ms). El mismo nombre de estado que durante la fase de 238 minutos, y el
comportamiento contrario.
Una salvedad: no podemos afirmar que el cliente estuviera haciendo la misma cantidad de trabajo en esos ciclos. La fase larga fue el primer inicio de sesión tras la sincronización inicial; los tres siguientes, no. No hemos medido con qué frecuencia ocurre.
Nuestra interpretación: precisamente eso es lo que lo convierte en un problema operativo. Un suceso raro e impredecible, pero que dura horas y parece normal, se gestiona peor que un error declarado: un error aparece en la monitorización, y esto no.
Qué significa un millón de archivos en cientos de equipos
Nuestra interpretación: todo lo de esta sección es una conclusión extraída de la experiencia de despliegue, no una cifra medida.
Los recursos se multiplican por el número de equipos. 6,6 GB de disco en reposo y hasta 21 GB en el pico, en cada dispositivo. Una base de datos de servicio de 2 GB que hay que leer y escribir en cada comprobación de cambios. Un pico de 3,6 GB de RAM: en equipos con 8 GB eso ya compite con las aplicaciones de trabajo, y el mínimo de 16 GB de Microsoft no es una formalidad.
Un suceso raro deja de serlo en un parque grande. No sabemos con qué frecuencia se da la fase patológica y no vamos a inventarnos una cifra, pero la aritmética de la escala es inequívoca: en cientos de equipos, incluso un problema esporádico y poco frecuente deja de ser el problema de un usuario — su tamaño lo fija el número de dispositivos y la frecuencia de esos sucesos.
Los usuarios no esperan. Los 52 minutos salieron de una máquina ociosa e ideal; en un portátil de trabajo cada archivo que se abre y cada Excel que se lanza compite con la sincronización por el mismo disco y la misma CPU.
Un segundo dispositivo es una segunda sincronización idéntica. El límite se define por instancia de sincronización y dispositivo: quien tiene portátil y sobremesa pasa por todo el ciclo dos veces.
Qué mostró la prueba
Mejor de lo esperado. La sincronización inicial de un millón de elementos es rápida, predecible y barata en recursos: 52 minutos, 2 GB de tráfico, 2 núcleos de 16, cero errores de servicio, cero limitación. Como ingeniería, es un resultado serio.
Lo que resultó ser un problema en nuestra prueba. Tras la sincronización inicial el cliente pasó 238 minutos en «Looking for changes», y 44 de 45 intentos de abrir un archivo acabaron en tiempo de espera. Tres ciclos posteriores de inicio de sesión no reprodujeron ese comportamiento.
Orientaciones prácticas:
- Hasta 300 000 elementos — la sincronización de OneDrive sigue siendo una elección sensata, y nuestros datos no contradicen la recomendación de Microsoft.
- Entre 300 000 y 1 000 000 — funcionará, pero solo en equipos que cumplan los requisitos de la versión preliminar, y entendiendo que está en terreno «admitido», no «recomendado».
- Un parque de cientos de equipos — presupueste el coste de mantener el estado estable, no el tiempo de la sincronización inicial.
- VDI — el límite de 1 000 000 no le afecta.
¿Necesita trabajar con una biblioteca grande de SharePoint sin sincronizarla localmente?
OneMount monta SharePoint y OneDrive como una unidad de Windows: los archivos se quedan en la nube y la gente trabaja con ellos en el Explorador — sin sincronización inicial de una biblioteca grande y sin índice local de un millón de elementos.
Probar OneMount →Cómo trabajar con una biblioteca grande de SharePoint
Dividir la biblioteca
Repartir el corpus entre varias bibliotecas o sitios para que cada dispositivo sincronice menos de 300 000 elementos. Funciona, pero exige reestructurar, reeducar a la gente y rompe los enlaces existentes: a menudo sale más caro en lo organizativo que en lo técnico.
Sincronización selectiva
«Elegir carpetas» permite no arrastrar todo el árbol. Pero el límite cuenta lo que haya seleccionado, los usuarios acaban marcando más de lo necesario y no le ahorra la fase de comprobación de cambios sobre lo que sí se sincroniza.
Dejar a la gente en el navegador
La opción más segura desde el punto de vista del cliente y la peor desde el de la costumbre: donde la gente lleva años trabajando con una letra de unidad, volver a una interfaz web encuentra resistencia, y parte del equipo buscará atajos.
Montar SharePoint como unidad sin sincronizar
Es la dirección que tomamos nosotros — y aquí repetimos la declaración de interés: desarrollamos OneMount, así que no somos parte neutral.
La lógica es sencilla. Todas las cifras de este artículo — 52 minutos, una base de datos de 2 GB, 149 GB de E/S de disco, 238 minutos de comprobación — son el coste de mantener una copia local del estado de un millón de elementos. Sin esa copia, el coste desaparece: no hay nada que verificar tras iniciar sesión, no hay una base de datos que crezca linealmente con el número de elementos, no hay un pico de 21 GB en la unidad del sistema. A cambio aparecen otros compromisos: hace falta conexión, y lo rápido que se abra un documento depende del enlace y no del disco local.
Nuestra interpretación: en bibliotecas donde la mayor parte del corpus es archivo histórico que se toca rara vez — en la nuestra, alrededor del 2 % de los archivos en 30 días — mantener un índice local completo de un millón de elementos en cada dispositivo parece un precio alto por un beneficio pequeño. Pero es nuestra valoración, y su perfil de uso puede ser distinto.
Preguntas frecuentes: OneDrive y 1 000 000 de archivos
¿Cuántos archivos puede sincronizar OneDrive?
Hasta 1 000 000 de elementos por instancia de sincronización y dispositivo en versión preliminar pública, siempre que se cumplan los requisitos. El límite cuenta elementos, es decir, archivos y carpetas juntos.
¿El límite de OneDrive es 300 000 o 1 000 000 de archivos?
Los dos. 300 000 es la recomendación de Microsoft para un rendimiento óptimo y 1 000 000 es el límite superior de soporte en versión preliminar pública. Una cifra no sustituyó a la otra.
¿Cuánto tarda en sincronizar 1 millón de archivos?
En nuestra prueba, 52 minutos para 997 392 elementos en una máquina con un Core i9, 32 GB de RAM, un SSD NVMe y una conexión de 99 Mbps. La velocidad media de la fase activa fue de 351 elementos/s. En un equipo más modesto, o con otras tareas en marcha, tardará más.
¿Puede OneDrive sincronizar 1 millón de archivos en Windows 11?
En versión preliminar pública Microsoft admite hasta 1 000 000 de elementos por instancia de sincronización, siempre que se cumplan los requisitos de Windows, RAM, SSD y cliente de OneDrive. En nuestra prueba, Windows 11 Pro 25H2 con 32 GB de RAM y un SSD NVMe sincronizó 997 392 elementos en unos 52 minutos.
¿Por qué OneDrive se queda atascado en «Looking for changes»?
Registramos dos modos que comparten nombre en la interfaz: uno corto (de 20,7 a 36,6 segundos, con los archivos disponibles) y otro largo (238 minutos, con 44 de 45 intentos de abrir un archivo agotando el tiempo de espera). No determinamos qué provoca el cambio, y nada en la interfaz estándar distingue uno de otro.
¿Por qué OneDrive sincroniza lento una biblioteca grande?
Según nuestras mediciones, el cuello de botella no es la red ni el disco, sino la latencia de ida y vuelta al servicio y el procesamiento de metadatos. Es revelador que la velocidad se mantenga en 402–469 elementos/s solo durante la primera mitad de la biblioteca y luego baje a 297 constantes sin recuperarse.
¿Cuánta RAM usa OneDrive?
El pico durante la sincronización inicial fue de 3 579 MB. En reposo, sin nada en marcha, el proceso mantenía entre 1 507 y 2 187 MB. Durante la fase larga de comprobación de cambios el consumo subió de 936 MB a 2 501 MB en dos horas de observación.
¿Cuánto espacio en disco ocupa sincronizar un millón de elementos?
6,57 GB en reposo con todos los archivos solo en la nube, con un pico de 20,62 GB durante la sincronización. De ellos, 2 036 MB son la base de datos del motor de sincronización: unos 2,1 KB por elemento.
¿Hace falta internet rápido para sincronizar OneDrive?
Según nuestras mediciones, no — no si ya dispone de unos 100 Mbps. OneDrive usó de media el 5,9 % del enlace y nunca se acercó a saturarlo.
¿Qué es el error 0x800701AA de OneDrive?
«The cloud operation was not completed before the time-out period expired»: la petición para descargar el contenido de un archivo en la nube no terminó en el tiempo permitido. En nuestra prueba vimos este código durante la fase larga de comprobación de cambios; fuera de ella, ningún intento de abrir un archivo falló.
¿Admite OneDrive 1 millón de archivos en VDI?
No. Microsoft indica explícitamente que VDI no es compatible en esta versión preliminar.
¿Cómo trabajar con una biblioteca grande de SharePoint sin sincronizar?
Hay cuatro opciones: dividir la biblioteca, sincronizar de forma selectiva, dejar a la gente en el navegador o montar la biblioteca como unidad de Windows sin copia local del estado. La última elimina todos los costes medidos en este artículo, pero exige conexión permanente — más detalle en cómo trabajar con una biblioteca grande de SharePoint.
Para la parte práctica — cómo asignar SharePoint a una letra de unidad, qué métodos existen y cuáles aguantan la carga: asignar SharePoint como unidad de red en Windows →
Si ya ha recorrido este camino y reconoce los síntomas — nuestra historia del año que pasamos peleando con la sincronización de una biblioteca de un terabyte →
Fuentes
- Microsoft — restricciones y limitaciones en OneDrive y SharePoint: la recomendación de 300 000 elementos.
- Microsoft Learn — compatibilidad del cliente de sincronización con VDI.
- Microsoft — la sincronización de OneDrive atascada en «processing changes».
- Mediciones propias de SkylFlow, 19–20 de septiembre de 2026: tres pruebas en una máquina física, con los registros completos en CSV y JSON.
Reproducibilidad. Todas las cifras proceden de nuestro propio script de medición, que lee la base de datos del motor de sincronización de OneDrive en vivo y en modo solo lectura y recoge los datos de carga por CIM. El script, el protocolo de prueba y los CSV en bruto están en preparación para su publicación: escríbanos si quiere repetir la prueba sobre su propia biblioteca.