One of today’s greatest cloud migration challenges actually sounds deceptively easy: lift and shift. The idea is that if you want to go on-prem to cloud, you can simply pick up your existing workloads and move them from your own servers to the cloud.

In theory, it’s all just a matter of migration. In practice, it often gets much more complicated than that.

Are you considering moving some of your workloads to the cloud? If so, you’ll likely run into some of the cloud migration challenges we outline here.

Are Your Systems Cattle, or Pets?

When you’re considering moving one of your systems to the cloud, ask yourself, “Is this application cattle, or a pet?”

Cattle systems are the systems you implement quickly and don’t care much about (for example, testing environments for your devops team). You need an application to do one specific thing, so you throw it onto the cheapest, most convenient server you can find. Much of the time, that server will be a cloud server. Cloud servers tend to provide cookie-cutter capabilities. Similar storage, similar performance, similar data transfer bandwidth—all at a price you can live with.

To set up a cattle system with cloud hosting, you typically use a web interface. You choose an operating system from a drop-down menu, maybe pick a few more options, and click a button to confirm. It’s all fast and easy, because again, you don’t really care that much about the details.

Pet systems, on the other hand, are the systems you really care about. These are the applications you use most, customize heavily, and take good care of for years at a time. You want the best hosting for them, so you tend to install them on-premises.

Your pet systems are the ones that are harder to move to the cloud. You’ve spent years tuning them to run exactly the way your organization needs, and you don’t want to have to go back and re-do all that work after a migration to the cloud. Can you imagine migrating your data center to the cloud? You wouldn’t be cavalier about your hosting, would you?

But consider again how the typical migration runs. You’d go to the web interface and choose Linux operating system from the drop-down menu. So far, so good.

What comes next? Once you’re live in the cloud, you’re probably looking at many long hours of installing patches and updates to get your data center running the way it did when it lived under your roof. Your cloud provider isn’t going to help you. This one is on you.

Faced with cloud migration challenges like these, it’s easy to see why so many Linux sysadmins are dead set against migrating to the cloud. They’re not lazy—they simply recognize the risk involved in a move like this one.

So what’s the answer? Should sysadmins simply resign themselves to missing out on the savings and ease of running major applications in the cloud? No. There’s a better way forward.

Consider This Proven Cloud Migration Solution

Yes, there are cloud hosting providers that provide infrastructure as a service (IaaS). These services help mitigate some cloud migration challenges by letting you move your virtual machine image into their virtual machine environment. But you’ll probably have to have exactly the right version of VMware to make it work. Remember: disk images are designed to end up in an environment exactly like the one they just left. Otherwise, you’re playing with fire.

Instead of choosing a pre-configured OS and hoping for the best, consider using a lift-and-shift solution to overcome the most common cloud migration challenges.

Storix System Backup Administrator (SBAdmin) lets you back up your entire system and then restore it in your new virtual environment. Our solution uses Adaptable System Recovery to migrate your Linux and AIX systems to the new cloud environment while intelligently adapting to changes.

A Storix specialist can walk you through our lift-and-shift approach and show you how many manual steps we can eliminate for you. To speak with one of our specialists, call (877) 786-7491 today.

Love AIX mksysb? Here’s How to Improve Your Protection with Less Work.

It’s alarming each time we hear that some AIX system administrators aren’t doing full-system backup. If you’re not backing up your applications and your operating system, you’re leaving your business vulnerable to extended downtime.

If you’re like most sysadmins, you’ll probably say, “We’re OK—I use AIX mksysb to back up everything.”

We can certainly see why you love mksysb so much. It’s a tremendous backup utility.

But as we explained in our last article, AIX mksysb may not be backing up absolutely everything you need. And this fantastic utility may be costing you more than you think in manpower. So, there’s a tradeoff involved here.

The bottom line here is that if you’re knowledgeable and conscientious enough to be using AIX mksysb as part of a thorough backup strategy, it behooves you to stop every now and then and reevaluate whether another approach could deliver even better protection with less effort.

Does Your AIX Backup Strategy Have These Gaps?

A hardworking IT team can piece together a complete AIX backup process using multiple solutions and scripts. But it will be a labor-intensive activity—and the more moving parts you have, the greater the chances that something will eventually break.

Many systems administrators will use AIX mksysb for backing up the operating system (though, as we’ve discussed, this utility only backs up the root volume group). To manage the process and move files around, they’ll write and maintain a series of scripts. They may also use a separate solution to back up data.

You and your team may very well have this whole process down to a science—but you could still find yourself with some gaps. For example, mksysb won’t back up your storage configuration for other volume groups beyond the root. These other volume groups contain the data, so you’ll have to recreate them along with the logical volumes and file systems. In other words, AIX mksysb restores the operating system portion of your environment, but you’ll still have to rebuild the rest. You may be used to this by now, but consider the time and effort involved.

Also, keep in mind that mksysb operates at the box level. If you’re running 10 servers, you’ll need to manage 10 versions of mksysb. This is doable, but how much time could you save if all the processes we’ve described here were automated? And how much potential human error could you eliminate?

One more point: as we’ve explained previously, AIX mksysb was originally written to be used on tape backup systems. Sure, you can still use it for disk or network backup, but you won’t get any features to help you with backup management. Remember back in the tape days how you could simply label your tapes and file them in a cabinet? In some ways, that was easier than what we’re doing now. Today, if you run mksysb, you’ll need to keep track of where that backup is stored and have an easy way to copy it to wherever it needs to go on the network.

How to Go Beyond mksysb for Complete Disaster Recovery

Again, none of the above is meant to imply that AIX mksysb isn’t an indispensable utility for AIX sysadmins. Quite the contrary. But you’ve probably noticed how much care and feeding it requires. The best way to streamline this work is to use a backup solution that not only backs up your entire system—including OS—but also provides the automation, scheduling, retention and removal, and reporting features you need to run your backups as efficiently as possible.

That solution is Storix SBAdmin—the only system on the market that offers complete, file-based backup for AIX. To learn more, visit us online, or speak with one of our disaster recovery experts at (877) 786-7491.

AIX Backup Challenges

In our last article, we discussed the challenges of backing up Linux on IBM Power servers. In a nutshell, sysadmins often wish there were a mksysb for Linux—but there isn’t. So they resort to using one of the various backup systems on the market. But most of them provide either data-only backup or image backup, neither of which offers the comprehensive, flexible backup functionality that will fully protect your business. It’s best to go with a file-level backup solution instead.

Now let’s turn our attention to AIX backup. If you’re managing servers that run AIX, you’ve probably come to rely on mksysb as a way to reinstall rootvg to its original state. It’s also a great utility for rolling back your system at any time.

But that doesn’t mean AIX backup should begin and end with mksysb. If you want to build a true disaster recovery solution for your AIX servers, you’ll need to add the right software to your backup mix.

The Shortcomings of Using mksysb for AIX Backup

As we said, mksysb is a very useful utility. But its shortcoming is that it only backs up the root volume group. Sure, it’s good that it backs up your operating system, keeping all your customizations intact—but rootvg is not the entire system. What about the other volume groups? This means that after a server crash, you’ll need to rebuild your other volume groups, logical volumes, and file systems. You’ll need to rebuild the rest of the system before finally copying your data back. So just getting rootvg back means you still have a lot more work rebuilding and fine-tuning to do.

Another shortcoming of mksysb for AIX backup is that, in its essence, it’s a basic command-line utility. You run it manually, and it creates an archive. There’s no automation. No scheduling. No reporting. No retention. And you can’t send your images off to another system. The archive you create goes to either a tape or a mounted drive. But there’s no easy way to transfer your backup from one system to another. To complete all these tasks around your backups, you have to write lots of scripts. It’s doable, but it’s a pain. (And when was the last time you saw someone actually use a tape?)

Now, the network install manager (NIM) can make your life somewhat easier. When you set up a separate NIM server, you can restore your systems over a network. But you do have to configure all the network booting manually. And you have to copy your images or mksysb backups to the NIM server yourself.

There’s more we could say about the manual effort involved in the typical AIX backup, but you get the idea. In fact, you’ve probably lived it yourself. What you need is a solution that goes beyond rootvg and provides powerful automation and scheduling capabilities for the entire system.

A Backup Solution that Gives You File-Level Control

The ideal AIX backup solution will provide complete backup management for your full range of systems, allowing you to manage all backups from a single pane of glass. It will also deliver powerful scheduling, retention and removal features, and in-depth reporting tools.

Although you can restore individual files and directories from a mksysb, it is not an intuitive or an easy task. Having a true file-based backup solution should allow you to easily restore either the entire system or just individual files. As a bonus, a good backup solution will also enable you to work in a modern interface rather than writing scripts.

All of this may sound too good to be true, but you can find it in Storix SBAdmin. (By the way, we integrate with IBM Spectrum Protect, formerly known as Tivoli Storage Manager.) To learn more, visit us online, or speak with one of our disaster recovery experts at (877) 786-7491.

In our next article, we’ll take a closer look at some of the pains of relying solely on mksysb to run your AIX backups.

If you are a sysadmin of AIX systems, you’ve probably come to rely on mksysb to meet your backup needs. You’re used to doing backups a certain way, and that way has worked reliably.

But at some point in your career, your job description expanded to include backing up Linux on IBM Power. You expect there might be a similar utility to mksysb on Linux. Then you find out that there’s not.

And so here we are. You may recall that when IBM introduced the Power line in 2004, they thought it would eventually supplant AIX. That never really happened. But IBM Power hasn’t disappeared, either, and it’s not going to anytime soon. If your organization has invested heavily in IBM Power, the sobering news is that backing up Linux on IBM Power will continue to be a challenge. But we’re here to help.

Linux on Power Is Growing

As you already know, IBM Power hardware is powerful enough to run multiple instances of your OS. You can just use Logical Partitions (LPARs) to run dozens or even a hundred different hosts on a single server. That adds up to huge cost savings and greater efficiency for your IT organization.

Over time, more and more IT teams have seen this situation as an opportunity to explore Linux. When you can carve up one server into so many logical partitions, why not use a couple of them to try out Linux? And so they have. We’ve seen increasing adoption of Linux on Power machines, due in large part to IBM’s prompting.

When SAP first released its HANA relational database management system in 2010, running Linux on IBM Power made even more sense. Companies also began to realize that it was not only possible, but advisable, to run other killer apps on Linux.

Of course, none of this changed the fact that there’s no mksysb on Linux. But there is something just as good, and in fact, better: Storix System Backup Administrator (SBAdmin).

The Need for Linux System Backups

Think about your last server crash on AIX. If you were backing up all your data like you’re supposed to, you were in a position to restore that data in minutes. But first, you had to complete one other task: reinstalling your operating system on a new server. That sounds like a straightforward exercise. But in addition to implementing the OS from DVDs, you had to install patches and updates. All told, the process may have taken several hours.

That’s why it’s essential to back up your OS as well as your data. What’s true on AIX is true on Linux. If you’re only backing up data, you’re leaving your business vulnerable to an outage of several hours—and potentially many thousands of dollars in lost revenue.

So if you’re looking into Linux backup solutions for IBM Power systems, don’t settle for just data backup. Look for a solution that will also backup your OS at the file level. A file-based system backup enables you to restore all the files you need and none of the ones you don’t. It also gives you the flexibility to restore your backup onto different hardware if you can’t find exactly the same server you were using before the crash.

In addition, make sure your backup solution is designed specifically for Linux backup on IBM Power. As you know, these machines boot very differently from Intel systems. Logical Partitions on IBM Power are not like your garden-variety VMs. LPARs often have complex storage configurations that can mix logical and physical resources such as multi-pathing. If your backup solution isn’t set up for that, you’ll suffer later when you try to restore after a crash. Finally, be sure your backup system supports both little-endian and big-endian byte ordering.

We’ve given you a lot to think about. In our next article, we’ll discuss why AIX backup must involve more than just mksysb. In the meantime, we hope you’ll take the time to learn more about the most robust Linux on IBM Power backup solution on the market. That solution is Storix SBAdmin —designed specifically for file-based backup for Linux on Power. To learn more, contact us, or speak with one of our disaster recovery experts at (877) 786-7491.

Will Your SAP HANA Backup Actually Protect You in a Disaster?

Your SAP HANA system just went down. What’s your first thought?

If you’re like many system administrators, you’re thinking, “It’s no big deal. We have a great SAP HANA backup solution in place. It will take some work, but we should have all our data restored in minutes.”

Yes, your backup software probably makes it easy to bring all your data back, exactly the way it was just minutes before the crash. But as important as data is to your business, it may be the least important consideration in the disaster recovery picture.

Most SAP HANA backup software can’t and won’t enable your business users to get fully back up and running within a timeframe that’s acceptable to your business. Here’s why.

What it Really Takes to Restore SAP HANA

Restoring your data is easy enough, whether you install a new box or simply swap out the hard drive on the down box. It’s what comes next that exposes the shortcomings of the typical SAP HANA backup solution.

We’ve all seen that dreaded error message at some point:

“No Operating System Installed.”

 

You can’t restore your data until you reinstall SUSE Linux. And you can’t do that without reinstalling not just the original OS from DVDs, but also the litany of security patches and updates you’ve installed over the past couple of years.

This isn’t challenging work for you, of course. But it’s time consuming. And every minute your business stays down will cost you money. How much money? That depends on your line of business—but most estimates start at several thousand dollars per minute.

The main problem in this scenario is that your SAP HANA backup software didn’t back up your OS—it only backed up your data.

This, of course, is why many sysadmins run high-availability (HA) systems that automatically fail over to a mirrored SAP HANA server in another location. HA systems do have a lot of advantages. But they also have a critical shortcoming—and we’re not just talking about the high cost.

Why High-Availability Isn’t a Foolproof Solution

