I've been doing some testing using some dedup appliances, and I've noticed that using the HPE StoreOnce VSA in Catalyst mode in backup to tape job, kind of slow.
What I mean, is that each copy of VBK file to tape, there is some sort of delay between them, creating the "tape shoe-shining or back-hitching" effect.
Anyway, I did created a NAS/CIFS repository in the same StoreOnce VSA using the same kind of backup files from the Catalyst repository, and the backup to tape from the CIFS repository, this symptom does not happen.
The log file that is located in:C:\ProgramData\Veeam\Backup\{BackupToTapeJob}\Agent.{BackupToTapeJob}.TapeVmBackup.log
Shows more clearly the symptom, where the copy between VBK files, there is some sort of delay, in this case, there is 12s pause to start to copy another VBK file to tape:
Code: Select all
[11.08.2020 22:37:00.585] < 3016> mt | File was backed up in elapsed: 197.2980, isIncomplete: false
[11.08.2020 22:37:00.585] < 3016> cli|
[11.08.2020 22:37:00.585] < 3016> cli| _______________________________________________________________________________
[11.08.2020 22:37:00.585] < 3016> cli| Waiting for the next command.
[11.08.2020 22:37:12.550] < 3016> cli| Next client command: [backupSrvFileToTape].
Using the CIFS repository, the delay/pause is about in less than a second, making the flow of the data to the tape drive more consistent and continuous, avoiding the stop/reposition/start of the tape.
Also, I did a bit further test, by installing the tape drive in another server and use the Tape Server service there, and the symptoms still happen in that server in the same way.
At the moment, I'm using an LTO5 SAS drive, and I do not notice problems with it, I can easily get 120MB/s in data transfers, so I don't see any sort of problems related to storage, cpu, drivers or even tape cartridges...
So, am I missing something? or maybe is there any sort for configuration in Veeam to reduce this "delay" between the "Waiting for the next command."
Best regards,
Nelson