BCDR – Business Continuity and Disaster Recovery – Part 3: Your Disaster Recovery Test Results Checklist

disaster recovery test results

About Us

SysAdmins creating software for SysAdmins.

BCDR – Business Continuity and Disaster Recovery – Part 3: Your Disaster Recovery Test Results Checklist

disaster recovery test results

We recently wrote about disaster recovery testing and provided three tips for your next test. Before you read any further, we strongly recommend you check out that article to determine how prepared you are for your next round of testing.

Even if you say, “We’re ready for anything,” that may only be half-true. Why? Because many companies put significant time and resources into preparing for testing but come up short on generating disaster recovery test results. And without the ability to gather meaningful results, you’ve really only done half the job.

Seven Questions to Ask After Running a DR Test

Ensuring that you can generate useful disaster recovery test results is just as important as planning your DR test in the first place—maybe even more so. We’re not saying it’s a fun task. In fact, it’s a little bit like eating your vegetables—nobody really enjoys it, but we all know we’ll be better off in the long run if we choke them down.

We’re here to make it as easy as possible. Consider these seven questions to be your checklist for assessing the effectiveness of your next DR test.

  • Were your goals clearly defined when you started the tests? We’ve all been there: you thought you had clear goals heading into a test, but once you got going, you encountered confusion about what to test and how to distinguish success from failure. It’s possible to get lured in by goals that look good on paper but don’t really address the most important priorities for your DR testing.
  • Did your entire team understand their roles and expectations? In other words, did any participants encounter knowledge gaps along the way?

    Look for something deeper than a surface-level answer here. Sure, maybe the person in charge of restoring the system felt fully qualified to do so. But they also had to work with two people from the network team, and neither of these employees understood the nature of the DR testing or their role in making it happen. A simple miscommunication or misunderstanding can cause critical delays that force you to miss your recovery time objective (RTO). Another common problem is that while everyone is capable of performing the duties assigned to them, some team members are unclear about when to complete their tasks. In this scenario, your business can lose precious minutes as a team member waits for “someone else” to do what’s actually his job.

  • Did you meet your RTOs and RPOs? RTO and recovery point objective (RPO) are by far the most important disaster recovery test results. It’s not wrong to say that as long as your DR program meets your RTO and RPO, it’s a success.

    But this is another spot where you must dig deeper than a surface-level answer. It’s possible to meet RTO and RPO by doing something off-script. If your team used a funky workaround to deliver on time, good for them—but can they repeat this performance next time?

    Consider also whether any failures were partial or complete. If some element of the plan failed completely, it’s good to know that you’ll need to replace it as you update your DR plan. If an element failed only partially, try to determine how these problems forced your team to adjust the plan. By taking this information into consideration, you’ll be able to build a much stronger plan for next time.

  • What unexpected things happened? It wouldn’t be a DR test without something weird happening. But don’t use that as an excuse to settle for less-than-optimal disaster recovery test results. Some unexpected things happen due to our own oversight. Perhaps your DR plan was missing a key element that made you kick yourself when you discovered it during testing. Nobody’s perfect, but you could have prevented that, right?

    Maybe you neglected to read thoroughly the technical specifications on the equipment you were using. Again, that’s just human, but it’s something that shouldn’t happen more than once.

    An even more common unexpected pitfall is when companies plan to restore to the same hardware they’ve been using—only to discover that the vendor no longer makes that exact model. We at Storix run into this all the time, which is why we designed our Adaptable System Recovery to let companies restore their backups onto practically any hardware.

    Other unexpected occurrences are beyond our control. A normally reliable piece of equipment fails at the worst possible moment. Someone makes a mistake they’ve never made before. These are occurrences to document so that you can develop a reasonable Plan B against them.

  • Did you document carefully? OK, so you ran your DR test and evaluated the results. Did you keep detailed records and produce a report? After each DR test, you should generate a report that you store away along with the results of the test. If you don’t keep records of these things, it’s like going to school with no report cards. How will you measure your progress?
  • Did you schedule a time to correct problems and make adjustments? Don’t stop at documentation. Before you lose your momentum, take those disaster recovery test results and schedule a time to discuss what changes you need to make to improve your performance next time. It’s the easiest thing in the world to generate a long list of results and then file them away. The only real improvement comes when you make changes to your DR plan based on those results.
  • Did you train your team on the changes and update your DR plan procedures? We can’t stress it enough: communication across the DR team is paramount. Even the smartest changes to your DR plan will be useless if you haven’t informed your entire DR team and provided them with the training they need to do things the new way. Make sure you put everything in writing, too. Otherwise, team members will simply revert to how they did things—less than effectively—in your last test.

