Newsgroup: it.comp.os.linux.sys
Titolo: Persi 3 Tb di dati in NAS basata su FS Linux

Ciao, non so se questo è il posto giusto per questo mio help ma sono
disperato...
Cercherò di essere breve e dare dati completi.
Ho acquistato una NAS basata su Linux, filesystem XFS - evms.
Montati 4 dischi SATA da 750 Gb ho creato 4 dischi diversi JBOD ed in
essi delle partizioni dove mettere i miei dati divisi (operazione
fatta utilizzando chiaramente il SW via browser della NAS).
Ad un certo punto stavo verificando i miei dati nn ho trovato "quasi"
più niente... Solo qualche (poche) dir e pochissimi files.
Sono andato a vedere il log della NAS:
Jun 06 2007 01:42:12 CEST System Criticol 879 unable.restore.database
Jun 06 2007 01:42:12 CEST System Criticol 875 unable.restore.database
Jun 06 2007 01:42:12 CEST System Criticol 859
invalid.database.regenerate
Jun 06 2007 01:42:11 CEST System Criticol 879 unable.restore.database
Jun 06 2007 01:42:11 CEST System Criticol 875 unable.restore.database
Jun 06 2007 01:42:11 CEST System Criticol 859
invalid.database.regenerate
Jun 06 2007 01:37:31 CEST Security Informazioni Utilizzatoreadmin
connesso da
Il panico sparito praticamente quasi tutto...
NAS rimandata in ditta ancora nn capiscono cosa sia successo....
Ho provato a mettere uno dei dischi su un pc con windows e utilizzando
il SW ontrack professional vede i file, funzionano ma sono tutti
nominati in sequenza tipo file0001 ecc... Ci sono migliaia di files e
così sarebbe impossibile capire cosa c'è.... Però questo mi dice che i
files ci sono... Ho installato il disco su un PC con linux Suse che
avevo, vedo con l'utility Configurazione LVM il disco in questo modo:
/dev/c3_18becd84/reg_swap1 Dimensione 512 Mb Tipo LV Filesystem Swap
/dev/c3_18becd84/reg_var1 Dimensione 256 Mb Tipo LV Filesystem XFS
/dev/c3_18becd84/reg_volume1 Dimensione 697.2 Gb Tipo LV Filesystem
XFS
Senza capirci niente (sono molto ignorante in materia linux) ho
provato a montare sempre con questa utility.
Se faccio il browse di volume1 trovo le mie directory/partizioni
principali che avevo creato... ma vedo tutto vuoto.
Non trovo nessuno che mi dia una mano... Io sono convinto che sia
possibile in qualche modo con qualche comando o con qualche utility
recuperare il database perso e ricostruire il tutto.... Ma come...
Non so se potete darmi una mano... lo spero tanto :)
Un saluto a tutti
Stefano

 ha scritto nel messaggio 
news:1182988699.0...@n2g2000hse.googlegroups.com...


 ha scritto nel messaggio 
news:1182988699.0...@n2g2000hse.googlegroups.com...
Ciao, non so se questo è il posto giusto per questo mio help ma sono
disperato...
[cut] 

 Stefano
Ciao, Mauro

 Montati 4 dischi SATA da 750 Gb ho creato 4 dischi diversi JBOD ed in
Scusa, non ho capito una cosa.
Tu hai 4 dischi da 750GB, in totale 3TB.
Se erano in raid0, o semplicemente 'affasciati' tramite LVM come mi pare 
abbia fatto tu, è normale che hai perso tutto.
Il raid0 (che ti permette di arrivare a 3TB come hai scritto tu 
nell'oggetto) o LVM non da ridondanza, anzi, il guasto ad un disco 
dell'array rende inutilizzabile anche tutti gli altri dati.
Con 4 dischi da 750, la soluzione più sicura (ma non è detto che sia la 
migliore) è un raid1 con sopra LVM. (oppure un raid 5, in questo caso 
avresti 750+750+750 da usare più un disco di parità usato dal raid per i 
suoi metadati)

 ha scritto nel messaggio 
news:ps5cl4x...@guestnews.guest.net...


 ha scritto nel messaggio 
news:46834a93$0$37198$4faf...@reader3.news.tin.it...


> ....dimenticavo... Ho chiesto ad una nota societą che fa recupero dati il


Ma cercare di farti pagare il recupero dalla ditta produttrice del NAS ? 
So' che e' difficile ma qua da noi quelli della HP ce ne regalarono uno 
molti anni fa per un loro errore di "taratura" di un server, come 
indennizzo.
Potresti provare a dar loro i dischi chiedendo solo indietro il contenuto.
Rizio

 tutti e 4 erano quasi pieni....
Rileggendo, ho letto male io la tua mail.

 suoi metadati)
Attenzione che detta così sembra che nel raid5 in un disco stiano tutti i
metadati e se lo perdi, perdi tutto.
-- 
Vide

Vide ha scritto:

Effettivamente, era proprio quello che stavo dicendo io.
E ripensandoci, se perdi il disco con i metadati perdi tutto, è vero.

 E ripensandoci, se perdi il disco con i metadati perdi tutto, è vero.
Nope, in RAID5 se un disco muore non succede nulla. Hai N-1 dischi
disponibili per dati ma i metadati sono divisi fra i dischi.
http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5
Se invece ne perdi due puoi perdere dati.
-- 
Vide

 Non so se potete darmi una mano... lo spero tanto :)
Sono certo che la prossima volta non arriverai impreparato e capirai
l'importanza del backup.
I 2500 euro che ti hanno chiesto per il recupero potevi investirli
preventivamente in un bel tape LTO3 e non avresti avuto problemi.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 E ripensandoci, se perdi il disco con i metadati perdi tutto, è vero.
Nel raid 5 il CRC viene scritto ciclicamente su tutti i dischi.
Comunque il NAS in questione era stato configurato in JBOD, non in RAID.
-- 
Tobe Bofh

 tutti e 4 erano quasi pieni....
Con il termine JBOD solitamente si intende la combinazione lineare dei
dischi (l'equivalente del target linear di LVM per intenderci), la fault
tollerance è la stessa del RAID 0. I dischi non sono affatto
indipendenti, se ne perdi uno il FS si trova un buco che ovviamente non
gradisce ;)
Luca
-- 
Mi piace avere amici rispettabili;
Mi piace essere il peggiore della compagnia.

 ha scritto nel messaggio 
news:f60rp2$6cg$1...@dreamland.darkstar.lan...


 ha scritto nel messaggio 
news:f608dr$nnh$1...@tdi.cu.mi.it...


 per il resto pazienza...
