How Vms backup works ?

[Hein van den Heuvel]

Hello there Jiri,

Judging by the points assignted to the replies the anwers received apparently did not answer the question asked. "help you better understand how VMS backup works?"

Or did you perhpas not like the answers, even though technically correct.?

It seemed to me the explanations offered where reasonably complete and to the point.
Now that you have several good starting points, maybe you want to restate the real question?

fwiw,
Hein.

[Jiri Koutnik]

Hi everyone,

let me summaries all your comments.

1)Backup has no knowledge of the contents of a file. => ok, nothing to add, expectations.
2) There have been noises from HP about a compressing BACKUP, though that's
not documented and available as yet. => here still Im confused, what does depends compression on ? we tested to backup empty datafile against data-full datafile and we can see the differencies at number of datafiles we are able to back up to the tape. So there must be some compression dependencies which calculate how much is datafile full of data or empty but in both cases is allocated on OS.
any idea ?
3) how VMS backup works => it reads in ascending disk block number order block-by-block all allocated block of the file (or files) in several parallel streams to memory, put them to defined buffer that goes to the tape.
am I correct ?

thanx alot, expect more points :-)
Jiri

[Volker Halle]

Jiri,

re 2) compression could happen at different levels: software (BACKUP) or hardware (tape). Adding compression into BACKUP may be an option possibly showing up in a future release of OpenVMS.

Compression algorithms may be able to better compress 'empty' files than 'full' files - if empty means: all ZEROs in the file.

Volker.

[Hein van den Heuvel]

>> we tested to backup empty datafile against data-full datafile and we can see the differencies at number of datafiles we are able to back up to the tape.

Interesting. It may well have been the tape defining the throughput. Backing up to the NL: device or a disk, or a virtual tape may remove that variable component from the test.
Virutal tapes are a new feature for the LD driver. See http://www.digiater.nl/lddriver.html.

>> So there must be some compression dependencies which calculate how much is datafile full of data or empty but in both cases is allocated on OS.

>> any idea ?

1) Could really be the tape hardware.

2) Secondary hardware and usage issues.
For example, whn you allocate space on an EVA controller you only get the PROMISS of space, not the actually disk blocks. It is only when you touch (chunks) of data for the first time that the EVA finds a free chunk.
So I recall one instance where sequential reads were surprisingly slow. It turned out that the data had been written randomly through the allocated range resulting in random access pattern for sequential reads.
Ever since that experience, when we do a serious benchmark, I first write zeroes to the allocated storage (with DD on unix or INIT/ERASE on vms) to make sure the result will be predictable. Maybe not optimal, but predicatble. This obviously slows us down and voids some EVA features (re-balancing) but that's ok by me.

>> thanx alot, expect more points :-)

It wasn't about the points themself. I took them as an indication that there were lingering, un specified problems / questions.

Hope this helps some more,

Hein van den Heuvel
HvdH Performance Consulting

[GuentherF]

"3) how VMS backup works => it reads in ascending disk block number order block-by-block all allocated block of the file (or files) in several parallel streams to memory, put them to defined buffer that goes to the tape.
am I correct ?"

BACKUP reads by extent size. See DCL-DUMP/BLOCK=COUNT:0/HEADER and look at the "Count:" number for each extent. Extents larger than the /BLOCKSIZE (which is also the size of BACKUP's internal buffers) are broken down into smaller I/Os to fit the remaining space in a buffer.

/Guenther

[Jiri Koutnik]

Thanx alot, I thing the provided information got me pretty good knowledge how VMS Backup works, or should works :-)

Jiri