If I am going to be picky, this is not always true.
"Data are received by a bptm process and written into memory."
If the backup is local, (media server backing itself up) the bpbkar process sends the data directly to te memory buffer, bptm process then reads it and sends it to the OS, which writes it to tape.
If the backup is remote (eg. client over network) bpbkar on the client sends the data to a TCP socket. The child bptm process then reads ir from the socket and puts it in the memory buffer, the parent bptm process then reads it from the memory buffer and sends it to the OS. At no time ever, does NBU write to tape.
Anyway, I got distracted ...
The memory buffer = a bucket
Data = water
The bucket has a size eg, 256k 128k etc ... this is specified in the SIZE_DATA_BUFFERS file.
The rule is that the bucket has to be full of water before it can be tipped out ...
So if the bucket is size 256k (= 1024 x 256 - 262144 in SIZE_DATA_BUFFER file) the 256k worth of water is sent at a time to the drives (via os of course ...).
In real life, it is data, so 256k of data is sent, we call this a block of data, so the size of the block = the size of the buffer.
So if my data size is 512k and my block size is changed to be 128k
512/128 = 4 so a total of 4 blocks would be sent.
So a block is simply a 'chunk' of data.
Before anyone asks, If you had total data of size of 520k, you would write 5 blocks of data :
128k , 128k , 128k , 128k , 8k = 520k
When before I said the bucket (buffer) has to be full, there is an exception if the last bit of data isn't enough to fill it (like above example). Here we write a 'short block' which simply means the block sent is less than the specified size.
This is why NBU requires the drives to be in variable block mode, the block size can change during a backup .
Martin