[RH enterprise 3] Tar kan tape niet lezen

[Verwijderd]

Hello,

Ik heb in mijn nieuwe server (2.8 Ghz P4, 1024MB ram) een SCSI DAT tapestreamer gestoken, een HP storageworks DAT72 streamer. Volgens RedHat is het ding uitstekend ondersteund, ook HP zegt dat het ding zo werkt. Maar ik krijg hem gewoon _NIET_ aan de praat. Volgens de HP faq kan ik hem het beste met tar aansturen, wat redhat standaard heeft. Het backuppen gaat opzich prima, als ik het command geef begint de tape netjes te te lopen, ik zie een terminal output waarbij alle files langs vliegen; kortom, dat werkt goed.

Nu wilde ik een controle uitvoeren of ik alles terug kon halen, maar dat werkt dus niet.

Mijn commando's:
[root@server /]# tar cvbf 20 /dev/st0 ./data/test
en dit gaat goed, ik zie alle files langs vliegen die ik wil backuppen.

Vervolgens:
[root@server test]# tar xvbf 20 /dev/st0
tar: /dev/st0: Cannot read: Invoer/uitvoer fout
tar: Begin van `tape', ik stop nu
tar: Error is not recoverable: exiting now

Ik heb de blocksize juist gedefineerd, hieraan zou het niet kunnen liggen.
Ik heb om zeker te zijn daarom mt -f /dev/st0 erase gedaan, na iets van 2 uur spoelen is de tape leeg. Ook heb ik met mt -f /dev/st0 setblk 0 ingesteld, en daarna 10240, beide zonder effect.

Een listing met tar geeft mij:
root@server root]# tar -ztf /dev/st0
tar (kind): /dev/st0: Cannot read: Invoer/uitvoer fout
tar (kind): Begin van `tape', ik stop nu
tar (kind): Error is not recoverable: exiting now

gzip: stdin: unexpected end of file
tar: Kind retourneerde status 2
tar: Fout afsluiting uitgesteld na eerdere fouten
Ook hier is dus niets uit te lezen Wat zou dit kunnen zijn? De tapedrive is goed, anders zou het schrijven al een probleem moeten zijn. Ook is hij goed aangesloten...ik snap het echt niet meer
Als ik de blocksize niet defineer, heeft dat ook geen nut; kortom: ik schnap het niet meer. Weet iemand wat ik fout doe?

Alvast heel erg bedankt

[_JGC_]

Probeer deze eens:

find /tmp/test | afio -o -c 512 -Z -G 9 /dev/st0
afio -t /dev/st0

tar vind ik persoonlijk een minder geschikt progsel om fatsoenlijke backups te maken, ik gebruik veel liever afio (is CPIO met gzip compressie per bestand)

je voert met find een directory op die je wilt backuppen, resultaat pipe je naar afio, die met gzip -9 en een blocksize van 512 de data op tape zet. De afio -t daarna test of alles erop staat.

Bovenstaande gebruik ik met een HP DDS-3 tapestreamer.

[Verwijderd]

Mja, ik moet met mt handmatig de tape rewinden voordat het werkt, hier mijn scriptje:

code:

#!/bin/sh
TAPE_DEV=/dev/tape
TAPE_LOADED="`mt -f $TAPE_DEV status | grep ONLINE`"
TAPE_EXIT=0
DISK_DIR=/home
if [ "$TAPE_LOADED" == "" ]; then
        logger -st do_backup No tape in drive $TAPE_DEV
        exit 1
fi
sync
mount -o remount,ro $DISK_DIR
if [ $? -gt 0 ]; then
        TAPE_EXIT=$?
        logger -st do_backup Couldn\'t remount $DISK_DIR read-only
        exit $TAPE_EXIT
fi
tar cf $TAPE_DEV $DISK_DIR > /dev/null 2>&1
mt -f $TAPE_DEV rewind
tar df $TAPE_DEV -C / > /dev/null 2>&1
if [ $? -gt 0 ]; then
        TAPE_EXIT=$?
        logger -st do_backup Tape archive $TAPE_DEV doesn\'t verify with $DISK_DIR
fi
mount -o remount,rw $DISK_DIR
if [ $? -gt 0 ]; then
        TAPE_EXIT=$?
        logger -st do_backup Couldn\'t remount $DISK_DIR read-write
fi
mt -f $TAPE_DEV eject
exit $TAPE_EXIT

Dit script maakt een backup van de partitie /home en verifieert deze. Het script is vrij safe omdat het de partitie read-only mount en synct voor het maken van de backup. Eventuele fouten worden gelogd. (Ik heb dus een symlink gelegd van /dev/tape naar /dev/st0; en de /home partitie staat in fstab.)

[ Voor 13% gewijzigd door Verwijderd op 05-07-2004 17:19 ]

[Robtimus]

Verwijderd schreef op 05 juli 2004 @ 14:06:

code:

mount -o remount,ro $DISK_DIR
if [ $? -gt 0 ]; then
        logger -st do_backup Couldn\'t remount $DISK_DIR read-only
        exit $?
fi

Die laatste exit $? geeft de verkeerde waarde terug; de nieuwe $? is de returnwaarde van je logger command, niet van je mount.

