Velikost cílového disku při obnově

Založil martin.80cz, 24. 11. 2013, 10:41:03

Předchozí téma - Další téma

martin.80cz

Pokud zálohují pomocí dd celý disk /dev/sda do image, musí potom při obnově být cílový disk stejně velký nebo může být větší?

Petr Gajdůšek

Samozřejmě může být větší. Ať už volné místo na cílovém souborovém systému, zálohuješ-li do souboru (image), nebo velikost cílového disku, zálohuješ-li přímo na nerozdělený disk.

Palo M.

Ja by som cely disk rozhodne nezalohoval. V pripade MBR by to este nejako mohlo zafungovat (aj ked to nie je iste, stale su tam aj CHS hodnoty ktore mozu byt ine pre novy disk, aj ked nove OS by mali pouzivat LBA/size hodnoty a nie CHS)... ale v pripade GPT by obnova na iny (vacsi) disk mohla robit problemy (na konci disku je sekundarna GPT, co by v pripade vacsieho disku nesedelo).
Pri zalohe jednotlivych oddielov disku tento problem nevznikne (na novom disku sa najprv vytvoria nove oddiely s patricnymi velkostami, potom sa obnovia jednotlive oddiely a pripadne este zostane volne miesto).
Ale celkovo je zaloha pomocou dd neefektivna (zalohuju sa vsetky bloky, nielen tie pouzite), ma to vyznam snad len pri full-disk-encryption.

Petr Gajdůšek

Zapomněli jsme zmínit, že v každém případě musí sedět velikost sektoru (512 vs 4096). Určitě ale bude existovat utilita, která by to přepočítala....

Co se MBR a C/H/S týká, tak se nic moc neděje i pokud partition entries neobsahují LBA a tedy zavaděč nebo OS čte z tabulky rozdělění disku C/H/S hodnoty.  Aby tedy disk bootoval nebo šel připojit stačí při nejhorším manuálně změnit C/H/S obnoveného disku v setupu BIOSu. Hodnoty se dají zjistit v setup BIOSu u nastavení původního disku (pokud je tam LBA není co řešit) nebo z tabulky rozdělení disku (C/H/S pro poslední sektor posledního oddílu) případně bývají uloženy i na souborových systémech. Navíc se to netýká linuxu, linuxové zavaděče geometrii reportovanou biosem nepoužívaly snad nikdy a u disků, které nemají v partition table LBA, IMHO použijí k přepočtu původní C/H/S geometrii. Ale i kdybych byl úplně mimo, není to nic, co by nešlo triviálně opravit testdiskem.

S GPT jsem se nikdy nesetkal, měl bych si rozšířit obzory, Palo, děkuji za vysvětlení. Nicméně podle wikipedie jsou v GPT hlavičce uloženy LBA primární i sekundární hlavičky, podle toho by snad nemělo vadit, když sekundární hlavička nebude LBA -1, nebo je to v praxi jinak?

Palo M.

GPT je stale pomerne nova zalezitost, takze by som sa pre istotu nespoliehal na to, ze vsetky nastroje budu stopercentne fungovat.
Ak ma ale disk viac nez 2 TiB, tak uz GPT treba pouzit, pomocou MBR sa neda adresovat viac nez tie 2 TiB...

Co sa tyka velkosti sektora, pokial viem, tak sa vsetky disky tvaria, ze maju 512 B sektory. Tych 4096 B pri novsich diskoch je velkost "nativneho" sektora, s ktorym pracuje firmware disku interne (ak sa cita/zapisuje lubovolny 512-bytovy "logicky" sektor, disk musi precitat/zapisat cely 4096-bytovy "nativny" sektor na ktorom ten 512-bytovy logicky sektor lezi - a s nim aj dalsich 7 logickych sektorov) - prave preto je pri tychto diskoch dolezite zarovnat (tie 512-bytove) sektory na nasobok 8, inak brutalne klesa vykon disku - suborovy system, napriklad ext2/3/4, pracuje totiz tiez s 4096-bytovymi blokmi. Je dost hlupe, ze sa to prepocitava hore-dole a bolo by urcite lepsie, keby sa s novymi diskami pracovalo priamo s 4096-bytovymi sektormi bez prepocitavania (a samozrejme aj bez CHS, ktore dnes uz nemaju ziadne opodstatnenie), ale... spatna kompatibilita (Windoze by taky disk urcite nedali a nie som si isty, ci by s tym neboli problemy aj v linuxe - ved vsetky layouty - aj ten GPT - pocitaju s 512-bytovymi blokmi).
Z hladiska zalohy/kopie teda pravdepodobne netreba riesit problem 512/4096, malo by to fungovat aj ak sektory nebudu zarovnane, akurat to bude patricne pomalsie...

