tar und streamer

[[moR-pH-euS]]

hy,
ich habe ein kleines backup-script das mir 7 verzeichnisse jeweils komprimiert in ein tar-archiv verwandelt und auf band sichert. insgesamt sind die 7 verzeichnisse 45gb gross. wenn ich von den 7 verzeichnissen tar-archive anfertige mit bzip2 kompression komme ich auf 18gb.

morpheus@freebsd-backup# du -ha /raid/tar-archive
61M /raid/tar-archive/daten_g_082404.tar.bz2
32M /raid/tar-archive/management_082404.tar.bz2
38M /raid/tar-archive/programme_082404.tar.bz2
9.1G /raid/tar-archive/projekte_082404.tar.bz2
8.1G /raid/tar-archive/transfer_082404.tar.bz2
10M /raid/tar-archive/vertrieb_082404.tar.bz2
431M /raid/tar-archive/angebote_082404.tar.bz2
18G /raid/tar-archive

so sieht das script aus:

morpheus@freebsd-backup# cat /home/morpheus/backup-scripts/backup-script-tar
#!/bin/bash

datum=`date '+%m%d%y'`

tar cfy /raid/tar-archive/angebote_$datum.tar.bz2 /raid/angebote

tar cfy /raid/tar-archive/daten_g_$datum.tar.bz2 /raid/daten_g

tar cfy /raid/tar-archive/management_$datum.tar.bz2 /raid/management

tar cfy /raid/tar-archive/programme_$datum.tar.bz2 /raid/programme

tar cfy /raid/tar-archive/projekte_$datum.tar.bz2 /raid/projekte

tar cfy /raid/tar-archive/transfer_$datum.tar.bz2 /raid/transfer

tar cfy /raid/tar-archive/vertrieb_$datum.tar.bz2 /raid/vertrieb

tar c /raid/tar-archive/*

der streamer wird folgendermassen erkannt:

sa0 at ahc0 bus 0 target 3 lun 0
sa0: <HP C5683A C111> Removable Sequential Access SCSI-2 device
sa0: 40.000MB/s transfers (20.000MHz, offset 32, 16bit)

es ist ein 20gb streamer (40gb komprimiert). eigentlich sollten die tar-archive locker auf das band passen, doch beim erstellen bricht er bereits bei dem tar-archiv transfer ab.wenn ich mir den inhalt vom band anzeigen lassen will, erscheint immer folgende meldung (zurückgespult habe ich es mit mt bevor die tar-archvie auf das band gespielt wurden)

root@freebsd-backup# tar tvf /dev/sa0
-rw-r--r-- root/wheel 452014274 Aug 24 02:09 2004 angebote_082404.tar.bz2
-rw-r--r-- root/wheel 63413007 Aug 24 02:11 2004 daten_g_082404.tar.bz2
-rw-r--r-- root/wheel 33285888 Aug 24 02:12 2004 management_082404.tar.bz2
-rw-r--r-- root/wheel 39828309 Aug 24 02:13 2004 programme_082404.tar.bz2
-rw-r--r-- root/wheel 9813817622 Aug 24 06:50 2004 projekte_082404.tar.bz2
-rw-r--r-- root/wheel 8737686706 Aug 24 09:46 2004 transfer_082404.tar.bz2
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

habe ich irgendetwas falsch gemacht oder ist das band einfach voll ? das ist jetzt schon bei drei bändern passiert... ist die größe von backup-bändern genauso wie bei festplatten angegeben (also 20gb sind in wirklichkeit nur 18gb, oder sind es "echte" 20gb ?)

 

[Tron]

Ein Schuss ins Blaue: Kann es sein, dass es sich bei den 20GB um "physiker-giga" handelt? (10^9 statt 2^30)
Dann schrumpfen die 20GB nämlich zusammen auf ~18,6GiB (20 * 10^9 / 2^30)

PS: #!/bin/bash ist bäh! Nimm die gute /bin/sh (:
PPS: Hat es einen besonderen Grund, dass du das nicht auf einmal auf das Band sicherst? So brauchst du nen Haufen temporären Speicherplatz auf der Platte.

 

[[moR-pH-euS]]

Ein Schuss ins Blaue: Kann es sein, dass es sich bei den 20GB um "physiker-giga" handelt? (10^9 statt 2^30)
Dann schrumpfen die 20GB nämlich zusammen auf ~18,6GiB (20 * 10^9 / 2^30)

PS: #!/bin/bash ist bäh! Nimm die gute /bin/sh (:
PPS: Hat es einen besonderen Grund, dass du das nicht auf einmal auf das Band sicherst? So brauchst du nen Haufen temporären Speicherplatz auf der Platte.

der speicherplatz ist egal, da das ganze auf einem 200gb raid liegt, ich hatte es zuerst direkt auf band gesichert und habe es jetzt mal so probiert damit die tar-archive auch auf dem raid liegen.
was heisst physiker-giga bzw. woran kann man erkennen das es sich um physiker-giga handelt ? google findet dazu nämlich nix...
aber das problem wird wohl die kapazität vom band sein...

 

[Tron]

Nunja, die offizielle Definition des Präfixes "giga" (kurz G) ist eben 10^9, damit rechnen Physiker und weil die Zahlen damit größer werden auch die Marketingfuzzis.
In der EDV ist ein "giga" jedoch zumeist 2^30 (== 1.073.741.824)
Daher wurde das Präfix "Gibi" (kurz Gi) für 2^30 eingeführt, aber das wird sich wohl nie durchsetzen.
Das Schlamassel fängt natürlich schon bei kilo (k 1000) bzw kibi (Ki 1024) an, jedoch ist hier der Unterschied gerade mal 2,4%, jedoch wächst der Fehler mit jeder Größenordnung expotentiell an.

 

[destiny]

das ist mal eine saufette erklärung, nix neues, aber sollte ich ausdrucken und jeder ebay versteigerung (festplatten) beilegen, damit nicht immer die rückfragen kommen

 

[Elessar]

Prinzipiell richtig, mit Marketing hats aber imho weniger zu tun.
Eine Festplatten mit normalen, dezimalen SI Größenangaben zu verkaufen ist ja nicht falsch. So wird in der Fertigung eben gezählt, es ist ein Produkt aus einer dezimal zählenden Ingenieurswelt - das der Computer anders arbeitet ist tragisch, aber Festplatte und Festplatte im Rechner sind hier eben unterschiedlich. Grobes umrechnen ist über SI-Kapazität * (0,9765)^Präfixstufe ja mit einfachen mitteln möglich.
Präfixstufe ist hier 1 bei kilo (10^3)^1, 2 bei mega (10^3)^2, 3 bei giga (10^3)^3, 4 bei ....

Richtig nervig ist das sie sich nich einigen können....
HDD-Angabe: Dezimal - zB 80GB == 80 * 10^9 Bytes == 74,49 GiByte
CD-R/RW-Angabe: Binär - 700 * 2^20 Byte == 700 MiByte == 734 MByte
DVD+-R/RW-Angabe: Dezimal 4,7 * 10^9 Byte == 4,7 GByte == 4,37 GiByte
Diskettenangabe: Willenlos. Eine "1,44MByte" Diskette hat 1,44 * 1000 * 1024 Bytes (sic!) == 1.474.560 == 1,47 MByte == 1,40 MiByte

 

[[moR-pH-euS]]

ok, damit wäre das ja geklärt ;-)
aber um wieder auf mein problem zurückzukommen:
das band wird wohl voll sein und bricht deswegen ab, oder habe ich doch etwas falsch gemacht ?