Get Help Gathering Disaster Recovery Test Results

Not sure you’re generating the right kind of data from your DR tests? Or want some guidance in creating and optimizing your DR test plan? We’re here to help. When you’re ready to talk, give us a call at (877) 786-7491.

Consider This Common ‘Gotcha’ Before Your Next Disaster Recovery

restore to dissimilar hardware

About Us

SysAdmins creating software for SysAdmins.

Consider This Common ‘Gotcha’ Before Your Next Disaster Recovery

restore to dissimilar hardware

Even the best disaster recovery plan probably has a few oversights. For example, many companies build their plan around the assumption that if they lose a server due to natural disaster, power surge, or hacker attack, they’ll simply restore onto the same kind of server.

But what if they restore onto their new box, only to discover that it is ever so slightly different? Sure, that server may seem virtually identical to business users. But even the slightest difference – in disc size or storage controllers – could prevent your restore from working properly.

A similar server isn’t the same server—and even the “same” server may not be identical if it’s a slightly updated version. It’s not only possible but highly likely that you will need to restore to dissimilar hardware or storage after your next system outage. Can your disaster recovery plan really support a change in hardware? Before we can answer this question, we must look at what goes into a good disaster recovery plan.

Building Your Disaster Recovery Plan

Disaster recovery is all about getting your computing systems back up and running after a significant disruption. So the first step in creating your disaster recovery plan is to ask your stakeholders: “How long can our systems be down without severely impacting our organization?”

Notice the word “severely.” Any network downtime will be a nuisance and will likely trigger complaints from your end users. But how long will it take before you can’t serve customers, have to shut down production, and so on?

This interval is known as your downtime tolerance. For some companies, it’s minutes. For others, it may be as much as an hour. But it’s seldom several hours almost never days; if you use computers at all, you come to depend on them more than that.

Based on your downtime tolerance, you can then determine your recovery time objective (RTO). Your RTO should be designed to ensure that you’ll restore your business systems before you exceed your downtime tolerance.

At this point in the process, many system administrators think, “We’re covered. Our RTO is one hour, and I know we can restore data from our backups within 20 minutes, so we should be fine.”

Don’t fall into this common trap. You’ll only be OK if you’re doing the right kind of disaster recovery backups.

Why System Image and Data-Only Backups Aren’t Enough

Many system administrators assume that their system image backups or data-only backups provide them with the protection they need in the event of a disaster. Here’s some tough love: they’re wrong.

Keep in mind that after a disaster, you’ll very likely have to restore to dissimilar hardware. System image backups are only designed to work on the exact same hardware. Put them on a differently configured system, and they’ll be useless.

Meanwhile, restoring from a data-only backup won’t help you meet your RTO. Even if you know it won’t take long to pull data onto your new hardware, keep in mind that your new hardware will need extensive preparation before you can use it. You’ll have to install the operating system, application patches, and updates, and you’ll need to make all the system configurations you made on your previous hardware. This process, alone, can take many hours.

So if you really want to be prepared to restore to dissimilar hardware, the best approach is to back up everything on your server. This includes your operations, applications, data, patches and updates, and configurations. And be sure your backups are configured to happen at the file level. That way, you’ll be able to restore selectively, omitting any files that were specifically related to the old server.

With a complete file-level disaster recovery backup like the one we’re describing, you can often recover your business systems on dissimilar hardware in minutes, not hours. And there’s no organization that wouldn’t want that kind of resiliency after a hack.

Protect Your Virtual Machines, Too

Now, if you’re running your business on virtual machines, this discussion of restoring to dissimilar hardware may seem irrelevant to you. Even if your VM vendor switches physical servers, you’ll see the same virtual environment.

But after disaster strikes, you may very well need to restore to a different virtual machine platform, or in a dissimilar cloud environment. Within a new VM or cloud environment, there may be nuances that can throw off your disaster recovery. System image and data-only backups won’t necessarily work correctly in the face of these changes—but complete file-level backups will.

Regardless of which hardware you’re coming from or which VM platform you’re going to, Storix SBAdmin helps organizations like yours restore operations in minutes after a cyber attack. We would love to provide you with a proof of concept tailored to your needs. To get started, call us today at (877) 786-7491 or schedule a time to speak with one of our disaster recovery experts.

BCDR – Business Continuity and Disaster Recovery – Part 2: DR Testing

disaster recovery test

About Us

SysAdmins creating software for SysAdmins.

BCDR – Business Continuity and Disaster Recovery – Part 2: DR Testing

disaster recovery test

Does the thought of preparing for your next disaster recovery test stress you out? Does a lot of that stress come from the fact that you can’t remember when you did your last disaster recovery test (DR test)?

We understand. Performing these tests is a little bit like exercising. You know you should be doing it regularly. You keep thinking you’ll make time for it. But it’s not easy or fun—and you seem to be doing OK without it. So you put it off for a while longer.

We’re not here to judge your mile time or the number of pullups you can do. But we are here to warn you about the dangers of putting off your next DR test. You never know when the next server failure, natural disaster, or malware attack will bring your business operations to a halt. And you need to know that you’ll be able to get your operations back up and running as quickly as possible. So there’s no getting around it: you should take a careful look at your current disaster recovery strategy.

3 Tips for Your Next Disaster Recovery Test

If you already have the ideal DR test plan in place but simply haven’t executed it in a while, then it’s simply a matter of devoting the manpower and you can probably stop reading this article.

But most companies have holes in their test plans—gaps that are challenging enough to prevent them from testing as often as they should. How often is “as often as they should”? Aim to strike a balance between testing so frequently that you’re disrupting normal IT operations, and testing so rarely that you’re certain at least one element of your disaster recovery plan will fail miserably.

Whether that means monthly, quarterly, or annually is up to you. But once you’ve set your DR testing schedule, your next question should be, “Are we ready for our next disaster recovery test?” Here are three tips to help ensure you can answer, “Yes!”

  1. You’re equipped to test for a wide range of disruptions. Even if your servers are housed in an area with few natural disasters, don’t assume that you can simply focus on recovering from a burned-out box and ignore other threats. Within the category of cyber attacks, for example, there’s a huge variety of emerging threats, each of which will place different demands on your disaster recovery systems. In addition, power outages can happen anywhere. And what about a good old-fashioned plumbing leak? If your server has water damage, can you recover within your recovery time objective (RTO)?
  2. You’re using multiple layers of protection. Data backups are essential—but they don’t cover everything. Are you also backing up your applications? Your operating system? And even if you’re backing up everything (kudos!), are you storing those backups in a single network location? Or are you also taking the precaution of copying them to the cloud as well as offline storage such as tape or removable USB drives?
  3. You can get help when you’re stuck. Suppose you’re doing everything we’ve suggested so far. Suppose you’re using the best backup technology money can buy and copying your backups to multiple locations. But when you try to restore your cloud backups, they’re failing, whereas your other restores are working just fine. Nobody on your IT team can figure out what’s wrong. What’s your next move?

    We know you’re not willing to say, “Oh well, close enough!” and then simply forget about it until your next disaster recovery test. That’s why you should know how important it is to work with a disaster recovery partner that can help you through your toughest technical challenges.

Work with a Partner Who Walks You Through the Process

Not all disaster recovery technology vendors provide robust support throughout the testing process. But Storix does.

When we say we support our Adaptable System Recovery platform, we don’t just mean that if it breaks, we’ll fix it for you. (That’s the bare minimum any software vendor should be doing.) We mean we’ll actually take the time to walk you through your disaster recovery challenges so that you be confident you’re 100% ready for your next disaster recovery test—and, if it comes to that, for your next disaster.

We’d love to hear about your disaster recovery challenges and help you overcome them. When you’re ready to talk, give us a call at (877) 786-7491.

Ransomware Backup Strategy: Beyond the 3-2-1 Rule

ransomware backup strategy

About Us

SysAdmins creating software for SysAdmins.

Ransomware Backup Strategy: Beyond the 3-2-1 Rule

ransomware backup strategy

If you’ve established a solid backup strategy for your business data, then you’re probably aware of the 3-2-1 rule. According to this longstanding rule, you need three copies of your backup data, on two different types of media, and one of them should be stored offsite unconnected to any network.

This is sound advice, and it has helped companies protect their digital assets for many years. The question is, does the 3-2-1 rule also apply to your ransomware backup strategy? We believe the issue is too complicated to address with a simple yes or no. First, we need to dive deeper into what ransomware is and how it operates.

Sobering Statistics About the Cost of Ransomware Attacks

What is ransomware? According to an FBI fact sheet:

Ransomware is a type of malicious software, or malware, that encrypts data on a computer making it unusable. A malicious cyber criminal holds the data hostage until the random is paid. If the ransom is not paid, the victim’s data remains unavailable.

During a ransomware attack, the malware bots or scripts indiscriminately try to encrypt every file they can find on your network. This means it’s not just your data files that are at risk—it’s also your onsite disk-based backup files. Simply having backup files for your systems won’t protect you from ransomware because your image-based backups and snapshots will probably get encrypted along with everything else if they’re stored on your network.

Ransomware is on the rise—so if you still don’t have a ransomware backup strategy, now is the time to develop one. Recent research by SafetyDetectives indicates that although the average ransom of $6,500 per incident may not seem like a big deal to larger organizations, the average cost of the downtime caused by a ransomware incident is $380,000—a crippling figure for many businesses. And in the U.S., 54 percent of organizations reported ransomware attacks in the past year.

What Your Backup Solution Must Provide

As we mentioned, any files on your network are at risk of being encrypted in a ransomware attack. So if your entire ransomware backup strategy revolves around backups stored on your network, you’ll need to revise your strategy.

Adding to the difficulty of building a good strategy, many of today’s backup solution providers no longer support tape-based backups. We get it: tapes seem like outdated technology, and you might feel silly using the IT equivalent of a rotary phone. But if we’re going to reject them on those grounds, we need to replace them with a product that can provide a similar level of protection.

The ideal solution to support your ransomware backup strategy is one that allows you to perform a complete system backup once and then copy the backup file to multiple locations and devices of your choosing. Still using tapes? Great! Perform your backup and have your solution automatically copy it to tape, where it will be safe from ransomware bots.

Using USB drives instead of tapes? That’s great too. Perform the backup and copy the file to your USB drive, then store that drive on a shelf.

Storing your backups at an offsite data location? To date, there hasn’t been any ransomware that can figure out how to access offsite data storage. Remember, ransomware may be dangerous, but it’s also simple-minded: it can only find and encrypt files. So if your backup solution can automatically pass your backup files to your offsite storage provider and then automatically retrieve them as you recover from a ransomware attack, you should be good to go.

Get Expert Advice on your Ransomware Backup Strategy

A good ransomware backup strategy should be quite simple. In fact, the FBI fact sheet we cited earlier provides five best practices, and the first is to keep your backups offline—something you may already be doing. With the right solution, you can automate the process of creating these backups and transmitting them to a secure location.

Could Storix help you plan and implement your ransomware backup strategy? For a free, no-pressure consultation, call us at (877) 786-7491.

All-in-One-Backup Solutions: Can One Backup Solution Really Do It All?

All-in-One-Backup Solutions

About Us

SysAdmins creating software for SysAdmins.

All-in-One-Backup Solutions: Can One Backup Solution Really Do It All?

All-in-One-Backup Solutions

If you really want to keep your data safe and your business moving forward in any circumstances, you need to create a comprehensive disaster recovery plan that can protect all the systems your business runs on. Your mission-critical business applications are too important to risk on any of the “good enough” all-in-one backup solutions that don’t really allow for a full and rapid recovery.

No single all-in-one backup solution on the market today can meet all the backup and restore needs of any organization that’s running a combination of Windows, Apple, Linux and Unix computers. And while you may not need to replace the backup software you’re already using, it would be wise to augment it with an additional layer of protection.

The good news is, the cost of adding a more effective backup solution may end up being only a fraction of the cost of letting your business sit idle for several hours during a system outage.

So, what’s the problem with the “we-can-backup-everything” solutions? Most of them fall into the category of either data-only backup solutions or image-only backup solutions. Let’s take a closer look at each of these.

Data-only backups

If your organization has adopted a data-only backup approach, you have total assurance that you’ll be able to bring all your data back online within minutes of a system crash. But as every sysadmin knows, getting to a fully restored application is often the hard part.

To put it another way, even the best data backup in the world is useless unless you have a functioning system onto which you can restore it. But before you can do that, you’ll need to reinstall the Linux operating system on which your business applications run. By the time you have a powered-up server with a working operating system, your business users may have been sitting idle for hours.

Image backups

If you’re backing up with software that offers “complete system backup,” the chances are good that it’s making image backups—a raw copy of a hard drive which will include the OS, the applications, user data and empty space. You would expect to be able to restore this image back to your server. That usually works in a virtual server environment, but it’s a different matter when you need to replace a physical server and want to restore your system exactly the way it was.

Although vendors often offer plugins for this purpose, it often lacks the robust functionality you’ll need to protect your business fully. If you use an image backup system that offers limited functionality for physical systems running Linux, you’ll struggle in a disaster recovery situation for a complex implementation of a business platform.

Restoring to new hardware

The Achilles heel of image backups is that they require you to restore your system onto the exact same hardware you were using before your crash. If you have changed any of your hardware variables—even slightly—there’s a good chance that your restore won’t work. And if you have new hardware, you may be out of luck due to different disk size, different disk geometry, or different storage controllers or drivers.

Your best alternative

A file-based backup lets you restore your entire system—including your operating system and user data—onto the bare metal of new hardware or virtual machines. Unlike image backup systems, a file-based system backup is flexible enough to let you restore onto different hardware or disk configurations. If there are corrupted files in your backup, a file-based backup allows you to restore individual files as you choose so you can leave them out when you reinstall on your new server.

Here’s the kicker: file-based backup is significantly faster than either data-only or image-only backups, so you can be more secure in meeting your RTO.

To learn more about the value of having a file-based backup system available for your disaster recovery plan—and especially if you are running business-critical applications on Linux or Unix servers—read our white paper Busting a Myth—Can One Backup Solution Really Do It All or call us at (877) 786-7491.

RTO and RPO: What They Mean and How to Achieve Them


About Us

SysAdmins creating software for SysAdmins.

RTO and RPO: What They Mean and How to Achieve Them


You can’t predict when an IT disaster will bring your business to a screeching halt. But defining and planning in advance for your response to the disaster is critical. To do this, you need to know the crucial metrics for disaster recovery—the length of time your business can survive until systems are restored (measured as RTO), and the amount of data your business can risk in restoring from a backup (measured as RPO). RTO and RPO values will vary across different companies, but all companies must find these points of compromise between their needs for system availability and their investment in safeguarding their data.

Understanding RTO and RPO

RTO and RPO are closely related terms. Both of them are paramount to your disaster recovery strategy.

Recovery time objective (RTO) is the amount of time after which you need to have your systems back up and running after an outage. In a perfect world, every business could have an RTO of, say, one second. But in the real world, it’s generally only stock trading websites that have that kind of RTO. With so much money at stake, they invest heavily in redundant systems and automatic failover. The price they pay wouldn’t be worth it for most other types of businesses.

So, there’s a tradeoff here. Nobody wants to wait days or weeks to bring their business back online. But depending on whether your RTO is measured in seconds, minutes, or hours, you’ll have different backup options at vastly different price points.

Recovery point objective (RPO) refers to the amount of business data you’re willing to lose to a system outage. In a perfect world, you’d be able to restore every keystroke anyone in your organization made up until the very instant of the crash. More realistically, you will have to be willing to let go of your most recent data. The question is: how recent? As with RTO, you’ll have different options for ensuring an RPO you can live with. The less data you’re willing to lose, the more you’ll generally have to pay for your backup solutions.

Clearly, there’s a balance to strike when your company is establishing RTO and RPO and finding solutions that meet these objectives.

Common Methods of Achieving RTO and RPO

Your ability to achieve your RTO and RPO will depend almost entirely on the technology you’re using.

If you’re doing data-only backups but you have to reinstall your operating system after a server crash, then your business will likely remain offline for many hours as your team works to reinstall your OS plus all of its patches and updates. Your RTO will need to reflect this reality.

If you’re doing image-based backups, you may not be much better off. Disk-image backups require that you install onto exactly the same kind of server you used before the crash. Otherwise, you’ll probably need to spend days rebuilding and patching your systems on the new hardware.

Some sys admins believe that if they use one of these methods but fully document all their processes and systems, they’ll be able to recover quickly from an interruption. But here’s the reality: IT is messy. Technology changes. People come and go, taking with them the processes that live only in their heads. Documentation goes missing. So do patches and updates.

On top of that, if you’re using a turnkey solution where your server came with the database and OS pre-installed, you’ll likely have little idea what has been done to these machines to make them work well—and so you’ll be in a tough position trying to replicate the configuration when a crash occurs.

That’s why we believe companies that want to maximize their chances of achieving their RTO and RPO need to invest in a more reliable system.

