Спершу про термінологію, бо вона важлива для розуміння всіх чисел нижче. У документації Microsoft ліміт синхронізації рахується в елементах — це файли і папки разом. У нашій тестовій бібліотеці було 997 392 елементи, з яких 890 191 — файли, а решта 107 201 — папки. Коли далі в тексті звучить «мільйон файлів», мова йде саме про елементи в розумінні Microsoft.
Коротка відповідь
- 997 392елементи в тестовій бібліотеці SharePoint
- 52 хвпервинна синхронізація з нуля
- 351/ссередня швидкість, пік — 590 елементів/с
- 3,6 ГБпікове споживання RAM
- 20,6 ГБпікова потреба в місці на диску
- 5,9%завантаження каналу 99 Мбіт/с
- 238 хвнайдовша перевірка змін після повторного входу
- 44 з 45спроб відкрити файл під час цієї фази — тайм-аут
Питання вже не в тому, чи може OneDrive синхронізувати мільйон елементів. Може. Питання — наскільки зручно працювати з такою бібліотекою після синхронізації.
Первинна синхронізація виявилася швидшою, ніж ми очікували, і нічого в системі не «лягло»: процесор був зайнятий на 2,1 ядра з 16, мережа — на 5,9% каналу, диск ніколи не мав черги. Проблема почалася після того, як ми вийшли з сеансу Windows і зайшли знову — тобто зробили те, що робить будь-який користувач щоранку.
Кожне твердження в статті позначене за типом:
Microsoft заявила — підтверджено офіційною документацією.
Ми виміряли — число з логів скрипта, є сирі CSV.
Ми спостерігали — що сталося, без пояснення причини.
Наша інтерпретація — наш висновок, а не факт.
Розкриття: ми розробляємо OneMount — інструмент, який підключає бібліотеки SharePoint як диск Windows без синхронізації, тож маємо очевидний конфлікт інтересів. Тому спершу йдуть цифри й методика, а про продукт — після висновків. Опублікованого незалежного benchmark саме такої конфігурації на мільйоні реальних елементів ми не знайшли; якщо він існує — надішліть, порівняємо методологію.
OneDrive справді підтримує 1 000 000 файлів?
Так. Microsoft заявила: клієнт синхронізації OneDrive у публічному превʼю підтримує до 1 000 000 елементів на один екземпляр синхронізації на пристрої (документація Microsoft). Microsoft поступово вмикає цю функцію для учасників програми Insider.
300 000 чи 1 000 000 елементів?
Це найчастіше джерело плутанини. Microsoft заявила: 300 000 елементів залишаються рекомендацією для оптимальної продуктивності. Заміни одного числа на інше не було — обидва діють одночасно й означають різні речі.
| Кількість | Що це означає |
|---|---|
| до 300 000 елементів | Рекомендація Microsoft для оптимальної продуктивності. Орієнтир для планування. |
| до 1 000 000 елементів | Верхня межа підтримки в публічному превʼю, а не гарантія продуктивності. |
Вимоги до Windows і заліза
Microsoft заявила — вимоги для превʼю на 1 000 000 елементів:
- Windows 11 або Windows Server 2022 і новіші;
- мінімум 16 ГБ RAM, рекомендовано 32 ГБ;
- SSD, не HDD;
- процесор рівня Intel Core i5 / AMD Ryzen 5 або кращий;
- клієнт OneDrive з активованою опцією «Версія для оцінювачів»;
- VDI не підтримується.
Останній пункт вартий уваги окремо: якщо інфраструктура побудована на віртуальних робочих столах, ліміт 1 000 000 вас поки що не стосується. Наш тест тому й виконано на фізичній машині.
Як ми тестували OneDrive з 1 мільйоном файлів
Тестова бібліотека SharePoint
Бібліотека реальна й робоча, не згенерована: документи, експорти, скани та проєктні теки за багато років, із типовими для такого корпусу довгими назвами й глибокою вкладеністю.
Ми виміряли: точну кількість елементів ми взяли з REST API бібліотеки до початку синхронізації: 997 392. Розмір розходиться у двох джерелах, і це нормально: центр адміністрування показує 1,38 ТБ (усе сховище сайту разом з історією версій і кошиком), а база рушія синхронізації нарахувала 995 ГБ логічного обсягу — поточні версії файлів, тобто те, що реально синхронізується.
Тестова машина
| Процесор | Intel Core i9-11900K, 8 ядер / 16 потоків |
|---|---|
| Памʼять | 32 ГБ — верхня рекомендація Microsoft |
| Диск | NVMe SSD під профілем користувача |
| ОС | Windows 11 Pro 25H2, збірка 26200.9457 |
| OneDrive | 26.168.0830.0004, з активованою опцією «Версія для оцінювачів» |
| Канал | Заявлено 99/100 Мбіт/с; вимір перед забігом — 98,57 / 99,63 Мбіт/с, пінг 2 мс |
| Профіль | Чистий, окремий обліковий запис Windows |
Слабших конфігурацій ми не вимірювали, тому всі числа нижче стосуються тільки цього стенду. Очікування, що на машині з меншою памʼяттю й повільнішим диском буде гірше, — припущення, а не вимір.
Методика вимірювання
Обходити дерево файлів під час синхронізації не можна: сам обхід втручається у стан файлів і
спотворив би результат. Тому прогрес читається прямо з бази рушія синхронізації OneDrive
(SyncEngineDatabase.db, SQLite) — наживо й тільки на читання. Звідти беруться
кількість елементів, розподіл «тільки в хмарі / завантажено локально», секунди тротлінгу з
боку сервісу та коди відповідей. Навантаження знімається через CIM, де імена властивостей не
залежать від мови ОС.
Окремо працює проба гідратації: скрипт періодично намагається відкрити невеликий хмарний файл із бібліотеки з жорстким тайм-аутом, фіксує результат і тривалість, після чого повертає файл у хмарний стан. Саме ця проба дала найцікавіші дані.
Наша інтерпретація: ми виходимо з того, що записи в цій базі й формують величину, до якої застосовується ліміт, — але методики підрахунку Microsoft не публікує, тож це припущення.
Скільки часу займає синхронізація 1 000 000 файлів
52 хвилини та 1 013 795 елементів
Час рахується від старту заміру, коли бібліотека ще не була підключена. Кнопку Sync натиснуто через 5 хвилин, лічильник елементів почав зростати ще через 25 секунд. Мільйонну позначку пройдено на 51,8 хвилині, а зростання лічильника припинилося на 52,9.
900,000 items at 46.3 min і
1,000,000 items at 51.7 min, лічильник показує 1 013 795 елементів. У треї —
Backed up and synced.
| Елементів на пристрої | 1 013 795 (905 313 файлів + 108 482 папки) |
|---|---|
| Додано за цей забіг | 997 379 — це і є бібліотека SharePoint |
| Було до старту | 16 418 — особистий OneDrive того ж облікового запису |
| Тільки в хмарі | 905 310 із 905 313 файлів (99,9997%) |
| Завантажено локально | 3 файли |
Клієнт побудував повне дерево з майже мільйона елементів, не завантажуючи вміст: на диску зʼявилися placeholder-и, а не файли. Різниця між 997 379 доданими й 997 392 довідковими — 13 елементів, і це розрахунок на живій бібліотеці, а не список знайдених файлів.
Швидкість синхронізації
| Позначка | Хв від старту | Швидкість на відрізку |
|---|---|---|
| 100 000 | 8,8 | — |
| 300 000 | 16,5 | 402 елем./с |
| 500 000 | 23,1 | 469 елем./с |
| 700 000 | 34,2 | 297 елем./с |
| 900 000 | 46,3 | 296 елем./с |
| 1 000 000 | 51,8 | 297 елем./с |
Ми виміряли: на перших двох відрізках клієнт тримав 402 і 469 елем./с, далі швидкість опустилася до 297 елем./с і залишалася там до кінця: 297,1, потім 296,5, потім 297,4. Це не поступова деградація, а перехід на рівне плато приблизно на середині бібліотеки. Середнє по активній фазі — 351 елем./с, пік — 590 елем./с.
Наша інтерпретація: причину назвати не можемо. Тротлінгу з боку сервісу не було взагалі — нуль вікон, нуль секунд, 1 156 викликів і нуль помилок. Мережа, диск і процесор у другій половині були навантажені не більше, ніж у першій. Рівність плато радше вказує на якусь сталу межу — розмір пакета запиту чи кількість паралельних потоків, — ніж на накопичувану вартість.
Скільки RAM, CPU та диска використовує OneDrive
| Ресурс | Виміряно |
|---|---|
| RAM, пік | 3 579 МБ |
| RAM після завершення | 2 790 МБ |
| CPU, середнє за активну фазу | 2,1 ядра з 16 (13,1%) |
| CPU, пік | 2,35 ядра (14,7%) |
| Трафік, завантажено | близько 2 ГБ |
| Диск, прочитано / записано | 69,3 ГБ / 79,3 ГБ |
| Черга до диска, 95-й перцентиль | 1 (пік 4) |
| База рушія синхронізації | 2 036 МБ фінально, 2 318 МБ у піку |
| Зайнято на диску, підсумково | 6,57 ГБ |
| Пікова потреба в місці | 20,62 ГБ |
| Тротлінг сервісу | 0 вікон, 0 секунд |
База на 2 ГБ. Ми виміряли: рушій витрачає близько 2,1 КБ службової бази на кожен елемент. Ця база лежить у профілі користувача й читається та пишеться при кожній перевірці змін.
149 ГБ дискових операцій на 2 ГБ трафіку. Наша інтерпретація: це приблизно 75-кратне підсилення запису відносно обсягу, отриманого з мережі. На NVMe непомітно; на SATA SSD початкового рівня або на HDD буде зовсім інша історія — і саме тому Microsoft ставить SSD у вимоги.
20,62 ГБ піку проти 6,57 ГБ підсумку. Ми виміряли: вільне місце падало з 253,93 ГБ до 233,31 ГБ на 51,6-й хвилині. Тимчасова потреба в місці була у 3,1 раза більшою за те, що залишилося по завершенні. Практичний наслідок: машина, на якій вільно близько 10 ГБ, впаде посеред синхронізації, хоча кінцевий стан помістився б без проблем.
Чи потрібен швидкий інтернет для OneDrive
Ми запускали тест на каналі 99 Мбіт/с саме щоб відповісти на це питання. Ми виміряли:
| Середня швидкість завантаження | 5,87 Мбіт/с — 5,9% каналу |
|---|---|
| 95-й перцентиль | 12,34 Мбіт/с — 12,5% каналу |
| Семплів із завантаженням каналу ≥ 80% | 0 |
| Семплів активної фази з трафіком < 0,1 Мбіт/с | 45,1% |
| Чистий час передачі всього трафіку | близько 3 хвилин |
Майже половину активної фази мережа фактично мовчала, а весь завантажений трафік на цьому каналі передається за неповних три хвилини — при забігу в 52.
У нашому тесті канал не був вузьким місцем. Швидший інтернет не скоротив би цей забіг.
Наша інтерпретація: вузьке місце — не пропускна здатність, а затримка службових звернень до сервісу й обробка метаданих. Мільйон елементів означає мільйон записів, які треба отримати, розібрати й покласти у власну базу; ширший канал не зменшує кількість цих операцій.
Для планування це означає: якщо у вас уже є стабільні 100 Мбіт/с, апгрейд каналу заради швидшої синхронізації не окупиться — гроші краще вкласти в RAM і NVMe. Нижче 100 Мбіт/с ми не вимірювали.
Що відбувається після синхронізації
238 хвилин «Looking for changes»
Після завершення синхронізації ми вийшли з сеансу Windows і зайшли знову. Жодних змін у бібліотеці, жодного перезавантаження.
Ми виміряли: процес OneDrive стартував о 18:18:03, а стан «Backed up and synced» зʼявився о 22:15:39.
14 255 секунд = 237,6 хвилини = 3 години 58 хвилин — стільки клієнт перевіряв зміни в бібліотеці, у якій нічого не змінилося. Це в 4,6 раза довше за саму синхронізацію.
Важливо одразу: ці 238 хвилин не повторилися. Три наступні цикли входу на тій самій машині з тією самою бібліотекою тривали 20,7–36,6 секунди, і всі проби відкриття файлів у них були успішні — деталі в розділі про повторні цикли нижче.
Детальні заміри навантаження охоплюють 116,9 хвилини з 237,6 — скрипт спостереження був запущений не з першої секунди. Повна тривалість рахується від старту процесу OneDrive до появи статусу; ці дві точки зафіксовані надійно.
| Викликів до сервісу | 14 — з них 2 EnumChanges; помилок 0 |
|---|---|
| Завантажено з мережі | близько 22 МБ (верхня межа по всій машині) |
| Диск, процес OneDrive | 0,50 ГБ прочитано / 0,17 ГБ записано |
| База рушія | не змінилася |
| Приріст елементів | нуль — жодного запису |
| CPU | 1,03 ядра в середньому, пік 1,79 |
| RAM | зросла з 936 МБ до 2 501 МБ |
Ми виміряли: лічильник елементів не змінився жодного разу за всю спостережувану фазу — 1 013 795 на кожному семплі. Два нові елементи зʼявилися через 33 секунди після появи статусу «Backed up and synced». Із 19 звернень EnumChanges на саму фазу припали лише 2, решта 17 — на чверть години після її завершення.
Наша інтерпретація: це не схоже на завантаження даних і навіть не на активний діалог із сервісом, а радше на довгу внутрішню роботу з власним станом — з тією самою базою на 2 ГБ. Підтвердити не можемо: OneDrive не публікує, що саме робить у цій фазі.
Ми спостерігали: ззовні фаза виглядає нормально. Іконка в треї показує «Looking for changes» — те саме, що під час пʼятисекундної перевірки після звичайного ранкового ввімкнення. Ми не побачили жодного індикатора прогресу, оцінки часу чи попередження. У штатному інтерфейсі клієнта ми не знайшли ознаки, яка відрізняла б «зачекай 20 секунд» від «зачекай 4 години».
Файли не відкриваються під час перевірки
Це вже не спостереження на око, а вимір: проба гідратації працювала постійно.
| Коли | Спроб | Невдалих | Частка |
|---|---|---|---|
| Під час перевірки змін | 45 | 44 | 98% |
| Після виходу в робочий стан | 9 | 0 | 0% |
Ми виміряли: з 45 спроб відкрити файл під час фази вдалася одна, і зайняла вона 49 342 мс — майже 50 секунд на файл розміром у сотні кілобайтів. Після виходу клієнта в робочий стан ті самі проби займали 305–645 мс.
Помилка 0x800701AA
Тут потрібна точність. Автоматична проба обриває спробу на 60-й секунді й записує
timeout, тобто припиняє виклик раніше, ніж Windows устигає повернути код помилки.
Ми спостерігали: код зʼявився при ручному відкритті файла на
початку тієї самої фази:
0x800701AA — The cloud operation was not completed before the time-out period
expired.
Ми спостерігали: Excel двічі відреагував на цю ситуацію повідомленням «file format or file extension is not valid» — тобто застосунок отримав частковий або порожній потік і зробив із цього власний хибний висновок. Наша інтерпретація: саме так виникають конфліктні копії та «зіпсовані» документи: користувач бачить помилку формату, пересохраняє файл під іншим імʼям — і далі ланцюжок розгортається вже без участі OneDrive.
Чи повторюється це після кожного перезавантаження?
Було б нечесно зробити з 238 хвилин правило. Ми провели третій тест — цикли перезавантаження й входу в сеанс на тій самій машині з тією самою бібліотекою. Записалося чотири прогони, три з них захопили повний цикл.
| Цикл | Тригер | До «Backed up and synced» |
|---|---|---|
| 1 | Чисте перезавантаження | 36,6 с (129,6 с від завантаження системи) |
| 2 | Вхід у сеанс, машина працювала 11 год | 20,7 с |
| 3 | Вхід у сеанс, 74 хв після старту | 35,8 с |
Ми виміряли: розкид на однаковій основі — 20,7–36,6 секунди. Проба гідратації за ці цикли виконалась 12 разів із 12 успішно, причому шість проб припали саме на стан «Looking for changes» — усі успішні, 707–2 572 мс. У сталому стані процес тримав 1 507–2 187 МБ памʼяті: на мільйонній бібліотеці півтора-два гігабайти RAM зайняті постійно.
[11:20:31] state -> LookingForChanges і три проби поспіль успішні
(2 212, 707 і 1 062 мс). Та сама назва стану, що й під час 238-хвилинної фази, але поведінка
протилежна.
Застереження: ми не можемо стверджувати, що в цих циклах клієнт виконував той самий обсяг роботи — довга фаза була першим входом після первинної синхронізації, наступні три — ні. Частоту ми не вимірювали.
Наша інтерпретація: саме в цьому й полягає експлуатаційна проблема. Подія, яка трапляється рідко й непередбачувано, але триває годинами й виглядає як норма, керується гірше, ніж відверта помилка: помилку видно в моніторингу, а цей стан — ні.
Що означає мільйон файлів для сотень ПК
Наша інтерпретація: усе в цьому розділі — висновки з досвіду впровадження, а не виміряні числа.
Ресурси множаться на кількість машин. 6,6 ГБ на диску в сталому стані й до 21 ГБ на піку — на кожному пристрої. 2 ГБ службової бази, яку треба читати й писати при кожній перевірці змін. 3,6 ГБ RAM на піку: на машинах із 8 ГБ це вже конкуренція з робочими застосунками, і вимога Microsoft у 16 ГБ мінімум — не формальність.
Рідкісна подія на великому парку перестає бути рідкісною. Частоти патологічної фази ми не знаємо й вигадувати не будемо, але логіка масштабу однозначна: на сотнях машин навіть рідкісна епізодична проблема перестає бути проблемою одного користувача — її масштаб визначається кількістю пристроїв і частотою таких подій.
Користувачі не чекають. 52 хвилини отримано на ідеальній машині без стороннього навантаження; на робочому ноутбуці кожне відкриття файла чи запуск Excel конкурує з синхронізацією за ті самі диск і процесор.
Другий пристрій — це другий такий самий забіг. Ліміт сформульований як «на екземпляр синхронізації на пристрої»: людина з ноутбуком і стаціонарним ПК проходить увесь цикл двічі.
Що показав тест
Працює краще, ніж очікувалося. Первинна синхронізація мільйона елементів швидка, передбачувана й дешева за ресурсами: 52 хвилини, 2 ГБ трафіку, 2 ядра з 16, нуль помилок сервісу, нуль тротлінгу. Інженерно це серйозний результат.
Що виявилося проблемою в нашому тесті. Після первинної синхронізації клієнт провів 238 хвилин у стані «Looking for changes», і 44 з 45 спроб відкрити файл завершилися тайм-аутом. Три наступні цикли входу цю поведінку не відтворили.
Практичні орієнтири:
- До 300 000 елементів — синхронізація OneDrive залишається розумним вибором, і наші дані рекомендації Microsoft не суперечать.
- Від 300 000 до 1 000 000 — працюватиме, але лише на машинах, що відповідають вимогам превʼю, і з розумінням, що ви на території «підтримується», а не «рекомендується».
- Парк із сотень машин — оцінюйте не час первинної синхронізації, а вартість супроводу сталого стану.
- VDI — ліміт 1 000 000 вас не стосується.
Потрібно працювати з великою бібліотекою SharePoint без локальної синхронізації?
OneMount підключає SharePoint і OneDrive як диск Windows: файли залишаються в хмарі, а користувач працює з ними у Провіднику — без первинної синхронізації великої бібліотеки й без локального індексу мільйона елементів.
Спробувати OneMount →Як працювати з великою бібліотекою SharePoint
Розділити бібліотеку
Розбити корпус на кілька бібліотек або сайтів так, щоб кожен пристрій синхронізував менше 300 000 елементів. Працює, але вимагає перебудови структури, переучування людей і ламає посилання — часто організаційно дорожче, ніж технічно.
Вибіркова синхронізація
Опція «Вибрати папки» дозволяє не тягнути все дерево. Але ліміт рахує те, що ви вибрали, а користувачі рано чи пізно вмикають зайве — і це не рятує від фази перевірки змін для того, що таки синхронізується.
Робота через браузер
Найбезпечніший варіант з точки зору клієнта й найгірший з точки зору звички: там, де люди роками працювали з буквою диска, повернення до вебінтерфейсу зустрічає опір, і частина команди знайде обхідні шляхи.
Підключити SharePoint як диск без синхронізації
Напрямок, у якому пішли ми — і тут повторимо розкриття конфлікту інтересів: ми розробляємо OneMount, тому не є нейтральною стороною.
Логіка проста. Усі числа в цій статті — 52 хвилини, 2 ГБ бази, 149 ГБ дискових операцій, 238 хвилин перевірки — це вартість утримання локальної копії стану мільйона елементів. Без неї немає й цієї вартості: нема що перевіряти після входу, нема бази, яка росте лінійно з кількістю елементів, нема піку в 21 ГБ на системному диску. Натомість зʼявляються інші компроміси: потрібне зʼєднання, а затримка відкриття документа залежить від каналу, а не від локального диска.
Наша інтерпретація: для бібліотек, де більшість корпусу — архів, до якого звертаються зрідка (у нашій тестовій за 30 днів торкнулися близько 2% файлів), тримати повний локальний індекс мільйона елементів на кожному пристрої виглядає як велика плата за малу користь. Але це наша оцінка, і ваш профіль використання може бути іншим.
FAQ: OneDrive і 1 000 000 файлів
Скільки файлів може синхронізувати OneDrive?
До 1 000 000 елементів на один екземпляр синхронізації на пристрої — у публічному превʼю, за умови відповідності вимогам. Ліміт рахується в елементах, тобто файли й папки разом.
Який ліміт OneDrive — 300 000 чи 1 000 000 файлів?
Обидва. 300 000 — рекомендація Microsoft для оптимальної продуктивності, 1 000 000 — верхня межа підтримки в публічному превʼю. Заміни одного числа на інше не було.
Скільки часу займає синхронізація 1 мільйона файлів?
У нашому тесті — 52 хвилини для 997 392 елементів на машині з Core i9, 32 ГБ RAM, NVMe SSD і каналом 99 Мбіт/с. Середня швидкість активної фази — 351 елемент/с. На слабшій машині або з паралельним навантаженням буде довше.
Чи можна синхронізувати 1 мільйон файлів OneDrive на Windows 11?
У публічному превʼю Microsoft підтримує до 1 000 000 елементів на один екземпляр синхронізації за умови виконання вимог до Windows, RAM, SSD і клієнта OneDrive. У нашому тесті Windows 11 Pro 25H2 із 32 ГБ RAM і NVMe SSD синхронізувала 997 392 елементи приблизно за 52 хвилини.
Чому OneDrive зависає на «Looking for changes»?
Ми зафіксували два режими з однаковою назвою в інтерфейсі: короткий (20,7–36,6 секунди, файли доступні) і довгий (238 хвилин, 44 з 45 спроб відкрити файл завершились тайм-аутом). Причину переходу в довгий режим ми не встановили, а ознаки, яка б розрізняла ці стани, у штатному інтерфейсі немає.
Чому OneDrive повільно синхронізує велику бібліотеку?
За нашими вимірами вузьке місце — не мережа й не диск, а затримка службових звернень до сервісу та обробка метаданих. Показово, що швидкість тримається на рівні 402–469 елементів/с лише на першій половині бібліотеки, а далі падає до сталих 297 і більше не відновлюється.
Скільки RAM використовує OneDrive?
Пік під час первинної синхронізації — 3 579 МБ. У сталому стані, коли нічого не відбувається, процес тримав 1 507–2 187 МБ. У фазі тривалої перевірки змін споживання зростало з 936 МБ до 2 501 МБ за дві години спостереження.
Скільки місця на диску займає синхронізація мільйона елементів?
6,57 ГБ у сталому стані при повністю хмарних файлах, з піком до 20,62 ГБ під час забігу. З них 2 036 МБ — службова база рушія синхронізації, приблизно 2,1 КБ на елемент.
Чи потрібен швидкий інтернет для синхронізації OneDrive?
За нашими вимірами — ні, якщо у вас уже близько 100 Мбіт/с. OneDrive використав у середньому 5,9% каналу й жодного разу не наблизився до насичення.
Що таке помилка OneDrive 0x800701AA?
«The cloud operation was not completed before the time-out period expired» — запит на завантаження вмісту хмарного файла не вклався у відведений час. У нашому тесті ми побачили цей код під час тривалої фази перевірки змін; поза нею жодна спроба відкрити файл не завершилася помилкою.
Чи можна синхронізувати 1 мільйон файлів SharePoint у VDI?
Ні. Microsoft прямо вказує, що VDI не підтримується в цьому превʼю.
Як працювати з великою бібліотекою SharePoint без синхронізації?
Варіантів чотири: розділити бібліотеку, синхронізувати вибірково, залишити людей у браузері або підключити бібліотеку як диск Windows без локальної копії стану. Останній варіант знімає всю вартість, виміряну в цій статті, але вимагає постійного зʼєднання — детальніше в розділі «Як працювати з великою бібліотекою SharePoint».
Практичний бік питання — як саме підключити SharePoint буквою диска, які методи існують і що з них витримує навантаження: підключення SharePoint як мережевого диска у Windows →
Якщо ви вже проходили цей шлях і впізнаєте симптоми — наша історія про рік боротьби з синхронізацією терабайтної бібліотеки →
Джерела
- Microsoft — обмеження та ліміти в OneDrive і SharePoint: рекомендація 300 000 елементів.
- Microsoft Learn — підтримка клієнта синхронізації у VDI.
- Microsoft — синхронізація OneDrive застрягла на «processing changes».
- Власні заміри SkylFlow, 19–20 вересня 2026: три тести на фізичній машині, повний лог у CSV і JSON.
Відтворюваність. Усі числа отримані власним скриптом вимірювання, який читає базу рушія синхронізації OneDrive наживо й тільки на читання, а навантаження знімає через CIM. Скрипт, протокол тесту й сирі CSV готуємо до публікації — напишіть нам, якщо хочете повторити тест на своїй бібліотеці.