The advantage of HA systems is that they’ll replicate everything on your IBM Power System server. It’s like SAP HANA backup on steroids.

That advantage is also a disadvantage. HA systems will replicate everything on your IBM Power System server. Even malware.

Cyber crime is on the rise. Criminals want your business data—even if your organization isn’t Fortune 500. They have an increasingly sophisticated array of techniques for attacking your network and evading detection. If their malicious code gets onto your main SAP HANA server, and that server is automatically replicated onto other servers….well, we don’t need to tell you the rest.

One cyber attack can easily knock out your entire HA system. But fortunately, there’s a practical, cost-effective solution for SAP HANA disaster recovery.

How to Get True SAP HANA Disaster Recovery

As you seek to protect your business from extended downtime, you’re thinking hard about balancing your recovery time objective (RTO) against your budget. Sure, every sysadmin would love to have a solution that ensures everything will be back up and running within seconds—but not every sys admin has the budget of a high-profile stock trading website. A more sensible solution is to pursue a bare-metal recovery solution.

With a bare-metal solution that backs up your entire system, you can get more than just SAP HANA backup—you’ll get true SAP HANA disaster recovery. And you’ll probably be surprised at how much bang it delivers for your buck.

Get the full story by downloading our free white paper, Why Your SAP HANA Backup System Isn’t a Disaster Recovery Solution—and What to Do About It.

You’ve probably read about the SolarWinds hack. It’s been all over the news the past couple weeks. The same group suspected of that hack is also behind a new rootkit called Drovorub. This attack specifically targets the Linux kernel versions 3.7 or lower due to a lack of adequate kernel signing enforcement. This would include a lot of Red Hat and SUSE Linux Enterprise servers currently in production environments.

How serious a threat is the Drovorub rootkit attack? It’s bad enough to compel the NSA and FBI to issue a joint security advisory.

If your Linux servers were to suffer this kind of attack, could you ever get back to where you were before it happened? Before you answer, consider that when you suffer that magnitude of attack, you’ll be doing more than just scanning files to see which ones have been corrupted. Your entire operating system will no longer be trustworthy because these serious hackers who have set their sights on Linux systems are using a rootkit to get the data they crave.

What is a rootkit? A rootkit will enable a hacker to gain unauthorized access to some part of your hardware or software. And once rootkits are in your network, they have various means of evading detection.

Some cyber security companies claim they can remove a rootkit, but in most cases the only remedy is to re-install the operating system. In extreme cases, when there’s a rootkit in your firmware, you’ll need to replace your hardware, too.

Why Rootkit Attacks Are So Hard to Fight

Your malware detection program may be top-notch. But even if it manages to identify and remove a rootkit, you’ll have a very hard time determining which other files were affected by it. For one thing, rootkits can simply prevent you from seeing all the contents of a directory. Other malicious files can then hide in plain view.

For another thing, rootkits can also change the dates of files to make them look older. As you’re cleaning up after a malware attack, you may simply decide to delete all files that were edited after the exact time of the attack. But rootkits can roll back the dates of your files to make them look as if they were untouched by the attack.

And remember, even the tools you’re using to detect rootkit attacks can be compromised by the very code they were designed to detect. We’re not talking about simple viruses here. We’re dealing with some of the most serious threats to Linux and Unix systems.

Two Safe Ways to Respond to a Rootkit Attack

As you can see, it’s virtually impossible to respond to a rootkit attack by removing the malware and all the files it affected. If you take that approach, you’ll likely discover that more and more of your files continue to get infected over time by installers that your detection tools can’t even see. Keep in mind that malware can even settle in at the kernel level, making your operating system unusable from that point on.

The only safe way forward is to start over on a clean system. To get there, you have two options. You could reinstall your operating system. This approach will also require you to reinstall all of your patches and updates, and to reapply all of your configurations. You’ll be in for many hours of work, and you may never get everything back to the satisfaction of your end users.

Your second option is to roll back to your last known good backup before the attack. If you’ve pinpointed the time of the attack, this should be no problem. But keep in mind that the all-too-common approach of backing up only applications and data isn’t enough. If your backups don’t include your operating system, they will be far too risky to rely on after a rootkit attack.

If you do back up your entire operating system, you’ll even have a reliable solution in the event of ransomware attacks. During these devastating attacks, cyber criminals encrypt your files and demand payment to unencrypt them. But if you can roll back your entire OS to before the attack, you’ll escape without paying a dime.

At Storix, we specialize in helping companies set up backups that empower them to restore their production Linux servers (including the operating system) after even the worst malware attack. We would love to provide you with a proof of concept for Storix SBAdmin. To get started, call us today at (877) 786-7491.