Re: Poškození FS - nova dobrodruzstvi a varovani pro vas

[Vladimír Macek]

Sdilim pouceni ze ztraceneho pul dne, abyste se tomu vyvarovali:

Dekuji za tip na rdiff-backup. Ano, prijde mi sikovne mit i stare 
inkrementy pro rekonstrukci minulych stavu FS. Jak jsem naznacoval nize, 
cely FS jsem mirroroval na druhy disk, aby pri selhani primarniho pocitace 
jsem mohl disk vsadit do starsiho notebooku a pokracovat v praci. Pouzival jsem

rsync --one-file-system --exclude-from F ... / /target

a otestoval, ze z ciloveho disku bootnu. Fajn. Mel jsem v F uvedenych radu 
veci, ktere jsem syncovat nepotreboval.

Pak jsem presel na

rdiff-backup --exclude-globbing-filelist F --exclude-other-filesystems ... 
/ /target

a uz jsem boot nevyzkousel. :-( To se mi dnes vymstilo a stravil jsem tim 
par hodin.

Zatimco rsync si excludnutych veci a mount pointu nevsima, rdiff-backup je 
z cile smaze!

Netrklo me to ani ve chvili, kdy mi rdiff-backup smazal z cile jisty 100GB 
imagefajl, ktery jsem tam chtel nechat, i kdyz ho mel excludnuty a rsync 
--exclude si ho predtim nevsimal. Proste autor rdiff-backupu pouzil jinou 
(podle me mene intuitivni) semantiku excludovani. A volbu pro ignore 
nepridal...

Takze kdyz mi na pred 14 dny koupenem novem Dell Inspiron 15 odesel MB (!), 
chtel jsem uplatnit svuj plan s mirror diskem. Pri bootu cryptsetup open v 
poho, LVM se spusti (coz neni samo sebou, pro mirrnuri se musi pouzit jine 
fstab a crypttab). Ale pak bum, chyby mountu a Kernel panic. Stravil jsem 
mile hodiny laborovanim a rescue USB a zjistenim, ze staci udelat

mkdir /{proc,run,sys,dev}

(vypada to, ze /tmp a /var/tmp se uz zvladnou vyrobit, kdyz chybi, ale 
pridam je do mirrorujici skriptu zrejme taky)

Ach jo. Tak bacha na rozdilne chovani, jehoz dopadu si nemusite hned vsimnout.

Konec pohadky.

V.


On 26. 01. 22 18:16, Josef Krieglstein wrote:
> Dobrý den,
>
> napovím, že existuje třeba rdiff-backup, tam není záloha v jednom velkém
> souboru, což je na obnovu malé části lepší. Je stále efektivní na
> zabrané místo na cílovém místě, díky "diff přístupu". A v neposlední
> řadě jsou ty změny obráceně, ta nejnovější je prostá kopie (dostupná bez
> nainstalovaného nástroje) a ty starší jsou "změny".
>
> S pozdravem
> Josef Krieglstein
>
> Dne 26.01.2022 v 14:18 Vladimír Macek napsal(a):
>> Děkuju za odpovědi.
>>
>> Příběh:
>>
>> Udělal jsem bajtovou kopii dešifrované parcely, pustil na ní fsck. Na zmíněnou otázku jsem dal yes a pak na 1000 dalších. Chvíli chroupal a skončilo to tak, že na disku je jenom lost+found a v něm 900 adresářů a 11 000 souborů. Všechny pojmenované #číslo. Celková velikost zhruba sedí s tím, co si pamatuju.
>>
>> Naštěstí jeden z těch adresářů je můj home včetně původní struktury, pouze nahodile mu chybí některé soubory a adresáře. Ty budou pravděpodobně bez názvů v tom lost+found.
>>
>> Pokud by někdo z vás věděl, jak to zrekonstruovat ještě lépe, velmi to uvítám.
>>
>> A kdyby mi někdo chtěl říct slovo záloha, tak tu mám, na vzdáleném serveru. Vždy prvního dělám nultou zálohu a denně inkrementy. U nulté 11GB hlásí gpg2 —decrypt pohodu, bzip2 -d následující v koloně však někde ve 3/4 ohlásí chybný kontrolní součet. Kdoví proč. Asi bug v pbzip2 (chtěl jsem ušetřit čas paralelizací). Doporučuju vám ho nepoužívat. Spíš přejdu na gzip.
>>
>> Takže ode dneška kromě vzdálených záloh budu dělat ještě týdenní rsyncy celého FS, protože mít harddisk, který bych mohl prostě vyměnit za ten co je v notebooku by mi ušetřilo teď minimálně dva dny. A přes USB 3 SATA adaptér to umí fičet až 400 MB/s.
>>
>> Ach jo, udělal jsem i další pitomosti, tak nebuďte blbý jako já.
>>
>> Vláďa Macek | +420 608 978 164
>>
>>
>>> 25. 1. 2022 v 17:52, Jan Kasprzak <kas na fi.muni.cz>:
>>>
>>>     Zdravim,
>>>
>>> Vladimír Macek wrote:
>>> : Zdravím,
>>> :
>>> : Po probuzení za spánku Xubuntu na notebooku hlásil, že je přemountoval ext4 root na ro.
>>> :
>>> : Po restartu a připojení disku přes adaptér k jinému počítači fsck opravil superblock ze zálohy.
>>> : Pak ukazuje
>>> :
>>> : Root inode is not a directory.  Clear<y>?
>>> :
>>> : Je nějaká naděje, že když se odpoví y, tak bude FS opraven? Případně jak doporučujete postupovat k obnově FS?
>>>
>>>      Udelat 1:1 kopii pres dd conv=noerror a experimentovat jen na ni
>>> nebo jen na originalu. Tipoval bych, ze pokud je treba vytvorit root inode,
>>> tak to prime potomky korenoveho adresare nataha do /lost+found, odkud je
>>> s trochou stesti pujde poznat. Teda pokud je poskozeny jen ten root
>>> inode a nic moc jineho.
>>>
>>> -Y.