Dotaz: Záloha běžícího systému (Debian)

[Hrabosh]

Zdravím

Přemýšlím, jak zálohovat běžící Debian na serveru (žádný Xka, ale Dovecot. MySQL, Apache, ftp server, NFS, Samba, XMPP server atd.).

Beží to ze 120GB SSDčka, konkrétně z jednoho 64G oddílu (system zabírá aktuálně asi 30G). Druhej 64G oddíl je volnej.

Napadlo mě: 1/ Prostě kopírovat / třeba s použití rsync. Tady ale nevím, jeslti to zkopíruje správně všechny soubory a taky co se stane, když se budou některé soubory během kopírování měnit.

2/ Udělat pomocí DD image oddílu s běžícím systémem do souboru na druhém oddíle. Prohnat to rovnou bzip2, aby to nebylo tak velký. Opět se ale bojí nekonzistencí, který můžou vzniknout při změne souborů během kopírování.

3/ Nahrát do prázndýho oddílu plnohodnotnej Linux a v rámci zálohy system automaticky rebootnout do tohohle systému. Z něj udělat přes DD image do souboru a pak se zase rebootnout zpátky. Tohle mi přijde z hlediska zálohy jako takové super, ale server bude po tu dobu offline.

Napadá vás jiná metoda, ideálně taková, která zachová konzistentní systém a nebude vyžadovat rebootování do pomocného Linuxu?

---

---

Odpovědi

[Peter Golis]

Aby si sa vyhol nekonzistentným dátam počas zálohy, tak by si mal mať eliminovanú možnosť menenia súborov počas zálohovania. Teda napr: vypnúť služby, spraviť snapshot disku, zapnúť služby. Snapshot môžeš riešiť napr. pomocou LVM, alebo na úrovni FS (ZFS, BTRFS).

[luky]

Pokud nemuzete pouzit snapshoty, tak prekopirujte vsechny soubory, pak zastavte sluzby (sql, apache...) a prekopirujte znovu, co se mezitim zmenilo.

[Petr K.]

https://www.veeam.com/cz/linux-backup-free.html

[jan.rok]

Tohle používám na serveru, kde běží Zentyal (Samba, postfix). Taky mě zajímalo, co to udělá se soubory, co se mění, ale ve VEEAM mi řekli, že je s tím počítáno. Ale neznám bližší podrobnosti. Zatím jsem byl nucen obnovovat ze záloh jen některé omylem smazané soubory, ale nikdy ne třeba celý server. Totéž ale provozuju na windows serverech, kde jsem s tím už dělal psí kusy, včetně obnovy virtuálů nebo MS SQL databází i celých serverů.

[Peter Golis]

Na Windows ale vieš využiť VSS ktorý predá aplikáciám info aby sa na nevyhnutný čas prepli do tichého módu ktorý zabezpečí konzistenciu zálohy. Na Linuxe takáto technológia nie je.

Ale aj mňa by zaujímalo čo urobí VEEAM zo súbormi ktoré sa dynamicky menia počas vykonávania zálohy. Ak s tým počítajú, tak dúfam že to riziko nedajú do nákladov namiesto jeho odpočtu.

[PetebLazar]

Dle detailu má i Linuxová edice obsahovat "Integrovaný ovladač sledování změněných bloků (CBT)". Jestli to dělá to co si pod tím asi představujeme, pak to nejspíš může okamžitý snapshot být schopno poskytnout. Jeho konzistence z pohledu vyšších vrstev bude asi věcí jinou. https://www.veeam.com/cz/agents-windows-linux-pricing.html

[Peter Golis]

Ono je pekné že majú vlastný ovládač čo sleduje žurnál FS. Ale čo im zabezpečí že k určitému času budú mať konzistentné súbory ktoré sa menia?

[Jendа]

Ideální by bylo kdybys měl třeba LVM a mohl udělat snapshot.

Ale prostě to rsyncnout za běhu bude téměř určitě v pohodě až na MySQL. Tu dumpni mysqldumpem do souboru.

[PetebLazar]

Systém na konzistentní on-line zálohání asi nebyl prvotně navržen, takže jediná šance je zjistit zda použité technologie něčím na své vrstvě nedisponují.

Určitě bych začal klasifikací jaká data a kdy se mění. Případně do návrhu řešení zohlednil i to, zda v případě využití definované retence záloh (tj. doba než se záloha přepíše další zálohou) nemohu požadavek na obnovu (typicky atomického souboru) pokrýt z předchozí/následné zálohy.

Případně zda je technicko-organizačními opatřeními přijatelné zajistit neměnnost některých dat(souborů) po dobu záloh.

Například: MySQL má údajně umožňovat binary log, což předpokládám je protokol změn DB nejspíš obdoba archive log režimu u Oracle RDBMS (sloužícímu mj. k umožnění on-line backupu), manuál MySQL naznačuje i možnost replikace na slave a vykonávání záloh až na něm. https://dev.mysql.com/doc/refman/8.0/en/backup-methods.html

Další nezmíněnou otázkou je křížová konzistence, tam kde v rámci procesu vznikají související data napříč technologiemi (DB, FS). Tam může být řešením (pokud to tedy technologie umožňují, preference umístění souborů do DB, tedy za předpokladu její podpory konzistentního zálohování a dostatku zdrojů.

Je třeba také zvážit zda případné řešení (díky zvýšenému opotřebení) nepošle do pekel SSD dříve než by bylo zdrávo.

Či zda řešení svou komplikovaností nezpůsobí větší nedostupnost či ztrátu dat, než nedokonalé jednoduché zálohování.

Backup/recovery není stav, ale proces. Nedílnou součástí by mělo být periodické ověřování scénáře obnovy (Murhyho zákony fungují v IT ještě účiněji než jinde a není dobré být nemile převapen).

Fascinuje mne obecně rozšířená fascinace technikou snapshotu.

[Peter Golis]

Fascinuje mne obecně rozšířená fascinace technikou snapshotu.

Nuž, keby si používal snapshoty VM na úrovni hypervízora typu VMware alebo Hyper-V, tak by to nebola až taká fascinácia.

[PetebLazar]

U těch virtualizovaných řešení je to pochopitelné, ale u nativních řešeních to asi má své limity.

[Peter Golis]

Áno, tie snapshoty majú svoje limity. Sú ňou v prípade jednoduchých LVM alebo FS snapshotoch: konzistencia pri bežiacich službách, absencia katalógu, nie veľmi pohodlné spravovanie retencie a podobné čínske slovíčka opisujúce španielsku dedinu.

Nuž, aj to je dôvod pre virtualizovanie riešení ktoré zvykli bežať na fyzickom železe. Ale to by sme už moc odbehávali od témy.

[/dev/null]

hlavne je problem s beziacimi SQL databazami, napiste to presne a priamo...

[Michal]

Obnovení ze snapshotu je jako spuštění serveru po výpadku napájení, hw problému nebo výtuhu. KAŽDÁ seriózně míněna databáze a aplikace nad ní s takovou situací bezpodmínečně musí počítat (atomické transakce). Amatérské apky nahradit a je to.

[Peter Golis]

A po nejakej dobe niekto dočasne vypne transakčné logy kvôli rýchlosti (aby nemusel čakať na výsledok spracovania do pol piatej), a zabudne ich zapnúť.

Nie, zálohovanie sa rieši bez spoliehania sa na to že žurnál musí byť vždy bezchybný.

[PetebLazar]

A proto žurnálů (archivů žurnálu) bývá více originálů/kopií. Ono nejde jen konzistenci zálohy, ale i o to že v archivním režimu je možné databázi zálohovat průběžně. V případe totální ztráty přístupu k živým redologům je doba ztráty dat dána intervalem switchnutí(archivování) redologů. Přípustnou dobu ztráty dat je tak možné zvolit (bude řádově jiná než u periodických záloh, či jednorázových snaphotů). V případě využití průběžného promítání archivu redologů do standby databáze se také snižuje doba obnovy provozu (na jiném železe).

[pavele]

A každý seriózní server má UPS, aby k takovému výpadku nedošlo.

Tolik teorie.

A teď praxe - tam se to chová trochu jinak...

[Andrej]

1. Udělat Btrfs snapshot.
2. Zkopírovat Btrfs snapshot.
3. Odstranit Btrfs snapshot.

Napadá vás jiná metoda, ideálně taková, která zachová konzistentní systém a nebude vyžadovat rebootování do pomocného Linuxu?

To dnes už nikoho nemusí "napadat" — taková metoda už dobrých 8 let existuje a funguje. (Dokonce existuje i déle než desetiletí, pokud vezmeme do úvahy ještě ZFS.)

[PetebLazar]

Dotaz: Pokud jsou soubory dejme tomu databáze rozloženy na více filesystémech zmíněného typu (z důvodu objemu, výkonu, dostupnosti, ...), umí zmíněné řešení zajistit konzistentní snapshot napříč všemi?

[pavele]

Pokud budeš dělat zálohu z běžícího systému, snapshot nebude nikdy konzistentní.

A je přitom jedno, jestli použiješ btrfs, LVM, KVM, Idera Hot Copy hcp, zajímavý trik pomocí přidání dalšího disku do RAID 1, rsync, cp, rear, Mondorescue - FSArchiver taky umí zálohovat z běžícího systému.

Zálohovat by se asi mělo na jiný disk - záloha na stejném disku je při výpadku disku k ničemu.

Nejjednodušší spolehlivá metoda je vypnout PC, provést zálohu, zapnout PC.

Pokud se bude provádět záloha z běžícího systému, tak vypnout služby - databáze, apache atd.

Spousta lidí bude tvrdit, že databáze xxx a systém yyy se souborovým systémem zzz je schopný přežít takovéto nekonzistence.

Je to možné. Chceš to zkusit?

[pavele]

A moje používané řešení je:

- Vypnu nepotřebné služby.

- Provedu snapshot systému

- Odkopíruji data pomocí rsnapshot nebo rdiff-backup na jiný disk. Databázi zálohuji samostatně.

[PetebLazar]

Vypadá to, že zakladatel vlákna se odmlčel, takže to tu bude patrně pokračovat pouze v teoretické rovině.

[Andrej]

…umí zmíněné řešení zajistit konzistentní snapshot napříč všemi?

Ne.

Mimo jiné proto se doporučuje nedělit zbytečně prostor na různé filesystémy. A proto také Btrfs podporuje RAID na úrovni filesystému — jediný skutečný RAID, který není pouze AID s iluzí redundance.

Nicméně pokud jde o databáze, většina z nich má (pokud vím) pořád ještě problém s využitím Btrfs. Pokud používají Btrfs stejným stylem, jako by to byl nespolehlivý filesystém ve stylu 90. let (Ext4, JFS, XFS atd. atp.), zpravidla to s sebou nese velmi chabý výkon.

[PetebLazar]

V čem spočívá iluze redundance u RAIDu na úrovni storage?

[Jendа]

V tom, že nedetekuje chybu, při které disk vrací jiná data, než která tam filesystém zapsal - např. je vadná paměť někde cestou nebo bug v driveru řadiče. V případě RAID1 pak můžeš dostat dvě rozdílné kopie a neumíš rozhodnout, která je správná. V případě RAID5 dostaneš tři bloky dat, přičemž dva z nich se nevyXORují na ten třetí a opět nevíš. btrfs ukládá ke všem blokům checksum, takže na tohle přijde. Bohužel má zase spoustu dalších problémů, z této oblasti například ten, že pro něj neexistuje použitelný fsck - pokud se ti poškodí struktury filesystému v paměti (vadná RAM, bug v driveru) a checksum se spočítá až po tomto poškození, nikdo si ničeho nevšimne (scrub kontroluje jen checksumy, nikoli sémantickou správnost datových struktur) a celé to časem grandiózně zfailí.

[PetebLazar]

Osobně si nemyslím, že ve standardní implementaci RAID1 se hlasuje o výsledku (nevezme se zavděk prvním čtením z členu, které neskončí CRC chybou na nižší vrstvě?). Je to samozřejmě věcí implementace, ale teoreticky by i v RAID1 mohlo být více členů(disků) připojených přes více řadičů. Takže si dovedu představit paranoidní implementaci, kdy se povinně vyčítá stejný stripe ze všechny členů a o správném výsledku rozhodne většina. Ale takové řešení by kromě značné redundance asi stálo i dost výkonu/latence (proti čtení dat z libovolného členu). Pokud si vzpomínám tak v devadesátých letech na Novell SFT III byla na úrovni storage redundance min. 800%, takže proč ne. Slušné RAID řadiče snad využívají ECC, ale na selhání v rámci SPoF logicky nic nezabere a je jedno, na které je to vrstvě. Pozn. Některé databáze pro své záznamy snad ukládají CRC, takže by měly být schopny dodatečně detekovat nekonzistenci na své úrovni.

[Jendа]

Osobně si nemyslím, že ve standardní implementaci RAID1 se hlasuje o výsledku

Defaultně během běžného provozu ne, minimálně Debian a CentOS ale každý měsíc (cronem) přečtou všechny disky ze všech RAIDů a kontrolují to.

Takže si dovedu představit paranoidní implementaci, kdy se povinně vyčítá stejný stripe ze všechny členů a o správném výsledku rozhodne většina.

Ano, ale to vyžaduje větší redundanci než se běžně dává (např. RAID1 se 3 kopiemi, RAID5 nejde vůbec, RAID6 jde; pokud se taková chyba zjistí během rebuildu, tak máš zase smůlu).

Pokud si vzpomínám tak v devadesátých letech na Novell SFT III byla na úrovni storage redundance min. 800%, takže proč ne.

Osobně mi přijde overkill mít redundanci nad 200-300%, pak je větší pravděpodobnost, že shoří něco jiného a stejně budeš muset obnovovat ze zálohy.

[PetebLazar]

U DELL HW řadičů je(byl) na to process PatrolRead, který aspoň co mám zkušenost 1x týdně zkontroluje konzistenci RAIDu (v mém případě RAID6). U toho SFT III to snad byly dva servery v clusteru, kdy v každém z nich byly min. dva řadiče a ke každému řadiči byly připojeny min. dva HDD. Kolega podílející se v minulosti na vývoji mainframe u nás, dnes vzpomínal na jednu z konstrukcí počítačů, která byla ztrojená a výsledkem byl převládající "názor". Podobnou konstrukci snad použili i pro projekt Apollo. https://en.wikipedia.org/wiki/Triple_modular_redundancy

[lertimir]

Nyní připravuji storage s redundancí 300%. 4 kopie. Na bázi rackových Synology. Dva systémy, RAID 1 na každém a HA zrcadlením mezi nimi.

[pavele]

No v tom případě mám já 6 kopií.

Dva systémy, RAID 1 na každém + samostatný disk na zálohy a HA zrcadlení mezi nimi.

[lazywriter]

To, co autor popisuje, se jmenuje bit rot - https://en.wikipedia.org/wiki/Data_degradation

[k3dAR]

mdadm RAID1 je RAID1, narozdil od btrfs RAID1 ktere je MatlAID1, protoze kdyz na >2 disky nedela mirror na vsechny ale stale jen na 2 disky, NEjde o zadnej mirror...

[Hrabosh]

Díky všem. Nejdřív asi zkusím rsync běžícího systému a dump mysql. Zrovna přesouvám jedno Kubuntu z HDD na SSD, tak to můžu zkusit v praxi. Jestli to vyjde, zkusím takhle zálohovat jak ten server (domácí), tak bežící Raspberry. Pokud to nevyjde, zkusím některou z těch náročnějších metod...

[Peter Golis]

Ak systém nič nerobí a má všetky dáta uložené, tak to vyjde. Ale ak by si mal otvorené nejaké súbory ktoré nemajú ukončený zápis, tak budeš mať o nekonzistenciu postarané. Takže veľa zdaru :)

[debian+]

plus je este pouzitie prikaz sync.

[Peter Golis]

Ten sync ti ale uvoľní diskovú cache, a nemá dosah na aplikáciu ak si tá aplikácia sama nezabezpečila konzistenciu zápisu počas svojho behu. Alebo sa tá aplikácia nevypne bežným spôsobom.

[pavele]

Rsync funguje pěkně i přes síť.

Když jsem si hrál s KVM, vytvořil jsem prázdný disk + diskové oddíly, provedl boot z live-cd, přes rsync nakopíroval data, přidal zavaděč a bylo hotovo, systém bez problémů najel.

[Peter Golis]

No, tu už nemá význam upozorňovať na riziká. Nech sa spáli kto je za to platený.

[k3dAR]

rizika nejsou, jen udelat rsync 2x posobe, poresit na nekolika mistech UUID, pri pouziti net udev rulez v nich MAC, hostname, hosts, regenerovat initramfs, SSH klice, atd...

[k3dAR]

+ samozrejme pouzit volbu --one-file-system a pripadne vice oddilu rsyncovat zvlast, aby to nesyncovalo tmpfs, devtmpfs, devpts, proc, sysfs, pripojene iso, usb flasky apod...

[Peter Golis]

Ten rsync by mu kľudne stačil len raz, keby mal vypnuté služby (a tým pádom dáta všetkých tých služieb v konzistentnom stave). Podľa povahy jeho otázky asi nerieši zálohu systému ktorý musí mať dostupnosť 99.95%, a v noci sa tých pár minút až pár hodín na offline backup v kľude nájde. S tým že sa mu ráno skontroluje stav služieb, a poprípade zruŠí tá záloha a nakopne sa to alebo pošle alert nech do toho pošťuchá palicou.

