There are three applications that we can protect in a VMware backup - Exchange, SharePoint, and SQL Server. I can speak knowledgeably about the Exchange case, and to a lesser extent, SharePoint. I have only a general idea of how SQL Server works, but I can get the answers if no one else provides them.
First, Exchange does not use SQL Server as its database engine. Like SQL Server, it does have database files and transaction log files, but the naming conventions are not the same.
NetBackup provides Exchange protection in VMware backups only for full backups. (Accelerator counts, if it's a full backup.)
You can do Exchange GRT restores from a VMware backup. That is, you can restore mail items rather than whole databases.
A non-VMware incremental backup using an MS-Exchange policy is a backup of the transaction log files. A non-VMware Exchange database restore from a set of backups including a full backup and one or more incremental backups, restores the database file and logs from the full backup, then restores the logs from the incremental backups. Exchange recovers the database when NetBackup is done restoring the files.
You can separate the Exchange database restore into two operations - restore from the full backup, then restore from the incrementals. If you do this, you tell NetBackup not to commit after the first restore. I mention this because you can combine restoration from a full VMware backup with incremental backups from an MS-Exchange policy. We tested this. I don't know of any customers who do it. I don't know whether you can do something similar with SharePoint or SQL Server.
The Exchange phase (called Application State Capture - ASC) of the backup didn't write any data to your STU and didn't create a persistent snapshot. All the data is on the VMware backup or datastore snapshot. The ASC job did create metadata in the NetBackup\online_util\fi_cntl\ folder, and this was backed up in the VMware backup.
When you do an Exchange database restore, there are up to three restore jobs. The first is the Exchange job. It conducts a VSS restore operation around the file restores. I think of this as a transaction with VSS. The second job restores Exchange metadata from the VMware backup if it's not already on the VM. (Only the metadata from the most recent Exchange ASC job persists on the VM.) The third restore job restores the actual database and transaction log files from the VMware backup. When all the data transfer is done, the first job completes the transaction with VSS.
SharePoint restores are similar. SQL Server restores have their own process.
