linux user group brescia

immagine del castello

Archivio della mailing list

[LugBS] macchina con architettura big endian

Rampage Rmp atomikramp a gmail.com
Lun 19 Dic 2011 08:56:05 UTC
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/20111219/3ddb439f/attachment.html>


Maggiori informazioni sulla lista Lug