Tape Popularity Increases in IBM i Land
March 10, 2021 Alex Woodie
With all of the disaster recovery options available to IBM i shops these days — virtual tape libraries, hardware- and software-based high availability, and backups to the cloud — it may be surprising to learn that customers are still installing tape drives in large numbers.
According to the recent HelpSystems’ Marketplace survey, 54 percent of respondents say they rely on tape as one of their ways to recover from a disaster. That was up 6 percent from the previous year’s study. It was also the highest figure for tape since the very first year the company conducted the survey, according to the company. However, HelpSystems changed the question it asked starting with the 2020 survey, enabling survey-takers to select multiple methods for recovering from a disaster (previously they were restricted to just one), making year-to-year comparisons less meaningful.
High availability is also more popular. According to the survey, 60 percent of IBM i shops are using some sort of HA solution to replicate data from a primary server to a secondary server. Two-thirds of the HA users rely on software-based HA technology, such as remote journaling-based systems, while 22 percent say they’re using hardware-based HA technology. The only hardware-based HA offering mentioned by survey-takers was IBM’s PowerHA, which features multiple disk-based data replication offerings.
One-quarter of survey respondents say they’re using a disk-based backup system, often called a VTL, while 10 percent say they’re relying on cloud backups to recover from a disaster. Two percent said they have no systems in place to recover from a failure.
The survey indicates that many IBM i shops are using multiple disaster recovery methods as a sort of insurance policy to minimize the odds of surviving an outage that would otherwise be a business-killing event.
For example, a company may use a software-based HA product to replicate data from a primary IBM i server to a secondary IBM i server (perhaps running in the cloud). In the event of an outage of the primary server, the company can switch transaction processing to the secondary machine, thereby avoiding a prolonged outage. The company may also regularly back up its IBM i data using a tape drive, providing a fallback option should the HA software fail to work during an outage (which is a surprisingly common occurrence, considering the low success rate of HA failover tests).
Recovering an IBM i environment from tape is not typically a fast process — that is, it brings a higher recovery time objective (RTO) than HA. With tape, the RTO could be a day or longer, while the RTO for HA may be close to zero. Tape also has an inferior recovery point objective (RPO) than HA, since it can only restore transactions that were recorded before the last save, whereas the RPO for HA may also be close to zero.
But tape drives, such as the LTO drives that IBM and others sell, and associated high-capacity tape cartridges, are significantly less expensive than an HA setup, which requires a secondary machine, a license to the HA software, and a sufficiently large network connection to replicate the transactional data to the secondary machine (not a trivial cost considering the chatty nature of the remote journaling replication method that dominates the market).
While the cost of an HA setup can be brought down by running the secondary IBM i LPAR on a slice of a cloud provider’s machine, the cheap insurance provided by tape clearly remains an attractive option for IBM i shops. Considering the downward pressures that COVID-19 and the economic lockdowns are having on IT budgets, tape remains a pragmatic choice.
The cloud is already factoring into the HA and DR activities of IBM i shops, and these activities are likely to grow in the years to come. According to HelpSystems’ Marketplace survey, 16 percent of IBM i shops are using the cloud in some way, shape, or form today (i.e., public cloud, private cloud, and hybrid cloud), compared to 84 percent who run their IBM i environment strictly on premise.
Among that 16 percent slice of active private/public/hybrid cloud users, the IBM i shops are running a mix of different workloads. Backup workloads were the most popular, with 71 percent of cloud users saying they’re backing up to the cloud (such as cloud-based VTL or utilizing of cloud object stores (such as IBM’s Cloud Storage Solutions for i). That was followed by 64 percent who say they are using the cloud for test and development, 60 percent who say they are running DR workloads there (i.e. cloud-based HA), and another 60 percent who say they are running core business applications in the cloud. Just as a given IBM i shop may use a mix of different backup and DR medium as a hedge against risk, running multiple IBM i workloads in the cloud makes sense, once an IBM i shop has made the leap to the cloud.
This was the first year that HelpSystems asked the cloud question, so year-to-year comparisons can’t be made. But there is a clear expectation that the cloud is expected to factor significantly into IBM i shops’ plans in the near-term and the long-term. As that happens, the sophistication of cloud-based IBM i backup and recovery options, as well as running general workloads, can be expected to grow, making it less of a novelty and more of a regular option for day-to-day IBM i operations.
But don’t expect the cloud to replace good old fashioned tape drives installed next to your IBM i server just yet.
Editor’s note: This article has been corrected. A graphic showing the percentage of IBM i shops using tape for disaster recovery increasing from the 25-percent-to-35 percent range to above 50 percent was deleted because it was misleading. HelpSystems notified us that it changed the question it asked starting with the 2020 survey by enabling survey-takers to select multiple methods for recovering from a disaster (previously they were restricted to just one). That made year-to-year comparisons from the 2016-to-2019 timeframe less meaningful. The headline was also changed. IT Jungle regrets the error.