Tape Rewind/Non-Rewind

[Jamie Laning]

Hi,

I am playing with backing up several (PROGRESS) databases to tape. Ideally I'd like to backup my databases and then copy UNIX files (programs etc) using fbackup, ftio or something like that.

I seemed to have some of this working using /dev/rmt/0mn, but things are now a mess.

So my questions are...

Can I mix a third party backup format (PROGRESS) with a UNIX format?

If so, I assume that I have to know where I am on the tape, in order to see the contents. (I'd have to use the utility for where I am on the tape). True?

Is /dev/rmt/0mn the same as /dev/rmt/0m, but non-rewinding?

If I use the rewinding, when does the rewind occur? Is it at the start, end or both ends of the operation?

If I use non-rewinding, how can I get the tape to rewind, when everything is done?

I was given "dd if=/dev/rmt/0mn of=/dev/null" as the way to move past each tape "section". Is this correct? Are there alternatives?

TIA

[James R. Ferguson]

Jamie:

Take a look at the man pages for 'mt' -- the tape positioning utility. You can rewind, forward space, etc.

See also section-7 of the man pages for general information on tape and tape devices. Do 'man 7 mt'.

Hopefully some of this helps.

...JRF...

[Alan Riggs]

I assume that your PROGRESS data is in raw logical volumes. If so , I would suggest using a backup utility that can process both raw and formatted space.

Both omniback and (I beleive) newer versions of veritas netbackup will handle both raw and formatted objects.

[Tom Danzig · Accepted solution]

Can I mix a third party backup format (PROGRESS) with a UNIX format?

* Not sure but I would do the Progess backup first and then the Unix backups (providede you can skip over the Progress backup on the tape).


If so, I assume that I have to know where I am on the tape, in order to see the contents. (I'd have to use the utility for where I am on the tape). True?

* You can uses "mt fsf 1" to skip to the next "file" on the tape (or any number you like). If you sequentially do the backups with the no rewind tape device, this shouldn't be an issue.


Is /dev/rmt/0mn the same as /dev/rmt/0m, but non-rewinding?

* Yes

If I use the rewinding, when does the rewind occur?

* After the read/write operation is completed.

If I use non-rewinding, how can I get the tape to rewind, when everything is done?

mt rew
(assuming the tape drive is /dev/rmt/0m). Otherwise:

mt -t /dev/rmt/Xm

where X is the number of your tape drive.

Hope this helps some.

[John Palmer]

Jamie,

Beware of fbackup, no matter what device file you use (rewind or non-rewind), it always rewinds the tape and overwrites the whole contents.

Regards,
John

[Bill Hassell]

A couple of notes: man mt is good because it describes the rather bizarre behavior of AT&t devices versus Berkley devices. For intuitive behavior, always use Berkeley device files. Under some conditions, AT&T devices will reposition to the beginning of a file. mt will position as expected if you always use Berkeley devices.

First rule of SysAdmin according to tapes:

Never skimp on tapes by storing multiple backups on the same reel.

Way too many sysadmins have had to spend hours trying to figure out what was stored on a tape and in what format. None of the backup programs recognize each other's formats (well, pax understands tar and cpio but that's all). So trying to see what's on a tape may require 5-10 hours or experimenting. And don't rely on writing on a label. Your operators *will* make a mistake and not record the info correctly.

fbackup's behavior is a good thing! Just like other commercial quality backups, fbackup writes a complete index of all the files selected in the backup set and the same information is recorded onto every reel that follows if the data won't fit on one tape. The advantages are numerous to this behavior:

- All the filenames on the tape are instantly available without having to read the entire tape (required for tar, cpio, dump, pax, ftio, etc).

- The index shows where files are located. On a multireel backup, the last tape's index has the names of all the files and on which tape they are stored.

- The index has high speed access markers that allow the tape to be positioned at very high speed to get close to the file.

- Commercial quality tools allow for multiple tapes to be used in parallel to improve throughput.

Unless your data is not very important, consider carefully the cost of a good backup program. Like insurance, it is purchased just in case... Insurance is usually priced relative to the value of the item being insured.

One last note: ftio is very obsolete. It was designed only for magtapes (1/2 inch reel-to-reel and 1/3 4 inch cartridges).

[John Palmer]

Providing you keep a log of what is where on the tape (type of backup and what of), you won't have a problem. Your backup script would be responsible for this. You can even append this log file as the last file on tape when you finish the backup.

Given only the tape, you can extract this file by positioning to the end of tape as follows:-

export TAPE=/dev/rmt/?mnb
'mt fsf 1' in a loop until failure
'mt bsf 3'
'mt fsf 1'
cat $TAPE

Another tip is to always offline your tape after a successful backup run. This will ensure that no other user can overwrite it accidentally. Use 'mt offl'