You have a couple of options when it comes to selecting a Pure Storage array for storing Veeam backups. I've previously posted about FlashArray//C. The DirectFlash optimized QLC in FlashArray//C makes it a great option for balancing all-flash performance and capacity.
When you want the absolute fastest speed possible for Rapid Restore however; that's where FlashBlade shines. FlashBlade is built on a scale-out Unified Fast File and Object (UFFO) architecture that scales performance linearly as you grow. In this post, I'm going to walk you through how to properly configure FlashBlade for use as a Veeam repository to ensure that you're taking the best advantage of the performance that comes from FlashBlade's unique architecture.
FlashBlade consists of anywhere from 7 to 150 individual nodes or "blades". Each of these blades has its own processing power and storage, but they all work together as a system. The key to driving high performance with FlashBlade is "parallelism." FlashBlade loves it when you have multiple clients all connecting in parallel to do work.
When configuring our Veeam repository, we're going to take advantage of Veeam's Scale-Out Backup Repository feature to ensure that we have a minimum of 4 data streams all targeting the FlashBlade at the same time in order to really make FlashBlade shine. In essence, rather than creating a single Veeam Repo on the FlashBlade, we're going to create 4 (you could even have more).
FlashBlade Configuration
Create a new FlashBlade file system. Disable the Fast Remove and Snapshot special directories (we won't need those here). Enable the NFSv3 protocol and apply an export policy so that the Veeam infrastructure servers will have access. (Do not enable NFSv4.1 or SMB on this file system.)
Ensure you have a unique FlashBlade data IP address for each of the repositories you plan to configure. In this demo I'll be setting up 4, but larger environments may benefit from more. It's pretty easy to add more later if you need to grow.
Why multiple IPs?
FlashBlade can actually leverage a singe data IP for all I/O. Why then are we creating 4 data IPs here? It has to do with the way client connections are distributed on FlashBlade with NFS. If we just used a single data IP, then all of the I/O from Veeam could potentially look like it's coming from a single client; the gateway server. That traffic would all get routed to the same blade and we would miss out on the performance of having it distributed across multiple blades. By creating multiple connections to the FlashBlade with different IPs, we force the I/O to look like 4 unique clients and get distributed across 4 blades.
Create Directories For Each Repo
You'll need to create a directory within the new NFS export for each of the repositories you plan to create. You can actually do this directly from Veeam. Head over to Inventory then File Shares and add a new File Share.
Add a new NFS File Share and add the NFS export (you can pick any data IP.)
Finally, head over to Files and find the export. From here you can right click and create a new folder. Repeat for each of the 4 repositories we plan to add.
Veeam Scale Out Backup Repository Configuration
Head over to the VBR console and start creating the 4 backup repositories. Each repository will be created identically except for the data IP and sub-directory used to connect to the FlashBlade.
Add a NAS repo...
NFS share.
Give the repository a unique name, and then enter the path to the export using the first of the 4 FlashBlade data IPs and the first of the folders that you created in the format [DataIP]:/[FileSystemName]/[FolderName]. If you want Veeam to be able to use any proxy server as a gateway, then stick with Automatic gateway selection, but if you need to specify a gateway server you can do that here.
Caution!
You can take the default Repository settings, but be cautious when selecting a Mount Server. Since NAS repositories don't have a dedicated repo server, they utilize the mount server to perform operations such as creating synthetic full backup files. This means you'll want to be sure to select a Mount server that has enough CPU and memory to handle this task. If you do nothing the Mount server selection defaults to the backup server, which may have been sized with far fewer resources than a say a proxy server.
Repeat the process 3 more times (or more for large environments) being sure to use a unique FlashBlade data IP each time. In our example that means I'll have a Veeam repo with each of the following shared folder paths:
10.255.8.120:/VeeamRepo/Repo0
10.255.8.121:/VeeamRepo/Repo1
10.255.8.122:/VeeamRepo/Repo2
10.255.8.123:/VeeamRepo/Repo3
When done, you should have something that looks like this.
Finally, create a new Scale-out Backup Repository to combine all of the individual repos together.
Add each of the individual repos you created previously (now called extents) to the Performance Tier for the SOBR.
It's critical that you leave the advanced setting "Use per-machine backup files" selected. Without this setting Veeam will only ever leverage a single FlashBlade blade per job and you'll prevent the FlashBlade from living up to it's full performance potential.
Also keep the Data locality placement policy. You may be tempted to select the Performance policy because of the name, but doing so will actually limit your ability to take full advantage of the FlashBlade's performance.
Now your new high performance FlashBlade scale-out backup repository is ready to use. When setting up backup jobs, just stick with the default storage settings for best results.
SafeMode for Ransomware Recovery
Now that you're protecting your data with Veeam, why not also protect your Veeam backups with SafeMode. Similarly to how SafeMode works on FlashArray//C, SafeMode on FlashBlade protects your entire dataset from unplanned deletion, even from a user with FlashBlade administrative credentials. To get started, head over to Pure1 where you can use the new SafeMode Assessment tool to ensure your FlashBlade is ready for SafeMode and start the process of getting it enabled.