Prečo som po rokoch vymenil dd za restic — a čo mi to ušetrilo (419 GB, ak sa pýtate)

24. júla 2026 · 5 min čítania

Niekedy najväčší problém nie je to, že zálohovanie nefunguje — je to, že funguje už tak dlho, že si nikto nevšimne, aké je zbytočne drahé.

Zálohovanie, ktoré fungovalo, len bolo obrovské

Domáci server má týždennú zálohu roky. Pôvodne šlo o obraz malej SD karty — dd, jednoduché, spoľahlivé, nič zložité. Problém prišiel s časom nenápadne: SD karta sa medzitým vymenila za väčší SSD disk, ale spôsob zálohovania ostal rovnaký — dd naďalej robil obraz celého disku, teraz už 238 GB, pri každom behu odznova, bez ohľadu na to, koľko sa od minulého týždňa reálne zmenilo.

Výsledok: 140 až 164 GB komprimovaného obrazu za týždeň, tri uchovávané zálohy naraz spolu zaberajúce 419 GB na zálohovacom disku. Za obraz s takmer nulovou zmenou obsahu oproti predchádzajúcemu týždňu.

Čo napokon prinútilo vec riešiť

Podnet neprišiel z toho, že by záloha zlyhala — prišiel z vedľajšieho vyšetrovania (prečo je dátový disk pod záťažou taký pomalý), pri ktorom sa ukázalo, že nedeľný beh zálohy sa časovo prekrýva s iným pravidelným udržiavacím behom na tom istom disku — dve súbežné, ťažké operácie na tom istom mieste v tom istom čase.

To bola príležitosť vyriešiť rovno oba problémy naraz: veľkosť aj časovanie.

Prečo restic, nie len "menšia dd záloha"

Riešenie nebolo urobiť dd zálohu menšiu (napríklad vynechaním časti disku) — bolo to prejsť na nástroj, ktorý zálohuje inak. restic je jeden statický binárny súbor (netreba ani sudo apt install, netreba systémové závislosti), ktorý zálohuje na úrovni súborov s deduplikáciou — pri každom behu sa na disk zapíše len to, čo sa reálne zmenilo, nie celý obraz odznova.

Namiesto obrazu celého disku bola nová záloha cielená: koreňový systém, docker volumes, a vybrané dôležité dáta (vedomé rozhodnutie vynechať objemné médiá — tie sa v prípade potreby dajú stiahnuť znova, nie sú jedinečné dáta). Pre databázu poznámkovej appky (Joplin) záloha navyše prešla z kopírovania surových súborov živej databázy na logický pg_dumpall export — konzistentný snímok, nie riziko poškodeného zápisu uprostred behu.

Chyba, ktorá sa objavila hneď pri prvom behu — a prečo je poučná

Prvý testovací beh nového skriptu prebehol pod bežným používateľským účtom a vyprodukoval desiatky chýb "permission denied" — na docker volumes, SSH kľúčoch, VPN konfigurácii, TLS certifikátoch mail servera. Nie bug v restic samotnom — jednoducho vlastníctvo týchto súborov patrí rootovi, a bežný účet k nim nemá prístup, hoci starý dd prístup (obraz celého blokového zariadenia) sa touto otázkou nikdy nemusel zaoberať, keďže kopíroval disk na úrovni, ktorá súborové oprávnenia úplne obchádza.

Presun na systémový root cron (/etc/cron.d/, nie osobný crontab bežného účtu) vyriešil všetko naraz — druhý beh mal nula chýb. Zaujímavý detail navyše potvrdil, že deduplikácia funguje presne tak, ako má: druhý beh (tentoraz kompletný, bez chýbajúcich súborov pre permission chyby) pridal do zálohy už len 534 MB nových dát — všetko ostatné bolo identické s tým, čo sa už (čiastočne, cez prvý neúplný beh) zachytilo.

Dôvera sa neoveruje predpokladom, ale skutočným obnovením

