0 Replies Latest reply on Apr 6, 2017 1:11 AM by foreseng

    Windows 2016 with Storage Pools over VMDKs and Veeam Backup/Rep

    foreseng Lurker

      Hello, was trying to find a specific answer for this matter but had no luck yet, so thought that it might worth to open a discussion.

      We are currently running a common windows 2012 r2 file server with several vmdks (on a san vmware datastore) of various sizes as simple volumes and DFS to present logical access to users.

      Basically what we are trying to define, is a new file server structure that allows us to easily expand (and mantain) the main company data disk space (~3.5 TB) without impacting on the current local veeam backup and replication over a wan connectivity (for a company disaster recovery plan), also giving us a long term support of the structure and a more "all-together" way to store users' files.

      We are evaluating a way to define a windows 2016 virtual machine with, let's say, 10x400 GB vmdks and a storage pool to span a big, unique, volume over these vmdks and the ReFS file system (we have a sum of ~20 million files and many many folders reaching over 255 char paths). Should an increment be needed (company data grew in a quite unpredictable way), just add a new vmkd disk to the storage pool and extend the windows virtual disk and its volume. This should achive quicker veeam replications and backups (local veeam backup are over a dedicate 10G nfs network) in this space extensions.

      Veeam 9.5 supports file level restore of ReFS file systems (something that on older releases were not) and adding a disk like this way does not impact on replicas and backup (does not run a whole new full backup or replication, let's say) and should have some advantages about this.

      I saw many lab scenarios around using hyper-v vhds to achieve this, but couldn't find anything like what we are testing on vmware, or any supported or unsupported specific statements for the 2016 platform storage pools over vmdks.
      Can this be a supported solution on vmdks ? or better keeping multiple vmdks (simple windows volumes as standard, that is, maybe reFS) keeping a more complex and sparse physical data and DFS folder distribution / structure ?

       

      Thanks for any reply !

      Francesco