There are 2 options to deal with this problem:
1) Deactivate the Logger in the VTPARMS member when you do a DR
2) Restore the active Logger data set backup at the same time as the BSDS.
Here is what the IBM Redbook says:
DASD-only log stream recovery like a CF-Structure based log stream, a DASD-only log stream can be affected by a system or System Logger failure. However, because DASD-only log streams are always duplexed to DASD, it is not necessary to go through the same recovery process that is required for CF-Structure based log streams, where System Logger attempts to move the log data to a non-volatile medium as quickly as possible. Also, because DASD-only log streams can only be accessed by one system at a time, the concept of peer recovery does not apply. Recovery for a DASD-only log stream only takes place when an application reconnects to the log stream. As part of connect processing, the System Logger reads log data from the staging data set (associated with the last connection to the log stream) into the local buffers of the current connecting system. This allows the application to control recovery, by selecting which system they wish to have reconnect to the log stream and when. Note that for another system to connect to the log stream and perform recovery, the staging data sets must reside on devices accessible by both systems.
Here is the link of this documentation:
IBM Redbook
So it is important for the MVS LOGGER address space to read the latest data written into the active logger for Vtape to pursue writing into it on the DR restart.