Backup Copy Jobs on RDX drive

[t-st]

My small business environment in a nutshell:

Veeam B&R 9.5 U3a (Standard/Essentials), Hyper-V Host (WinSrv2016), 4 VMs (all guests WinSrv2016), one of which runs the Veeam Backup Server. Internal RAID 10 with 10k SAS disks. External USB 3.0 Tandberg QuikStor RDX drive with HDD media.

I have configured an internal ReFS formatted volume on the Hyper-V host that is set up as my internal backup repository (and is separate from the RAID 10 the VM disks sit on). A backup job is configured twice a day that backs up all 4 VMs to that internal repository. This works as expected with reasonable transfer rates (300-500 MB/s). So no complaints with that.

I have configured another backup repository on the RDX drive backed by rotated disks (sitting directly on the Hyper-V host, so no USB pass-through to the Backup Server VM). Since removable disks aren't supported by ReFS, those disks are kept formatted with NTFS as is. Of course, during configuration of the repository, I'm warned by Veeam that the disk isn't formatted with ReFS. I've read the best part of the Veeam manual, several support documents by Veeam and Tandberg and I haven't found any specific information concerning this topic and what performance implications I have to expect in conjunction with RDX. Tandberg's own integration brief (https://ftp1.overlandtandberg.com/websi ... r_EMEA.pdf) describes the setup of a RDX repository within Veeam including screenshots of each step and doesn't mention this topic with a single word. Conveniently the warning dialog concerning the file system is omitted from the screenshots altogether. So my guess is that I'm supposed to just ignore that issue.

Using the RDX repository as target I have configured a backup _copy_ job that uses the backup job mentioned before as source and is set up to start a new interval daily at 00:00 and permitted to run between 00:00 and 06:00.

I have to following issues:

1. Ejecting media: I know Veeam doesn't support automatic ejection of RDX media. So I was prepared to use a tool like freeeject.exe with some post-job scripting to eject the RDX medium. But the real problem here seems to be that backup copy jobs don't start, run and stop when they're done. They run continuously and instead of stopping after having copied the most recent retention points of the source job, the backup copy job sits idle waiting for new retention points to arrive at the source. By doing so, it keeps the RDX repository busy which in turn keeps the RDX drive busy. So no way to gracefully eject the medium no matter what method you're using. In fact, stopping the idle backup copy job by temporarily disabling it will release the RDX drive and I can successfully eject the medium using freeeject.exe. So how am I supposed to use rotated media with backup copy jobs (and the manual is suggesting this would be recommended practice) if there is no reasonable way to safely remove the medium? Has anybody with a similar configuration got this working?

2. Performance: The source job reaches transfer rates of 300-500 MB/s. The backup copy job only reaches 30-35 MB/s. I would expect rates at 80-120 MB/s with an USB 3.0 RDX drive. In any case I would expect the RDX drive to be the bottleneck. But Veeam reports the source as bottleneck. As a test I have created another standard backup job for the 4 VMs that targets the RDX repository instead of the internal repository. Transfer rates when running this job are now 60-70 MB/s. Again reporting the source as bottleneck. The same source that delivers 300-500 MB/s when using the internal repository as target. Has anybody real-world figures with USB 3.0 RDX drives? Even if my numbers are pretty much in line with other people's results I wonder why the source is reported as the bottleneck while I'm pretty sure it's not (at least not the drive).

TIA, Torsten

[foggy]

1. Post-job script should be triggered after all data processing tasks are completed. Please also review this thread for a workaround.
2. Backup copy performs random reads on source, so cannot be compared with regular backup job performance. Btw, how the repository is added to Veeam B&R, via a Windows server (Hyper-V host) or a presented to backup server VM directly?

[t-st]

1. I didn't even try to eject from a script yet. The backup copy job started a new cycle, did its thing and then stayed idle. I then tried to manually eject the drive. That only worked after I disabled the job. Anyway, I gave the whole process another try and now eject works when the backup copy job sits idle without having to disable it. I don't understand why this suddenly works, so I'm afraid that issue might come back sooner or later. I'll now try to automate ejection with a script and see how far I get and how reliable this works.
2. Well, I expected it to be slower but wasn't sure by what magnitude. I'm new to Veeam and have no reference points to compare with. Same with RDX. The RDX repository is added via Windows server, i.e. the Hyper-V host. A standard backup job runs at 60-70 MB/s. I would expect this to be higher as the source in this case is able to deliver 300-500 MB/s when backed up to another target.

Thanks for your help,

Torsten

[foggy]

Feel free to ask support to take a closer look at your setup, the last point does indeed sound a bit confusing to me (provided the same transport mode is used and source is still reported as bottleneck).