Ant-Green has the right idea.
I have seen a number of sites where the system engineers (or a dedicated backup team) are using agent processes to take backups of everything. This is most likely what is happening at your place.
The fun can start if you ask whoever is taking these backups to do a restore to a different server. And then show they have a useable database. Most tools that do virtual backups of this type can also get the restore right, but not all of them. And very few tools can include log backups to restore to a given point in time.
The biggest problem with these virtual backups is their RTO and RPO is different to the SLA you are working to with your own SQL backups. (Hopefully you are meeting the DB RTO and RPO with your SQL backups).
Very often it is not possible to reconcile the DB SLA requirements with the capabilities of the virtual backup. This results in wasted time and cost doing and keeping the virtual backups. It can sometimes get very political, with the people running the virtual backups putting on pressure to say the SQL backups are redundant and should be stopped.
In all of this remember the DB RPO and RTO. You build a restore strategy, and the backups are merely tools you use to meet the restore strategy.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara