Determine size of Backup save set prior to backup

[Cass Witkowski]

I'm trying to come up with a method to determine the size of a BACKUP save set prior to performing the backup so I can make sure I have enough free disk space.

I have a disk I want to defragment. Easiest way would be to image backup this disk to a save set on another disk and then restore.

However, I would like to know how much space this save set is going to take up to prior to actually doing the backup. My resources are limited so I may or may not have another disk with the amount of free space needed. If I can't backup to a disk I will be forced to back up to tape and restore.

I know to set /GROUP=0.

BACKUP a.dat,a.com a.bck/sav/group=0

I have been working a bit with HP and experiementing a bit. For example I backed up some files (1 block each)to a save set and then dumped the save set and saw that files were all in the same save set record. However, if I now backup the three files a.dat, a.com and a.bck, each file is in its own backup save set record. The resulting backup save set is 252 blocks = 4 * 63 (32,256 bytes)

Needless to say it is a little confusing. I know that each save set record has a header and each file has a header as well.

Is there any documentation that describes how things are layed out in a backup save set? Any information on how it chooss to put only one or more than one file in the same save set record?

Thanks

Cass

[David B Sneddon · Accepted solution]

Cass,

To get a better feel of what the save set looks
like, create the save set then do a BACKUP/ANALYZE
to see details of the contents i.e. headers and
records.

Dave

[Volker Halle]

Cass,

make that command $ BACKUP/LIST/ANAL saveset.bck/SAVE

The backup saveset file and record structure is only available from the OpenVMS source listings.

For a BACKUP/IMAGE, I would expect the size of the backup saveset to be 'just a little bit more' than the USED disk space of the input disk - taking into account files marked /NOBACKUP.

I don't think it's worth while to experiment with just a few files. If you want to experiment, take a whole directory tree (couple of 100 files maybe) and then compare DIR/SIZ <...> with the backup saveset size.

Volker.

[Andy Bustamante]

Hi Cass,

Long time no see.

What sort of storage are you working with? Any chance you could either borrow disk or use a "spareset" disk for the target of your backup then modify the disk identifier and configuration.

Andy

[John Gillings]

Cass,

Why not do an IMAGE backup to another disk, then swap them around in the shelf? (or reassign LUNs in the controller) One step only required, and you know exactly what size you need (as long as the target disk is at least as large as the existing drive, you can't go wrong ;-)

Estimating the exact size of a backup saveset is tricky as it depends on LOTS of factors. I'd allow for at least twice the size of the files to be sure it will fit.

Don't try to work it out from the backup saveset layout - expect that to change. Also expect any method to estimate sizes to change. (maybe very soon! ;-)

[Cass Witkowski]

David and Volker thanks for the info about /ANALYZE. Gotta love those undocumneted qualifiers.

Andy, Sorry about the points. Blame it on the scroll wheel on my mouse. Please reply again so I can assign points. We have 100 sites with disk subsystems ranging from HSZ40s and SW300 cabinets to HSG80, to MSA1000. I would rather not have to have each site modify their disk layout. One is that is dificult to write the instructions for a variety of disk subsystems and two, the level of sophistication varies from site to site so I want to keep this simple.


John can you elaborate on things changing very soon?

I have done some testing.

In one test I had a directory where I created 10,000, 20,000, 30,000 and 40,000 files each being 1 block in size. I then did an image backup of that disk and examined the size of the backup save set.

Backup command was:
BACKUP/IMAGE diskT: diskS:a.bck/sav/group=0


Disk Size of
#files Blocks Save set
2 2 378
10,003 11,002 18,207
20,004 22,003 36,036
30,005 33,004 53,865
40,006 44,005 71,631

Remember directory file is growing also.

I also tried the same backup of real life disk I want to backup.

Disk Size of
#files Blocks Save set
15,607 66,942,568 68,035,338
11,487 44,407,522 45,134,964

No clear pattern that I can see comes to mind that can explain the different sizes of the backup file with regards to the number of files and disk blocks being backed up.


My problem is coming up with an way to estimate the size of the disk needed to store the backup file that is reasonable but not too high. I don't want to prevent someone from using a disk for the save set (versus tape) just because they didn't think they had enough free disk space.

[John Gillings]

Cass,

>John can you elaborate on things changing very soon?

Sorry, not at this time... let's just say the release notes and new features guides for V8.3 should make very interesting reading ;-)

[Volker Halle]

Cass,

the backup saveset size values seen when backing up your 'real life disks' should be more typical than the backups from your 1-block file tests.

It may be near to impossible to predict the maximum backup saveset size for backing up a certain disk.

Another test comes to mind:

$ BACKUP/IMAGE disk NLA0:BCK.BCK/SAVE

then type CTRL-T from time to time and see the saveset block count increase. Unfortunately, the Operation Count on the NLA0: device does not increase, but if you did type CTRL-T shortly before backup has finished, you'll know the backup saveset size pretty well (saveset block count times blocksize divided by 512 bytes).

Volker.

[Wim Van den Wyngaert]

Adding /group=0 will decrease the size with about 10%.

Wim

[Aaron Lewis_1]

Cass, If disk space is the concern, why not do the image copy out to tape, then restore it back to the same drive?

[Wim Van den Wyngaert]

I just did a defrag on a development system :
remove 1 disk from the system disk shadow set, mount/for of the disk, image backup from active disk to foreign disk, reboot from new disk. All well ? Then add the other disk to shadow disk. No ? Reboot from the old disk.

Very simple.

Wim

[Cass Witkowski]

Thanks for the info one and all.

[Cass Witkowski]

If I have enough time I think I will write a little DCL procedure to parse the output of the analyze output to see what interesting trends I can see.

Thanks one and all for your input.

[Cass Witkowski]

Just an update. The request to enhance the Backup utility to calculate the size of a save set proactively has been submitted to OpenVMS Engineering for their consideration.

Cass