• JD Wallace

FlashArray//C - A Fast, Dense, and Secure Veeam Ready Repository

Updated: May 27


It's no secret that I'm a huge fan of using FlashArray//C as my Veeam Repository. //C has the perfect combination of Flash Speed (for Fast Recovery), QLC Density (for Cost Optimization), and SafeMode Immutability (for Threat Mitigation). It's also been tested and qualified as a Veeam Ready Repository for added confidence.


I have another post where I write in detail about why FlashArray//C makes such a great Veeam Repo, but in this post I'll walk through some setup steps and optimizations. As you'll see... it's so simple "It Just Works."


If you're following along, I'm using VMs with in-guest iSCSI since this is a lab (shhh, don't tell Cody), but for production please consider a physical repo server with either FC or iSCSI.


Windows or Linux?

We're going to configure a Direct Attached Storage repo type for our FlashArray. You can use either Windows or Linux, the choice is completely up to you. Just make sure you follow Veeam's guidelines for sizing. I'll walk through both.

[A Note on NAS Repos] With Purity//FA 6.0 Pure introduced support for File Services (SMB and NFS) on FlashArray. I'm excited to explore this new capability as another Veeam repo option, but for now block remains the tested and supported way to create your repo on FlashArray.


Windows Backup Repository

We'll start with a fully patched Windows Server 2019 VM and then provision a Purity volume. Veeam's best practices are to create volumes no more than 200 TB in size. If you need a larger repo, consider creating multiple 200 TB repositories and combining them in a Scale-Out Backup Repository (covered later). If you need a refresher on creating FlashArray volumes you'll find instructions here for FC and here for iSCSI.


ReFS or NTFS?

Previously I recommended NTFS for Veeam Repos hosted on SAN storage due to Microsoft's lack of unmap support. The concern was that the lack of unmap could cause erroneous space reporting on the FlashArray. However, newer testing indicates that this is not the case and as a result I'm now recommending ReFS formatted volumes with a 64 KB cluster size. It's possible to see significant performance gains by leveraging Veeam Fast Clone capabilities with ReFS. I am recommending however no less than Windows Server 2019 if you'll be using ReFS. See Veeam's Fast Clone documentation for more specific implementation details.


Linux Backup Repository

This time we'll start with a fully patched Ubuntu Server 20.04.1 LTS VM and then provision a Purity volume. Again, Veeam's best practices are to create volumes no more than 200 TB in size. If you need a larger repo, consider creating multiple 200 TB repositories and combining them in a Scale-Out Backup Repository (covered later). You'll find the official Pure guide for iSCSI with Linux here, but I've actually written a post with more specific guidance for Ubuntu iSCSI setup for FlashArray.


XFS or ext4?

Similar to ReFS on Windows, Veeam Linux Repositories can benefit from Veeam Fast Clone built on the data block sharing (reflink) feature of XFS to increase efficiency for synthetic full backups. Ext4 is still considered a very solid option in terms of reliability, but Veeam has invested heavily in testing and supporting XFS and for that reason I'm recommending XFS for most deployments. See Veeam's Fast Clone documentation for more specific implementation details.


Creating Repository (Windows & Linux)

Proceed with the Veeam Add Repository wizard as usual. When you get to the Repository settings, be sure to select the path to the formatted FlashArray volume. Also, consider the setting for limiting the number of concurrent tasks. This setting will largely depend on the number of CPU cores your repo server has (typically 1 task per core). If you have the compute resources to justify increasing this value you will certainly want to do it so that you're taking the best advantage of FlashArray's performance. In fact, consider a minimum of 12 CPU and 48 GB RAM for any production deployment. The process is very similar for both Windows and Linux.


Windows


Linux


Next, open Advanced settings and apply the following:

  • Align backup file data blocks - Checked (Note that this settings is disabled by default in v10 and enabled by default in v11. In either version we want to use it.)

  • Decompress backup file data blocks before storing - Checked

  • Use per-machine backup files - Checked


Windows and Linux


Take the default setting for everything else and now we have our repo.


Scale-Out Backup Repository

We could stop right here. Our new repository is ready to go just as it is. However, I like to configure a Scale-Out Backup Repository (SOBR), even if it only contains a single extent. Doing so gives me a lot more flexibility in the future. I can easily add or remove storage without having to modify my jobs. If you're creating multiple repositories in order to avoid going over the 200 TB best practice, then using a SOBR to combine them is a must.


This process is incredibly simple, and identical for both Windows and Linux. Simply start the Add Scale-Out Repository wizard and take all the defaults.


Add your new repository as an extent in the Performance Tier settings for the SOBR.


Keep the default Data locality placement policy. You may be wooed by the fact that the other option is named Performance, but don't be. The Performance policy will try to achieve some additional performance by splitting full and incremental backup files onto different extents. Truthfully, with a single extent as we have now, both settings have the exact same effect; but even if that changes in the future I still prefer to keep backup chains together on the same storage. With per-VM backup files we'll get distribution across multiple extents anyway.


We can use Capacity Tier to extend our backups onto Pure Storage FlashBlade via S3, but that'll have to wait until a future post. Today we're focused on FlashArray//C and with up to 7.3PB of effective capacity in the //C60-1877 I think we'll be good for a while. :)


FlashArray SafeMode

The final configuration is to make sure we've enabled SafeMode on our FlashArray and established regular snapshots of our Veeam repo volume.


What is SafeMode?

SafeMode is a FlashArray feature that may be enabled to further reduce the chance of unintentional data loss. SafeMode changes the administration of FlashArray in three important ways.

1. SafeMode snapshots can't be eradicated (deleted), modified, or encrypted.

2. SafeMode snapshot cadence and eradication scheduling are customizable.

3. SafeMode may only be configured or modified by Pure Technical Support working with an authorized designee from your organization.


Configure a FlashArray Protection Group for Veeam Repo

First let's create a schedule to automatically create snapshots of our Veeam repository. We do this by creating a Protection Group (PGroup).


Give our PGroup a name.








Add our Veeam repo volume as a member of the PGroup.


Notice the volume is now listed as a member. Next we'll need to create a Snapshot Schedule.


At this point, think carefully about how much protection you will need. Once you enable SafeMode, you can increase the PGroup retention on your own, but won't be able to decrease the schedule without Pure support. I'm going to save 1 snapshot a day and keep the last 14 days worth.










Enable SafeMode

This is not something I can walk you through here, so reach out to your Pure Storage account team to get the the process started.


Backup Job Settings

At this point we're basically done. You now have a Veeam repository, backed by FlashArray//C and protected with SafeMode. I did want to take just a minute to cover recommended job settings to use with this repository. It's actually really simple... just take the defaults!


For the best experience, use the Incremental backup job method with regular (Weekly is typical) Synthetic Full backups. Keep all of the Advanced Storage Settings at their defaults including Compression Level (Optimal) and Storage Optimization (Local Target).


Final Thoughts

That's it. We've now created a Veeam repo that's fast, secure, and has the capacity and data efficiency we need to do it in an economical way. Furthermore, it's built on the same simple to use FlashArray platform we already know and trust. Go create some new backup jobs and sleep better tonight.

789 views0 comments