[ Voor 3% gewijzigd door Robtimus op 05-07-2004 14:18 ]

[Verwijderd]

IceManX schreef op 05 juli 2004 @ 14:17:
[...]
Die laatste exit $? geeft de verkeerde waarde terug; de nieuwe $? is de returnwaarde van je logger command, niet van je mount.

Klopt, oude versie gepost ik pas het ff aan.

[Verwijderd]

Hmmm ik heb met mt -f /dev/st0 rewind de tape al wel eens handmatig gewind, (en ook geforward voor de grap) maar dat heeft iig geen effect. Dat is het helaas niet

[Verwijderd]

Wat zegt mt -f /dev/st0 status (zowel voor als na het maken van de backup)?

[Verwijderd]

Verwijderd schreef op 05 juli 2004 @ 18:00:
Wat zegt mt -f /dev/st0 status (zowel voor als na het maken van de backup)?

code:

[root@server /]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x47 (TR-5).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN
[root@server /]#

Nu staat de blocksize op 0 aangezien ik ergens gelezen had dat iemand zijn tape nu wel aan de praat kreeg. Ik heb uiteraard ook 20*512 geprobeerd wat neerkomt op 10240 bytes. Dit geeft hetzelfde resultaat (niet leesbaar)

[Papillon]

Probeer die tar command anders op de volgende manier the gebruiken ter backup:

tar -c -v -b20 -f/dev/st0 ./data/test

Ik vermoed dat je naar een bestand "20" hebt zitten backuppen. Normaliter stoei ik niet met de blocksparameter (probeer het anders ook eens zonder)

Restoren met:

tar -x -v -b20 -f/dev/st0

BTW is module "st" ook geladen (cat /proc/modules) ?

[ Voor 11% gewijzigd door Papillon op 07-07-2004 08:13 ]

[Verwijderd]

Papillon schreef op 07 juli 2004 @ 08:07:
Probeer die tar command anders op de volgende manier the gebruiken ter backup:

tar -c -v -b20 -f/dev/st0 ./data/test

Ik vermoed dat je naar een bestand "20" hebt zitten backuppen. Normaliter stoei ik niet met de blocksparameter (probeer het anders ook eens zonder)

Restoren met:

tar -x -v -b20 -f/dev/st0

BTW is module "st" ook geladen (cat /proc/modules) ?

De exacte commandregel zoals hij daar staat heeft geen effect, ook zonder blocksize geen resultaat (bij beide i/o error)

SCSI tape is wel geladen aangezien ik anders niets kon wegschrijven naar de tape. Al met al:

[Verwijderd]

Sorry dat ik zo laat reageer, beetje druk. Wat gebeurt er als je op een lagere density probeert te schrijven? (instellen met mt setdenisty). Een andere mogelijkheid is dat je verkeerde (SCSI) driver opties hebt gezet; als je opties gezet hebt met mt stsetoptions zou ik die opties weer cleanen met mt stclearoptions en eens kijken of dat helpt.

[u_nix_we_all]

En wat zegt RedHat Support ervan ?
Je hebt bij RH ES3 namelijk recht op support, je kunt dus gewoon bij
hen een probleem aanmelden. toch ?

[Verwijderd]

Verwijderd schreef op 07 juli 2004 @ 16:59:
Sorry dat ik zo laat reageer, beetje druk. Wat gebeurt er als je op een lagere density probeert te schrijven? (instellen met mt setdenisty). Een andere mogelijkheid is dat je verkeerde (SCSI) driver opties hebt gezet; als je opties gezet hebt met mt stsetoptions zou ik die opties weer cleanen met mt stclearoptions en eens kijken of dat helpt.

Ik heb een paar dagen flink geprobeerd maar het resultaat is nog steeds nul Ik voerde eerst gewoon tar cvbf 20 /dev/st0 /data/test uit, dat gaf een i/o error. In de var/log/messages staat dan het volgende:

code:

(scsi0:A:3:0): parity error detected in Data-in phase. SEQADDR(0x1a6) SCSIRATE(0x95)
st0: Error with sense data: Current st09:00: sense key Aborted Command
server kernel: Additional sense indicates Data phase error

Het lijkt er dus op dat de SCSI rate te hoog staat (had 0x20 moeten wezen toch?) Ik heb vervolgens met mt -f /dev/st0 setdensity 1 gekeken of dat nut had, maar nu krijg ik bij tar als ik een blocksize opgeef: invalid blocking factor. Detail is dat als ik geen blocking factor opgeef, dat het wegschrijven dan wel werkt, maar terughalen nog steeds niet. mt status geeft het volgende:

code:

[root@server /]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 20 bytes. Density code 0x47 (TR-5).
Soft error count since last status=0
General status bits on (41010000):

Ik denk dat de densitycodes overal verkeerd staan, maar het is me niet duidelijk hoe ik dat verander (mt setdensity verandert aan de densitycode helemaal niets )

Overigens heb ik het probleem ook bij redhat neergelegd, alleen ze komen er niet echt uit tot nu toe

[Verwijderd]

Nog een reply in 10 minuten dan maar:
ik heb even in lspci gekeken:

code:

2:0a.0 SCSI storage controller: Adaptec AIC-7892B U160/m (rev 02)

en vervolgens lees ik op linuxtapecert.org:
Adaptec 789x SCSI Issues
Over the past weeks we have been running into more and more issues involving tape drives not working properly on Adaptec 789x chipset based SCSI adapters. We are looking into recommended solutions, but for the time being our recommendation is to use a 40MHz Ultra Wide SCSI adapter like the Adaptec 2940 family (788x based) or another brand such as SiiG, Advansys, Initio, ACCard, or other.

Het ligt dus toch aan de SCSI card, ik baal er inmiddels best wel van Ik zal jullie geupdate houden over mijn bakkie maar ik denk dat ik eerst de SCSI adapter moet vervangen.

[Verwijderd]

Verwijderd schreef op 09 juli 2004 @ 08:57:
Ik denk dat de densitycodes overal verkeerd staan, maar het is me niet duidelijk hoe ik dat verander (mt setdensity verandert aan de densitycode helemaal niets )

Met setdensity verander je alleen de density voor de actieve tape, de default density zet je met mt defdensity. Met mt desities krijg je een lijstje van de beschikbare densities.

Als het probleem i.d.d. bij de SCSI-controller ligt wordt het afwachten, want dan kun je met experimenteren waarschijnlijk meer aan de tape-drive kapot maken dan goed doen (die parameters die je met mt zet zijn voor een groot deel parameters van de st module).

[Verwijderd]

Verwijderd schreef op 09 juli 2004 @ 10:42:
[...]


Met setdensity verander je alleen de density voor de actieve tape, de default density zet je met mt defdensity. Met mt desities krijg je een lijstje van de beschikbare densities.

Als het probleem i.d.d. bij de SCSI-controller ligt wordt het afwachten, want dan kun je met experimenteren waarschijnlijk meer aan de tape-drive kapot maken dan goed doen (die parameters die je met mt zet zijn voor een groot deel parameters van de st module).

Kleine update, ik heb adaptec aan de telefoon gehad en zei zeggen dat ze bekend zijn met het probleem. Ik heb op hun aanwijzing de datadoorvoersnelheid van de SCSI id van de tape lager gezet (ik zat op 160 en nu op een miserabele 16 mb/s, meer geeft errors) Het werkt nu iig wel, ik kan backuppen en ook terug halen, maar die doorvoersnelheid

Moraal voor de search: heb je problemen met je SCSI adapter en dan vooral de adaptec 789x, zet je doorvoersnelheid lager. Ik weet nog niet of ik dit acceptabel vind, maar ik denk niet dat de tape zoiezo veel sneller kan schrijven dan 16 mb/s.

[Coen Rosdorff]

16MB/s lijkt mij voor een tapedrive niet heel verkeerd. Hangt een beetje van het soort tapedrive af, en of je veel kleine danwel grote bestanden aan het backuppen bent.

(16MB/s ==> 57GB per uur)

[Verwijderd]

mijn oude normale tapestreamer (800MB tapes) deed 5 MB/s meen ik me te herinneren

[Verwijderd]

Nog een tip: let op met compressie.

• Het is efficiënter de tape-drive de compressie te laten doen dan tar i.c.m. gzip of bzip (of afio), tape-drives hebben gepatenteerde compressiealgoritmes (in hardware) die beter comprimeren dan gzip of zelfs bzip.

• Gebruik nooit zowel hardware- als software compressie tegelijk want dat produceert grotere bestanden op tape dan op disk, zodat je voor onplezierige verrassingen te staan kunt komen (m.n. volle tapes en incomplete backups).

• Het voorgaande betekent dus dat indien je veel data backupt die al gecomprimeerd is (zoals tar.gz zip, rar, cab, jpeg, mpeg, mp3, enz.), je het beste helemaal geen compressie bij het backuppen gebruiken kunt (in dat geval hardware compressie uitzetten met mt, meestal is de standard density een gecomprimeerd formaat).

[_JGC_]

Verwijderd schreef op 10 juli 2004 @ 14:02:
Nog een tip: let op met compressie.

• Het is efficiënter de tape-drive de compressie te laten doen dan tar i.c.m. gzip of bzip (of afio), tape-drives hebben gepatenteerde compressiealgoritmes (in hardware) die beter comprimeren dan gzip of zelfs bzip.

• Gebruik nooit zowel hardware- als software compressie tegelijk want dat produceert grotere bestanden op tape dan op disk, zodat je voor onplezierige verrassingen te staan kunt komen (m.n. volle tapes en incomplete backups).

• Het voorgaande betekent dus dat indien je veel data backupt die al gecomprimeerd is (zoals tar.gz zip, rar, cab, jpeg, mpeg, mp3, enz.), je het beste helemaal geen compressie bij het backuppen gebruiken kunt (in dat geval hardware compressie uitzetten met mt, meestal is de standard density een gecomprimeerd formaat).

Puh, hardware compressie goed? Misschien bij een DAT72 streamer wel, maar bij een HP DDS-3 streamer trekken afio en gzip de tapestreamer eruit qua compressieratio.