Le foto le recuperi sicuramente con photorec. Al più le dovrai ricatalogare
(viva exif).


 Quindi nn ho speranze :(
Hai forse speranze di recuperare parte dei dati sui dischi sani, ma è
abbastanza in forse e non senza sbattimento.
-- 
 "ti rispondo senza glissare, io"
Ricordi, i-a.d.d, 07-03-2007

 
se si tratta di foto stai tranquillo, photorec ti sarà di immenso aiuto.
-- 
777 fanno 21, arriva la volante e non c'è nessuno

motion musso: aka sathia wrote:
o in alternativa: 
http://groups.google.com/group/it.arti.fotografia.digitale/browse_frm/thread/142f5d0c4758e2c7/963adceaf034cf59?lnk=st&q=motion+musso+perl&rnum=2#963adceaf034cf59
palesemente copiato copiato da: 
http://snipurl.com/w7hm
autore:
John Stumbles
avendo linux e perl è sufficiente inserire la vostra memory card in un
lettore o collegare la macchina fotografica al computer
localizzare dove viene collegata attraverso dmesg, ad esempio nel mio caso:
sdf: assuming drive cache: write through
 sdf: sdf1
creare una directory, mkdir recovery, cd recovery, inserire il file
riportato sotto in questa directory:
recovery.pl
creare un'immagine del contenuto:
dd if=/dev/sdf1 of=recovery.img
eseguire questo comando:
cat recovery.img | perl 
recover.pl
sfogliare le immagini trovate con il vostro programma di immagini preferito.
ecco il programma da salvare con un normale editor di testo:
---inizio file
#!/usr/bin/perl
use warnings;
use strict;
my $header = "\xff\xd8\xff\xe1";
my $buff;
my $got_jpg=0;
my $outfile;
my $outfile_no=0;
my $outfile_base="recover_";
my $outbuff;
while ( ($buff=<STDIN>) )
{
    if ($buff =~ m/$header/) {  # got start of new JPG
        # write out current JPG (unless new one is the first)
        $outfile=$outfile_base . $outfile_no++ . ".jpg" ;
        print "Outfile $outfile\n";
        if ($got_jpg) { # new JPG :- end of old one
            $outbuff .= $` ; # add pre-match string
            write_outfile ($outfile, $outbuff);
        }
        $got_jpg=1;
        $outbuff = $& . $';
    }
    else { # part of JPG, or maybe not
        $outbuff .= $buff;
    }
}
print "Done\n";
sub write_outfile(){
    my $name = shift or die;
    my $buff = shift or warn "Empty buffer to write";
    open (OUT, ">$name") or die "Could not open $name";
    print OUT $buff or die;
    close OUT or die;
}
--- fine file
spero vi sia utile, nel caso vi trovaste in questa spiacevole situazione è
sufficiente installare o avviare una distribuzione live di linux
ciao ciao


 
http://groups.google.com/group/it.arti.fotografia.digitale/browse_frm/thread/142f5d0c4758e2c7/963adceaf034cf59?lnk=st&q=motion+musso+perl&rnum=2#963adceaf034cf59
Io con Sleuthkit ho recuperato di tutto, da partizioni ntfs, per di più.

 basata su Linux, filesystem XFS - evms. 
Ammettendo che sia stato un problema con il filesystem, ma esistono da 
qualche parte delle statistiche di affidabilita' dei vari filesystem per 
linux?
No, proprio non me ne frega niente delle filosofie e del perche' Linus 
non vuole usare reiser4 (se usa i plugin o se non li usa), oppure di 
presunti problemi con le licenze.
A me interesserebbe solo sapere se un filesystem e' affidabile al 99%.
Io sto usando evms + reiser, poiche' ho avuto un problema analogo al tuo 
con ext3.
Pero'.... chi mi dice che non potra' succedere anche con reiser?
Anche la storia dei problemi di licenza con zfs e' veramente molto 
stupida: io non posso usare zfs, pero' posso comprare una licenza di 
Veritas e usarlo con il kernel linux.
Non riesco a trovare un senso in questa cosa.
Allora cosa aspettiamo? Che ZFS sia venduto? Cosi' la gente potra' 
comprare una licenza per poterlo usare?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 comprare una licenza per poterlo usare?
Aspettiamo che Sun capisca di aver fatto l'ennnesima BBEP, magari.
E sì, zfs è la cosa migliore che Sun abbia mai fatto, probabilmente.

 comprare una licenza per poterlo usare?
Il problema di ZFS e' che SUN ha impiegato 10 anni e un fracco di soldi a
svilupparlo, visto che si discosta molto dal modo tradizionale con cui i
filesystem sono fatti. Inserirlo nel kernel di Linux, a parte problemi di
licenze e brevetti con cui ci si puo' mettere d'accordo con SUN - anche
sentito quello che dice il loro CEO - e' che diventa difficile pensare a
come usare ZFS con lo stesso kernel che ha lvm e VFS. E' certo che e' un bel
file system, ma Torvalds ha detto - forse era una boutade - che preferisce
trattare allora con NetApp per il WAFL :)
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname

 Jun 06 2007 01:42:12 CEST System Criticol 875 unable.restore.database
Bella pensata utilizzare XFS su di un NAS poi č particolarmente utile vero?
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/linux/bks/SGI_Admin/books/LX_XFS_AG/sgi_html/ch01.html
Dai un occhio al capitolo 6 ma dubito che ci sia qualcosa di utile per 
il tuo caso..
PS: verifica se č possibile ricompilare il kernel di Suse con il 
supporto a XFS

 Bella pensata utilizzare XFS su di un NAS poi è particolarmente utile vero?
Perche`, tu cosa avresti utilizzato?
Enrico
P.S. XFS e` l'ultimo anello, il problema potrebbe essere anche LVM o il
RAID 0/JBOD

 Perche`, tu cosa avresti utilizzato?
Ext3, perche' e' inutile avere un file system orientato alle super
prestazioni se poi hai sopra il collo di bottiglia dell'NFS. 


 prestazioni se poi hai sopra il collo di bottiglia dell'NFS. 
XFS non ha solo super prestazioni (che possono fare molto comodo,
soprattutto considerando le dimensioni massime dei file(), ma ha anche
un bel po' di funzionalita` interessanti (e.g. quota native nel file
system)
Enrico

 
beh potresti chiedere a qualche società italiana

 Raid5 "classico" è fault tolerant su un disco, QUALSIASI.
E` interessante che tu risponda a un post (a cui hanno gia` risposto in 
due) di oltre 20 giorni fa, dicendo cose gia` dette dagli altri due...