Re: READ FPDMA QUEUED und Daten weg
Am Montag, 23. April 2012 schrieb Siegfrid Brandstätter:
> Am Montag, 23. April 2012 schrieb Ulf Volmer:
> > On Mon, Apr 23, 2012 at 09:02:12PM +0100, Siegfrid Brandstätter
wrote:
> > > Hallo,
> > >
> > > Am Montag, 23. April 2012 schrieb Martin Steigerwald:
> > > > Am Montag, 23. April 2012 schrieb Siegfrid Brandstätter:
> > > > > > Aber bei dein Problem sollte dass doch eigentlich gar nicht
> > > > > > auftreten, du willst doch einzelne LVMs kopieren, oder?
> > > > >
> > > > > So ich hoffe das diese Mail heute durch geht, die letzten
> > > > > sind immer zurück gekommen, abgewiesen wegen Spam verdacht.
> > > > >
> > > > > Das Problem ist, dass die Externe nun nicht mehr eingebunden
> > > > > wird, dmesg zeigt sie zwar an, aber mounten geht nicht mehr.
> > > > > Aber nach einem "fdisk" auch nicht.
> > > >
> > > > Ok, nochmal ganz von vorn. Ich hab die letzten Mails in dem
> > > > Thread gelesen und blicks gerade nicht, was Du gemacht hast und
> > > > was die kaputte Partition / logisches Laufwerk
> > >
> > > # lvdisplay --maps
> > >
> > > --- Logical volume ---
> > > LV Name /dev/backup/bk1
> > >
> > > Physical volume /dev/sdb5
> > > Physical extents 57500 to 102299
> > > >
> > > > 1) Was ist die Partition, von der Du Daten retten möchtest?
> > > > Welches Dateisystem ist da drauf?
> > >
> > > Disk /dev/sdb: 500.1 GB, ext4
> >
> > Nein, Du hast eigentlich zwei LVM- Devices auf der Platte.
> > Ich würde eigentlich empfehlen, die beiden auch separat zu
> > behandeln.
> >
> > Dass macht die weiteren Schritte dann deutlich einfacher.
>
> Noch dazu wo ich das /backup-bk1 ganz normal kopieren kann weil ich
> darauf zugriff habe und dort kein Problem besteht.
>
> > > Leider hat die EXterne einen extrem blöden Namen ;-)
> >
> > Den kannst Du mit e2label ändern.
>
> Ahh Super, dass werde ich anschliessend gleich machen.
>
> > > # ddrescue -n /dev/sdb /media/d6bdcbaa-9432-4dc2-88da-
> > > ee6104f8b072/rettungsimage.iso logdatei.log
> > >
> > > Danach mache ich noch ein:
> > > # ddrescue -RT /dev/sdb /media/d6bdcbaa-9432-4dc2-88da-
> > > ee6104f8b072/rettungsimage.iso logdatei.log
> >
> > Wie gesagt, ich würde die Filesystem einzeln sichern, also
> >
> > ddrescue -n /dev/mapper/backup-bk1
> > /media/d6bdcbaa-9432-4dc2-88da-ee6104f8b072/backup-bk1.img
>
> Da genügt es dann auch wenn ich nur das mache:
> > ddrescue -n /dev/mapper/backup-Kino
> > /media/d6bdcbaa-9432-4dc2-88da-ee6104f8b072/backup-Kino.img
>
# ddrescue -n /dev/mapper/backup-Kino /media/d6bdcbaa-9432-4dc2-88da-
ee6104f8b072/backup-Kino.img
Press Ctrl-C to interrupt
rescued: 187904 MB, errsize: 65536 B, current rate: 298 B/s
ipos: 19968 B, errors: 5, average rate: 43556 kB/s
opos: 19968 B, time from last successful read: 0 s
Finished
# ddrescue -RT /dev/mapper/backup-Kino /media/d6bdcbaa-9432-4dc2-88da-
ee6104f8b072/backup-Kino.img
Press Ctrl-C to interrupt
rescued: 93428 MB, errsize: 0 B, current rate: 18350 kB/s
ipos: 94476 MB, errors: 0, average rate: 18344 kB/s
opos: 94476 MB, time from last successful read: 0 s
Copying non-tried blocks...
Ist noch in Arbeit!
Auf "/media/d6bdcbaa-9432-4dc2-88da-ee6104f8b072/ habe ich nun ein
/backup-Kino.img mit 175,00 GIB
Wenn ich nun das "backup-Kino.img" habe, wie gehe ich dann weiter vor?
Ich frage lieber bevor ich es wieder vergeige.
--
Einen Schönen Gruß,
Sigi
Reply to: