Questions about tentative design for initial Veeam setup

[corbitech]

I'll be a new Veeam customer soon, and I'm in the planning stages of building what I hope will be a relatively simple design for my Hyper-V and Veeam backup infrastructure. For this post, my goal is not to create the "perfect" design. Instead, I wish to avoid significant design flaws due to my lack of Veeam experience. I've done my homework as well as anyone new to Veeam can do, but I'd appreciate some feedback regarding my questions at the end of this post.

For sake of brevity, I'll abstract away the details of my research, and I'll intentionally exclude most explanations for my current design choices. I'll present a simplified, partial view of what I'm attempting to do. Assume that I have 2 physical servers:

1. Hyper-V host running on Windows Server 2016 x64 (Datacenter Edition) capable of running up to 50 VMs concurrently.
2. Dedicated "all-in-one" Veeam server running on Windows Server 2016 x64 (Standard Edition) with local storage.

ALL Veeam Backup Essentials 9.5 components (Veeam Backup & Replication and Veeam ONE) will be installed on the Veeam server. I'll be installing the free SQL Server Express Edition that comes with Veeam rather than using SQL Server Standard Edition. Assume that the Veeam server's Data Storage Volume is sized appropriately for the planned backup jobs and that its underlying hardware provides adequate IOPS. Tentatively, the dedicated Veeam server has the following hardware resources:

CPU: 2x Intel Xeon E5-2650 2.6GHz Octo Core
RAM: 64 GB registered ECC DDR3
OS/Applications Volume Capacity (C drive = 128 GB): 2X 128 GB SSD in software RAID 1
Data Storage Volume Capacity (D drive = 24 TB): 8X 6 TB SAS HDD (7200RPM) in hardware RAID 10 (LSI 9271-8i) with battery backup (LSI CacheVault) for 1GB onboard cache (write back mode enabled) and warm spare HDD
Data Storage Volume Caching: 2X 400GB SSD in hardware RAID 1 (LSI CacheCade) with battery backup (read/write caching enabled) and warm spare SSD

For simplicity in installation and management, it would be ideal to install the Windows Server 2016 OS and most Veeam Backup Essentials components (excluding the Veeam repository) to the C drive. The D drive is intended to hold the Veeam repository and any other data populations that tend to grow large in size (e.g. logs, indexes, temporary storage spaces etc.).

The C drive capacity of 128 GB is a hard limit under the proposed design. I cannot increase it without significantly changing my proposed hardware configuration. I'm concerned that 128 GB is not going to be adequate, and that over time I will run the risk of approaching a "disk full" scenario on the OS partition which will bring my Veeam server down.

QUESTIONS:

1. Is 128 GB C drive an adequate capacity for building an "all-in-one" Veeam server as described above?
2. If not, what is the recommended disk size for the C drive for this type of installation?
3. Is it possible to redirect some of the data growth that might occur on the C drive for this "all-in-one" Veeam server? For example, if certain Veeam components generate log files, perhaps they could be safely redirected to the D drive without complicating the overall setup significantly. I'm not concerned much about the SQL Server Express database growing because it's capped at a maximum of 10 GB.

[DaveWatkins]

If you have Enterprise Manager running and turn on indexing in all your jobs you could easily use that space with index data. You can however turn on NTFS compression on the folder and recover a LOT of space, I believe you can also redirect that folder to another drive with a registry change

[PTide]

Hi,

1. Please check this to calculate the exact amount of HDD space required for your setup.

3. As Dave's mentioned, you may need to move Veeam Backup Catalog to the other drive.

Thanks

[blithespirit]

As mentioned before if your worried create a 2nd partition of 40GB from your 128GB (Leave rest for root) and place your VBRcatalog folder on this drive (option during install to locate) in the event it gets full it will constrain the data to the non root drive. Also if your not using Ent Manager ensure you never index your guests. You can also change the location of log files (Reg key) to move your log files but for simplicity I would not worry about that.

[corbitech]

Thanks to all who have commented so far. blithespirit - I like your recommendation about creating a second partition on the SSD. I'll do that just to be safe.

After thinking about this situation a little further, I might go with a slightly different approach. I might install a larger SSD RAID 1 on the Veeam server so that I can allocate more space to a 2nd partition on it. I'm wondering if that might be helpful in case I use the Instant Recovery or Sure Backup features. As I understand it, those two features need a temporary workspace with high IOPs preferred. If I get a larger SSD (compared to the 128 GB I was originally planning), then perhaps I could reserve more space on the 2nd partition of the SSD for this purpose.

Does anyone have feedback about the use of larger SSDs on the Veeam server for Instant Recovery and Sure Backup features? Or is it possible to direct the Instant Recovery and Sure Backup to the Hyper-V server itself? I'd prefer to point the Instant Recovery and Sure Backup tasks to the Hyper-V server because I'll have plenty of spare high IOPS storage capacity on the virtual server. If I install larger SSDs on my Veeam server for Instant Recovery and Sure Backup, I'd lose a couple of hard drive bays to that, and therefore my total backup storage capacity would be lower.

[vClintWyckoff]

You're correct, for SureBackup & Instant VMRecovery you'll need to allocate a directory for the vPower NFS Service for the changes of the recovered VM and this is done on the Repository - in your all-in-one case, it will be all on the same server. On Hyper-V the process for IVMR is slightly different than on VMware, and a pair of data mover services, one for the disk mount and one for the data recovery. So the issue you're speaking of below should not be as large of a concern as any changes during the the IVMR will be written to the production storage. Hope this helps