[unix/linux] tape restore probleem

[Verwijderd]

Dag ik heb hier een unix bak binnen gekregen waarvan de hd is gecrash. doet niks meer. maar der is een backup gemaakt op tape. deze tape heb ik. Ik heb een linux bak opgetuigt met tape der in en ben met verschillende programma's gaan proberen de tape te restoren.
tar, cpio, dd,restore werken allemaal niet. iemand nog tips/ ideenen die ik eens zal proberen?

ik weet trouwens niet met welk pakket de boel op tape is gezet.

[Tomaat]

en als je dat eens aan de eigenaar van die tape vraagt

[Lancer]

dump......

Welke unix?

[Verwijderd]

wat voor tape? hoe is het erop gezet? word die drive herkend?

[Tomaat]

Verwijderd schreef op 09 oktober 2002 @ 13:14:
wat voor tape? hoe is het erop gezet? word die drive herkend?

hoe het erop gezet is, wil hij dus weten.

[Verwijderd]

Mja, niet goed gelezen..
maar dan nog is het wel handig te weten wat voor tape (drive) het is

[im_ik]

Op het moment dat je met dd nix van je tape afkrijgt kan je het bijna schudden. (cleaning tape)
Maar post eens de error van #dd if=/dev/st0 of=tape.dd
Als je dat lukt heb je zoizo een backup van die tape op je HD staan (altijd handig,als je maar 1 tapje heb met de data
post dan ook #file tape.dd deze leest de header er kijkt og hij weet wat voor formaat het is.
cpio / tar herkendt hij zoizo.

[Verwijderd]

de eigernaar van de tape weet er niks vanaf.
het was volgens de eigeneer een sco unix machine. maar dat wist hij niet zeker. wat ik wel weet is dat het een mega lomp grote zware NCR bak is.

ok de output van dd if=/dev/st0

code:

dd: reading /'dev/st0' : Cannot allocate memory
0+0 records in
0+0 records out

[im_ik]

Ncr draait meestal mp-ras op dit is een clone van sco... (solaris/linux/sco doet het ook erop)
Maar das wel een vreemde error, wordt je tape-drive wel door je kernel herkent ?
(als root)#dmesg | grep tape

[Verwijderd]

De installaties van SCO welke wij verzorgen is altijd en alleen maar met cpio en via een script opgestart via crontab (alle mij bekende NCR levernaciers met SCO doen dat trouwens )

[im_ik]

Verwijderd schreef op 09 oktober 2002 @ 14:25:
De installaties van SCO welke wij verzorgen is altijd en alleen maar met cpio en via een script opgestart via crontab (alle mij bekende NCR levernaciers met SCO doen dat trouwens )

Maar als ik hem goed begrijp wil die NRC machine juist niet meer booten en wil hij
de data van de tape halen....via een linux machine.
allen hij heeft al een error met dd dus kan hij zoizo ook geen tar/cpio erop los laten.

[Verwijderd]

im_ik: ik denk dat hij kan uitsluiten dat het een tar backup is en kan aannemen dat dit een cpio tape is
Die melding van dd die hij hier heeft staan is al een verdachte melding en ik ben bang dat hij dan ook een groot probleem heeft.:)

<-->

Zijn er nog andere backups die je kunt uitproberen? Want meestal komt een crash nooit zonder andere problemen... _{en de kans is groot dat ik die klant van je ken}

[grep]

Verwijderd schreef op 09 oktober 2002 @ 13:59:
de eigernaar van de tape weet er niks vanaf.
het was volgens de eigeneer een sco unix machine. maar dat wist hij niet zeker. wat ik wel weet is dat het een mega lomp grote zware NCR bak is.

ok de output van dd if=/dev/st0

code:

dd: reading /'dev/st0' : Cannot allocate memory
0+0 records in
0+0 records out

Deze error kan veroorzaakt worden door een afwijkende blocksize.
Wat je dus nog kan proberen is met verschillende blocksizes te dd'en, bijvoorbeeld:

dd if=/dev/st0 bs=64k

