Kolik místa doopravdy zabírají verze v SharePointu

Existuje představa, kterou v různých obměnách slyším roky: SharePoint přece používá shredded storage, takže si u verzí ukládá jenom rozdíly. Zní to rozumně, opírá se to o skutečnou technologii a ve výsledku to vede k závěru, že verzování je z hlediska místa skoro zadarmo.

Není. A protože jde o tvrzení, které se dá změřit, změřili jsme ho.

Tenhle článek není názor. Je to protokol z měření na živém tenantu Microsoft 365, doplněný o citace z dokumentace Microsoftu. Všechna čísla níže si můžete na svém prostředí zopakovat – postup uvádím včetně konkrétních dotazů.

Co přesně se tvrdí

Mýtus má dvě části a je užitečné je rozdělit, protože jedna z nich je pravdivá:

1. „SharePoint používá shredded storage.” Pravda – jde o reálný mechanismus, který Microsoft zavedl v SharePointu Server 2013.
2. „Takže verze zabírají jen rozdíl oproti předchozí verzi.” Nepravda, alespoň v jediném smyslu, který zákazník může pozorovat a platit: v započtení do kvóty.

Rozdíl mezi těmi dvěma větami je jádro celého nedorozumění a vrátíme se k němu v samostatné kapitole.

Metoda

Měřeno 2. září 2026 na produkčním tenantu Microsoft 365 (SharePoint Online), na demo webu s knihovnou dokumentů v předvýchozím nastavení: verzování zapnuté, dílčí verze vypnuté, limit 500 hlavních verzí.

EnableVersioning: true
EnableMinorVersions: false
MajorVersionLimit: 500

Data se čtou přes SharePoint REST API, které vrací velikost každé verze zvlášť:

/_api/web/GetFileByServerRelativeUrl('<cesta>')/Versions?$select=VersionLabel,Size

Sloupec Size je v dokumentaci Microsoftu k sestavě využití verzí popsán jednoznačně jako „The size of the version in bytes”. Není to tedy odhad ani přepočet – je to velikost, kterou služba u dané verze eviduje.

Provedli jsme tři nezávislá měření: pozorování na reálném dokumentu, řízený pokus a kontrolu úplnosti verze.

Měření 1: reálný dokument se třemi verzemi

Metodický dokument ve wordovém formátu, který vznikal a upravoval se běžnou cestou v průběhu několika měsíců.

Verze	Vznikla	Velikost
1.0	18. 4. 2026	33 485 B
2.0	28. 8. 2026	40 606 B
3.0 (aktuální)	2. 9. 2026	40 728 B
Celkem		114 819 B

Aktuální soubor má 40 728 bajtů. Historie k němu přidává dalších 74 091 bajtů. Dohromady tedy 2,82násobek velikosti souboru, který v knihovně vidíte.

Všimněte si druhého řádku pozorněji, protože ten je nejvýmluvnější. Mezi verzí 2.0 a verzí 3.0 je rozdíl 122 bajtů. Kdyby se ukládaly delty, stála by verze 2.0 řádově stovky bajtů. Eviduje se u ní 40 606 bajtů, tedy prakticky plná velikost dokumentu.

Měření 2: řízený pokus, kde se nezměnil ani bajt obsahu

Pozorování na reálném dokumentu má slabinu – obsah se mezi verzemi měnil, takže by někdo mohl namítnout, že se změnila podstatná část souboru. Proto druhý pokus, navržený tak, aby tuhle námitku vyloučil úplně.

Postup:

1. Do knihovny jsme nahráli textový soubor o velikosti přesně 1 048 576 B (1 MiB).
2. Třikrát po sobě jsme změnili výhradně metadata – hodnotu sloupce Název přes REST. Binární obsah souboru zůstal nedotčený.
3. Po každém kroku jsme odečetli velikosti všech verzí.

Výsledek:

Krok	Aktuální verze	Historické verze	Celkem
Po nahrání	1.0 (1 048 576 B)	–	1,00 MB
Po změně metadat č. 1	2.0 (1 048 576 B)	1.0 = 1 048 576 B	2,00 MB
Po změně metadat č. 2	3.0 (1 048 576 B)	1.0, 2.0	3,00 MB
Po změně metadat č. 3	4.0 (1 048 576 B)	1.0, 2.0, 3.0	4,00 MB

