How to Backup an All-Flash Array

They can dramatically change how you deploy production applications and virtual machines (VM), but understanding how to backup an All-Flash Array (AFA), is potentially more critical. AFAs are not, technically, harder to protect than a hybrid or hard-disk (HDD) based storage system but the expectations on the speed of the backup and recovery process is much higher. Most critical is performance of an application or VM in its recovered state. However, the problem is legacy backup storage targets are unable to meet these performance challenges.

Five AFAs “Must Haves” of Backup Storage Targets:

  1. Support a wide variety of backup software
  2. Ingest data as fast as the AFA can send it
  3. Retain data more cost effectively than the AFA
  4. Deliver instant-recovery performance similar to AFA
  5. Deliver enterprise class data availability

AFA Backup Storage Must Support a Variety of Backup Software

Most data centers today have multiple AFAs because of the AFA vendors’ inability to support mixed workloads. As a result IT may deploy an AFA for VMware, another for databases and still another for files. In many cases IT will also have a preferred backup application for each of these use cases. What you don’t want to have to do is then deploy a separate backup storage target for each backup application.

Look for a backup storage target that can support iSCSI, NFS, NVMe-oF, SMB, S3 Object and yes, even fibre channel. Most backup storage targets can’t support the entire gamut of protocols which means if you change backup applications in the future you may need to add another backup storage target.

AFA Backup Storage Must Ingest as Fast as the AFA can send data

AFAs deliver excellent read performance, which means backup software applications can “pull” data from them rather quickly. Additionally, modern backup applications use varying techniques to backup AFAs. Some may still do the traditional Full/Differential method, while others may do the newer incremental forever method, leveraging block-level backups. The two backup types deliver two entirely different IO patterns.

how to backup an All-Flash Array

Look for a backup storage target that has a flash tier to which all inbound data is written prior to it being automatically moved to a more affordable hard disk tier. Make sure the flash area is indeed a storage tier and not a cache so that data is well protected and has time to come to rest completely prior to being moved to a HDD tier. Also make sure that the backup storage target is able to handle different IO streams without impacting either session’s performance.

AFA Backup Storage Must Retain Data Cost Effectively

The answer to how to backup an all-flash array is not with another AFA as some vendors might lead you to believe. Backing up a TLC based AFA to a QLC AFA is not going to provide cost efficient data retention. As we explain in our white paper “The Hard Drive Conspiracy” and despite what AFA vendors claim, hard disk drives are dramatically less expensive than even QLC based AFAs. An AFA backup storage target must have hard disk drives and it must automatically move data from the aforementioned flash tier to the hard disk tier, in a logical manner.

For AFA backup look for a storage target that supports tiering to a large hard disk tier. Supporting hard disk as a tier is not enough, however. The backup storage target must leverage the cost effectiveness of high-density hard drives without making compromises elsewhere. For example, a no compromise system should be able to return the environment to a protected state in less than two hours, regardless of the density of the hard disk drives. It should also be able to mix hard drive sizes and add capacity without requiring any changes to the backup software it supports.

An AFA Backup Storage Target Must Deliver Production Class Performance

Modern backup software, during instant-recoveries, expects the backup storage target to act like production storage. The problem is there is a massive delta between AFA performance and virtually every backup storage target on the market. Most backup storage targets don’t have a flash tier, and the few that do, have a tier so small that it is not suitable for instant-recovery.

Additionally, most backup legacy storage targets continue to use deduplication, even though almost every backup software solution has deduplication built in. During instant recovery, if the appliance has deduplication, then every read must be rehydrated and every write must be re-deduplicated, adding significant overhead and latency to the total IO path.

Look for a backup storage target that does not include deduplication since the software already has it. Also look for a backup storage target that is designed to deliver production class performance by first ensuring that all instantly recovered VMs are initiated on the backup storage target’s flash tier. Second, make sure that the backup storage target’s storage software is optimized to take full advantage of flash media and doesn’t treat it as a slightly faster hard disk.

An AFA Backup Storage Target Must Deliver Production-Class Availability

An instantly recovered VM uses the backup storage target as if it were primary storage while it is in that recovered state. For a variety of reasons the instantly recovered VM may continue to use the backup storage target as its primary storage for days or even weeks. This long duration means that the backup storage target must deliver production class availability, like redundant controllers and advanced RAID protection.

Rapid recovery from RAID failure is particularly important because, to keep data retention costs down backup storage targets use hard disk drives, preferably high-density hard drives, which have notoriously long RAID recovery times, which are typically measured in days. IT needs to look for an All-Flash backup storage target that is able to break the chains of the past and recover hard drive volumes in a couple of hours, not days.


Backing up an all-flash array is not as simple as it sounds. First, you need to find the right backup software, which can intelligently identify and quickly move the data requiring protection. Next, you want to exploit features within the backup software like changed-block backups and instant recoveries.

The final piece of the puzzle is the backup storage target. The expectations on recovery of an all-flash array are high. IT needs to make sure that the backup storage target will be able to exceed those expectations.

Want More Content from StorONE?

Every day, we share unique content on our LinkedIn page including storage tips, industry updates, and new product announcements.

Posted in


What to Read Next

How Do You KNOW All-Flash Is Right For You?

As an IT planner, every so often, you might wonder how a particular workload might perform on an all-flash array instead of the current hard disk-based or hybrid storage system. The […]
Read More

The Problems of Using Primary Storage for DR

Most organizations count on their backup process for disaster recovery (DR) because of the problems of using primary storage for DR. Most backup solutions are far more flexible with what […]
Read More

Using Optane to Lower VMware Costs

Did you know that you can use Intel® Optane™ to lower VMware costs? When used correctly, a VMware professional can use the technology to do more than lower storage costs. With Optane™, […]
Read More

Download Program Overview

Learn More About the Hidden Cost of Dedupe

  • This field is for validation purposes and should be left unchanged.