Why Full System Backups?

Here’s a better way to achieve your RTO and RPO: perform full-system backups. With full-system backups, you regularly back up your entire system—OS, business applications, and data.

Storix Adaptable System Recovery (SBAdmin) is full-system backup that enables you to schedule your backups and perform them incrementally. This way, you can choose to back up only the files that have changed within a certain period of time you designate. For example, you might schedule a weekly backup, and then from there, do incremental backups every day, every hour, and every few minutes. You can maximize your chances of achieving your RPO without putting a burden on your storage.

As for RTO, SBAdmin helps you there, too. By backing up your entire system, you’ll shave many hours off your recovery process because your team won’t have to reinstall your OS, patches, and upgrades. They’ll simply restore all of this from your latest backup – even to dissimilar hardware or storage.

So, are your RTO and RPO realistic for your business? Are you well-equipped to meet them? Our disaster recovery experts can help you answer questions like these. For a free, no-pressure consultation, call us at (877) 786-7491.

Bare-Metal Restore: How to Protect Your Business

bare-metal restore

About Us

SysAdmins creating software for SysAdmins.

Bare-Metal Restore: How to Protect Your Business

bare-metal restore

Bare-Metal Restore: How to Protect Your Business

Ever had to do a bare-metal restore in which you’re reinstalling your business systems onto new hardware that doesn’t even have an operating system installed? Without the right approach, it can be a painful process. But it doesn’t have to be that way.

An Often Overlooked Need for Bare-Metal Restore

There are still sysadmins who figure they won’t have a need for bare-metal restore. They invest in the best servers. They have server redundancy. They even run their servers in a part of the country that’s not prone to natural disasters.

Fair enough. But what about OS upgrades? Unexpected things can happen through no fault of your own. Before you embark on these projects, it’s best practice to create a thorough backup of your entire business environment. That way, if the update leaves the system unable to boot, you are not left with a cold box. You need an easy way to roll backup the system to what you had before so that your business can keep working as your IT team plans its next step forward.

How Most Companies Approach Backups (and Why They’re Not Really Protected)

When it comes to disaster recovery, most companies fall into one of two camps:

  • They back up their data but not their OS. They will have to reinstall their OS before they can even think about restoring data from their backups. For them, restoring the entire system will be a long and involved process.

    Reinstalling an OS is so much more than just pulling out DVDs and installing them, onto the new server. As you’ve probably experienced, you must also reinstall all the security patches and updates that have been issued for that OS since the initial release. You’re probably looking at many hours of downtime for your systems and lost revenue for your business.

  • They take image-based backups. This approach can work if the company is planning on restoring systems onto exactly the same hardware. But with the pace of change in computer hardware, it’s not always a given that a company will be able to find the same model of server with the exact same storage two years later. Since an image-based recovery is all or nothing, reinstalling the operating system isn’t really an option as the data is locked inside the disk image.

    Bottom line: when image-based backups work, they work really well. When they don’t (and this is all too common), you are left with a system image that you effectively cannot use.

A Better Approach to Bare-Metal Restore

As you can see, both of the above approaches have severe limitations. We recommend an entirely different way of preparing for the dreaded bare-metal restore. We call it Adaptable System Recovery (ASR). This is a file-level backup that includes your entire system—OS, business applications, and data. Yes, that’s a lot to back up, but it gives you at least three advantages in the event of a server crash or even a natural disaster:

  1. You won’t have to reinstall your OS before recovering your data. you can just restore the entire system exactly as it was at the time of your latest backup.
  2. You won’t have to find hardware that exactly matches your old one. Your full-system backup will work on any hardware (physical or virtual).
  3. You can select which files you want to restore. Our file-level backups aren’t all-or-nothing like an image-based backup. So if you’re concerned that some of your files might have been corrupted or were erased by mistake, you can play it safe and restore only the ones you need.
  4. Does This Work for Virtual Machines? Of Course!

    Some sysadmins will read this and say, “Oh, this doesn’t apply to us. We use virtual machines, so we’ll never have to do a bare-metal restore.” But that’s not quite true. What we’re talking about here is any restore in which you have to start by reinstalling the operating system. It makes no difference whether you’re running physical or virtual machines; if there’s an OS reinstall involved, then you’re going to spend hours rebuilding your systems and business is going to be at a standstill until you finish.

    But what about VM snapshots? Don’t they provide the kind of protection for virtual machines that we’re talking about here for physical machines? Not exactly. Much like image-based backups, VM snapshots are all-or-nothing. You lose the flexibility to decide which files you want to backup or restore. And so, as we said, you’re going to be in a tough position if you need to just recover system files and don’t want to replace the entire virtual machine. We say full-system backups with ASR is a much better approach.

    Restore With Confidence

    We would love to chat with you about protecting your business by preparing you for a fast, seamless bare-metal restore. For a free, no-pressure consultation, call us at (877) 786-7491.

