But I need a bit more basic information to give to the customer, so we can make the decision if SMSQL will be something they will be able to use. The goal is to persuade them to use our product, but I am trying to make a case for it, and I am unfamiliar with how VMDK's relate to SMSQL, as well as the volume / file level snapshots within a VM and a datastore. Will recovery in a case stated as the customer's below planned layout be relatively slow?
This is the current VMDK layout:
C: - 50GB (nothing but OS)
😧 - 50GB (SQL binaries, system db’s, analytical stuffs, etc)
F: - 10GB (User db’s MDF/NDF)
L: 10GB (User Logs LDF)
T: - 10GB (Temp db)
X: - 20GB (SQL bkups)
These VMDK's are assigned on a single VM on a single datastore - NFS.
The questions I and the customer have are:
What are the requirements for using SMSQL within a vm that has nothing but vmdk’s?
If we only keep a few days of online backups with SMSQL, how can we easily restore the vm and the database using the snapshot of the entire vm from days before the last online SMSQL backup is available?
There are 121 Virtual SQL servers, standalone. These are to be migrated onto new FAS6240A.
How do you plan around the 64 NFS datastore limit in this scenario with 112 Virtualized SQL servers? Have any best practices been written to address the different SMSQL in a VM architectures and restore scenarios?