Using VMware snapshot backup type (Flashbackup-Windows) with "live" database servers may produce backups of inconsistent data database files reside in virtual disk containers (VMDK files) and therefore is not recommended.
Database applications reliy on data structures on disk remaining consistent with memory contents at any given point in time. Therefore, a database application needs to be aware that it is being taken a backup of so it has a chance to flush its data buffers to disk and hold any pending disk transactions until the backup completes. This process is called quiescing.
VMware backups do not quiesce databases – they would only quiesce the file system. While this guarantees data consistency on the file level, a database application remains unaware of backups and restores and may not have consistent data files when it is being backed up. This can lead to seemingly successful backups of inconsistent data.
VMware has a generic quiescing mechanism through user scripts as per this Article:
However the actual implementation will be down to the end user. It may not be possible or feasible to have databases paused while the backup is taking place.
Database backups should be pefrormed with respective NetBackup database agents that use database APIs to make application-aware backups.
Otherwise, by doing the backup on VMware level, data consistency is only guaranteed on the file system level and not on the application level which defeats the purpose of a data protection solution.
In addition to causing a performance hit, VMDK container files have a limit of 2TB due to an inherent VMWare datastore limitation:
Symantec recommends using disks with Raw Device Mapping (RDM) to keep database files outside of VMDK containers.
To migrate data from VMDK containers to RDM, follow the procedure in this VMware KB article:
Imported Document Id