Back In Time velice dobrý, ale někdy velice líný

[compaq]

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.

[Roman Vacho]

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.

[Jana]

Jen tak ze zvědavosti jsem zkusila tento dotaz zadat AI a toto odpověděla:

Kód: [Vybrat]

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.