Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ufsdump / ufsrestore / space on tape

Status
Not open for further replies.

MarkBox

Technical User
Apr 17, 2001
46
US
Howdy,

I've read over a dozen threads here regarding tape backup/restore and have learned a lot.

I'd like to know how I can determine how much data is on a tape, or rather, how much free space is left on a tape.

Also, last night I created backups of 3 file systems:

ufsdump 0fu /dev/rmt/0n c0d0t0s0
ufsdump 0fu /dev/rmt/0n c0d0t0s2
ufsdump 0fu /dev/rmt/0 c0d0t0s4

I then checked the content of the tape with:

ufsrestore tvf /dev/rmt/0n (showed s0 data)
ufsrestore tvf /dev/rmt/0n (showed s2 data)
ufsrestore tvf /dev/rmt/0 (showed s4 data)

No problem. Then I wanted to add another slice to that same tape so I did this:

mt -f /dev/rmt/0 eom
ufsdump 0fu /dev/rmt/0n c0d0t0s5

However, when the backup was complete the only data I could find on the tape was for slice 5. My attempt to append to the tape failed for some reason and the backup of slices 0, 2 and 4 were overwritten.

Any ideas?

thanks :)
 
I noticed on the s4 slice you had /dev/rmt/0, is this a typo
error?
 
You have to use raw devices in ufsdump command, Slice tw0 is called entire disk, therefore u can not back up using by ufsdump instead of ufsdump use dd command.

ufsdump 0fu /dev/rmt/0n /dev/rdsk/c0t0d0s0
ufsdump 0fu /dev/rmt/0n /dev/rdsk/c0t0d0s4
.

Farah regal
good luck
"think twice and hit enter once"
 
My examples above may not be "exactly" what I used so don't worry about which 'slice' is which at this point.

No, it's not a typo. I ran two seperate backups to the same tape. The first backup at 5PM was for slices 0, 2 and 4.

I then ejected the tape (which of course rewound itself).

Then at 6PM I wanted to append more to the tape and used "mt -f /dev/rmt/0 eom" believing it would position the tape at the end of media which according to the man pages should have positioned the tape at the point just after my above backups of slices 0, 2 and 4.

I thought my backup of slice 5 would be appended to the tape after slices 0, 2 and 4 (which is why I specified /dev/rmt/0n where n means no rewind in my command for slice 5) but instead slice 5 overwrote my earlier backup.

So, instead of one tape with backups of slices 0, 2, 4 and 5 (created in 2 different sessions) I ended up with a tape backup of just slice 5.

So, was my use of "mt -f /dev/rmt/0 eom" incorrect? Is there a more proper way (one that works - ha ha) to position the tape such that I can append data to that tape since it already contains backups?

Also, still want to know of a way for me to determine how much data (megabytes) is currently on a tape or how much space is still available for backups on a tape that was previously used.

thanks for the responses :)
 
The output from ufsdump should tell you how much data is being written. You might need a switch for this output to be more detailed. A quick man on ufsdump should tell you.
As far as the tape positioning, I would use the non-rewinding device /dev/rmt/0n if you are going to lay down multiple ufsdump's from the same date. However, it is a bad practice to put multiple ufsdumps from different times on the same tape. This can cause some real heartache when restoring. You want to have "a backup" on one tape. It is worth it to buy more tapes, rather than risk over writing a good backup, by attempting to append to the tape.

crowe
 
In your command:

mt -f /dev/rmt/0 eom
ufsdump 0fu /dev/rmt/0n c0d0t0s5

you need to replace the /dev/rmt/0 eom on the first line with the non-rewind device /dev/rmt/0n

Otherwise, mt is happy enough to find the end of media, completely ignore it, and then rewind the tape to the beginning. I've always thought this is strange default behaviour, but there you go.

Hope this helps.

 
DOH! Silly me for thinking mt eom would LEAVE the tape at the end of media (seemed obvious at the time). I'll try using /dev/rmt/0n instead of /dev/rmt/0 with that command.

crowe - So if it's "bad practice to put multiple ufsdumps from different times on the same tape" are you telling me that every day I need to go in and change tapes so that the evening incremental goes on a new tape each time? That seems insane when I can put 20 Gig on a tape and an incremental only requires 2 Gig of space.

I plan on a level 0 dump once a week using a 4 tape rotation. Then a once daily incremental (levels 2, 4, 6 and 8 Tue-Fri or Mon-Thur) which I was hoping only needed one tape re-used each week (but maybe I'll use 2 to have 2 week incremental coverage)

But this is "my first tape drive" so advice is always welcome :)
 
I am suggesting to use a different tape each evening. One tape with 5 backups on it... would not be my choice.
Lets say that tape gets lost, damaged, overwritten, or whatever. It is possible that I would have to restore from a week earlier than that.
It is a single point of failure. Tapes are relatively cheap compared to a weeks worth of data.
If time is not a factor, I would suggest doing a full backup every night as well.

crowe
 
why? incremental backups don't take up loads of space, and are a far better install process

on friday we do a level 2 dump
on monday we do a level 3 dump
on tuesday we do a level 4 dump
on wednesday we do a level 5 dump
on thursday we do a level 1 dump
and eject the tape on thursday ... that way if the building burns down over the weekend the tape for the previous week is off the premises

we then do a level 0 dump every 10 tapes.

doing a level 0 dump every day is excessive ... to restore any machine:
put level 0 tape in drive and restore it ...
put last level 1 tape in drive (from previous thursday)
and move forward to the most current day ...

if you wanted to simplify matters you could just work with level 1 dumps during the week. matters how much changes on your machine and size of disks etc.

as an asside

i had a backup script that made a tar of a database directory twice a day (silly windows database kept dying without ability to repair).
it stored 60Mb tar files ... and rotated them ...

10 tar files mv'ed every day to the next numeric, when it reached 10 it deleted the last.

4 databases ... approximating 120Mb in 4 tar files ... 2 times a day 7 days a week ...
about 2.4 Gb a day ...

i found i had a problem with backup if i used DDS 2 dat tapes in my DDS 3 tape drive ...

i changed my script ...
 
Thanks for all the great info! I think I've got a handle on the "how" issues. Now I've got to decide on the backup scheme (rotation, dump levels, to incremental or not, etc).

The amount of data in a level 0 dump for the most important disk slice is only 5 Gig and a daily incremental of that slice is about 2 Gig. choices choices :))
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top