Very Computer

I have a few question on tape backup:

- every time i press the eject button, the drive does a rewind before
reject. Is this common? Is there a way to eject without rewind?

- related to the above question: if i cannot see how much tape has
been used, how can i judge whether the tape has enough room for my
next backup session? (i.e. whether this tape should be "recycled" by
starting from beginning.)

- In our current situation, each backup session fits in one single
tape. Is this common, or what happens if a tape backup session
requires multiple tapes?

- is there somewhere that explains the output of "mt status":
mt status
Mammoth EXB-8900 8mm Helical Scan tape drive:
   sense key(0x0)= No Additional Sense   residual= 0   retries= 0
   file no= 3   block no= 0

- if i do "mt fsf n" where n is large, i get
/dev/rmt/0n fsf 1 failed: I/O error
is this normal?

- what is the difference between fsf and fsr? (i.e. EOF vs records)

- i believe i have searched deep and wide on tape backup manuals and
docs. Including Sun's 2 or 3 volume Solaris Sys Admin, also parts of
the book _Unix Backup & Recovery_ W. Curtis Preston. There seems to
have very little info on how backup is done manually through tar, and
virtually no info on "mt" command. (expect the man page, which expect
one to have implemented unix) Is there a resource, a simple
introduction, a compprehensive manual, that covers the unix manual
backup process using tar and a tape drive?

- why unix so sux arses to the hilt?

------------------
background context:

We have a solaris Enterprise 220 server.
I do weekly backup manually, from a directory that contains all files
needed to backup, to a single tape, by this command, e.g.:

tar cf /dev/rmt/0n /backup_source_directory

