Cristie Software Completes Acquisition of Storix, Inc.

 

Cristie Software extends its solution portfolio for the recovery of Linux, AIX and Solaris based systems through the acquisition of Storix, Inc.

London, UK, & San Diego, CA, USA, 24 February 2023 – Cristie Software a leading system recovery, replication, and migration solutions provider, today announced the completion of the acquisition of Storix, Inc. for an undisclosed sum.  Storix is a provider of backup and recovery software for Linux, AIX and Solaris based virtual and physical systems through its product SBAdmin (System Backup Administrator). SBAdmin was released in 2004 as the first flexible full-system backup and bare-metal recovery solution for Red Hat, Ubuntu, and SUSE Linux on x86 hardware and later for SUSE Linux running on IBM’s Power Systems (Little Endian).  Storix provides system and data protection to over 200 customers, mostly in the United States.

Cristie Software provides bare-metal recovery solutions that integrate with leading backup solutions including Dell Technologies’ Avamar and Networker products, Cohesity DataProtect, Rubrik Security Cloud and IBM Spectrum Protect. The addition of Storix SBAdmin extends bare-metal recovery support for IBM Linux on Power hardware. SBAdmin will compliment and extend Cristie Software’s existing portfolio of system recovery, replication, and migration solutions.

“We are delighted to add Storix adaptable system recovery and backup management solutions to our portfolio of software products and to provide ongoing development and support for existing and future customers,” said Scott Sterry, VP Business Development at Cristie Software. “This acquisition comes at an exciting time as we continue to expand the feature set of our system recovery solutions including our patented machine learning technology which automates system recovery failure resolution. We are also delighted to officially welcome the incredibly talented Storix team to Cristie Software.”

Manuel Altamirano, VP Sales of Storix Inc said “The introduction of Storix into the Cristie family not only greatly increases our development resources but also opens up exciting opportunities to offer our customers a much wider portfolio of solutions”.

 

About Cristie Software

The Cristie group of companies founded in Stroud, England in 1969 and looks after more than 300,000 installations worldwide. Cristie Software work with some of the most advanced modern data management technology partners to provide a range of highly scalable solutions that facilitate data growth without vendor lock-in. Cristie Software develops its own software solutions in the fields of system replication, migration, and disaster recovery. The Cristie Virtual Appliance and Bare Metal Recovery solutions fit seamlessly into existing backup applications. Cristie Software recovery solutions can restore complete systems to different hardware platforms while providing powerful time saving DR testing orchestration to ensure systems will recover in the event of a disaster. Learn more at www.cristie.com

About Storix, Inc.

Storix, Inc. was incorporated in San Diego, CA, USA in 2003, shortly after releasing SBAdmin, their flagship Adaptable System Recovery and Backup Management solution for Linux, AIX and Solaris based platforms. Learn more at www.storix.com

If you’re searching for Linux backup solutions, we commend you for taking seriously an area that many organizations neglect. Just about every business has methods of backing up at least some of its data, and many have a means of restoring business applications after a system outage. But if you’re considering backing up on a wider scale rather than simply copying what you consider to be your most important files, you’re obviously willing to give your organization a higher level of protection.

The question remains: what should that protection be? That’s not a question we can answer in a few paragraphs because it depends on where your Linux servers are located, how quickly you want to be able to restore your systems after a crash, and how much of an investment you’re willing to make in Linux backup solutions (hint: you need not break the bank, but freeware probably won’t cut it, either).

Let’s get started.

Part One: Where Are Your Servers?

You can’t find the right Linux backup solution until you’ve thought about where your Linux servers are located. They’re probably either in a third-party data center (co-location) or in a server room on your company’s property (on-premises).

Third-party data centers come in several flavors. Some data center providers provide rack space in a data center but leave you responsible for maintaining your servers. Other vendors provide a full range of services, such as backups and monitoring.

And then there are cloud data centers (often called “infrastructure as a service,” or IaaS). Some IaaS providers offer full service. Others (including Amazon) simply offer the servers but leave you to maintain them.

The truth is, most organizations have a mixture of all of the above. Companies will probably always find a need to manage some of their own servers, whether those servers are down the hall or in a data center in the next state. And despite all the buzz that cloud computing has received in recent years, a 2019 survey revealed that 98 percent of companies still had at least some on-premises servers. Having boxes in-house continues to appeal to CIOs who want to protect themselves from cloud vendors who may raise prices, change terms of service, or simply go out of business and leave customers scrambling. A capable IT team can maintain a server in-house quite cost-effectively. And some executives would prefer the capital expenditure of a server purchase to the operating expenditure of a cloud server.

“There is a fairly significant amount of repatriation going on,” said Michael Dell, in an interview with CRN. “As much as 80 percent of the customers across all segments – small, medium, large – are reporting that they’re repatriating workloads back to on-premise systems because of cost, performance and security.” ¹

Part Two: Backups Are Still Necessary

If it’s fair to assume that businesses will always have some physical servers, then it’s also fair to assume that most—if not all—businesses will tap into the cloud for at least some of their computing power. In fact, the trend is towards more cloud servers and fewer physical ones. But as companies increasingly embrace the cloud, a dangerous myth is emerging—one that says the need for backups is disappearing along with the company server room.

Nothing could be further from the truth. As long as your company has mission-critical applications that cost you thousands of dollars for every hour they stay down, and as long as you have irreplaceable data, you’ll need backups.

