Yep, those are the conflicts I was asking you about. What kind of issues did you have?
Well the original conflict turned out to be IT instituting McAfee EndPoint security without really notifying key folks when they were putting into place on servers.
In trying to figure out why my backups were taking longer and longer to complete thus taking from 24 to 36 hours to complete I received recommendations that VEEAM really should be on its own server.
Considering how many VMs that were added over time it made sense.
I had already tried setting up the tape drive on VEEAM, but it interferred with my other backup software which was using the tape subsystem. Makes sense but was worth a shot at the time.
So my VEEAM server does not have a direct attached tape subsystem.
It backs up to local disks. When it was on the same server as my other backup software, it was easy enough to just back up the local disks.
Sorry, but it's still unclear
Sorry, I sometimes have a hard time trying to explain.
I have 3 backup jobs to try to separate the main job for most of my VMs, from the few that I occasionally have problems with which are also split between two jobs.
The schedule is fairly simple. Full once a week, incrementals in between.
They get backed up to local disk configured as the local VEEAM repository.
Attached to each of those main backup jobs are Backup Copy jobs. Those back up to the other VEEAM repository on the old server.
Those Backup Copy jobs I gather do synthetic fulls when they are copying the original backup files to the alternate server since the size of the files is usually smaller on my other backup server.
You mention GFS restore points with labels. I don't make it that complicated. I figure if I have to restore something from an older backup, once I restore the needed files from tape, I should be able to point VEEAM to them and start a restore process.
From there my other backup server backs up the all files on the disk which includes the Backup Copy files to tape.