The external tape drive is a model with part number: 599-2081-01, made
by Sun.
The tape drive has no markings to indicate model etc. I think it is
marketed as
Sun Storedge Unipack.
http://www.sun.com/storage/unipack/
(Sun products are so confusing. I can't even find a exact page online
for my drive's model, spec or manual)

The tape used is EXATAPE, Exabyte 170m AME Mammoth, 8mm data catridge.

thanks.

 Xah

 http://xahlee.org/PageTwo_dir/more.html

Depends on the tape, but yes, this is common.  DLT tapes have only one
spool, so there is no way to eject without rewinding.

Ahh, you put 'mammoth' in the subject.  Yes, I believe you must rewind.

Quote:> - related to the above question: if i cannot see how much tape has
> been used, how can i judge whether the tape has enough room for my
> next backup session? (i.e. whether this tape should be "recycled" by
> starting from beginning.)

Keep track of how much you've written to the tape and hope.  I don't
know if the mammoth can notify you of the amount used so far.

Quote:> - In our current situation, each backup session fits in one single
> tape. Is this common, or what happens if a tape backup session
> requires multiple tapes?
> - is there somewhere that explains the output of "mt status":
> mt status
> Mammoth EXB-8900 8mm Helical Scan tape drive:
>    sense key(0x0)= No Additional Sense   residual= 0   retries= 0
>    file no= 3   block no= 0
> - if i do "mt fsf n" where n is large, i get
> /dev/rmt/0n fsf 1 failed: I/O error
> is this normal?

If you don't have n files already on the tape, then it will fail.  fsf
means go forward that many files.  The files must already exist and be
present on the media.

Quote:> - what is the difference between fsf and fsr? (i.e. EOF vs records)

You can write a file with many records.  fsr moves forward records
within a file.  fsf moves forward files.

Quote:> - i believe i have searched deep and wide on tape backup manuals and
> docs. Including Sun's 2 or 3 volume Solaris Sys Admin, also parts of
> the book _Unix Backup & Recovery_ W. Curtis Preston. There seems to
> have very little info on how backup is done manually through tar, and
> virtually no info on "mt" command. (expect the man page, which expect
> one to have implemented unix) Is there a resource, a simple
> introduction, a compprehensive manual, that covers the unix manual
> backup process using tar and a tape drive?

Hmm.  I'm not sure what you're looking for.  The man page for 'tar'
tells how to read files from disk and write to a tape.  Each "session"
is written as a tape file.

You can 'mt fsf' to forward past tar "files" already on the tape.

tar cf /dev/rmt/0ubn /
will put the entire machine on tape.

Quote:> - why unix so sux arses to the hilt?

You don't want to know.

Quote:> ------------------
> background context:
> We have a solaris Enterprise 220 server.
> I do weekly backup manually, from a directory that contains all files
> needed to backup, to a single tape, by this command, e.g.:
> tar cf /dev/rmt/0n /backup_source_directory

Looks good....

Quote:> The external tape drive is a model with part number: 599-2081-01, made
> by Sun.
> The tape drive has no markings to indicate model etc. I think it is
> marketed as
> Sun Storedge Unipack.
> http://www.sun.com/storage/unipack/
> (Sun products are so confusing. I can't even find a exact page online
> for my drive's model, spec or manual)
> The tape used is EXATAPE, Exabyte 170m AME Mammoth, 8mm data catridge.

Your command seems okay.  Have you tried to restore anything?

Most tapes (mammoth included) provide almost no information back to the
host about the amount of tape used.

'mt' is a program designed to work with lots of different drives, so it
tends to support only the least common denominator.  Since some drives
don't know how much tape is left, mt doesn't ask.

Most more complex backups programs (like Veritas Netback and Legato
Networker) don't ask and don't really care how much space is left on a
tape.  They just write data until the tape informs them that it is
full.  They then start on another tape.  That's it.

--

Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
          < How are you gentlemen!! Take off every '.SIG'!! >

Most tape drives have to rewind before ejecting.  It's the drive, not
the OS.

Quote:> > - related to the above question: if i cannot see how much tape has
> been used, how can i judge whether the tape has enough room for my
> next backup session? (i.e. whether this tape should be "recycled" by
> starting from beginning.)

Keep track of how much data you've backed up (in Mbytes or Gbytes) and
know the theoretical capacity of the tape.  Incidently, most modern tape
drives support hardware compression.  Instead of using /dev/rmt/0n
(first tape-drive in non-rewinding mode) use /dev/rmt/0cn (first
tape-drive but use hardware compression and non-rewinding mode).

Quote:> > - In our current situation, each backup session fits in one single
> tape. Is this common, or what happens if a tape backup session
> requires multiple tapes?

Depends on the capacity of your tapes & the size of your backups (is it
a whole filesystem?, just a few select directories or files?, etc.). My
own tape drive holds around 14Gb (uncompressed capacity) and none of my
filesystems are this large, so for me it's normal).

Quote:

> - is there somewhere that explains the output of "mt status":
> mt status
> Mammoth EXB-8900 8mm Helical Scan tape drive:
>    sense key(0x0)= No Additional Sense   residual= 0   retries= 0
>    file no= 3   block no= 0

don't know

Quote:

> - if i do "mt fsf n" where n is large, i get
> /dev/rmt/0n fsf 1 failed: I/O error
> is this normal?

I'm not sure what you mean by "large" - but you may have a
misunderstanding of the meaing of a "file" w/respect to the tape drive.
  When backing up a directory of, say, 1000 files, using tar, the result
is just 1 tarfile on the tape (not 1000 files).

I generally prefer ufsdump over tar as a routine backup utility.  I use

tar to bundle files for moving over the net or for making a quick tape
that I intend to send off to someone.  I find ufsdump & ufsrestore much
more flexible and it can also handle special files or attributes better
than tar.

Most tape drives have to rewind before ejecting.  It's the drive, not
the OS.

Quote:> > - related to the above question: if i cannot see how much tape has
> been used, how can i judge whether the tape has enough room for my
> next backup session? (i.e. whether this tape should be "recycled" by
> starting from beginning.)

Keep track of how much data you've backed up (in Mbytes or Gbytes) and
know the theoretical capacity of the tape.  Incidently, most modern tape
drives support hardware compression.  Instead of using /dev/rmt/0n
(first tape-drive in non-rewinding mode) use /dev/rmt/0cn (first
tape-drive but use hardware compression and non-rewinding mode).

Quote:> > - In our current situation, each backup session fits in one single
> tape. Is this common, or what happens if a tape backup session
> requires multiple tapes?

Depends on the capacity of your tapes & the size of your backups (is it
a whole filesystem?, just a few select directories or files?, etc.). My
own tape drive holds around 14Gb (uncompressed capacity) and none of my
filesystems are this large, so for me it's normal).

Quote:

> - is there somewhere that explains the output of "mt status":
> mt status
> Mammoth EXB-8900 8mm Helical Scan tape drive:
>    sense key(0x0)= No Additional Sense   residual= 0   retries= 0
>    file no= 3   block no= 0

don't know

Quote:

> - if i do "mt fsf n" where n is large, i get
> /dev/rmt/0n fsf 1 failed: I/O error
> is this normal?

I'm not sure what you mean by "large" - but you may have a
misunderstanding of the meaing of a "file" w/respect to the tape drive.
  When backing up a directory of, say, 1000 files, using tar, the result
is just 1 tarfile on the tape (not 1000 files).

I generally prefer ufsdump over tar as a routine backup utility.  I use

tar to bundle files for moving over the net or for making a quick tape
that I intend to send off to someone.  I find ufsdump & ufsrestore much
more flexible and it can also handle special files or attributes better
than tar.

Most tape drives have to rewind before ejecting.  It's the drive, not
the OS.

Quote:> > - related to the above question: if i cannot see how much tape has
> been used, how can i judge whether the tape has enough room for my
> next backup session? (i.e. whether this tape should be "recycled" by
> starting from beginning.)

Keep track of how much data you've backed up (in Mbytes or Gbytes) and
know the theoretical capacity of the tape.  Incidently, most modern tape
drives support hardware compression.  Instead of using /dev/rmt/0n
(first tape-drive in non-rewinding mode) use /dev/rmt/0cn (first
tape-drive but use hardware compression and non-rewinding mode).

Quote:> > - In our current situation, each backup session fits in one single
> tape. Is this common, or what happens if a tape backup session
> requires multiple tapes?

Depends on the capacity of your tapes & the size of your backups (is it
a whole filesystem?, just a few select directories or files?, etc.). My
own tape drive holds around 14Gb (uncompressed capacity) and none of my
filesystems are this large, so for me it's normal).

Quote:

> - is there somewhere that explains the output of "mt status":
> mt status
> Mammoth EXB-8900 8mm Helical Scan tape drive:
>    sense key(0x0)= No Additional Sense   residual= 0   retries= 0
>    file no= 3   block no= 0

don't know

Quote:

> - if i do "mt fsf n" where n is large, i get
> /dev/rmt/0n fsf 1 failed: I/O error
> is this normal?

I'm not sure what you mean by "large" - but you may have a
misunderstanding of the meaing of a "file" w/respect to the tape drive.
  When backing up a directory of, say, 1000 files, using tar, the result
is just 1 tarfile on the tape (not 1000 files).

I generally prefer ufsdump over tar as a routine backup utility.  I use

tar to bundle files for moving over the net or for making a quick tape
that I intend to send off to someone.  I find ufsdump & ufsrestore much
more flexible and it can also handle special files or attributes better
than tar.

Most tape drives have to rewind before ejecting.  It's the drive, not
the OS.

Quote:> > - related to the above question: if i cannot see how much tape has
> been used, how can i judge whether the tape has enough room for my
> next backup session? (i.e. whether this tape should be "recycled" by
> starting from beginning.)

Keep track of how much data you've backed up (in Mbytes or Gbytes) and
know the theoretical capacity of the tape.  Incidently, most modern tape
drives support hardware compression.  Instead of using /dev/rmt/0n
(first tape-drive in non-rewinding mode) use /dev/rmt/0cn (first
tape-drive but use hardware compression and non-rewinding mode).

Quote:> > - In our current situation, each backup session fits in one single
> tape. Is this common, or what happens if a tape backup session
> requires multiple tapes?

Depends on the capacity of your tapes & the size of your backups (is it
a whole filesystem?, just a few select directories or files?, etc.). My
own tape drive holds around 14Gb (uncompressed capacity) and none of my
filesystems are this large, so for me it's normal).

Quote:

> - is there somewhere that explains the output of "mt status":
> mt status
> Mammoth EXB-8900 8mm Helical Scan tape drive:
>    sense key(0x0)= No Additional Sense   residual= 0   retries= 0
>    file no= 3   block no= 0

don't know

Quote:

> - if i do "mt fsf n" where n is large, i get
> /dev/rmt/0n fsf 1 failed: I/O error
> is this normal?

I'm not sure what you mean by "large" - but you may have a
misunderstanding of the meaing of a "file" w/respect to the tape drive.
  When backing up a directory of, say, 1000 files, using tar, the result
is just 1 tarfile on the tape (not 1000 files).

I generally prefer ufsdump over tar as a routine backup utility.  I use

tar to bundle files for moving over the net or for making a quick tape
that I intend to send off to someone.  I find ufsdump & ufsrestore much
more flexible and it can also handle special files or attributes better
than tar.