2 May
2002
2 May
'02
12:01 a.m.
So I finally got this TSZ07 that I've been wanting for a while so I can
archive a mountain of magtape I have (including System III sources for
the 11/780, on up to distro tapes of the 1990s). I can use dd to slurp
stuff off of tape, but it's tedious. What tools are people using for
tape archiving under Linux or Solaris? AIX seems to come with "tcopy"
that essentially pulls everything off the tape until logical or physical
EOT. I'm looking for something similar - point it at the drive and
siphon it on down.
At present, because of cable reach, I am talking to the tape drive
through an Adaptec AHA1460 PCMCIA SCSI interface on a Dell Latitude LM
running RedHat 5.2. I can address the drive fine and dump files with
dd and cat. I'm looking for a bulk data slurper, source or RH RPM. I'm
willing to throw this beast on the SPARCstation 5, but I'd rather not
put it in that corner just yet. At the moment, the drive is several
dozen times larger than the computer controlling it.
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
2 May
2 May
12:53 a.m.
On Thu, May 02, 2002 at 02:01:33AM -0700, Ethan Dicks wrote:
So I finally got this TSZ07 that I've been wanting
for a while so I can
archive a mountain of magtape I have (including System III sources for
the 11/780, on up to distro tapes of the 1990s).
Unfortunately System III is not
covered by the Caldera Ancient UNIX
License. http://www.tuhs.org/Archive/Caldera-license.pdf
But if you have somthing that is not in the TUHS Archive and covered
by the license, please hand it to Warren Toomey...
What tools are people using for tape archiving under
Linux or Solaris?
cptape,
ftp://ftp.cs.tu-berlin.de/pub/bsd/UnixArchive/PDP-11/Tools/Tapes/
from the README:
This program can read a tape on
a UNIX box without the user having to
know anything about its format. This program automatically determines how many
files are on the tape, what is the record size for each, and whether there are
any oddities such as partial records. It saves each tape file into a separate
disk file and produces a log of everything found on the tape.
Restoreing the tapes can be done with:
ftp://ftp.cs.tu-berlin.de/pub/bsd/UnixArchive/PDP-11/Distributions/ucb/2.11BSD/maketape.c
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
12:59 a.m.
there is also dump & restore, if the Sparc is running solaris there is
ufsdump and ufsrestore, and finally if all else fails tar
these programs should allready be (dump and restore) on the redhat box.
Benjamin
On Thu, 2 May 2002, Ethan Dicks wrote:
So I finally got this TSZ07 that I've been wanting for a while so I can
archive a mountain of magtape I have (including System III sources for
the 11/780, on up to distro tapes of the 1990s). I can use dd to slurp
stuff off of tape, but it's tedious. What tools are people using for
tape archiving under Linux or Solaris? AIX seems to come with "tcopy"
that essentially pulls everything off the tape until logical or physical
EOT. I'm looking for something similar - point it at the drive and
siphon it on down.
At present, because of cable reach, I am talking to the tape drive
through an Adaptec AHA1460 PCMCIA SCSI interface on a Dell Latitude LM
running RedHat 5.2. I can address the drive fine and dump files with
dd and cat. I'm looking for a bulk data slurper, source or RH RPM. I'm
willing to throw this beast on the SPARCstation 5, but I'd rather not
put it in that corner just yet. At the moment, the drive is several
dozen times larger than the computer controlling it.
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
1:34 a.m.
On Thu, 2 May 2002 cvisors(a)carnagevisors.net wrote:
there is also dump & restore, if the Sparc is
running solaris there is
ufsdump and ufsrestore, and finally if all else fails tar
these programs should allready be (dump and restore) on the redhat box.
I'd be very interested to know if RedHat dump/restore will fly on
those magtapes. Linux' version only works on ext2 filesystems on the
dump side, but since the tape archive (_IF_ it was generated by unix
dump) isn't exactly a filesystem.... My bet would be a big no go, but
now I'm curious.
BTW, Jochen turned me on to the maketape utility from PUPS a while
back. It works very well.
Doc
4:25 a.m.
--- cvisors(a)carnagevisors.net wrote:
there is also dump & restore, if the Sparc is
running solaris there is
ufsdump and ufsrestore, and finally if all else fails tar
these programs should allready be (dump and restore) on the redhat box.
You misunderstand the direction I'm going. I have magtape with data
already on it. I want to extract that data into a file or set of
files on the disk that I can then burn to CD-R. I can use dd to move
raw records, but I would like to also know what the block size was
for a particular file so I could reconsitute the tape later if
necessary. I'm not so worried about the VMS BACKUP tapes I need to
spin off - I want one saveset per file. If I want to dup any install
tapes (non-VAX), the blocking becomes more critical.
Essentially, a physical backup that is primarily for data recovery,
but secondarily for later restoration.
I do not intend to use magtape as a primary backup media for Linux
or Solaris. Writing tape is not a concern here, only reading. I
do know how to operate dump/restore, tar, etc. They are of _no_ use
here.
Benjamin
On Thu, 2 May 2002, Ethan Dicks wrote:
>
> So I finally got this TSZ07 (to) archive a mountain of magtape...
> What tools are people using for tape archiving under Linux or Solaris?
(by "tape archiving" I mean "archiving *of* tape, not *to* tape; sorry
if my exact phrasing here is confusing. I thought there was enough
context to show what I was trying to do).
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
7:01 a.m.
Ethan Dicks wrote:
(by "tape archiving" I mean "archiving
*of* tape, not *to* tape; sorry
if my exact phrasing here is confusing. I thought there was enough
context to show what I was trying to do).
Check this web page out http://www.trailing-edge.com/
It may say a good way to archive stuff.
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
1:01 p.m.
--- Ben Franchuk <bfranchuk(a)jetnet.ab.ca> wrote:
Ethan Dicks wrote:
Doh! Good suggestion. It should have been one of my first stops.
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
..."archiving *of* tape...
Check this web page out http://www.trailing-edge.com/
It may say a good way to archive stuff.
2:43 p.m.
On Thu, 2 May 2002, Ethan Dicks wrote:
--- cvisors(a)carnagevisors.net wrote:
I realized after looking at the message again, oh well, I was just trying
to return the help I have recieved off this group many time...
Benjamin
there is also dump & restore, if the Sparc is
running solaris there is
ufsdump and ufsrestore, and finally if all else fails tar
these programs should allready be (dump and restore) on the redhat box.
You misunderstand the direction I'm going. I have magtape with data
already on it. I want to extract that data into a file or set of
files on the disk that I can then burn to CD-R. I can use dd to move
raw records, but I would like to also know what the block size was
for a particular file so I could reconsitute the tape later if
necessary. I'm not so worried about the VMS BACKUP tapes I need to
spin off - I want one saveset per file. If I want to dup any install
tapes (non-VAX), the blocking becomes more critical.
Essentially, a physical backup that is primarily for data recovery,
but secondarily for later restoration.
I do not intend to use magtape as a primary backup media for Linux
or Solaris. Writing tape is not a concern here, only reading. I
do know how to operate dump/restore, tar, etc. They are of _no_ use
here.
Benjamin
On Thu, 2 May 2002, Ethan Dicks wrote:
>
> So I finally got this TSZ07 (to) archive a mountain of magtape...
> What tools are people using for tape archiving under Linux or Solaris?
(by "tape archiving" I mean "archiving *of* tape, not *to* tape; sorry
if my exact phrasing here is confusing. I thought there was enough
context to show what I was trying to do).
-ethan
3 May
3 May
11:27 a.m.
On Thu, 2 May 2002, Ethan Dicks wrote:
> ...I'm not so worried about the VMS BACKUP tapes I need to
> spin off - I want one saveset per file. If I want to dup any install
> tapes (non-VAX), the blocking becomes more critical.
Because blocking has come up over and over again on this thread, I
thought I should share the cause of my concern and the instigation
of that comment... I am fairly certain that when I was playing with
2BSD 10+ years ago, I had to go through some gyrations to duplicate
the install tapes because it uses two block sizes, depending on
the file and what program consumes the file (there's a boot file, a
cat utility, a readme file, a disk format program, a restore utility
and a saveset)
Just capturing the contents of the tape with dd, gives me the data,
no question about that. What I won't be able to do, though, is to
build a bootable, installable tape if all I have are the resulting files.
i.e. - I'll have the data but not the meta-data.
In any case, thanks for all the suggestions. I'll be looking for
the software mentioned in this thread.
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
2 May
2 May
5:13 a.m.
At 02:01 AM 5/2/2002 -0700, Ethan Dicks wrote:
I can use dd to slurp
stuff off of tape, but it's tedious. What tools are people using for
tape archiving under Linux or Solaris? AIX seems to come with "tcopy"
that essentially pulls everything off the tape until logical or physical
EOT. I'm looking for something similar - point it at the drive and
siphon it on down.
I was looking for tape-sniffing tools the other day, too.
I didn't find one, but I'll try this 'cptape' under RedHat.
As we all do, I'm sure, I have piles of miscellaneous media
(DAT, 8mm, DLTs, floppies, etc.) that may not have proper
labels. I throw them into piles and hope to someday confirm
whether they're readable or which file system made them,
before I toss them or archive the contents.
Maybe Sellam has found some useful tools for his data recovery
business. When I searched the web for tape-sniffing tools,
most links pointed to commercial four-figure solutions,
either for law enforcement or data recovery emergencies.
- John
7:25 a.m.
At 02:01 AM 5/2/2002 -0700, Ethan Dicks wrote:
I can use dd to slurp
stuff off of tape, but it's tedious. What tools are people using for
tape archiving under Linux or Solaris? AIX seems to come with "tcopy"
that essentially pulls everything off the tape until logical or physical
EOT. I'm looking for something similar - point it at the drive and
siphon it on down.
Whats wrong with cat ?
use the /dev/nst0 device, its the one that dont rewind
( use mt commands for that kind of stuff )
cat /dev/nst0 > file1.tap
cat /dev/nst0 > file2.tap
and so on
I see most are using dd when cat is all they need
dd was originally, and still is an ebcdic <> ascii
conversion tool that will do reblocking
and is still the tool to use if you want to
count xx blocks of size xx, use offsets etc
but for pulling off of tape or writing a floppy
image to a floppy all you need is cat
cat /dev/scd0 > /files/cdromimage.iso
presto an iso that you can mount
on the loop device or burn to another cd
get the picture ?
9:05 a.m.
On 2002.05.02 18:25 Raymond Moyers wrote:
Whats wrong with cat ?
[...]
I see most are using dd when cat is all they need
cat(1) and dd(1) do not read / recognize the _physical_ block size of
the tape. The block size that you can specify with the "bs=' parameter
of dd(1) is _not_ the physical block size of the tape, it is the size of
the dd(1) internal buffer space, i.e. the third parameter of a read(2)
call. I think you can play with cat(1) / dd(1) to read / write the data
but you will have to set / snoop the tape block size with mt(1)
accordingly... A very painfull and error-prone procedure. As boot tapes
and the like are critical about the physical block size of the tape, you
need a programm that reads / writes the data _and_ the physical block
size for each file on the tape. => cptape / maketape.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
10:08 a.m.
On Thursday 02 May 2002 13:05, you wrote:
On 2002.05.02 18:25 Raymond Moyers wrote:
At the portion of the work where you just want to get the stuff
spooled to a file, you dont care about "block size" yet, you
just need to get it pulled off.
Unix will treat any device as a stream of bytes
On my old sony, mkboot is broken, you cant use the OS to
create a bootable volume of itself
so ... you hang the old scsi disk off your linux box and
cat /dev/sdb > /files/sonyhdimage.img
hang the new scsi disk off your linux box
cat files/sonyhdimage.img > /dev/sdb
Put new disk in sony, look mom it boots !!
Now you redo the disklabel and shove everything
except root up to a new volume above the footprint of the old disk
redo the middle volumes to suit ... move the stuff back down
mount the new space as /usr/local whatever
Now you have a 1g bootable disk in a machine that cannot create
one for itself...
Do you see what im getting at here ? hello ?
and guess what ... i never even bother to involve myself with
any "block sizes" even as the multiple volumes on
that image uses a mix of logical block sizes.
I was pointing out a tool used as a simple bit stuffer
and it was my intention to point out some things that might
not be clear, if they was not familiar with the raw
behavior of what they was doing.
Raymond
Whats wrong with cat ?
[...]
I see most are using dd when cat is all they
need
cat(1) and dd(1) do not read / recognize the _physical_ block size of
the tape.
2:12 p.m.
On 2002.05.02 21:08 Raymond Moyers wrote:
Unix will treat any device as a stream of bytes
And that is not appropriate for tapes. You have files on a tape. A tape
file consists of records (blocks). The records may be different in
length from file to file. Unix does not know about that, so the
information about the record size is lost. But many boot Proms rely on
particular record sizes.
And keep in mind that streaming tapes for backup (i.e. that what we know
as tape today) is only a "simplification" of a real tape station. A real
tape station can handle tapes in block addressable mode, exactely as a
disk! You have block devices for this tapes and you can put a regular
file system on it, and mount that file system like a disk.
(I saw one of these beasts running on a CDC Cyber 960 supercomputer on
the VCFe last weekend. Really impressive! That litle Cray EL98 beneath
the CDC looked like a toy compared to that dinosaur.)
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
8150
days inactive
8151
days old
13 comments
7 participants
participants (7)
-
bfranchuk＠jetnet.ab.ca -
cvisors＠carnagevisors.net -
doc＠mdrconsult.com -
erd_6502＠yahoo.com -
jfoust＠threedee.com -
jkunz＠unixag-kl.fh-kl.de -
rmoyers＠nop.org