Tři úpravy, při kterých se nezměnil jediný bajt obsahu, zčtyřnásobily místo, které dokument zabírá. Přírůstek na jednu změnu byl pokaždé přesně 1 048 576 bajtů, tedy plná velikost souboru.

Tohle je zároveň odpověď na otázku, kterou dostávám nejčastěji ze všech: ano, i hromadná úprava metadat – doplnění sloupce přes Excel, překlasifikování knihovny, běh skriptu nad tisíci soubory – vytvoří novou verzi u každého dotčeného dokumentu a každá z nich se počítá v plné velikosti.

Měření 3: je historická verze úplný soubor?

Poslední možná námitka: co když je ta hlášená velikost jen účetní fikce a fyzicky tam plná kopie není?

Stáhli jsme obsah historické verze 1.0 přímo:

/_api/web/GetFileByServerRelativeUrl('<cesta>')/Versions(<id>)/$value

Přeneseno 1 048 576 bajtů. Přesná shoda s hlášenou velikostí. Historická verze se tedy chová jako kompletní, samostatně stažitelný soubor, ne jako přírůstek, který by se musel z něčeho skládat.

Testovací soubor byl po měření odstraněn včetně koše.

Odkud se mýtus vzal a proč je napůl pravdivý

Shredded storage skutečně existuje. A existuje i dokument Microsoftu, který ho zmiňuje přesně v souvislosti s velikostí verzí – znalostní článek KB 3038333. Popisuje scénář, který je našemu druhému měření nápadně podobný: stomegabajtový soubor, změna pouze v metadatech, a výsledná hlášená velikost 200 MB.

Microsoft to komentuje takto:

„This behavior is by design. SharePoint Server 2013 uses SQL Server Shredded Storage to improve data transfer performance and reduce storage utilization. But the SharePoint quota component has no direct relationship to how SQL Server stores it physical data. Therefore, the quota component can’t report on the space that’s used on SQL Server physical storage.”

Tady je celý rozpor v jedné citaci. Shredded storage je mechanismus uvnitř SQL Serveru. Kvótová komponenta s ním nemá přímý vztah a fyzické místo v SQL neumí vykázat. Ta věta se často cituje jako důkaz, že „reálně to zabírá míň” – jenže říká něco jiného a mnohem méně příjemného: kvóta o fyzickém uložení nic neví a počítá plné velikosti.

Ke dvěma věcem je přitom potřeba být poctivý:

• Citovaný článek se týká SharePointu Server 2013, tedy on-premises produktu se SQL Serverem. Do SharePointu Online se nedá mechanicky přenášet – SPO ukládá obsah jinak a Microsoft o jeho vnitřním uspořádání nezveřejňuje detaily.
• Kolik místa vaše verze fyzicky zabírají v datacentru Microsoftu, nikdo mimo Microsoft změřit nemůže. A pro vás to nemá praktický význam.

Význam má jediné číslo: to, které se počítá proti vaší kvótě. A to je podle našeho měření i podle dokumentace plná velikost každé verze.

Nepřímý důkaz z dokumentace

Existuje ještě jeden argument, kterého si při čtení dokumentace lze všimnout a který celou věc potvrzuje z druhé strany.

Microsoft v roce 2024 zavedl automatické limity historie verzí a v návodu k plánování úložiště je popisuje takhle:

„Under automatic settings intermittent older versions are trimmed over time, resulting in 96% version storage reduction in six months period compared to count limits.”

A o kus dál, na jiném příkladu, „~94% reduction in version storage used compared to applying count limits only”.

Tahle čísla dávají smysl jenom tehdy, když každá verze zabírá místo úměrné velikosti souboru. Kdyby se ukládaly delty, promazání části mezilehlých verzí by tak dramatickou úsporu přinést nemohlo – nemáte co ušetřit, když tam skoro nic není. Microsoft ty automatické limity nezaváděl proto, že by verze byly levné.

Co s tím prakticky

Verzování je jedna z nejužitečnějších vlastností SharePointu a rada „vypněte ho” by byla špatná. Cílem je platit za ně vědomě.

Zapněte automatické limity historie verzí. Microsoft je sám doporučuje jako výchozí volbu a princip je rozumný: hodnota staré verze pro obnovu s časem klesá. Algoritmus je zdokumentovaný a stojí za to ho znát, protože z něj poznáte, co ještě půjde obnovit:

• všechny verze v rámci limitu 500 během prvních 30 dnů,
• hodinové verze mezi 30. a 60. dnem,
• denní verze mezi 60. a 180. dnem,
• týdenní verze po 180 dnech, dokud se nenaplní strop 500 verzí.

Než něco změníte, spusťte analýzu „co kdyby”. SharePoint umí vygenerovat sestavu využití úložiště verzemi pro web nebo knihovnu a modelovat dopad limitu ještě před jeho nastavením. Vyplatí se to – u velkých webů běží sestava i několik dní, ale získáte reálná čísla místo odhadu.

Prořezání existujících verzí je nevratné. Verze smazané limitem nebo naplánovanou úlohou obcházejí koš a nedají se z něj obnovit. Naopak verze, kterou smaže uživatel ručně, do koše jde – a dokud se koš nevysype, místo drží dál.

Počítejte s výjimkami. U obsahu pod retenční politikou nebo v režimu eDiscovery hold se limity verzí ignorují, dokud výjimka trvá. U dokumentů označených jako záznam je mazání verzí zablokované úplně. Kdo se spoléhá, že limit vyřeší všechno, může být překvapený.

Hlídejte hromadné úpravy metadat. Jak ukázalo druhé měření, je to nejlevnější způsob, jak si nafouknout úložiště, aniž byste přidali jediné užitečné slovo. Před migračním skriptem nebo hromadnou reklasifikací je namístě zvážit, jestli je potřeba mít po celou dobu zapnuté verzování.

Pro představu, co to dělá v běžném provozu: prezentace o 5 MB, kterou tým během roku upraví dvěstěkrát, drží při limitu 500 verzí zhruba gigabajt. Jeden soubor.

Limity tohoto měření

Aby byl závěr poctivý, patří sem i to, co jsme nedokázali:

• Měřili jsme velikosti hlášené službou, ne fyzicky obsazené bloky v úložišti Microsoftu. Ty zvenčí změřit nelze a Microsoft je nezveřejňuje.
• Rozhraní StorageMetrics, kterým jsme chtěli údaje ověřit ještě na úrovni knihovny, vracelo na testovaném tenantu nuly – kontrolu z tohoto směru se nám tedy provést nepodařilo.
• Souhrnné využití úložiště webu se podle dokumentace aktualizuje se zpožděním, řádově až 48 hodin. Okamžité měření rozdílu na kvótě proto není spolehlivá metoda a záměrně jsme se o ni neopírali.
• Měřeno na jednom tenantu, v jedné knihovně, ve výchozím nastavení (500 hlavních verzí, dílčí verze vypnuté).

Co je naopak prokázané: číslo, které SharePoint u každé verze eviduje – a na kterém stojí kvóta – se rovná plné velikosti souboru, a historická verze je samostatně stažitelný celek. Pro rozhodování o úložišti je to ta relevantní veličina.

Co si z toho odnést

1. Ne, verze nejsou delty. Pro kvótu se každá verze počítá v plné velikosti souboru. Dokument se třemi verzemi zabírá zhruba trojnásobek toho, co ukazuje sloupec Velikost.
2. Ani změna pouze metadat není zadarmo. Naměřili jsme přírůstek přesně o plnou velikost souboru na každou takovou změnu. Hromadné úpravy sloupců jsou z pohledu úložiště drahá operace.
3. Shredded storage se týká něčeho jiného. Je to mechanismus uvnitř SQL Serveru u on-premises SharePointu a Microsoft sám píše, že kvótová komponenta s ním nemá přímý vztah. Jako argument „verze jsou levné” neobstojí.
4. Řešení existuje a je zdokumentované. Automatické limity historie verzí, sestava využití, analýza „co kdyby” a prořezání. Microsoft sám uvádí úsporu 94 až 96 procent oproti pouhému počtu verzí.

---

V EP365 řešíme úložiště a governance SharePointu jako součást kontroly prostředí a návrhu governance – včetně toho, kolik vás stojí historie, o které nevíte. Pokud vám kvóta roste rychleji, než dává smysl, ozvěte se nám a projdeme to nad vaším konkrétním tenantem.

V příštím dílu se podíváme na to, co se s obsahem děje na konci jeho života – retence, archivace a proč právě lifecycle rozhoduje o tom, jestli vaše AI odpovídá z platných dokumentů.