Záloha, ktorá sa nikdy neskúsila obnoviť, nie je overená záloha — je to len nádej. Súčasťou prechodu bol preto aj reálny test: restic restore konkrétnych súborov a následné porovnanie (diff) proti originálu. Zhoda, bez rozdielu.

Výsledok v číslach

Predchádzajúci stav: 140 až 164 GB za týždeň, 419 GB v troch uchovávaných zálohách, beh trvajúci vyše troch hodín. Po prechode: približne 11 GB celkovo vďaka deduplikácii, prvý plný beh za približne desať minút. Zálohovací disk klesol z 87 % na 71 % využitia v ten istý deň (vrátane zmazania starých, už nepotrebných dd obrazov). Časovanie behu bolo presunuté mimo kolízie s druhým udržiavacím procesom.

Stará posledná dd záloha nebola zmazaná okamžite — zostala ako poistka, kým sa nový systém plne neoverí zálohou aj obnovou, a zmazala sa až potom.

Druhá vrstva: udržať pri prechode aj pravidlo 3-2-1

Cloudová záloha nie je v tomto setupe žiadna novinka — držím sa pravidla 3-2-1 (aspoň tri kópie dát, na dvoch rôznych médiách, jedna mimo domu) plus studená kópia bokom už dávno, a týždenný upload na cloudové úložisko bol súčasťou reťazca ešte pred prechodom na restic. Problém bol užší, ale reálny: ten existujúci upload skript bol napísaný presne pod starý dd formát (nahrával opi_backup_*.img.gz) — po prechode na restic by ticho prestal nahrávať čokoľvek zmysluplné, keďže nový systém už tento typ súboru vôbec neprodukuje. Tichý, nepovšimnutý výpadok offsite kópie by bol horší než žiadna zmena vôbec.

Namiesto opravy starého skriptu vznikol druhý, nezávislý restic repozitár priamo v cloudovom úložisku (cez existujúce prepojenie, žiadny nový nástroj netreba), so skriptom, ktorý kopíruje snapshoty medzi lokálnym a vzdialeným repozitárom pri zachovaní rovnakej retenčnej politiky — presne tak, aby aj po zmene lokálneho mechanizmu zostalo v platnosti to isté pravidlo, akým sa zálohy riadia dlhodobo.

Čo si z toho odniesť

"Funguje to už roky" nie je to isté ako "je to stále správne dimenzované". Zálohovací spôsob zvolený pre malú SD kartu ostal nezmenený aj po výmene za desaťnásobne väčší disk — nikto sa nepýtal, či to ešte dáva zmysel, kým to nezačalo kolidovať s niečím iným.
Deduplikovaná záloha na úrovni súborov dokáže byť rádovo menšia než opakovaný obraz celého disku — najmä keď sa väčšina dát medzi behmi vôbec nemení.
Zmena spôsobu zálohovania môže odhaliť skryté predpoklady, ktoré starý spôsob nikdy netestoval — tu konkrétne súborové oprávnenia, ktoré dd na úrovni blokového zariadenia jednoducho obchádzal.
Záloha bez otestovaného obnovenia je len predpoklad. Skutočný restore + porovnanie s originálom je jediný spôsob, ako vedieť, že záloha naozaj funguje, nie len že beží bez chybovej hlášky.
Zmena mechanizmu môže potichu podkopať pravidlo, ktoré inak dlhodobo funguje. Pravidlo 3-2-1 (viac kópií, iné médium, kópia mimo domu) tu platilo už predtým — riziko bolo v tom, že starý upload skript bol naviazaný na starý formát súboru a pri tichej zmene formátu by prestal robiť čokoľvek užitočné, bez akejkoľvek chyby, ktorá by na to upozornila.

Zálohovanie je jedna z tých vecí v homelabe, ktoré sa najľahšie nechajú bežať bez povšimnutia roky — presne preto sa oplatí občas sa spýtať, či ešte robí to, čo má, tým najlepším dostupným spôsobom.