Asisstance in computing size

[Chaim Budnick]

One of our customers has a TZ88 tape.

We did a backup using /media=comp and /block=65535.

After the backup completed I did a mount/over=id abd then a dir/size.

There are three backup save sets with following sizes:

1. 628573
2. 2397
3. 39576

What are these block sizes (512 or 65535)?
What is the total size in BYTES of the 3 savesets?

What is the total capacity of the TZ88 tape in /media=comp mode?

Thanks,

Chaim

[Bojan Nemec · Accepted solution]

Chaim,

The size is computed in 65535 blocks. So the size of all three save sets is 43944232110 bytes.

Now the capacity:
CompacTape III (10 GB native, 20 GB compressed)
CompacTape III XT (15 GB native, 30 GB compressed)
CompacTape IV (20 GB native, 40 GB compressed)

It looks that you have put more than 40 GB on one tape ;) This is not realy true. Backup will recompute the block size to be more suitable. So you must do a BACKUP/LIST and in the header of the save set you see the real block size. Now you can compute the size in bytes.

Bojan

[Chaim Budnick]

Thanks!

Question:

It appears then that the backup savesets total size is marginal with the tape capacity. If during the course of the backup the size would actuallu exceed the capacity, then BACKUP would request inserting a second tape. Would I see this in the log file?

Over the weekend, the backup job which usually takes about 4 hors did NOT complete until Sunday morning. I did NOT see any indication in the log file that a second tape was requested, and the job appears to complete successfully. The person who switches tapes each day was unable to tell me if there was an operator request on the console. SO, I really don't know if the delay was due to a request for a second tape or not.

Chaim

[Wim Van den Wyngaert]

To my knowledge there is a message in the log file when a second tape is needed.

If you are storing compressed files such as zip files, you can store only the uncompressed quantity, or even less.

When you use backup, the default for /group is 10 (%). So, 10% overhead is added to the save set. Also the tapedrive itself is using some kind of raid-5 technique to compress the data (+- /group=25). I think this overhead is already in the tape capacity but I've not seen a written confirmation of that.

Wim

[Bojan Nemec]

Chaim,

In the log file you should see a line like this:
%BACKUP-I-RESUME, resuming operation on volume 2
and
%MOUNT-I-OPRQST, Please mount volume "VOLNAME" in device "DEVICE":
BACKUP requests: Saveset "SAVESET", Volume number 02, write ENABLED

In the sys$manager:operator.log there should be also trace of the request:

Request 1, from user "USER" on "NODE"
Please mount volume DSA002 in device "SAVESET":
BACKUP requests: Saveset "SAVESET", Volume number 02, write ENABLED

Simply try SEARCH sys$manager:operator.log BACKUP.

Bojan

[Antoniov.]

Hi Chaim,
I use BACKUP/LIST=myLogFile and I can see in myLogFile the 2.nd tape request.

Antonio Vigliotti

[Chaim Budnick]

OK!

There is indeed a request for a second tape in the operator.log. I do not see that the request was fulfilled! There is absolutely no mention at all in the backup log file.

Chaim

[Chaim Budnick]

I take that back!!!

After looking a little more carefully there is indeed a request for another tape.

Thanks so very much for all the assistance!!!!

Chaim

[Ian Miller.]

the key message to look for the mount of the second tape - then you know the 2nd tape was provided. Its a problem guessing in advance if the job is going to overrun to a 2nd tape. I added a request to the hp advocacy site
"It would be useful if BACKUP could display a summary of how many blocks, block size and number of files where written (like the one at end of the listing file). This could be used for capacity planning (monitoring of backup size)."

http://www.hpuseradvocacy.org/advocacy/metoo/metooissue.cfm?IssueID=1795

If you agree something like this would be useful then please add your vote.

[Jim Strehlow]

I often see someone asking the question "How much of the tape have I used? How much more may I put on the tape?"

On a "new" system that I set up or when I install a new tape drive, I usually run a "disk image loop" where I backup all the information on all of my disks to tape in an infinite loop.

On a new system I might notice that it looped three times before asking for another tape. I then "kill the job".
That would then give me a "sense" of how much more data it will take before we will need to plan for handling continuation tapes.

It appears you will always need a continuation tape.
On larger systems I have seen a magnetic tape magazine (stack of blank tapes) where the BACKUP will continue with the next tape in the magazine.

Jim, OpenVMS Administrator, Alameda, CA, USA