Blog

IBM Maximo has been a mainstay of Enterprise Asset Management (EAM) for decades. Organizations running physical assets at scale — power and utilities, oil and gas, transportation networks, manufacturing plants, facility operations, aviation, and healthcare providers — lean on it to manage preventive maintenance schedules, inventory, work orders, and the full lifecycle of equipment that keeps operations running.

To stay ahead as AI became a competitive differentiator, IBM drew on its AI portfolio — Watson, Cloud Pak for Data, and related tools — to reshape Maximo into today’s Maximo Application Suite (MAS): A modular platform combining asset management with monitoring, visual inspection, health analytics, and predictive maintenance. Once IBM acquired Red Hat, and OpenShift with it, the path forward was set: Maximo was rebuilt for OpenShift, and traditional VM-based deployments stopped being supported.

That single decision reshaped the conversation. Modernizing Maximo today means adopting Kubernetes, whether teams are ready for it or not.

MAS Was Engineered for OpenShift, Not Just Deployed on It

It’s tempting to assume a move like this is just a monolith lifted onto Kubernetes with little else changed. Working inside an actual MAS deployment tells a different story: The platform is built around OpenShift primitives from the ground up. IBM didn’t simply containerize Maximo, they re-engineered it to lean on the platform:

• A mature operator pattern: Platform state runs through well-defined custom resources — ManageWorkspace, ManageDeployment, and ManageBuild for the Manage module, plus a top-level Suite object (mas.ibm.com/Suite) governing the application’s global configuration. The desired state genuinely lives inside these CRs.
• Namespace isolation and RBAC by design: Components sit in dedicated namespaces (mas-<instance>-core, mas-<instance>-manage, db2u, and mongoce, ibm-sls, among others), with access scoped to the right roles.
• Built to be rebuilt: Because BuildConfig and ImageStream are used so heavily, images can be regenerated on demand rather than guarded as untouchable artifacts.
• Native certificate lifecycle management: cert-manager owns TLS end-to-end, with ClusterIssuers signing both internal service certificates and public routes.
• A fully self-contained option: Every database can run inside OpenShift on OpenShift Data Foundation (ODF), or any other CSI-capable storage, for a platform that needs nothing external.
• Flexibility where it counts: Attachments can move to S3-compatible object storage, and the bundled DB2U engine can be swapped for an external MSSQL or MySQL instance.
• A modern take on the bundled database: DB2U, when used, follows current best practices for running databases on Kubernetes: Operator-managed, encrypted at rest, and replicated. (We published a dedicated DB2U blueprint specifically so Kasten can recover it cleanly in a disaster-recovery scenario.)
• A genuinely pluggable design: Most deployments start with the Manage component, then add Optimizer, Health, Predict, Monitor, and Visual Inspection over time. CRDs paired with the Operator Lifecycle Manager make that expansion straightforward.
• Operable on day two: OpenShift Pipelines (Tekton) drive deployment and upgrades, making the platform far easier to run day-to-day than a hand-assembled install would be.

IBM got a lot right here: This is OpenShift the way it’s meant to be used.

The Catch: A Paradigm Shift, Especially Around Disaster Recovery

Here’s the tension. The same architectural rigor that makes MAS well-designed is precisely what trips up the people who’ve run Maximo for years.

Most Maximo administrators come from a VM-centric world, and the jump to Kubernetes isn’t incremental, it’s a fundamentally different way of thinking, with a steep learning curve. That gap shows up most sharply around business continuity and disaster recovery, two areas where teams who knew exactly what to do on VMware or bare metal often found themselves without a clear playbook once Kubernetes entered the picture.

This is exactly where Veeam Kasten makes the difference. Its Kubernetes-native approach to backup and restore is what turns that steep learning curve into a manageable, repeatable process, which is what the rest of this piece walks through.

Customers succeed fastest when they pair Kasten with a partner already fluent in OpenShift. Shipping the backup and DR solution is only half the work; the rest is helping the customer build real understanding of the platform they now depend on daily. That combination of product and support is what makes the difference.

We currently protect a large number of Maximo customer environments with Kasten, and we’re glad to support customers earlier in their OpenShift journey too, though we’d still recommend bringing in a platform-savvy partner alongside us.

How Veeam Kasten Protects Each MAS Component

Everything we do is documented in a publicly available enterprise blueprint for Maximo. Rather than treating MAS as one giant backup target, Kasten organizes protection component-by-component. Today, the blueprint covers the three components nearly every deployment uses:

A few implementation details are worth calling out, because they show how closely Kasten’s design must track the operator model:

• Every policy leaves CertificateRequest objects out: They exist only briefly — cert-manager spins them up to fulfill a certificate and garbage-collects them shortly after — and trying to PUT one back during a restore gets rejected by its admission webhook. Backing them up would just set up a future restore failure.
• DB2U backups are made application-consistent: A Kanister pre-hook triggers the online db2 backup db BLUDB … include logs command from inside the engine pod, then places the encryption master key next to the resulting backup image, so a matched image-and-key pair always reaches the backup PVC before Kasten fires its snapshot. The DB2 SSL keystore is deliberately left out: On restore, cert-manager should stay in charge of the certificate lifecycle, so Kasten restores data only.
• Storage strategy adapts to what’s available: Kasten uses CSI snapshots wherever the storage supports them. CephFS volumes rely on Kasten’s shallow-snapshot capability instead. And where storage can’t snapshot at all, we point customers to Veeam Backup & Replication, addressing the file share as NAS storage rather than bolting fragile data-mover sidecars onto dozens of workloads.

Restore Isn’t One Button in Kasten, And It Shouldn’t Be

Let’s be direct about this. Given how complex Maximo is, and the range of failures you might face — from a small user error, where a full DR would be overkill, to complete data loss, where nothing less will do — a single “restore everything” button was never realistic.

We tried building one. Replaying every restore point in a single Kasten action sounds appealing, but it doesn’t hold up for MAS, for three reasons:

1. Installation follows a fixed pipeline order, and re-applying manifests without respecting that order breaks things.
2. Nearly everything is managed by operator controllers, which creates deep parent/child dependencies. Restore everything simultaneously, and parents and children show up at the same moment and reconciliation collapses.
3. Many certificates are scoped to the originating cluster’s cert-manager CA key pairs, and those pairs carry no meaning on a different cluster.

So rather than fight the platform’s design, we built a repeatable runbook on top of Kasten’s restore operations, sequenced deliberately.

Recovering on the Same Cluster: Typically, Under an Hour

For the everyday incidents — a bad configuration change, a corrupted database, or an operator gone sideways — recovery happens on the same cluster. In Kasten, the sequence starts by restoring the top-level CR (the Suite object, or the ManageWorkspace/ManageDeployment/ManageBuild trio), scaling every deployment to zero, then restoring the remaining resources with overwrite existing enabled, excluding pods and CertificateRequest. Letting Kasten restore the underlying resources directly brings MAS Core back in roughly 7 minutes, versus about 2.5 hours if the operator has to rebuild everything from a cold start.

Failing Over to a Different Cluster: Usually Three to Seven Hours

A full disaster-recovery scenario means resurrecting the instance on a cluster that has nothing to do with the original one. The blueprint takes a deliberate approach: Reinstall Maximo on the new cluster using the source configuration, and only then use Kasten to restore each component. The platform itself is never restored wholesale.

Sequence matters here:

1. Skip restoring cluster-specific namespaces like cert-manager, since the MAS operator generates its own trusted CA on the new cluster automatically. Restoring the old CA key pairs onto new cluster infrastructure just creates conflicting trust anchors. Let the operators manage cert-manager state; use Kasten to restore data only.
2. Scale Manage down and set autoGenerateEncryptionKeys: false so the operator doesn’t overwrite the encryption key you’re about to restore.
3. Use Kasten to restore the MongoCE database.
4. Restore the Manage database, whether DB2U or an external engine. For a cross-instance DB2U restore, the saved key is imported into the target keystore, which is what lets the recovered backup image actually be unlocked.
5. Scale Manage back up and watch ManageWorkspace reconcile to Ready.

The three-to-seven-hour window mostly comes down to whether you’ve already staged a warm standby or you’re rebuilding from nothing.

In our demo, Kasten takes a Maximo instance hosted on-premises on bare-metal OpenShift and brings it back up on OpenShift running on Azure, a real cross-site failover, not a lab simulation.

What once looked like an unsolvable problem is now a runbook you follow step by step, driven end to end by Kasten. That’s the point.

Kasten Adoption for Maximo Tends to Be the Starting Point, Not the Destination

One more observation worth making: For most organizations, modernizing Maximo marks the start of a broader OpenShift adoption, not the finish line. The applications that feed into or consume Maximo data eventually land on OpenShift too, and they need the same level of protection.

We see this pattern constantly: Customers who adopt Veeam Kasten for Maximo end up extending it to cover the rest of their application estate on OpenShift. Protecting the most critical workload becomes the on ramp to defending everything else running on the platform.

Get In Touch

If you’re running Maximo on OpenShift, or planning to, and want to discuss backup strategy, fast in-cluster recovery, or a full cross-cluster failover with Veeam Kasten, we’d welcome the conversation. The Maximo enterprise blueprint is open for anyone to explore; its subpages walk through how Kasten backs up and recovers each component. Reach out any time, we’re glad to share what we’ve learned and help you get there.

The post IBM Maximo on OpenShift: Backup and Disaster Recovery with Veeam Kasten appeared first on Veeam Software Official Blog.

from Veeam Software Official Blog https://ift.tt/0wYRvbB