Red Hat Linux Backup and Restore: Are You Fully Protected?

red hat linux backup and restore

About Us

SysAdmins creating software for SysAdmins.

Red Hat Linux Backup and Restore: Are You Fully Protected?

red hat linux backup and restore

If you’re running Red Hat® Enterprise Linux®, you’re running on the world’s leading enterprise Linux platform. Since no software or hardware is infallible, at some point, your server is going to go down. You may be tempted to say, “We’re covered. We have a Red Hat Linux backup and restore solution in place. We’ll just bring everything back online and carry on as always.” But that may not be the entire story. Yes, your backups no doubt capture all your business data. And yes, it’s relatively easy to restore business data onto a server that’s configured to run your OS precisely the way you left it. And therein lies the challenge. If your Red Hat Linux backup and restore solution only backs up your business data, there’s a huge gap in your disaster recovery plan. Here’s why.

What it Really Takes to Restore Red Hat Linux

Let’s take a step back and look at what recovering from this problem really entails. Suppose one of your Red Hat Linux users complains that their systems are down. Your first step is to reboot. That usually works, but what if it doesn’t? In this case, you’ll either install a new box or swap out the hard drive on your old machine. So far, easy enough. But here’s where we see the shortcomings of the typical Red Hat Linux backup and restore solution. No matter how good your backup solution is, until you’ve reinstalled Red Hat Linux on your new server, it’s not doing you any good. That process will require you to re-provision the OS or worse pull out install DVDs of the OS and reinstall them one by one. Next, you’ll need to install the numerous security patches and updates you had installed on your previous server over the past couple of years. Your IT team may not mind this extra work. After all, it’s not difficult. But every minute they spend on this tedious task is a minute that your business isn’t serving customers and generating revenue. A single Red Hat Linux outage could easily cost your company six digits. This scenario illustrates the importance of using a Red Hat Linux backup and restore solution that is designed to back up your entire OS as well as your business data. “That’s not necessarily true,” you may object. “Couldn’t we just run a high-availability (HA) system?” While HA systems deliver a lot of value, they also come with a critical flaw.

Even High-Availability Won’t Give You Total Protection

Installing a HA system gives you peace of mind that everything on your Red Hat Linux server will be replicated to a failover server. But “everything” really means everything. Even malware. So, picture a scenario in which the outage we’ve described above was caused by a virus. Your HA system will back up that virus to your failover server and most likely bring it down, too. The unfortunate outcome is one well-planned cyber attack can easily wipe out your entire HA system—costing you time and dollars invested in your HA system. The good news is that there’s a much more practical, cost-effective way to protect your Red Hat Linux servers.

A True Red Hat Linux Backup and Restore Solution

For a better way to protect your business against extended downtime, look for a comprehensive backup solution. Demand a bare-metal solution that backs up your operating system as well as your business data. Storix is the only vendor that provides such a solution—and Storix System Backup Administrator (SBAdmin) for Linux is a certified Red Hat solution. For a smaller investment than implementing HA software and servers, you can give your business true protection against server outages. SBAdmin is also the only product that fully supports Red Hat Enterprise Linux for IBM Power. It’s much easier to meet your recovery time objective (RTO) when your backups contain everything you need—except for hardware. Simply get your new box up and running, and then restore your complete system backup onto it in minutes. Our disaster recovery experts are happy to discuss with you how to get the most value for your money as you seek to protect your Red Hat Linux servers. For a free, no-pressure consultation, call us at (877) 786-7491.

Overcome Cloud Migration Challenges with Our On-Prem to Cloud Approach

cloud migration challenges

About Us

SysAdmins creating software for SysAdmins.

Overcome Cloud Migration Challenges with Our On-Prem to Cloud Approach

cloud migration challenges

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.

AIX mksysb: Here’s Something Even Better

AIX backup software

About Us

SysAdmins creating software for SysAdmins.

AIX mksysb: Here’s Something Even Better

AIX backup software

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.