[Hrabosh]

Backup kdy jsou služby offline není až takovej problém, jedná se opravdu o domácí server. Na druhou stranu ale ten počítač řídí jakousi domácí automatizaci, takže třeba reboot nebo startování systému z jiného oddílu by problém být mohl.

Co teda doporučujete vypínat? MySQL, Apache a zastavit stahování mailů pomocí Fetchmailu?

[Peter Golis]

Pokiaľ je problém neinteraktívny reboot (teda musíš doňho čumieť keď nabieha a šťuchať doň paličkou), tak ten stroj podľa mňa nie je doriešený a neoplatí sa to zálohovať. A na kúrenie by som nechal bežný autonómny programátor (možno s IR pre de/aktiváciu módu udržovať cca 5°C nech nepopraskajú trubky).

[Hrabosh]

Nene, to nemusím, rebootuje správně sám. To topení je zatím TBD, ale ted to třeba řídí myčku nádobí (posílá jí příkazy, co má dělat, mysí program je vlastně skript v bashi). V (krátkodobém) plánu je třeba automatické spuštění myčky až zapnout nízký tarif (noční proud). To se může stát v noci a kdyby se zrovna v tu dobu spustila nějaká automatická záloha s rebootem, tak se to rozese...re.

[lertimir]

Ty máš myčku, které se dá něco poslat bashem? Osobně se už kloníme k tomu mít různé stroje pro různé zařízení. Takové RPi Nano je za pár korun. A když by systém měl kritickou činnost v noci, ta zálohovat přes den.

[Hrabosh]

Jj, odešel mi v ní programátor, tak jsem si postavil s jednočipem vlastní. Má to seriovou linku. Fyzicky je připojená do Raspberry Pi, ale příkazy souští server prostřednictvím SSH. Přišlo mi to tak jednodušší, protože se to spouští přes webovou stránku v PHP (ta běží na serveru) a dělají se tam různé logy, statusy a locky.

[PetebLazar]

U OS kde v dané době nedochází ke změnám (typicky konfigurace/aktualizace) a žijí prakticky jen souborové logy, u kterých se případná ztráta konzistence snad ani nezaznamená, možná. Ovšem cokoli jiného (živá užitečná data) hrají při triviálním backupu Ruskou ruletu s revolverem co má plný bubínek.

[k3dAR]

rsync beziciho je v pohode, jen je dobre jak to vypnuti sluzeb, tak i treba schozeni desktopu (napr. systemctl stop lightdm(resp dm dle toho co pouzivas), jeste je takove pravidlo, delat rsync 2x posobe, poprve se dela kompletni a pripadne zmeny mezitim se muzou stat, takze pak pustis rsync totozne podruhe a tim ze uz se dotahuji jen zmeny od predchoziho rsyncu tak je to rychle a poresis tim prave ty pripadne zmeny...

"zaloha" pomoci DD rozhodne nedelat za chodu/primontovani, tam totiz nepujde jen o zmeny jednotlivych souboru mezi pocatkem a koncem chodu DD, ale budou tam napr. bloky s casti puvodniho souboru, bloky s casti noveho souboru, castecne smazane soubory, filesystem NEbude konzistetni, proste je to naprosta prasarna...

pokud bys chtel delat offline zalohu, misto DD doporucuju pouzit Clonezillu (udela zalohu jen pouziteho misto, komprimuje, zalohuje vsechny oddily zvlast, zalouje rozdeleni disku, info o disku, o hw atd, atd...)

[pc2005]

Před rokem jsem dělal

rsync -a -H -A -X --exclude '/proc/*' --exclude '/sys/*'

Z běžícího slackwaru a pak jsem měl rozházený služby. Takže bych doporučil to dělat třeba z nabootovanýho systemrescuecd. Jinak funguje to super. Taky by šla použít clonezilla.

[k3dAR]

misto vynechani proc a sys (proc ze jsi nevynechal takto i run, dev atd? nemel pak system pri startu bordel v dev? misto zakladnich zarizeni tam mel vse co udev v bezicim systemu udela):

 -x, --one-file-system       don't cross filesystem boundaries

jinak rozhazene sluzby? nevim co tim myslis, kazdopadne s Ubuntu/Debian/Mint to za chodu funguje za predpokladu

[pc2005]

Já jsem ten rsync pustil vyčerpaný až jako poslední možnost po tom co jsem se pár dní snažil updatovat UEFI (což má ten notebook rozbitý) a po tom, co jsem měl problémy s updatováním v nějaké minimální konfiguraci windows. Takže jsem prostě použil první příkaz co jsem vygooglil (tedy nestudoval jsem pořádně dokumentaci).

Jo to s /run byl pak možná problém, ale s /dev problém nebyl nikdy. Rozházené služby byly myslím problémy s autodetekcí síťovky a myslím i nějaký služby dbusu. Ale ten notebook má ten hardware+UEFI dost divnej, takže to mohlo být i něčím jiným (koneckonců bylo upgradovaný UEFI).

[Hrabosh]

Já jsem zkoušel tohle:

rsync -avH --delete --exclude=/mnt/ --exclude=/proc --exclude=/dev --exclude /home --exclude=/sys / /mnt/storage/AutoBackup/DebServer/

... takže lepší bude:

rsync -avHx --delete --exclude=/mnt/ --exclude /home / /mnt/storage/AutoBackup/DebServer/

.. jinak pokus o obnovu se uplne nezadařil, ale spíš byl problém na úrovni LILO/GRUB. Další pokus chci udělat přímo se systémem ze serveru, kde je Debian s custom kompilovaným jádrem, bez initramfs, fstabu kde jsou UUID místo klasicky /dev/sdxx apod.

[Josef Kufner]

Podstatné je to spouštět jako root a to jak na zálohovaném stroji, tak na tom kam se zálohuje, aby se zachovaly všechny atributy u souborů. Také je nutné zachovat vlastníky souborů (--numeric-ids nebo to správně namapovat).

Co se týče bootování, osvědčilo se mi udělat na obnovovaném stroji minimální instalaci ve stejné verzi jako je obnovovaný systém a tuto instalaci pak přeplácnout zálohou. Vyřeší se tím rozdělení disku, bootloader, minimální /dev i instalace rsync a ssh.

[Hrabosh]

[...]Vyřeší se tím rozdělení disku, bootloader, minimální /dev i instalace rsync a ssh.

to mi pripomelo ze sem zapomel, uz sem to s nekym(kdo me na to take upozornil) zde pred casem resil, --one-file-system opravdu vynecha zakladni zarizeni v /dev, misto --one-file-system je tedy vhodnejsi:

sudo mount --bind / /mnt/holej_rootfs

a pak rsyncovat misto / prave ten /mnt/holej_rootfs, tim se nesyncuje jak proc, sys tak dev (kde v nabehlem je zarizeni generovane udev), ale prave ze se ponechaji ty zakladni/vychozi/staticke zarizeni v /dev...

k tve varianta, ja preferuju ze system na cil neinstaluju, disk rozdelim rucne, nepotrebuju ssh(pokud jde o lokalni stroj) protoze rsync na cilovem pustim jako demon, tim se na cil zapisuje jako root, neni potreba ssh ani aktivni root uzivatel pro ssh aby to slo rsync pres ssh... v cili teda nahodim LiveUSB/CD/DVD/PXE a to uz rsync nainstalovane ma, jen zapnu a nastavim rsyncd

[Hrabosh]

Zkoušel jsem rsync -avz na ten "holej_rootfs" a když jsem potom ten tu zazálohovanou partition zformátoval a rsyncem ty soubor přesunul zpátky, tak to naběhlo ! Nicméně jsem to zkoušel na Raspberry, kde moc služeb neběží ... další pokus bude přímo na tom serveru.

[k3dAR]

u serveru/desktopu/notebooku pozor, narozdil od RPi nepozivaji pevne oznaceni prvniho zarizeni (u RPi mmcblk0) ale prave kvuli predejiti problemu prohazeni disku, resp. nazvu zarizeni sda, sdb... pouziva se UUID, coz je "jedinecne" cislo prirazene pri formatovani, kdyz tedy preformatujes rootfs a vratis zalohu tak /etc/fstab, /boot/grub/grub.cfg, /etc/initramfs-tools/conf.d/resume (info o swapu pro obnoveni z hibernace), /boot/initrd.img* a mozna jeste nekde co mi ted vypadlo, budou uvedene stare/puvodni UUID, takze je to potreba v nich zmenit (grub.cfg regenerovat pres "update-grub", initrd pres "update-initramfs -u -k all"), NEBO si pri zaloze zazalohuj i "blkid >/zaloha_blkid.txt" kde mas UUID uvedene a pri preformatovani nebo novem disku pouzijes parametr pro "mkfs.ext4 -U TEN-PUVODNI-UUID" aby pouzil konkretni(puvodni) UUID... pak netreba nic menit, resp. jen pripadne nainstalovat GRUB