VMware, a software company founded in 1998, was one of the first commercially successful companies to offer x86 virtualization. The storage company EMC purchased VMware in 1994. Dell Technologies acquired EMC in 2016. VMware’s parent company is now Dell Technologies. VMware has many software products that run on desktops, Microsoft Windows, Linux, and macOS, which allows the virtualizing of the x86 architecture. Its enterprise software hypervisor for servers, VMware vSphere Hypervisor (ESXi), is a bare-metal hypervisor that runs directly on the server hardware and does not require an additional underlying operating system.
TRUSTED BY
1. Auditing: What is being backed up (identify business critical resources), how often is it "successful", how often does it "fail"? What are the failures, and have they been corrected? Who get's the notifications and what do they do with them? This "Audit" process should be scheduled.... Monthly, weekly, ...whatever you deem necessary for business continuity. You may add resources that are not immediately included in your backup process, but nonetheless are critical for business continuity. (this is why a periodic Audit is very important)
2. Documentation: EVERYTHING involved in your backup process, should be DOCUMENTED. The service accounts, the resources, the personnel involved, the step-by-step restore process, the frequency, AND ANY CHANGES THEREOF. The entire plan should be documented, in case the person(s) involved in your disaster recover plan get hit by a bus, or the plane they were all on goes down. (not joking)
3. Demonstration: Periodically, you need to DEMONSTRATE, that the critical resource backups you are getting... can actually result in a full restore, for critical business processes. Each one, should be periodically checked... for example... FINANCIAL DATA. Your tech personnel should be able to demonstrate, at least quarterly, that they can restore the backups for those critical resources to full functionality. Your process for doing so may vary, but it is critical that you test the restore process and DOCUMENT the steps so a third grader can follow it. This is very important, because you will discover nuances, failures, and other things you "can't know"... until you actually try to restore something. You may find in this process, that you are "missing something", that should be backed up. In many cases, people don't find these things out until a failure occurs. You don't want to be that person.
My advice is based on my experience in IT SOX compliance. Your mileage may vary, and you may find some of my suggestions to be overkill for your business size/model... but the principles are the same no matter what your company size. Your critical resources for business continuity, are what your disaster AND recovery plan, is all about.