Názory k článku Rozvaha nad zálohováním dat v Linuxu a jejich rychlou plnou obnovou

par profesnich zkusenosti:

* Bitová kopie disku pomocí dd - nefunguje spolehlive ve chvili, kdy zdrojoovy a cilovy disk maji jinou velikost bloku - velikost oddilu se pocita v blocich, takze nastane problem ve chvili, kdy zdrojovoy a cilovy disk maji jinou velikost bloku (512 vs 4096) - resenim je zalohovat s dd oddily, nikoliv cely disk (kdo to dela? :)

* s rsyncem je problem, ze clovek musi znat spoustu parametru, aby opravdu "vsechno" probehlo bez problemu - napr. prenos /var/lib/docker (rsync -avPHSX) - rensenim je tar ;)

(lepsi diskova pole tady samozrejme neresim)

good luck

2. 9. 2026, 01:55 editováno autorem komentáře

Prozkoumal jsem to s tím "dd" a velikostí bloku. U SSD disku se rozlišují logické.a fyzické bloky. Disk může mít fyzické bloky třeba 4096 bajtů, ale má komatibilní režim, kde operačnímu systému bude hlásit 512 bajtů. 512 bajů, jak jsem zjistil, by měl být takový "standard", tedy že to běžný spotřebitelský SSD disk umí, ikdyž fyzické bloky mají ve skutečnosti jinou velikost.

Já mám Debian doma jako amatér - nevím, co řeší profesionál administrátor - avšak jeví se to tak, že pro mě je "dd" v pohodě, protože kdykoliv kouopím nějaký "standardní" SSD disk někde na Alze, tak ten bude 512 bajtů kompatibilní režim umět.

Do detailu problematice disků nerozumí, ale vypadá to, že se nemusím touto limitací "dd" zabývat.

2. 9. 2026, 12:16 editováno autorem komentáře

Pokud nemám virtualizaci, která řeší rychlou obnovu asi nejlépe, tak co zálohovat jen rozdělení disku ?

sudo sgdisk --backup=gpt_bac­kup.bin /dev/sda
Obnova
sudo sgdisk --load-backup=gpt_bac­kup.bin /dev/sda

Snapshoty řeším pomocí Kopia.

Ten hlavní problém, který s tím mám, je, že to nebude umět zálohovat LVM logical volumes, a tipuju že to nepomůže ani s LUKS oddíly - tedy musel bych si LUKS v terminálu ručně vytvářet.

Bohužel s LVM neumí uspokojivě pracovat ani GPart - nějaké funkce jako změnu velikosti umí, ale neumí tam sázet nové oddíly a neuměla mi to udělat ani obdoba GPart v KDE (název si teď nevybavuju).

To je problém, protože seskupit všechny informace na Internetu, aby si to člověk udělal v terminálu, není úplně jen tak - je to na několik hodin práce si to najít, vyzkoušet a sepsat do howto.

Proto používám ten "dd", protože mi všechny tyhle problémy odpadají - to je ta původní myšlenky. Profesionální administrátor Linuxu bude asi jako nejrychlejší variantu považovat, že si vše v terminálu znovu vytvoří (GPT, LVM, LUKS) - ale pro amatérského uživatele, jako já, to moc není, protože ty příkazy jsou pro mě tak trochu žabí polévka, zejména když se k tomu přidají ty příkazy pro LVM. Ten "dd" mě od toho "zachrání".

Když by doma na server někdo "nepotřeboval" šifrovaný disk ani LVM, tak by to tak udělat šlo a odpadne "dd". (Můj pohled na věc - záleží jak kdo chce umět ty relevantní příkazy v terminálu)

2. 9. 2026, 12:27 editováno autorem komentáře

Tak a systémový disk vyhořel. Kromě obnovení systému do stavu, kdy „běží jako dřív, jako by se vlastně nic nestalo“, mám ještě jeden důležitý požadavek: nechci u této činnosti strávit celou neděli.

Tohle zni jako RAID1.

Raid-1 je neco, co na notebooku rozbehnete lusknutím prstu ;) Nebo ne?

Obávám se, že RAID chrání jen před HW problémem. Malware a Uživatel je statisticky vyšší hrozba :-)

Nechrani pred havarii proprietarniho radice ktery uz neni k mani a kde se vyrobce rozhodl pouzit u novych nekompatibilni format ci provozne nekompatibilni format (read only na zachranu dat).
RAID1 neni popis konkretniho reseni. Je to jen popis vyssiho levelu architektury. Tady konci akademik architekt.

Predpokladam (jako typicky sysadmin) tudiz ten nejhorsi mozny scenar. HW raid od vyrobce pojd na mne z boku kde k tomu neni hned druhy kus. A kdyz treba nahodou je tak s jinym firmware ktery nejde normalne stahnout a flashnout/dow­ngradovat/je nekompatibilni, nutno delat force updaty, skryte revize -> ahoj supermicro.

Takze jsou z toho sobota a nedele zafrcane zkusenim open source utilitek, koupi draheho softwaru nebo pripravou na postup k data recovery firme.

Ne že by na té myšlence něco nebylo, ale v kontextu článku je řeč o domácím serveru. Tam nikdo (soudný) asi nebude používat nějaký obskurní proprietární HW RAID.

Děláte jako by ty řadiče odcházeli každý den.
Já ignoruji doporučení výrobce vyměnit řadič po šesti letech a jedu jeden řadič klidně 12 roků. Poté ho měním kvůli technologické zastaralosti. Mám tu jeden Adaptec 4 × SATA II.
Chcete?
Kromě jednoho extrému, kdy kondenzát z klimatizace nakapal do diskového pole, mi řadič nikdy neodešel. Ťuk Ťuk Ťuk.

RAID 1 je řešení jak rychle nahradit vadný disk.
On tam ten disk je připraven k okamžité výměně.
Ani Instant VM Recovery není tak rychlí.
Navíc při správném zarovnání to zdvojnásobí rychlost čtení.

Samozřejmě doba se pohnula a spolehlivost SSD je řádově větší než HDD.
Takže nevýhoda v podobě pořizovací ceny jaksi převáží přínos.
Stejně musíte řešit offline zálohu.
A když jí vyřešíte dostatečně rychle, tak RAID 1 nepotřebujete.
Což s příchodem USB 3.0 není nic drahého.

Ano, ale za to když odejde... Mimochodem zrovna teď o víkendu mi v notebooku odešly zřejmě obvody regulující napětí v napájení NVMe slotu (což je, mimochodem, naprosto raritní závada) takže mi notebook nejdříve odpálil jedno SSD a po výměně během několika hodin pro jistotu i záložní SSD.

a) raid neni zaloha
b) jakykoli obnovovani zaloh je vzdy az to posledni, co chce kdo delat, a vzdy to trva. Ti co maji nejaky disasterrecovery plan (v pisemne podobe na papire), tak alespon vedi, jak dlouho to bude trvat ... ti ostatni ... se pak divi, kdyz zjisti ze to je na tydny.

Instant VM Recovery

Zkusil bych zvážit, zda nezměnit základ celého problému - proč potřebuji takto obnovovat fyzický disk? Přijde mi, že množství případů, kdy by to dávalo smysl, je dnes minimální, ale budu rád, pokud autor uvede, co ho k tomu vede.
Pokud potřebuji spolehlivou obnovu celého OS, pak použiji virtualizaci, kterou kdykoliv nainstaluji během chvilky na jiný stroj. Navíc, pokud potřebuji spolehlivý systém s minimem výpadku, budu mít další stroj v clusteru. Už se opravdu nejedná o nějaké náročné řešení.
Připadá mi to stejné jako opravovat třeba šptnou instalaci Windows. Kdysi jsem to dělal, než jsem zjistil, že je rychlejší a spolehlivější je prostě reinstalovat. Bohužel, takovou radu pak začali dávat i oficiálně z MS.

Když jsem začínal hostovat své docker aplikace, začal jsem na čístém debian serveru, kde jsem prováděl zálohování jen pomocí borgu. A tak nějak jsem ze začátku neřešil zálohu celého serveru, čím víc jsem se dostával do této králíčí nory. Tak jsem přesedlal na Proxmox a roztočil virtuálku z Debianem a zálohy pomocí Proxmox Backup Serveru. Tím bych měl zálohy celého debianu vyřešenou, taktéž jsem si pronajmul vzdálený proxmox backup server a každou noc se provádí vzdálený sync. Takže mám data v bezpečí. A co se týče běžících databází, to mám ošetřené aplikací Portabase.

Kde se dá pronajmout proxmox backup server. Jaho mám doma v lan, takže požár, ani blesk atd to neřeší.

na proxmoxim redditu jsem neco videl, bylo to letos urco najdes.
(ja mam pbs svoje tak jsem to nezkousel ale vypadalo to zajimave pro nekoho kdo nema..)

Veeam agent for Linux. Free vec, software je dlouhodobe stabilni a i free ma podporu pres web. Umi sifrovany volumy a ma volume i file restore moznosti.

Skript na zálohování s pravidly, který používám nejen pro svůj desktop ale také pro další zařízení. https://github.com/tomasmark79/safedata

Ano, tato složitost mi také vadí.

Jak tady už někdo zmínil RAID1, tak to je další varianta, jak snížit riziko nutnosti přeinstalace systému a obnovování. Tedy člověku běží v PC dva stejné disky obsahující stejná data a rychlost čtení je vyšší. Finanční náklady a spotřeba elektřiny také.

Aktuálně to nemám moc snadno udělané. Mám návod na rozdělení disku (používám BTRFS + LUKS), který bych četl v mobilu nebo notebooku a aplikoval při instalaci systému na nový disk. Pak mám návod na instalaci aplikací, konkrétně příkaz apt nainstalující většinu mnou používaných aplikací a příkazy pro obnovu /home/jmenouzi­vatele/ a důležitých nastavení v některých souborech a složkách /etc/. Obnova by byla ze zálohy, kterou provádím denně automaticky pomocí Back In Time na externí disk (neustále připojený k PC). Zálohu datového disku (ne systémového) provádím méně často na disk, který je odpojen od PC a připojen ručně před spuštěním zálohy.

2. 9. 2026, 07:19 editováno autorem komentáře

Je k dispozici ten script pro obnovu ~ a /etc ?

Pořád hledám inspiraci pro tu "správnou" cestu

Díky

Moderni programatori maji slozitost obvykle radi, jenomze pak narazi na realitu udrzovatelnosti a musi k tomu prijit sysadmin.

Já jsem měl dilema především na pracovním stroji. Luks nad lvm. Nakonec je ideální cesta prostě rsync obalený skriptem, který zálohu odlévá za živa na NAS. V případě LVM odlévá právě vytvořený snap. Na mém NixOS je relevantní pouze /home jelikož je celý root generován nixem. Věci jako Lun SCSI a time shift jsou spíše bolehlav.

2. 9. 2026, 07:43 editováno autorem komentáře

ReaR je dobra a spolahliva volba.

Já mám všechny věci v kontejnerech a Ansible se stará o zbytek. Zálohuju bash skriptem, který zastaví kontejner, zkopíruje jeho data, případně jen udělá DB dumpy z běžících a přesune na jiný stroj. Mám v plánu ale zkusit spíš Borg.

Free verzia Veeamu ?

Coz je jeden ze zalohovacu, ktery zalohovat neumej a to ani na platforme, pro kterou je to urceny primarne (tzn vmware). A to ani ty veci, o kterejch vyslovne tvrdej, ze to umej (mssql napr).

Misto desitek MB to zalohuje stovky GB a tomu SQLku to neumi rict, ze se zalohuje a ze je dozalohovano, takze ... treba nikdy nevyklopi transakcni log. Jup v mem pripade to resili rok, a nevyresili nic, takze byli poslani kam patri.

Jako bonus, je to trvale jak reseto deravy. Libovolnej nakolene uplacanej script bude bezpecnejsi.

Jako funkční minimalistická varianta mi přijde btrfs send/receive. V kombinaci s isci z NASu a zapozdřené na straně backupu v btrbk to fungovalo fajn.

Jup, pokud pocitas s tema neduhama ktery to ma a nevadi ti to, tak tohle je dobrej zpusb = minimalizace prenasenych dat = pomerne slusna rychlost obnovy vybranyho snapu. Ale nesmis na tom mit databaze a podobny veci.

A proto mám jako operační systém atomickou Fedoru (Silverblue, Kinoite). Instalace nebo upgrade jsou jen přepnutí image.

Restic (dříve Borg) mi zálohuje home se všemi konfiguracemi a Flatpak aplikacemi.

Na speciality jako udev pravidla (které normální uživatel nepotřebuje) mám jeden ansible skript.

"protože každý oddíl má nově vytvořené jedinečné UUID"

A presne proto ze UUID nepouzva, ale pouzije se nastaveny nazev prislusne partysny. Pricemz script na vytvoreni tech partysen (a jejich pojmenovani) by mel byt soucasti takove zalohy.

"Potom budu muset ze zálohy obnovit zvlášť oddíly /boot a /boot/efi a pomocí příkazů jako update-grub,update-initramfs nebo grub-install obnovit správné zavádění systému"

Coz je presne ten duvod proc to takhle nedelat (predevsim nepouzivat UUID). Mimochodem, i to se samozrejme da pripadne nastavit, ale proc to delat jednoduse, kdyz to lze slozite.

"Jako typický příklad se uvádí, že vám na serveru běží třeba vytížená databáze nebo Docker.

Proto některé souborové systémy umí vytvořit snapshot souborového systému."

Coz je krasna ukazka toho, kdyz nekdo nevi co dela ... jako bez sorry.

Konzistence dat je nejproblematictejsi vec libovolnyho zalohovani, a snapshoty FS ti konzistenci dat nijak nezajistej. Snapshot FS zajistuje pouze a vyhradne konzitenci prave toho FS. Nic vic. Zajistuje to pouze a vyhradne to, ze soubor bude souborem. TECKA. Nijak to nezajistuje, ze ten soubor bude pouzitelny prislusnou aplikaci.

Aby byl ten soubor konzistentni z pohledu aplikace, musi ta aplikace na vytvareni toho snapshotu (pripadne libovolnyho jinyho typu zalohy) reagovat, musi s tim umet fungovat = dokoncit zapisy/pozastavit dalsi (a samozrejme ten snap toho FS na to musi pockat). Coz v drtivy vetsine pripadu neplati.

A pokud jde o konzistenci datovou, ani tohle nestaci. Na to musi prislusna aplikace fungovat transakcne, a co vic ty transakce se museji korektne pouzivat (tzn nestaci ze to databaze umi, musi to pouzivat a spravne i priuslusna aplikace ktera nad tou databazi bezi). V opacnym pripade budes mit v zaloze treba polozky dokladu, ale uz ne hlavicku.

Vysledek tvyho snapsnotu na urovni FS bude treba ciste textovej konfigurak, kterej sice pujde uplne vpohode skopirovat (a pripadne i cist) ale bude ho jen cast, takze ti ta vec co tu konfiguraci nacita v lepsim pripade nenastartuje vubec v horsim uplne blbe.

BTW: Kolik apek si overuje hash nebo podpis nacitanyho souboru aby se ujistily ze je OK?

Použití názvy oddílů místo UUID je zajímavý nápad. Nevýhoda je, že Debian instalátor udělá by default UUID. Nevšiml jsem si, že by toto implicitní chování šlo u instalace jednoduše ovlivnit. Tedy u Debianu, nepoužít UUID by znamenalo, že musím manuálně provést změny ve fstab, crypttab, pak ještě v tom souboru pro hibernaci, pak zavolat update-grub, update-initramfs. Tak, snad jsem na nic nezapoměl. Přijde mi, že to vyžaduje expertní znalosti, které ne každý má.

FreeBSD implicitně má ve fstab nastaveno, že použije jako identifikátory jména zařízení z "/dev/". Tohle je jednoduché a řeší to problém s UUID, avšak nevýhoda je, že když systémový disk zapojíte jinam, třeba si ho vyndáte a dáte ho jako externí, tak se diskové oddíly nenačtou - toto vyřeší až "linuxvé" UUID. Avšak mám-li "domácí server" udělaný dostatečně "statický" (nebudu "čarovat" s disky, prostě je jednou zapojím někam, a už tak jsou navždy), tak je na FreeBSD mnohem jednodušší udělat "bare metal recovery" - nepotřebuju "dd", jen udělám novou instalaci FreeBSD na nový disk, nakopíruju tam soubory za zálohy, disk následně zapojím do stejného rozhraní, aby měl stejný název v "/dev", a je to hotovo. Nejjednodušší recovery jde na FreeBSD, s využitím implicitního chování instalátoru.

Uff to byla fuška...

A teď se dostávám k těm snapshotům. Ano, je to hrozné, ale ani ty snapshoty souborového systému nezajistí 100% konzistentní zálohu třeba databáze, a aplikací jako je Docker. Důvod je, že tyto aplikace můžou data držet v RAM. Zde se nedá udělat nic jiného, než aplikace buďto ukončit, a teprve pak spustit zálohování, nebo použít speciální software přiložený k těmto aplikacím, který byl napsát speciálně k účelu provedení zálohy s běžící aplikací. Já však Docker nepoužívám a jako databázi používám souborovou databázi Sqlite.

Místo snapshotu používám fsfreeze (nakonec nepoužívám LVM). Na domácí server mi to, mám za to, dostačuje.

"jména zařízení z "/dev/". Tohle je jednoduché a řeší to problém s UUID"

Neresi ... ve skutecnosti je to jeste horsi. Co myslis, co rozhoduje o tom, ktery ze dvou disku bude /dev/sda ??? Odpoved ... je to zcela random.

Jasne mozna si na to nikdy nenarazil, ja jo. Takovej priklad je HP microserver gen 8. sda bude ten disk, kterej system nadetekuje prvni. V ty krabici tech disku muzes mit neurekom (4 v suplicich, 5tej na ksande od mechaniky, dalsi v podobe uSD, dalsi v podobe interniho USB donglu ...) a sda bude libovolnej z nich. Pri kazdym rebootu i bez jakyhokoli zasahu do konfigurace.

Mimochodem, kdyz to chces(=potrebujes) resit, tak zjistis, ze jak generator configu tak grub je rozbitej (roky). Kdyz mas totiz v tom configu tzv hinty, tak dostanou vzdy prednost pred uuid ... lol. A nemuzes tomu rict, ze tam ty hinty nechces, musis si udelat extra script kterym je odmazes.

Pro server mi jako časově (!) nejméně náročná metoda přijde občasné dd na externí disk. Nevýhodou je, že se musí pouštět zvenku, ale výhodou je, že obnova je zdaleka nejrychlejší: vyhořelý disk vyhodím, z externího disku udělám interní, a koupím nový externí (a provedu naň novou zálohu).

Blby u cisteho dd je to s kompresi nul a deduplikaci. Pokud si muzu dovolit to hnat na pasky, neni takovy pohyb dat a je to par jednotek TB tak to neresim (resp. kompresi resi backup sw a backplane mechanik u robotu). Pokud je to neco low cost tak zalohy boli. Nejhur asi boli zalohy v cmoudu a to i pokud uzivat infra cmoud providera. Tam si clovek zatracene dava bacha.
U jednoho startupu se nam i normalne vyplacelo nechat si poslat sifrovana media ze zahranici az do trezoru a pak jen delat diffy misto transportu pres sit.

dd nie je predsa problem prehnat pajpou cez gzip, ci remote prenasat kompresovane cez ssh.

Jsem to přivolal: dneska restart a "kernel panic"... ;D

Kdyz jsem doma virtualizoval na debianu+kvm , tak jsem v kazde vm mel btrfs a pomoci btrbk jsem delal snapshoty. Ty jsem pak pomoci btrbk vyzobaval z externi VM. Obnova mela probihat pomoci btrfs send+receive na nejaky cerstve nainstalovany system.

Ted, kdyz mam proxmox, tak zalohuju pomoci pbs a vytvareni nove vm nemusim resit

"Ted, kdyz mam proxmox, tak zalohuju pomoci pbs"

A tohle https://forum.proxmox.com/threads/proxmox-backup-from-2-to-500-cpu-during-backup-tasks.167365/ uz soudruzi vyresili? Ja bych spis rek, ze je to cim dal horsi.

V poslednich mesicich si totiz lidi zacli stezovat ve velkym, ze jim to vpodstate odstreli nejen ten zalohovanej stroj ale vsechno co bezi na dotcenym HW.

ja mam celkem dobre zkusenosti s BORG. Na Synology jsem udelal server, na vsech compech, co chci zalohovat, mam relativne jednoduche scripty, ktere kazdou noc zalohuji. Posila se to pres priblizne 1km dlouhy wifi link. Prestoze se zalohuje priblizne 6 computeru kazdou noc, drzi se nekolik desitek zaloh (poslednich 10 dni, pak kazdy tyden po dobu 5 tydnu jedna, kazdy mesic pod dobu 12 mesicu a pak kazdy rok), celkova velikost zaloh je az neuveritelne mala. Umi to nachazet stejne bloky a odkazovat na ne, takze i kdyz mam na 3 computerech stejny file, v zaloze bude jenom jednou.
Restore je az neuveritelne jednoduchy. Namontujes si jednu nebo vsechny zalohy toho konkretniho compu, vyberes si datum a mas tam cely file system zalohy. Vyberes si file, co chces vytahnout a zkopirujes ho. Pak jenom nesmis zapomenout odmontovat tento file system, jinak se nebude zalohovat. Pres tento wifi link namontovani trva radove minutu, pak uz prochazeni strukturou adresaru je celkem rychle. Rychlost kopirovani je pak samozrejme dana kapacitou linky.

Zajímavé. Já se po sžitím s logikou subvolume ustálil na btrfs s oddělenými snapshoty pro root a home a send/recieve do záložních míst, resp. celé dělané automatizovaně za pomoci btrbk. Obnova (resp stěhování na jiný disk) už ručně přes btrfs send/receive těch btrbk snapshotů jsem párkrát dělal a vyžaduje to pár ručních kroků, ale nic hrozného. To jsou hlavně, rozdělení disku a po send/receive dodatečné subvolume, změna UUID ve fstab a "regenerovat" boot resp hlavně grub pokud si pamatuji.

Myslím, že se tu míchá záloha aplikací a záloha uživatelských dat.

Uživatelská data, to je prostý rsync, tam to asi lépe nejde, pokud chci mít k dispozici možnost částečné obnovy. Snapshoty a další věci jsou výborná podpora a používám...

A aplikace - to se dá rozdělit na tři části - aplikace samotná, její konfigurace a stavová data. Pokud nepoužívám nic, co bych si musel složitě instalovat (kompilace zdrojových kódů), tak aplikace samotné jsou vlastně jen seznam toho, co chci nainstalovat. A konfigurace aplikací je zase seznam těchto souborů a tyto soubory samotné. Proč zálohovat celé etc, když na většinu souborů ani nesáhnu, jsou vytvořeny automaticky při instalaci...

Aplikační data jsou jediné úskalí, protože zde mi rsync ani snapshot nepomůže získat konzistentní data. Zde je nutná podpora ze strany aplikace - například, zastavit aplikaci, abych mohl zazálohovat její databázi a podobně. "Rsync" nebo snapshot jsou zde dobrá pomůcka, ale ne řešení, to musí být na míru dané aplikaci. Třeba konkrétně Nextcloud - tam je potřeba zazálohovat DB a uživatelská data atomicky, takže je třeba zapnout maintanance mód, vylít DB a synchronizovat uživatelská data bokem, pak můžu nextcloud zase pustit. Co udělám s daty vytvořenými zálohovacím procesem je jiná věc (třeba rsync na jiné úložiště).

Osobně mám zálohu vytvořenou tak, že zálohuji uživatelská a aplikační data. Systém samotný mám definovaný jako ansible playbook. Znamená to disciplínu při provádění změn - vše mít v playbooku, ale na druhou stranu, pak nemusím řešit velikost zálohy a totální obnova znamená jen minimální instalaci, pustit ansible a obnova uživatelských/a­plikačních dat. UUID disků mne prostě nezajímá, zároveň mi to dává prostor pro revizi špatných rozhodnutí z minulosti stran například rozdělení disku - třeba se hodí zvětšit /boot/ a podobně. Nemusím při obnově řešit spoustu věcí, které můžou být jinak - například, migraci VPS k jinému hostingu.

Stejně tak nepotřebuji zálohovat docker kontejnery, ale stačí mi jejich popis (a ta aplikační data)...

U uzaivatelskych dat jsem si oblibil pouzit btrfs snaphsoty + send/receive. Lze pak delat inkrementaly, ktere se na druhem ulozisti pak objevujou jako full zaloha.

Co se tyka aplikaci, tak dobre napsana aplikace by nemela transakcnim zapisem souboru na disk (jako napr. v BTRFS) udelat corrupted data tak,aby zase nenabehla (napriklad problemy zpusobene nahlou ztratou napajeni)

Podle mě je trochu problematická úvaha, nechci s obnovou strávit celou neděli. Havárie disku je to dost hypotetický scénář a člověk může strávit týden zkoušením obnovy, která proběhne rychle a bez problémů, ale je to scénář aplikovaný jednou za deset let.
Reálně to beru spíš tak, že instalace Linuxu je postradatelná a irelevantní, nějaký seznam balíčků a pak copy&paste sudo rpm install .... řeší dost věcí.
Plus nějaký checklist typu nastavit hostname, povolit něco ve firewallu, loginctl linger username, systemctl enable ... . Pro služby pak mít zálohy podman volume přes podman volume export do taru a nějakých docker compose souborů, případně podman quadlets (dotfiles/.con­fig/systemd/con­tainers). A nezapomenout na podman secrets a .env soubory.
A pak zálohu nějakých pracovních adresářů v home (nebo celého home kromě kontejnerů, které jsou zálohované jinou cestou). Před zálohou je nutné službu zastavit, ale u domácího serveru není problém. Nebo zálohu provést exportem databáze nebo nějakým specifickým příkazem, ale pak není úplně přímočará obnova, zase to třeba umožní migraci na novější verzi.
Ano, pořád je obnova na nějaké nedělení odpoledne nebo tři večery. Ale postup si lze zkusit ve virtuálce a první večer mít obnovené přinejmenším to, co má prioritu. A skoro mezi tím lze přejít na jinou distribuci a/nebo úplně jiný stroj.

Když to shrnu, rozdělit systém na
1. základ (postradatelný)
2. home
3. kontejnery (git, ...)
A u všeho si obnovu zdokumentovat a zkusit. Body 2. a 3. jsou platformě nezávislé a bod 3. se dá řešit po částech. Obnovit základní systém by měla být půl hodina instalace a půlhodina konfigurace dle checklistu.

pro
1. musíte mít
- verzi/variantu OS
- aspoň přibližnou geometrii disku
- zazálohované soubory změněné/vytvořené mimo instalační/up(dat|gr­ad)ovací proces např. repositories
- seznam nainstalovaných aplikací a verzí
- jiné instalční systémy (brew, snap, flatpak, /opt, /usr/local ...) někde stačí seznam aplikací a verzí?