[Verwijderd]

im_ik schreef op 09 oktober 2002 @ 14:22:
Ncr draait meestal mp-ras op dit is een clone van sco... (solaris/linux/sco doet het ook erop)
Maar das wel een vreemde error, wordt je tape-drive wel door je kernel herkent ?
(als root)#dmesg | grep tape

jah tape wordt herkend door de kernel. heb al met andere tapes gebackuped en gerestord door middel van tar op dat apperaat in die machine.

Maar als ik hem goed begrijp wil die NRC machine juist niet meer booten en wil hij
de data van de tape halen....via een linux machine.
allen hij heeft al een error met dd dus kan hij zoizo ook geen tar/cpio erop los laten.

inderdaad dit is het geval. Ok die NCR bak is oud. draaide de afgelopen 3 jaar haast niet meer maar der staat nu belangrijke data op.maar de hd doet niks meer. heb die HD in een ander machine gedaan en de partiti tabel opgevaargd dmv fdisk(onder linux) en ding gaf allemaal rare tekens en zo iets als "cannot read partition table"

maar goed ik zit niet stil en was net verder bezig met dd en de output was net:
[code]
.....
....
....
0+0 records in
0+0 records out
0+18 records in
0+18 records out

als jullie nog wat weten hou ik me aanbevolen. of denken jullie dat het aan het tapje ligt? want kan nog wel een tape regelen van een eerder backup eventueel.

[im_ik]

Ah das mooi tis opgelost

[Verwijderd]

grep schreef op 09 oktober 2002 @ 14:44:
[...]

Deze error kan veroorzaakt worden door een afwijkende blocksize.
Wat je dus nog kan proberen is met verschillende blocksizes te dd'en, bijvoorbeeld:

dd if=/dev/st0 bs=64k

thanx terwijl ik stukje hierboven aan types was had jij deze gepost. en wat denkje? ik krijg de volledige lijst met wat er op de tape staat!

[Verwijderd]

Woei. grep heeft de pils verdient zie ik

Maar wie maakt er nog tapes met een BS van 64k?

[Verwijderd]

Verwijderd schreef op 09 oktober 2002 @ 14:52:
Woei. grep heeft de pils verdient zie ik

Maar wie maakt er nog tapes met een BS van 64k?

denk ncr was kan en klare bak van ncr...


klant is trouwens KAS (amersfoort)

[Verwijderd]

nu komt probleem nummer 2. het restoren wil niet. ik ben zelf geen held in cpio maar ik heb de man page er bij gehad en pak de zooi uit met cpio -icvb -C 32768 < /dev/st0
maar lukken ho maar. enige wat ik krijg is" FOUND end of volume."
help?

[im_ik]

Verwijderd schreef op 09 oktober 2002 @ 15:32:
nu komt probleem nummer 2. het restoren wil niet. ik ben zelf geen held in cpio maar ik heb de man page er bij gehad en pak de zooi uit met cpio -icvb -C 32768 < /dev/st0
maar lukken ho maar. enige wat ik krijg is" FOUND end of volume."
help?

uhm als je dd met 64K blocken leest is het meschien ook handig om dat met cpio te doen:

cpio -icvdum -C65536 < /dev/st0

[Verwijderd]

in de header staat het volgende:

code:

%FULL/INCREMENTAL%
Full Backup


%cpio-options%
-oc -C 32768

is het verstandig om dit te geloven ? of is dat bullsh#t?
der staat dus ook full backup dus het moet mogelijk zijn dit weeer op een ander hd te pompen en dan zou alles moeten werken toch? maar jah dat luk me dus nie....

[Verwijderd]

ERIK: Ja dat zou betrouwbaar moeten zijn maar als je met dd met 64k de tape door kan lezen zou ik die ook met de restore gebruiken

Ik gebruik zelf nagenoeg altijd cpio -ivdmuc </dev/...

Houd je er rekening met dat er een absoluut pad op de tape kan staan?
Ik meen dat de optie op dat te overrulen A is (maar jij heb de man-page voor je denk ik )