Yes, the never ending story with DBAs
I have the same discussion every time the DBA changed.

But it is the same with many application admins, too.

Having a discussion as to why a Dedupe appliance is not a good design and primary target for backups!  Then having my fears come try restoring a SQL server that took 3 days for Production.  

Really sounds familiar If such a maintenance plan is setup right, with monitoring and failure handling, and also coordinated with the backup team, then they're OK in my opinion. If not, then I would suggest to do an application consistent backup with Veeam in addition; if the DB backups fails, you still have a safety net.

A common design which often only looks good in theory is the implementation of deduplication appliances. They can be really useful if sized correctly and for specific use cases. Where things can easily go wrong is:

1. The dedupe rate was overestimated and therefore the appliance is filling up before achieving the planed retention. This can happen if the change rate is too high or the data can't be deduplicated.
2. They're used as primary repositories and with the first restore you'll notice that you can't achieve your recovery time objective. Over time the random read performance decreases, so you should always use a fast performance tier.

Oh I didn’t see your post while writing mine @Chris.Childerhose ...looks like we’ve had the same experience here

Nice to see there are others with this pain.

I’m pretty constantly revising my own plans for backup architecture.  Moving away from Synology NAS’s has been helpful but I was unfortunately down that track for about 3 or 4 years because that was always how we did it, but we finally convinced people to start using purpose-built Dell servers with local storage.  That said, getting folks to put the VBR Backup server at the recovery site instead of the primary site has been an issue in some cases, but that’s getting easier.  Using REFS was usually not an issue, but I have a coworker that has had issues with REFS in the past and is very afraid of it, and I’ve run into it as well with Microsoft’s various patches that cause REFS volumes to show as RAW, etc.

Now I’m starting down the road of the correct architecture for Linux Native Immutable backups.  My plan that was down for a client was that at the primary site there is a purpose-build Dell server with local storage.  Great.  The NAS that they are currently using for primary storage (will be repurposed as a copy repository at the recovery sites once the actually SAN that is on backorder until hopefully no later than next month) will host the data, but I was going to attach it as a RDM to a linux VM, but as others have pointed out, that’s a weakness as access to the ESXI console will allow access to linux VM console…..so, back to the drawing board.  I have a single host with gobs of disk space that’s going to be going to the recovery site, but it’s going to be an ESXI host that is going to be the replication target.  So...might have to repurpose a different server to act as a physical linux box for the copy repo.

Fortunately, I don’t run into many people-based architecture issues such as with DBA’s and app management folks because the environment’s I support I generally have full or fullish control over because we’re pretty solidly in the SMB space with our clients and my team generally does a good job of managing things with some logic on covering all the bases.