Multiple fbackups on one tape

[Dennis Haynes]

I want to set up my hp-ux system to run fbackups nightly onto the same tape. The tape would be changed weekly (after 7 backups have run). Is this possible? If so, what would the command look like? Are there any issues with doing an frecover from one of the backups on this tape? How would I skip to the 3rd backup on the tape to recover a file?

[Jeff Machols · Accepted solution]

You will have to use the mt command (man mt) and fast forward the tape. You will need to keep track of how many backups you have on the tape, then fast forward that number. To do a restore, you can rewind the tape, the fast forward to the count you want, and issue the frestore

[Darrell Allen]

Hi Dennis,

You have to remember to use the no-rewind device when positioning (fsf) the tape.

One major point: Don't get caught by the "all your eggs in one basket" trap. You're planning on 1 tape holding a week's worth of backups. If that tape goes bad (and they do) then you've lost the backups for the week.

Darrell

[Steven Sim Kok Leong]

Hi,

I agree with Darrell. Note that non-rewinding device drivers end with a "n" eg. /dev/rmt/0mn.

If you have the budget, I suggest you purchase Omniback. I prefer Omniback over fbackup as a backup tool because of the strong media management facility in Omniback and ease of use.

With Omniback, you can append backups to the same tape while having them fully tracked. There is also no need for you to specify a non-rewinding device in Omniback. During restoration, you simply click on the file version you want to restore (based of either last modified timestamp or last backed up timestamp) and Omniback will prompt you for the correct tape number to insert.

Excellent product.

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[John Palmer]

Hi Dennis,

It's NOT possible to do what you want using fbackup.

fbackup always rewinds the tape and writes backup data from beginning of tape.

Each one of your backups would overwrite the previous.

Regards,
John

[fg_1]

Dennis

John is absolutely correct, just to prove this I did an fbackup of a directory and then put a command at the end of a script to mt (see below) the tape and when I specified another backup to go, it wrote over the first one.

You might be able to accomplish this with Tar's but not with fbackup.

MT command: mt -f /dev/rmt/0mn eod

This mt command would seek out the end of the data on the tape then try to append another fbackup to it. Didn't work though.

[Bill Hassell]

It's important to understand why fbackup (nad Omniback and all other commercial backup programs) always rewind the tape.

In the old days of 1/2" reel-to-reel magtape when a 12" reel of tape could hold about 50 to 150 megs, it was common to append backups onto the tapes to save some money on media. tar even has an option to do this onto a single backup session. But consider the fallacy of this technique: A table of contents (tar tvf) will show multiple copies of the same file! Hummm, how do you get the one from 3 days ago?

But what's worse is the human factor...someone forgets to put the right tape in place, or worse, someone writes over the beginning of a 4 day archive, thus destroying 4 days' worth of backups. And the picture gets really complicated when the data exceeds the tape and another is needed...

fbackup ensures that there is a complete directory of all files at the beginning of the tape, something that would not be possible with appending. That directory also has index markers to allow high speed searches, something that simply doesn't exist for cpio or tar or dump or pax.

Backups are simply an insurance policy, and buying cheap insurance usually means that when you need it, it doesn't pay off. I would treat the disks, the tapes and tape drives, and the backup software as a single unit when buying new systems. Always place a value on the data, then figure what percentage of that value should be insurance.