Vlákno názorů k článku Rozvaha nad zálohováním dat v Linuxu a jejich rychlou plnou obnovou od bez prezdivky ... - "protože každý oddíl má nově vytvořené jedinečné UUID" A...

"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.