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:
- Support a wide variety of backup software
- Ingest data as fast as the AFA can send it
- Retain data more cost effectively than the AFA
- Deliver instant-recovery performance similar to AFA
- 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.
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.
Conclusion
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.
