Jak miliony malých souborů zpomalují výkon zálohování v roce 2026

Velké souborové systémy Miliony malých souborů zpomalují zálohování zahlcováním metadat I/O operací, nikoli šířkou pásma. Každý soubor vyžaduje procházení adresářů, volání statistik a operace otevírání/zavírání, což ze záloh dělá pracovní zátěž omezenou na IOPS a latenci. To prodlužuje okna zálohování, zvětšuje velikosti katalogů, snižuje efektivitu deduplikace/komprese a komplikuje plánování kapacity a cíle doby obnovy (RTO).

jestli ty manage Pokud jde o výkon zálohování milionů malých souborů, pravděpodobně jste již zaznamenali kolaps propustnosti navzdory rychlým sítím a úložišti. Tato příručka vysvětluje, proč jsou malé datové sady s velkým objemem souborů obzvláště problematické, jak zkreslují plánování kapacity a praktické strategie, které doporučuji (s více než 15 lety zkušeností v oblasti hostingu a zálohování), jak zkrátit zálohovací okna a řídit náklady na úložiště.

Proč miliony malých souborů ničí výkon zálohování

Většina zálohovacích architektur je optimalizována pro streamování velkých dat. Malé soubory převádějí streamovací úlohu na miliony drobných operací s metadaty. Tento posun je hlavním úzkým hrdlem.

Režie metadat dominuje propustnosti

Každý soubor představuje práci se souborovým systémem: chodící adresáře, atributy statingu, vyhledávání ACL, otevírání popisovačů souborů a výpočet hashů. V Linuxu je to záplava systémových volání; v NTFS to ničí MFT. Zálohy tráví více času „nacházením“ a „kontrolou“ než skutečným čtením bajtů.

Náklady na procházení adresářů a procházení souborů

Zálohovací software musí zjistit, co se změnilo. Prohlížeče souborů procházejí stromy adresářů, porovnávají časová razítka nebo žurnály a vytvářejí seznamy souborů. S desítkami milionů inodů může přenos jakýchkoli dat trvat hodiny, což prodlužuje okno zálohování i u přírůstkových úloh s malými změnami.

Pracovní zátěže s omezenou latencí a vyhledáváním

Malé soubory náhodně ovlivňují I/O operace. Na úložištích NAS nebo polích s pevným diskem se každé čtení souboru může promítnout do vícenásobného vyhledávání. Dokonce i SSD disky pociťují při škálování režijní náklady, protože hloubka fronty a malé velikosti I/O operací snižují efektivní propustnost. Šířka pásma sítě je méně důležitá než hrubé IOPS a latence.

CPU, Hašování a dedupování

Hašování, komprese, šifrování a segmentace malých objektů se přidávají na soubor CPU daň. Dedup enginy vynikají velkými, opakovatelnými částmi; u malých, unikátních souborů klesá poměr deduplikace, rostou výpočetní cykly a repozitáře se fragmentují.

Jak to ovlivňuje plánování kapacity

Nafukování záloh katalogů a indexů

Každý soubor se stává položkou v indexech, manifestech nebo katalozích. S rostoucím počtem rostou i databáze metadat, RAM potřeby zpracování úloh a velikosti obnovených obrazů. Naplánujte paměťový prostor úložiště a serveru pro růst metadat, nejen pro velikost nezpracovaných dat.

Míra změn a uchování násobí úložiště

U milionů souborů i malá procentuální změna vede k obrovskému počtu objektů na úlohu. GFS (Grandfather Father Son) neboli 30–90denní uchovávání dat tuto režii znásobuje, zejména když syntetické plné úložiště znovu vytváří metadata. Křivky růstu úložiště často překvapují týmy, které dimenzovaly úložiště pouze podle TB, nikoli podle počtu souborů.

Nižší zisky z dedup a komprese

Malé, již komprimované formáty (image, protokoly, binární soubory) odolávají kompresi a deduplikaci. Očekávejte, že deduplikace klesne z 5–10× u imagí virtuálních počítačů na 1.2–2× u malých souborů, což přímo zvyšuje požadavky na kapacitu úložiště a výstupní data do cloudu při replikaci mimo pracoviště.

Záložní okno vs. pracovní doba

Pokud dominují metadata I/O, zálohovací okna se prolínají s produkční dobou, což ovlivňuje aplikační I/O. To zvyšuje potřebu přístupů založených na snapshotech, omezování nebo samostatných zálohovacích sítí. Okna musí být plánována s ohledem na odhadovanou dobu trvání procházení souborů a dobu přesunu dat.

Změřte si základní linii (rychlé, praktické testy)

Než přepracujete strategii zálohování, kvantifikujte problém. Jednoduché testy odhalí, kde se nachází úzké hrdlo.

Počítání souborů a měření času chodce souborů

# Count files and average file size (Linux)
find /data -type f -printf '.' | wc -c   # total file count
du -sb /data                              # total bytes
# Estimate walker speed (no read, metadata only)
time find /data -type f -printf "%p\n" > /dev/null

Simulujte inkrementální skenování a tlak I/O

# Rsync walk without copying to estimate traversal cost
time rsync -a --delete --dry-run --stats /data/ /mnt/backup-stub/

# Watch storage behavior during traversal
iostat -xz 5
pidstat -d 5
iotop -oPa

Windows: Měření skenování malých souborů

:: Count files and measure traversal
powershell -Command "Measure-Command { Get-ChildItem -Recurse -File C:\Data | Out-Null }"

:: Test copy with lots of small files
robocopy C:\Data X:\Stub /E /R:0 /W:0 /L /NFL /NDL /NP

Pokud průchod dat dominuje běhové době a disky vykazují vysoké IOPS s nízkým počtem MB/s, jste vázáni na metadata.

Strategie pro urychlení zálohování malých souborů

Používejte zálohy na úrovni snímků a obrazů/bloků

Upřednostňujte snímky úložiště nebo souborového systému (LVM, ZFS, Btrfs, NTFS VSS) v kombinaci se zálohami na úrovni bitové kopie. Tyto snímky čtou bloky ve velkých, sekvenčních proudech a obcházejí výčet na úrovni souborů. Sledování změn bloků (CBT) dále snižuje přírůstkovou zátěž.

Konsolidace malých souborů před zálohováním

Seskupujte malé soubory do větších kontejnerů, abyste snížili režijní náklady na soubor:

• Denní archivy (např. podle adresáře/data) archivujte pomocí TAR nebo ZIP a vytvářejte objekty o velikosti 100–500 MB.
• Používejte nativní balíčkové soubory aplikace (např. balíčkové soubory Gitu, výpisy databáze, maildir do mboxu).
• Použijte úložiště objektů, které ukládá agregované objekty s indexováním manifestů.

Kompromis: Obnovení jednotlivých malých souborů může vyžadovat rozbalení archivu. Vyberte velikosti shardů, které vyvažují rychlost zálohování a granularitu obnovy.

Zvýšení paralelismu a velikosti dávek

Moderní zálohovací nástroje umožňují více vláken čtení a paralelní zpracování souborů.

• Vlákna čtenářů podle zdroje (sledujte CPU a rezerva IOPS).
• Dávkování seznamů (předgenerování seznamů souborů podle adresáře nebo projektu).
• Více úloh zálohování paralelně na samostatných přípojných bodech nebo sdílených položkách.

Vyladění souborových systémů a operačního systému pro metadata

• Pro hluboké adresáře použijte XFS nebo ext4 s dir_index; zakažte aktualizace atime (noatime/relatime).
• Při vytváření souborového systému udržujte dostatek inodů, abyste se vyhnuli tlaku na fragmentaci.
• V systému souborů NTFS využijte deník USN k urychlení detekce přírůstkových změn.
• Udržujte řadiče a firmware aktuální; zajistěte, aby hloubka front nebyla omezena nastavením HBA nebo multipath.

Optimalizace nastavení zálohovacího softwaru

• Povolit CBT nebo inkrementální ukládání založené na deníku, kde je to podporováno.
• Používejte syntetické plné verze, abyste se vyhnuli periodickému opětovnému načítání, ale během syntetizátorových sestavení sledujte I/O operace v repozitáři.
• Upravte velikosti bloků pro odstranění duplicit; větší bloky mohou pomoci se streamováním archivů, menší bloky pomáhají se smíšenými úlohami.
• Škrticí mechanismus během výroby, prasknutí po několika hodinách.

Vyberte správné úložiště pro repozitáře a zdrojové kódy

• Zdroj: Úrovně SSD/NVMe dramaticky zkracují dobu přenosu dat ve srovnání s poli obsahujícími pouze pevné disky.
• Repository: Pro úložiště s velkým množstvím metadat a duplicitních dat používejte SSD nebo SSD cache; udržujte dostatek IOPS pro souběžné úlohy.
• Síť: upřednostňujte nízkou latenci; více 10GbE linek nepomůže, pokud jsou úzkým hrdlem disky.

Vyloučit šum a data o chladu na úrovni vrstvy

• Vyloučit artefakty sestavení, mezipaměti a dočasné soubory.
• Úložiště neměnných dat pro objekty na úrovni chladných vrstev s politikami životního cyklu a neměnností.
• Zkraťte dobu uchovávání pro malé, nestálé soubory, pro konsolidované archivy zachovejte dlouhodobé uchovávání.

Plánování kapacity: Jednoduchý a spolehlivý model

Naplánujte si úložiště i čas. Zde je postup krok za krokem, který používám s podnikovými a hostingovými klienty.

1) Kvantifikace aktiv

• Celkový počet logických dat (TB) a celkový počet souborů.
• Průměrná a mediánová velikost souboru; hloubka adresáře 95. percentilu.
• Denní míra změn v bajtech a v počtu souborů.

2) Odhad denní zálohovací stopy

• Přírůstkové bajty = změněné bajty × (1 − faktor deduplikace/komprese pro malé soubory).
• Růst metadat = nové/změněné soubory × metadata na položku (v katalozích často 200 B–2 KB/soubor).

3) Udržení modelu

• Inkrementální navždy s plnými syntezátory: součet denních přírůstků + réžie syntetizátoru.
• GFS: přidat týdenní/měsíční základní hodnoty; zahrnout duplikaci indexu.
• Replikace mimo pracoviště: Použijte stejnou matematiku pro cílové místo nebo úložiště objektů.

4) Modelování zálohovacího okna

• Doba průchodu = počet souborů ÷ rychlost procházení souborů (soubory/s).
• Doba přenosu dat = změněné bajty ÷ efektivní propustnost streamování.
• Celkové okno = traversal + přenos + syntetizátor/úplné zpracování + bezpečnostní vyrovnávací paměť (20–30 %).

Zpracovaný příklad

Datová sada: Celkem 40 TB, 50 milionů souborů, 1% změna/den v bajtech, 5% v počtu souborů. Faktor dedupizace/komprese: 1.5× pro malé soubory.

• Denně změněné bajty ≈ 400 GB raw → ~266 GB uloženo po 1.5× efektivitě.
• Změněné soubory/den ≈ 2.5 milionu → růst katalogu 2.5 M × 600 B ≈ 1.5 GB/den.
• Rychlost procházení naměřená na 15 tisíc souborů/s s 8 čtečkami → ~167 minut jen na procházku.
• Streamování rychlostí 300 MB/s → 266 GB za přibližně 15 minut.
• Celkové okno ≈ 167 + 15 + 10% režie ≈ ~3.3 hodiny (pokud daný den není syntezátor plně zatížený).

Všimněte si, jak v harmonogramu dominuje procházení souborů, i když je přesouváno málo dat. Největší výhru přináší investice do rychlejšího vstupu/výstupu metadat nebo snížení počtu souborů.

Scénáře a doporučení z reálného světa

Webhosting: Miliony PHP, JS a obrazové podklady

Challenge: drobné soubory v hlubokých stromech napříč sdílený hosting účty. Používejte zálohy podkladových svazků na úrovni snímků a na úrovni obrazů a pro delší uchování archivujte domovské adresáře jednotlivých lokalit každou noc do tarballů o velikosti 200–500 MB.

Poštovní servery (Maildir)

Challenge: Jeden soubor na zprávu, neustálý fluktuační proces. Konsolidovat do periodických archivů poštovních schránek (např. měsíčně) a pro denní archivy používat žurnálování/CBT. Ukládat archivy na objektové úložiště s neměnností pro zajištění souladu s předpisy.

Softwarové repozitáře a artefakty CI/CD

Challenge: vysoký počet souborů a vysoká míra změn. Vyloučte dočasné artefakty, udržujte krátkou dobu uchovávání sestavení a ukládejte balíčky vydaných verzí do úložiště objektů s verzemi pro dlouhodobé uchovávání.

Kontrolní seznam osvědčených postupů

• Pro malé svazky s velkým množstvím souborů preferujte snímky a zálohy na úrovni obrazů/bloků.
• Agregujte malé soubory do větších shardů, abyste snížili režijní náklady na jeden soubor.
• Nejprve škálujte IOPS: SSD/NVMe pro úložiště s velkým množstvím zdrojového kódu a metadat.
• Povolit inkrementální čtení založené na CBT/časopisech a vyladit vlákna čteček.
• Vyloučit šum; vrstvit studená data do úložiště objektů s verzí a neměnnými údaji.
• Změřte dobu průchodu a rychlost procházení souborů; podle toho naplánujte okna.
• Modelujte kapacitu podle počtu souborů a růstu metadat, nikoli pouze podle TB.

Nejčastější dotazy