But as we will soon explore, not all backups are created equal. If you’re backing up all your mission-critical servers to the cloud but it would take 10 hours to restore them, you don’t have a solution—you have a potential problem. If your cloud provider has all the control over your applications and data, how long will it take you to restore that backup on premises at your company? The answer to this question can make or break your Linux backup strategy.

“Remember that the cloud service you use, whether it is IaaS, PaaS, or SaaS, is just another data center like one you might build yourself—only it’s in another place run by other people. They may be the best at what they do, but neither they nor the systems they employ are infallible. That is why you should always have backup and disaster-recovery plans in place. Hope you never have to use them, but have them ready if you do,” says W. Curtis Preston, Chief Technical Evangelist at Druva. ²

Now, how does cloud repatriation change the picture? This is a new trend in which some companies are moving their cloud workloads back to on-premises servers. Cloud repatriation doesn’t indicate a permanent shift away from cloud resources—indeed, there are many reasons companies may choose to take some of their resources back in-house, and many do so only temporarily. But as companies move workloads freely to and from the cloud, the need for a comprehensive, flexible Linux backup strategy only becomes more urgent.

Part Three: Best Practices for Linux Backup

In a sense, there’s only one best practice for Linux backup: back up your business environment in such a way that you can restore data and applications in minutes, not hours. Of course, designing such a plan is the difficult part. In the process, system administrators often make one or more critical oversights or mistakes. For that reason, it may be most helpful to express best practices in terms of what not to do.

Here are several Linux backup mistakes that can threaten the health of your business:

1. Not backing up the operating system. Most companies focus on backing up their data—and with good reason. Losing your entire customer database, for example, would be devastating. Some companies also back up applications. But few back up the OS. They figure it’s not worth the effort. With OS disks readily available, it doesn’t seem like such a burdensome task to reinstall the OS after a crash.

   Although installing an operating system may not take long, think of all the updates and customizations you’ve made to your OS since the original installation. If your OS is completely wiped out by a disaster, you would not only have to provision a new base OS, but also install a series of patches and updates to get to the same state before the failure. That process can take several hours. Add those hours on to all the other tasks involved with disaster recovery, and you could be costing your business thousands of dollars in lost revenue.

2. Making image-based backups. Image-based Linux backups sound like a great idea. They allow you to restore from a mere snapshot of your system. But they have a catch: you must restore onto exactly the same hardware.

   That may not sound like a big issue. But think about how often hardware vendors make slight changes to their servers. If one of your servers is completely wiped out and you’re forced to restore onto a new box, you don’t want to have to search eBay for a discontinued server model. That’s why making image-based backups is a short-sighted strategy.

3. Making snapshot backups. Some system administrators see virtual machine (VM) snapshots as a good backup solution. In theory, they’re a great solution: they take an image of the entire virtual machine and allow you to restore onto new hardware.

   In practice, though, VM snapshots have a significant weakness: they’re all-or-nothing. It’s extremely challenging—some would say nearly impossible—to select the exact files you want to restore after a disaster. If that disaster was malware-related, then you’re going to be in a bind: you could end up restoring malicious files onto a clean new server and perpetuating the problem you were trying to solve.

   VM snapshots have their place in day-to-day system maintenance. But we say they’re not a flexible enough Linux backup solution for disaster recovery.

4. Discontinuing disaster recovery drills after moving data to the cloud. As wonderful as the cloud is, it can lull system administrators into a false sense of security. They get a vague sense that even if the unthinkable happens to their applications and data, they’ll simply be able to log in and restore everything.

   But if you’ve handed over control of your applications and data to your cloud provider, keep in mind that after a disaster, your access will be on your vendor’s terms, not your own. Your disaster recovery plan should take this into account as you plan your restore time objective (RTO) and recovery point objective (RPO). And you should continue to conduct disaster recovery drills that verify how realistic your RTO and RPO really are.

The ideal Linux backup strategy will revolve around a solution that can perform full-system backups—and it will call for you to conduct disaster recovery drills just as often as you did before you started moving your data and applications to the cloud.

“In some cases, keeping certain backup or disaster recovery processes on-premises can help you retrieve data and recover IT services rapidly. Retaining some sensitive data on premises might also seem appealing if you need to comply with strict data privacy or data sovereignty regulations,” says IBM. ³

Part Four: Overview of Linux Backup Solutions

As you consider possible Linux backup solutions, you have no shortage of options. However, here’s a scorecard with services to consider as you shop around:

Conclusion

It’s a crowded market for Linux backup solutions. But don’t make the mistake of thinking that one solution is as good as the next—or that a freeware solution deserves consideration simply because it won’t increase your IT budget.

To ensure that your business can meet its RTO and RPO, you need a full-system backup solution that enables you to restore to any hardware in minutes—not hours or days. Storix SBAdmin is that solution.

As we mentioned above, Storix only backs up Linux, Unix, AIX, and Solaris. But it provides the highest level of protection for these systems. So, if your organization is also running Windows or Mac servers, we believe you should implement Storix for Linux and a separate solution for Windows and Mac.

See why Honda, CVS, Kohl’s, Lockhead Martin, McKesson, Bridgestone and other leading companies rely on Storix for their Linux backup needs.

---

¹ https://www.crn.com/news/data-center/michael-dell-it-s-prime-time-for-public-cloud-repatriation
² https://www.networkworld.com/article/3615678/backup-lessons-from-a-cloud-storage-disaster.html
³ https://www.ibm.com/cloud/learn/backup-disaster-recovery#toc-dont-wait–HyEmAQNh

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.

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.

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.

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.

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.

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

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.

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.

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.