problém je např. /var kde je spousta souborů které seod instalace mění ale jen některé ovlivňují chování nains. aplikací např. /var/www

tak easy to ůplně není ale je to as8 nejschůdnější cesta ...

Ne, vůbec neřeším obnovu 1:1, prostě nějak rozdělím disk, nainstaluji zrovna oblíbený OS a seznam balíčků nebude po nějaké době přesně sedět a mezi distribucemi vůbec. Ale obsahuje 90% toho co jsem potřeboval. Jo, flatpak jsem zapomněl, ale přes ten instaluji tak steam, freecad a tím to asi končí. /var/www neřeším, takové věci jsou v kontejnerech.Gitové repozitáře forgejo kontejner.
Ale tímto stylem zálohy nemají 300GB, které musím každý týden někam zkopírovat, momentálně je to pár instancí nginx, cloudflare tunnel, cloudflare ddns a nějaké databáze plus pár markdown souborů. Nejhorší je /home který nějakých pár set giga má, ale většina dat není důležitých.
Ono nehledě na zálohy je dobré si držet přehled jak co nainstalovat a zprovoznit a kontejnery se mi osvědčily proto, že třeba u Fedory se s upgradem systému skoro vždycky něco rozbije - databáze, verze pythonu pro kterou v říjnu dva týdny po releasu nejsou všechny moduly, ... a tím systém beru jako věc, kterou nemá smysl zálohovat a obnovovat 1:1. Pak mám třeba vývojový kontejner s claude-code, který má asi 5GB v /home, ale celý systém se vygeneruje jedním příkazem z jednoho souboru a má všechny vývojové nástroje, co používám.

Sice data nemám obnovená hned, ale toho, co má smysl zálohovat pravidelně je dost málo - hlavní je git repozitář a někdo tu psal dobrý tip používat na pracovní data syncthing.

Ale tady je to o tom, co má člověk k dispozici, pokud jde záloha na NAS nebo externí disk, tak stovky GB ještě nutně nevadí.

Já dospěl k názoru, že pokud má stroj požadavek na rychlou obnovu, vyplatí se jej "podložit" virtualizací.

Osobně používám Proxmox. Zálohovat s tím jde snadno celé stroje, záloha je inkrementální (takže rychlá), denní (může být i častější). A obnovení je vysloveně easy. Nainstalovat Proxmox, připojit ho na backup server a zálohovaný stroj může běžet už během obnovy ze zálohy.

Nebo koneckonců lze i udržovat teplou kopii stroje na jiném serveru a na tu v případě problému přejít (to osobně nepoužívám).

Je to tak easy na použití, že už to nedělám jinak.

A na strojích, které různě tahám s sebou (mám jich víc), mám na důležité soubory Syncthing. Jednak tam jinak není nic, co by neopravila reinstalace, takže není třeba zálohovat celý stroj, a Syncthing navíc umí držet historii souborů, takže řeší i případné omylem smazané nebo přepsané soubory.

Souhlas. Pokud to (ať už to je cokoli) slouží jako server, PROXMOX... přes PBS zálohy celýho systemu.

je to tak hodně convenient, že se to vyplatí i v případě že v tom hypervizoru bude jenom jedna VM. mam PROXMOX i na 8x8x8cm krabičce, s intel J4125 a 8GB integrovaný RAM... konkrétně na tomdle devicu mam VMka s TS3 serverem a Home Assistantem...

1x denně incremental backup po síti celý HA VM: 23 sekund: (INFO: backup was done incrementally, reused 59.85 GiB (93%)
INFO: transferred 4.17 GiB in 23 seconds (185.6 MiB/s) )...

restore na domácí 2.5G síti cca 65 sekund (restore image complete (bytes=68719476736, duration=64.39s, speed=1017.77MB/s) - skipuje to prázdný místo, a pak to vypadá jako když mam 10G síť, ale nemam, fejkuje to tu rychlost ....)

2. 9. 2026, 17:57 editováno autorem komentáře