Identifying the process that is backing the databases to virtual device

  • We have about 20 SQL Servers. We use Net backup or Native backup for SQL Server database backups.

    When I query the msdb to find the backups, 2 servers have backup method different. In addition to the native backup some other process is backing up the databases to virtual device. I am struggling to identify that process.

    It is backing up using SQL Agent job to local drive & also backing up to some virtual device by some unknown process. I am sure it is not because of Net backup. Example is below

    Servername DatabaseName     Backup_Start_Date                 Physical_Device_Name

    TestServer     Test DB              2023-9-20-17:00:02:000         D:\MSSQL\Backup\TestDB

    Test Server    Test DB              2023-9-20-17:00:50:000          {F085C836-F873-...}3

    Test Server    Test DB              2023-9-20-17:00:50:000          {F085C836-F873-...}4

    From the event viewer, the backup to virtual device is showing by the user SYSTEM.

    If  it is windows backups (As mentioned in below forum) or  VM replication why that entry is logging to msdb


  • Can very well be NetBackup taking the backups.

    Anything which integrates with the VSS/VDI API's can take a backup and write the information to msdb as it's a valid backup as a virtual device.

    So yeah, go talk to your backup admins and ensure they are backing up what you want them to backup and how you want them to back it it up.

    Also setup monitoring for the time the VSS/VDI backup is taken, generally the session calling the API will have passed in the application name so you can track the application that way also.

  • 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: 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

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply