Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Software => Téma založeno: compaq 14 Prosince 2025, 21:52:49
-
S úspěchem léta používám Back In Time.
Teď zálohuji cca 300GB dat z luks šifrované micro SD karty na šifrovaný HDD. Záloha (první) běží už třetí den a je na 80%. Prosté kopírování všech souborů by bylo za 12-20 hodin. Proto jsem se rozhodl pro Back In Time, aby v budoucnu byla záloha rychlejší. Prioritu BiT i rsync jsem dal naplno. Nic.
Že to trvá dlouho, to chápu, ale proč jsou procesory využívány na cca 10%, proč je využito málo paměti a swapu, proč se čte z disku minimálně a většinou ne, to mi hlava nebere. Působí to dojmem, že se stroj prostě fláká (viz obrázek). Když kopíruji, nebo hashuji desetisíce fotek, jedou procesory naplno a paměť i swap je zpravidla skoro nadoraz.
Chápu, že je adventní neděle, ale...
Díky za rady a tipy.
-
Musel bys ten Monitor software GNOME nastavit, aby Ti zobrazoval veškeré procesy. Což ty běžné GUI monitorovací programy v základu nedělají. V KDE si to mohu nastavit. V GNOME nevím.
-
Jen tak ze zvědavosti jsem zkusila tento dotaz zadat AI a toto odpověděla:
Tahle situace působí frustrujícím dojmem, ale ve skutečnosti je to docela typické chování pro **rsync + šifrované blokové zařízení + malý zdrojový disk (microSD)**. Kombinace těchto faktorů způsobí, že systém vypadá „líně“, i když reálně jede na hraně toho, co mu hardware dovolí. Pojďme to rozebrat.
---
## 🧩 Proč CPU běží jen na ~10 %
Rsync není nástroj, který by uměl efektivně využít vícejádrové procesory.
Dělá tohle:
- čte malý blok dat
- porovnává ho s cílem
- případně zapisuje
- čeká na I/O
Tohle je **sekvenční proces**, který se většinu času fláká, protože čeká na disk.
CPU se zapojí jen na zlomek času – a to ještě jen jedno jádro.
Navíc:
- **LUKS šifrování** je dnes extrémně rychlé díky AES-NI, takže CPU to skoro nezatíží
- **microSD karta** je brutálně pomalá v náhodném čtení
- rsync čte *malé bloky*, takže microSD je permanentně zahlcená latencí, ne propustností
Výsledek: CPU se nudí, protože čeká na I/O.
---
## 🧩 Proč se skoro nečte z disku
MicroSD karty mají:
- mizerné náhodné čtení (často 1–2 MB/s)
- vysokou latenci
- interní wear-leveling, který způsobuje „záseky“
- při šifrování ještě větší latenci
Rsync navíc:
- čte malé bloky
- dělá spoustu stat() a lstat() volání
- kontroluje metadata
- vytváří snapshot strukturu
To znamená, že místo plynulého čtení typu `dd` nebo `cp` se disk chová jako kdyby ho někdo brzdil každých pár milisekund.
---
## 🧩 Proč paměť ani swap nejsou využité
Rsync není navržený jako „streamovací“ nástroj.
Nepoužívá velké buffery.
Nečte dopředu.
Neprovádí paralelní operace.
Je to nástroj pro **bezpečné, konzistentní kopírování**, ne pro rychlost.
Back In Time nad tím jen staví GUI a snapshot logiku, ale rychlost je pořád limitovaná rsyncem.
---
## 🧩 Proč prosté kopírování je rychlejší
`cp` nebo `rsync --whole-file`:
- čtou velké bloky
- neporovnávají
- nepočítají hashe
- neřeší metadata
- neřeší snapshoty
Takže jedou plynule a využijí maximum toho, co microSD zvládne.
---
## 🧩 Proč první záloha trvá extrémně dlouho
První snapshot je vždy nejpomalejší, protože:
- rsync musí projít *všechny* soubory
- zapsat *všechny* soubory
- vytvořit strukturu snapshotu
- zapsat metadata
- zapsat hardlinky
- řešit šifrování na obou stranách
- a to vše na dvou pomalých médiích (microSD + HDD přes LUKS)
Další zálohy budou rychlé, protože:
- rsync bude přenášet jen změny
- většina dat bude hardlinkovaná
- I/O bude minimální
---
## 🧩 Co s tím, pokud chceš rychlejší první zálohu
Pokud ti jde jen o první zálohu, můžeš použít:
### 1️⃣ Zkopírovat data ručně a pak nechat BiT vytvořit snapshot
Back In Time to umí – pokud cílová složka obsahuje data, rsync je použije jako základ.
### 2️⃣ Použít rsync s parametrem `--whole-file`
Ten vypne delta algoritmus a jede rychleji na pomalých discích:
```
rsync -av --whole-file /zdroj/ /cil/
```
### 3️⃣ Připojit microSD přes rychlejší čtečku
USB 3.0 čtečky dělají obrovský rozdíl.
### 4️⃣ Zkontrolovat, zda microSD není „fake“ nebo degradovaná
Staré nebo levné karty mají extrémně špatné I/O.
---
## 🧩 Shrnutí
Tvůj systém se **nefláká** – jen je limitovaný:
- pomalým zdrojem (microSD)
- sekvenční povahou rsyncu
- snapshot logikou Back In Time
- šifrováním na obou stranách
- malými bloky a vysokou latencí
CPU a RAM se nudí, protože **I/O je úzké hrdlo**.
---
Pokud chceš, můžeme se podívat na konkrétní parametry rsyncu, které Back In Time používá, nebo na to, jak optimalizovat první zálohu.
Pokud to není vhodné tak se omlouvám.