V kazdom pripade, podla mna dump celeho disku pomocu dd nie je velmi vhodny na pravidelne zalohovanie. Hodi sa to skor na nejake "jednorazove" laborovanie (napriklad ak boli omylom prepisane nejake sektory na disku a chcem z neho stale dostat data, tak cez dd urobim kopiu disku a hram sa s tou kopiou kolko chcem, na povodny disk nic nezapisujem, aby som tam nepokazil dalsie veci).

martin.80cz

Děkuji za odpovědi.

Takže mi z toho plyne, zazálohovat MBR zvlášť a pak jednotlivé oddíly také zvlášť, správně?

Zmiňujete, že dd je nevhodný nástroj, co tedy doporučujete?

Ostatně pokud jsem zálohoval dd 60GB SSD, na kterém je obsazeno něco přes 6GB výsledná image disku v archívu gz má něco přes 5GB a ne 60GB ...

Palo M.

Zalohovanie je pomerne komplexna zalezitost, jednoducha odpoved na otazku "co odporucate" teda neexistuje.

Napriklad, pri pouziti dd sa vytvori jeden klon daneho disku v danom case. Ak chcem aj nejaku historiu zaloh, povedzme poslednych 7 dni, tak potrebujem priblizne 7-nasobne viac miesta. To uz zacina byt dost neefektivne...
Inak co sa tyka toho SSD: Ak je zapnuty TRIM (co je pri SSD vysoko odporucane), tak sa bloky oznacene filesystemom ako volne (po zmazani suboru) oznamia disku a ten sa odvtedy tvari, ze tieto bloky su prazdne (akoby tam boli nuly), teda obraz takehoto disku je komprimovatelny vysokym kompresnym pomerom. Pri klasickom disku ale zostava obsah blokov po zmazani suboru na disku (len sa bloky oznacia ako volne - potom je mozne aj "undelete", ak tie "volne" bloky este neboli znovupouzite pre ine subory), takze po zaplneni klasickeho disku povedzme videom a jeho naslednym zmazanim sa komprimovatelnost obrazu disku pravdepodobne vyrazne zhorsi.

Ja napriklad spravidla nezalohujem cely system. Najdolezitejsi pre system je /etc (v kombinacii s balickom etckeeper, ktory automaticky priebezne uklada historiu zmien v /etc do verzovacieho systemu) a /var/backup (tam su jednak zalohy z dpkg-selections a tiez sluzieb ako mysqld alebo slapd - tiez je tam nielen posledny snapshot, ale aj niekolko predchadzajucich). Toto staci rsyncnut na iny stroj a s tymto by som v pripade dokazal obnovit cely system s potrebnymi sluzbami - zalohu veci ako /usr fakt nepotrebujem. Je pravda, ze v pripade uplneho krachu disku by som sa trocha viac narobil s obnovou systemu, pretoze by som ho musel znova instalovat, aj vsetky dalsie baliky podla dpkg-selections a potom este prekontrolovat konfiguraciu, ale zase na serveri mam RAID1, takze totalny vypadok nie je az taky pravdepodobny (a este sa mi to nestalo). Pre mna je dolezitejsie, ze nezalohujem veci, ktore su nahraditelne, ale len konfiguraciu (lebo v tej je kus mojej roboty). Ale kazdy moze byt v inej situacii. Preto univerzalne odporucanie neexistuje.

Na zalohu nesystemovych dat (napriklad uzivatelske adresare) pouzivam momentalne rdiff-backup (predtym tiez rsync, ale to bol tiez len jediny snapshot momentalneho stavu bez historie, pri rdiff-backup sa da uchovavat historia zmien podla potreby). Uchovava to momentalny snapshot a "reverzne inkrementy", teda starsia verzia je vzdy diff k novsej verzii - daju sa potom lahko zmazat "prilis stare" verzie bez toho, aby sa manipulovalo s tymi cerstvejsimi. Tiez to pouziva hardlinky a ine finticky, takze celkova velkost zalohy je celkom znesitelna. Navod na rdiff-backup je napriklad tu.

Prave sa trocha pohravam s myslienkou, ze si vyskusam zalohovaci system Bacula, vyzera zaujimavo. Paci sa mi na tom, ze sa da komplexne vyriesit zalohovanie viacerych strojov (pri tom rdiff-backup je to skor o tom, ze na kazdom stroji je to nakonfigurovane trocha inak podla potreby a pri viacerych strojoch zacina byt trocha gulas v tom, co sa odkial kam zalohuje). Ale konfiguracia je zlozitejsia...