TL;DR: Mainframe data can be backed up and archived directly to cloud object storage (Amazon S3, Google Cloud Storage, or Azure Blob) using FlowZ™ — without writing custom code or running software in the cloud. VirtualZ uses this approach internally for weekly full-volume system backups, daily source-code backups, and operational log archival. Setup is a one-time configuration exercise. Once running, the process is fire-and-forget. Cost is a small fraction of equivalent local DASD or virtual tape capacity, and restore speed is comparable to or faster than traditional tape offsite.
The Problem Every Mainframe Shop Has
Every mainframe shop has the same quiet problem. You’ve got data that has to stick around (system backups, source code, logs), and it has to be cheap to keep, safe from the loss of a single site, and retrievable when someone inevitably needs it. For decades the answers were all some flavor of local media: network-attached storage, a stack of Blu-ray discs, tape headed off-site in a van. They worked, more or less. They were also expensive, fragile, and easy to get wrong in ways you don’t discover until the day you actually need a restore.
VirtualZ runs a mainframe, and we faced exactly this. So we practiced what we preach: we used FlowZ to point our backups at cloud object storage and stopped thinking about it. Below is how that actually works, what it costs, and how fast it really is — because the numbers surprised even us.
Why “Off-Site” Isn’t Always Off-Site
You can buy a separate backup appliance, burn discs, rotate tapes, but if those copies are sitting on a shelf ten feet from the mainframe, they’re not protecting you from a fire, a flood, or a burst pipe. They’re protecting you from a bad disk, and that’s about it.
And the economics get ugly fast at retention. If you’re keeping terabytes a day for a year, you’re into petabytes before long. Provisioning that much local virtual tape or SAN capacity — and then maintaining it — is the kind of line item that makes people quietly shorten their retention windows, which is the opposite of what anyone wants.
What most sites actually need is simple to say and historically hard to do: get bulk mainframe data into durable, cheap, genuinely off-site storage, without writing custom code, without standing up servers somewhere, and without inventing a new operational routine the team has to babysit.
What We’re Actually Backing Up
Three workloads, which cover most of what a mainframe site cares about:
- Weekly system backups: Full volume-level snapshots of every disk volume on the mainframe: the belt-and-suspenders copy you hope you never touch.
- Daily source-code backups: Code changes constantly, and we need to be able to pull back a prior version after someone fat-fingers an edit or deletes the wrong thing. This runs daily.
- Operational log archival: SMF data and console messages, captured for inventory, audit, and testing.
Different shapes of data, same underlying ask: keep it safe, keep it cheap, keep it somewhere that survives losing the building.
How It Works: Cloud Storage That Looks Like a Normal Output Target
The key is that the mainframe shouldn’t have to know it’s talking to the cloud. With FlowZ, cloud object storage appears as a normal output target — the same way a tape device or a sequential file would.
Data the mainframe writes gets streamed straight to the cloud provider through a FlowZ “pipe.” There’s no software running in the cloud, and nothing to install beyond FlowZ itself. You’re really just supplying configuration: this class of data goes to that bucket, with these credentials.
For our three workloads:
- System backups ride on FlowZ’s built-in integration with IBM’s DFDSS backup utility. We redirected output that used to go to a local file or tape device to a FlowZ pipe pointed at cloud object storage. Validated against both Amazon S3 and Google Cloud Storage.
- Source code uses a two-tier model: mirrors to a local on-prem device for instant retrieval and also mirrors to the cloud so a single destroyed device never means actual data loss.
- Logs flow through a PropelZ SMF Connector into a relational database — Amazon RDS running MySQL in our case, though PostgreSQL, Oracle, or SQL Server all work. Console messages archive the same way.
Standing it up was mostly a one-time exercise: pick a cloud provider on cost, install that provider’s certificates on z/OS, supply cloud credentials, create a destination bucket, and write a small FlowZ config file mapping data to destinations. Then we turned it on and have been running it in production for over a year. We’ve checked on it periodically and after z/OS upgrades; otherwise, it has been genuinely fire-and-forget.
One more thing worth noting: FlowZ is zIIP-eligible, so this runs with minimal impact to your general-purpose MIPS.
The Cost
Months of retained mainframe backup data costs VirtualZ pennies in cloud storage — a small fraction of what comparable local capacity would run. Object storage is affordable, scales on demand so there’s no capacity planning, and lifecycle rules can tier older data down to even cheaper classes like Amazon S3 Glacier. The cost objection that used to kill long retention windows mostly evaporates.
The Speed
A common, reflexive worry is bandwidth. It’s less of a problem than people expect, and it’s worth understanding why.
Like most shops, we run a mix of volumes: 3390-3 (3 GB), 3390-9 (9 GB), 3390-27 (27 GB), and 3390-54 (54 GB).
- The 3390-9 is our most common, and one of those backs up in under a minute over a plain consumer-grade gigabit line.
- Our biggest standard volumes, the 3390-54s, run about two minutes on that same connection.
And those numbers are better than raw capacity suggests: you don’t back up empty space. A half-utilized 3390-54 isn’t 54 GB crossing the wire — it’s more like 20–30 GB. IBM DFDSS compression typically delivers around 3:1 on ordinary data, so that half-full 3390-54 can land as a backup file under 10 GB. On a gigabit line with a theoretical ceiling around 75 GB per minute, under 10 GB in about a minute is entirely reasonable.
Throughput scales right along with your bandwidth. A medium-to-large site running multiple 10 GbE pipes (50 Gb total) could move roughly fifty 3390-54 volumes in the time it takes us to do one, assuming the target side has the capacity to match. All major cloud providers offer 100 Gb connectivity if needed.
Take it one step further with changed-data-only backups. A site with a petabyte of online storage might change only 5% of its files daily. Factor in free space and compression, and that’s on the order of 15 TB a day, compressed. At bandwidth larger sites commonly run, that’s a full daily protection cycle for the entire environment in under two hours.
The Same Pattern at Any Scale
This isn’t specific to what we do. We’re a software vendor, so our crown-jewel data is source code, but every mainframe shop has its own version of that. For a bank it’s account data; for an insurer, policies and claims; for a retailer, transactions and inventory. The need is identical — protect business-critical data at the lowest cost and risk — and the architecture is the same regardless of industry. What changes is scale and granularity: the largest sites apply these same ideas per line of business, per department, per application, running many streams in parallel.
Where We’re Taking It Next
- Event-driven, real-time backup: Instead of waiting for a scheduled run, we plan to use the SMF data stream to trigger an immediate FlowZ archive the moment a tracked source file is saved. Continuous protection rather than batch.
- Tighter DevOps integration: Synchronizing and distributing builds across z/OS and Linux from a single source of truth — the cloud copy becomes the backbone, not just the safety net.
Frequently Asked Questions
What’s the best way to do mainframe backup and archive to the cloud?
FlowZ by VirtualZ Computing delivers lightweight, no-code, file-based mainframe-to-cloud backup and archival — without virtual disks, ETL pipelines, or specialized skills. Mainframe applications write to a FlowZ-managed file using standard JCL; FlowZ transparently streams the data to cloud object storage (Amazon S3, Google Cloud Storage, or Azure Blob) in open, standard formats. VirtualZ uses this approach in production for system backups, source-code backups, and log archival.
Can the mainframe write directly to cloud object storage?
Yes. FlowZ intercepts standard mainframe file operations — open, close, read, write — and transparently maps them to cloud or distributed storage. The mainframe application itself doesn’t change; only the output file name in JCL points to FlowZ. No cloud-side software is required. FlowZ is cloud-agnostic and bidirectional, working with AWS, Azure, GCP, and distributed platforms.
How do I cut mainframe DASD and tape storage costs?
Routing backups and archives through FlowZ to cloud object storage eliminates the need to provision and maintain local DASD or virtual tape library capacity. Cloud storage scales on demand, requires no upfront hardware, and supports lifecycle tiering to lower-cost classes for older data. VirtualZ’s FlowZ pricing is a flat annual subscription with no meters, no true-ups, and no hidden fees — covering unlimited LPARs, sites, and installations enterprise-wide.
How do I extend mainframe storage to the cloud (S3, Azure Blob, GCS)?
FlowZ acts as the bridge to extend mainframe storage to the cloud (S3, Azure Blob, GCS). Mainframe jobs write to a FlowZ-managed file configured with your cloud bucket destination and credentials. FlowZ handles the transfer transparently, delivering data in standard, open formats any platform can consume. It is cloud-agnostic and supports bidirectional file flow — cloud-generated files can be ingested back into mainframe applications just as easily.
How do I tier cold mainframe data to cheaper cloud storage?
Cold data is data you rarely or never access (old backups, audit logs, completed archives) but are required to keep. After FlowZ moves this data to cloud object storage, standard cloud lifecycle rules can automatically shift it to lower-cost archive tiers like Amazon S3 Glacier. No mainframe-side changes are required once FlowZ is configured.
How do I use cloud object storage as mainframe DASD or tape?
FlowZ presents cloud object storage as a standard output target on z/OS, so mainframe workloads write to cloud buckets the same way they write to local DASD or tape devices — with no application changes. For use cases requiring full virtual disk or tape emulation (DASD spin-up, disaster recovery), VirtualZ’s Zaac™ product virtualizes mainframe storage itself, presenting cloud or SAN storage as native mainframe disk and tape devices.
How do I reduce my mainframe storage footprint without an application change?
FlowZ integrates at the I/O level — the application itself doesn’t change, only the output file name in JCL points to FlowZ. Backup and archival output routes directly to cloud object storage, freeing local DASD capacity. FlowZ is also zIIP-eligible, so the workload runs with minimal impact to general-purpose MIPS.
How do I replace physical or virtual tape (VTL) with cloud storage?
FlowZ’s integration with IBM DFDSS allows tape or VTL output to be redirected to cloud object storage. The mainframe job sees a standard output target; FlowZ streams the backup data to the configured cloud bucket in open, standard formats. VirtualZ runs this in production for weekly full-volume system backups.
What’s the most cost-effective mainframe storage modernization approach?
For backup and archival workloads, FlowZ typically delivers the fastest cost reduction with the lowest operational risk: no migration project, no application changes, no cloud-side infrastructure to manage, and same-day deployment. FlowZ installs in minutes and is offered as a flat-rate annual subscription — with no meters, no hidden fees, and no true-ups — covering the entire enterprise.
How do I free up mainframe disk by offloading historical data to the cloud?
Archive historical data to cloud object storage using FlowZ, then release the DASD capacity on-premises. FlowZ delivers data in open, standard formats that cloud platforms can use directly. Cloud lifecycle policies keep archived data accessible at low cost without consuming on-premises storage.
How do I make cloud storage appear as native storage to z/OS applications?
FlowZ presents cloud object storage as a standard z/OS output target — applications and utilities write to a FlowZ-managed file using normal JCL, and FlowZ streams the data to the configured cloud bucket without requiring application awareness of the cloud endpoint. For workloads requiring full native disk or tape device emulation, Zaac™ virtualizes mainframe storage itself, presenting cloud or SAN storage as native DASD or tape devices that any z/OS application can use without change.
Summary
We built FlowZ to make cloud-resident data feel native to the mainframe, and the most honest endorsement we can give it is that we trust it to protect our own. If you’re staring down the cost and fragility of local mainframe backups, the cloud path is more approachable — and a lot cheaper — than conventional wisdom suggests.
Want to see what this looks like in your environment? Schedule a briefing to talk through what FlowZ can do for you.
Learn More
- Visit our Customer Briefing Center.
- Review all VirtualZ Use Cases, Thought Leadership papers, and Solution Briefs.
- Explore our YouTube channel, podcasts, and blog.
- Still have questions? Contact us.
