Backup log

 :file-save
 
 Is this an Incremental Save        (y or <n>)? n
 Console Listing to printer         (y or <n>)? n
 Send statistics Report to printer  (y or <n>)? n
 Verify save with 't-verify (enlt'   (y or <n>)? y
 Bypass inconsistent groups         (y or <n>)? n
 Do you want to sleep               (y or <n>)? n
 
 File Save Beginning at 23:59:01  10 Oct 2022
 
 Block size: 500
 1     2 
etc.,etc.

and then cleared the dirty bits and then
this finished withe final 7 lines as follows;

Disconnected from Virtual Machine 'pick0:LINUX'
sending incremental file list
backup.tape

sent 198,933,675 bytes  received 99,075 bytes  15,922,620.00 bytes/sec
total size is 199,987,305  speedup is 1.00

Now all we get is the final 7 lines and we don't know why. It actually happened on 11th October 22. It worked from August 21 until 10th and changed on 11th and no idea why.

Does anybody have any suggestions?

Hi Alex,

There are many ways you could be skinning this particular cat; but I suspect the following is true; or similar:

In Linux you have a crontab entry which executes the Linux script at a certain point in time, daily.

That script will exist in Linux somewhere and will have steps within it.

One step will be a d3tcl command to run some d3 command that performs the actual file-save; answering the prompts with data-stacked answers to the file-save AND with Linux std-out [screen output] redirected to a certain file in the Linux space; with overwrite. That is, it obliterates what is already there and starts over.

The next step will be something which 'sends' the backup to another location; also with screen output redirected to the SAME Linux file, but this time with append [or at least that is what should be happening]. We know the transfer itself is happening as the reported file size looks about right. 

Finally the script emails you that Linux file using it as the body of the email.

If so, it appears either the first step's redirected output isn't happening [you could comment out the following-on lines, run the script and see what makes it to the Linux file] for some reason. Or it is happening, but is then being over-written by the follow-on command instead of being appended to the Linux file. A similar debug method would help diagnose which.

That's where I'd start looking: it's all in the script that runs. Step through that and see what's happening.

HTH.