linux user group brescia

Allora, alla fine è stato un lungo parto ma ce l'ho fatta, e purtroppo non
con mdadm, con quello non c'è stato verso.

comunque, ho utilizzato r-studio, gli ho dato in pasto le 3 partizioni che
componevano il raid, gli ho detto che era un raid5, block size 64k e poi da
lì ho fatto l'immagine dd.

però a linux questo non bastava, perchè il filesystem era comunque
corrotto, il log dell'XFS era "sporco" e quindi non mi montava nulla, sa il
demonio che cosa gli è stato fatto a quel povero NAS.

fatto sta che con un po' di XFS repair e incrociando le dita, alla fine
sono riuscito a montare il filesystem e domani con calma mi copierò fuori i
dati che mi servono.

tuttavia non sono ancora contento della cosa, perchè non capisco
assolutamente per quale motivo mdadm si rifiuti così insistentemente di
riassemblarmi l'array.

ho dato un'occhiata alle partizioni anche con testdisk e disktype, e la
cosa interessante è che con testdisk mi riesce anche a dire la versione di
mdadm usata per creare le partizioni (metadati 0.9 compatibili).

mentre questo è l'output del comando disktype eseguito su una delle 3
immagini.

--- NAS_hdd1.001
Regular file, size 149.0 GiB (160000000000 bytes)
DOS/MBR partition map
Partition 1: 1.915 GiB (2056287744 bytes, 4016187 sectors from 63)
  Type 0xFD (Linux raid autodetect)
  Linux swap, version 2, subversion 1, 4 KiB pages, big-endian
    Swap size 1.915 GiB (2056183808 bytes, 501998 pages of 4 KiB)
Partition 2: 146.6 GiB (157423633920 bytes, 307468035 sectors from 5028345)
  Type 0xFD (Linux raid autodetect)
  XFS file system, version 4
    Volume name ""
    UUID 83FC6212-B86A-4218-A7CF-733A67039327 (DCE, v4)
    Volume size 293.2 GiB (314846478336 bytes, 76866816 blocks of 4 KiB)
Partition 3: 494.2 MiB (518192640 bytes, 1012095 sectors from 4016250)
  Type 0x83 (Linux)
  Blank disk/medium

tra l'altro, anche l'ultima partizione di tipo x83 (linux) non la monta
nemmeno a pagarla.....

mi sorge il dubbio a questo punto che i dischi fossero in qualche modo
danneggiati a livello logico, perchè è veramente assurdo.

Francesco


2011/12/19 Rampage Rmp <atomikramp a gmail.com>

> Ho recuperato tutto quello che potevo sull'apparato,
> non ho il modello esatto ma è una buffalo terastation, ho trovato
> parecchia documentazione online a riguardo, è basata su processori ARM e
> tutti quanti dicono di utilizzare mdadm per riassemblare il raid, anche
> facendo le operazioni di inversione del byteorder nel caso si tenti un
> recupero su architettura x86 invece che PPC (big endian).
>
> un'azienda che propone servizi di recupero dati ha sviluppato un
> softwarino sciocco che costa anche poco (50€ ero veramente tentato di
> acquistarlo) che mi riconosce tutto e mi fa accedere ai dati, il raid array
> è un raid5 tradizionale 1,2,p,4,p,3,p,5,6 la dimensione del filesystem è di
> 320gb (160gb*3-160gb) e riesco ad accedere ai dati.
>
> E' che ormai è diventata una questione di principio...
> Francesco
>
>
> 2011/12/19 Andrea Gelmini <andrea.gelmini a gmail.com>
>
>> Il 18 dicembre 2011 22:59, Rampage Rmp <atomikramp a gmail.com> ha scritto:
>> > Ciao,
>> > ho provato con un tool di data recovery che avevo qui (r-studio) per
>> > windows, che fa l'assemblaggio dei RAID, e anche se non mi riconosce il
>> > filesystem, analizzando i dati in hex editor si vede abbastanza
>> chiaramente
>> > che con un algoritmo standard raid5 i dati sono coerenti (le stringhe
>> ascii
>> > sono complete ecc).
>>
>> Ma, di grazia, in base a quale criterio assembla un Raid5?
>> Gia' solo l'implementazione di mdadm ha un fottio di modalita' di
>> creazione.
>> La mia idea è che se non c'è un superblocco adeguato, semplicemente
>> non si tratta di un software raid del kernel.
>>
>> > purtroppo io ho solo le immagini dei dischi, lo scatolotto infernale non
>> > l'ho, il fatto che il filesystem sia XFS mi fa pensare che FORSE
>> potrebbe
>> > essere stato usato un sistema BSD, ma a quel punto non mi spiegherei
>> > l'identificativo della partizione come Linux RAID.
>>
>> La marcatura della partizione è assolutamente aleatoria. E' chiaro che
>> si può marcare in tutte le salse, e la sostanza non cambia.
>> Voglio dire, poiché la marcatura è, ovviamente, numerica, i
>> costruttori possono averla marcata in qualsiasi modo, anche
>> casualmente.
>>
>> > c'è da dire che XFS essendo come signature proprio all'inizio inizio
>> della
>> > partizione, non so dove potrebbe eventualmente mdadm aver messo i
>> > superblock.
>>
>> Se mdadm -E non torna nulla, significa che il superblock non c'è.
>> Mdadm controlla
>> tutte le varie versioni (in testa e in fondo alla partizione, ecc).
>> Io userei un altro approccio:
>> a) fai un xfs_check della partizione secca (ovviamente forzando di non
>> fare modifiche, per stare sul sicuro monta i loopback su una
>> partizione readonly);
>> b) a seconda di quello che torna, unisci tutte le immagini, e ripeti
>> l'operazione. Il fatto che manchino dei marcatori specifici per la
>> roba raid, a me fa pensare che il tutto fosse stato messo insieme in
>> modo completamente lineare;
>> c) fai un'analisi dei superblocchi di XFS, per cominciare a capire la
>> dimensione del filesystem. In questo modo puoi avere piu' informazioni
>> sullo stato di configurazione dei dischi.
>>
>> Reperisci la marca/modello dell'affare, probabile online di trovare
>> almeno delle informazioni.
>>
>> Non da ultimo, prova a far girare sulle immagini raw photorec.
>> Ovviamente non ti interessa tanto il recupero, quanto vedere cosa
>> recupera. Se effettivamente piglia tronconi tutti uguali di file
>> (intendo, come dimensione) allora si possono fare delle ipotesi.
>>
>> Per altro, se il sistema originario era BSD, mi sembra strano che
>> tutto il giro non fosse configurato con le slice e UFS.
>>
>> Ciao,
>> Gelma
>>
>> --
>> Info/Lamentele/Segnalazioni: andrea.gelmini a gmail.com
>>
>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lugbs.linux.it/pipermail/lug/attachments/20111221/49221ed2/attachment-0001.html>