By Christine Taylor
-- Backup used to be simple in SMB environments: You slapped on your tape and autoloader, scheduled backup in the backup application, and set it to run. Occasionally you would test to see that it actually did run. Most of the time it worked; when it didn't you could troubleshoot the problem and make sure backup ran that night. No harm, no foul.
Those days are long gone. Backup remains a critical function but several factors contribute to making a once-simple process anything but.
Manage complex backup procedures. Backup used to be tape. Now it's tape/VTL/SAN/NAS /DAS/cloud, etc. Your choices depend on what you already own, what you're familiar with, if the data is primary or secondary, if the data is regulated and/or valuable, and how much time you actually have to spend on all this. Multiple applications require multiple backup procedures, which change depending on server locations, application types, data sizes, service level agreements (SLAs), and backup targets. There is nothing wrong with having multiple procedures, but the complexity makes it awkward to administer and verify.
Grapple with restore. If you want to restore from backup – which is the entire point – you must protect the backup. The most basic procedure is to store inactive backup tapes off-site, but this begs the question of quickly restoring priority data. Storing lower priority data off-site is fine, but you should keep critical data protected and close to hand for fast restores. This requires maintaining secondary sites that enable near-immediate restoration of critical data. However, this is an expensive proposition. Costs go down if you use commodity hardware at the secondary site, but this architecture is generally reserved for well-heeled enterprises because of the expense.
Application-centric backups. Different applications require different backup treatments, which traditional backup software may or may not easily support. For example, Oracle backup is different from VMware backup, which is different from SharePoint backup, which is different from file server backup. Your backup application should simplify this task for you with wizards, templates and built-in front-ends for these popular but challenging applications. This is difficult and time-consuming to write into a homegrown backup script, and traditional backup programs frequently lack important front-ends such as Oracle.
Common backup options
Let's look at several common choices for mid-size businesses and SMBs: 1) purchase a traditional backup product, 2) write your own backup scripts, 3) adopt open source backup, or 4) deploy an open source backup appliance.
Option A: Traditional backup
Traditional backup vendors are deeply entrenched in the enterprise. (Images of Star Trek's Borg implants come to mind.) Many of these installations have been in place for years even though they are often expensive, complex and built on proprietary code that requires a huge investment in development and maintenance work. Of course these costs are passed on to the customer, as are sales and marketing costs. As these applications expand and are upgraded, customers must adapt to the changes and purchase new features.
Sometimes the vendor lock-in is so profound that it is not worth it to rip-and-replace with a new backup product or procedure. But sometimes the incumbent's cost and complexity will make it worthwhile to look at other options. While making the choice, consider the costs associated with being locked into a proprietary format in the future. Of course, if you are not already locked into a given backup application then your options are wider. Traditional backup is a popular choice, but it is not the only choice.
Option B: In-house backup scripts
SMBs or remote business units in the enterprise may choose to write backup scripts for a variety of reasons: their IT staff likes writing scripts, they want to save money, they need to customize, and/or it's relatively easy.
Sounds good if you never grow. But assuming that growth is good, homegrown backup scripts can cause trouble. Script writers frequently start with a single application and base their backup script on native copy tools. So far, so good. However, once you spend the time to write one script you're duty bound to maintain it. And what happens as your backup script writing chores expand to other equally deserving applications? Now you're supporting a mix of applications, servers, RTOs, RPOs, and backup targets. And that's just to tape – What happens if you need to back up your test VMware environment? Or back up to a new VTL? Or even back up to the cloud? Your script-writing task was never supposed to consume your entire workday.
Option C: Do-it-yourself open source backup
One way to get around script-writing headaches is to adopt open source backup. This has advantages in that it gives you a ready-made code base and an active community of users and developers. And open source can be very inexpensive from a purchasing standpoint, to say the least. (Zero dollars is a fine price.)
Open source backup may be inexpensive to buy, but it's not necessarily cost-effective. You could run into some of the same issues as writing in-house backup scripts. You will still have to manually update your code with revisions to the core base, and will have to monitor community or in-house modules. You will have to adapt the code to serve the needs of disparate applications. You also have the problem of complexity if you expand the code to serve multiple backup targets and processes – all of which may not be very cost-effective in dynamic environments.
Option D: Open source backup appliances
Open source software comes with its own set of challenges, but it can serve as an excellent base for a backup appliance. In this option, you purchase a pre-configured backup appliance that is built on open source code. The open source roots keep purchase and ongoing fees low, and the appliance does the configuration and customizing for you. The appliance replaces disparate backup procedures and homegrown scripts with a centralized backup routine across multiple systems and applications. And unlike scripts or open source backup code, you are not on your own with customer service.
When looking at a backup appliance built on open source, here are some features and functionality to evaluate:
Ease of deployment and use. The system should be simple to set up using wizards, templates and application front-ends. A centralized console enables efficient administration and flexible scheduling such as backing up to disk and then tape, or backing up to cache and then scheduling backup to remote storage. The appliance should also be capable of backing up directly to the targets from the application servers and not depend on another backup applications' backup server.
Optimize application backup with pre-configured setups. The appliance should come with common application front-ends, including local drives and network shares, email servers, and databases. Examples include Oracle and virtualized formats such as OVF, VMX, and a wide variety of VMware formats. Simplified ongoing administration should include wizards and templates as well as a point-and-click user interface. The administration console should help IT to automate backup schedules optimized for different applications and media.
Support multiple media. IT should be able to easily choose different configurations to suit various applications and SLAs. The appliance should support multiple media, including the cloud and on-premise storage such as DAS, SAN, NAS, iSCSI, and tape drives. Scheduling should be highly flexible, allowing administrators to combine optimal media choices and backup configurations.
Security. Running every service plus the kitchen sink increases security vulnerabilities. The backup appliance should only run essential backup services and should automatically install all OS security patches. And if it backs up to the cloud as an option, it must maintain a robust firewall and encryption for data-in-flight.
Ongoing cost-effectiveness. You expect an open source appliance to have a low purchase price but it should not stop there. The appliance should offer ongoing hard and soft cost savings. Expect ongoing fees to be reasonable, as the backup vendor should be passing on open source cost savings to you. You save on soft costs because the simplified system relieves management overhead.
Open format. You need to keep your backup secure, but not at the cost of availability. An open backup format will enable you to access that data years from now without wondering a) how you're going to find a copy of that proprietary backup software again, or b) what on earth came of that backup appliance you are no longer using. An open format keeps you in control of your own backed up data.
Zmanda is a good example of an open source backup vendor. Zmanda already offers its Amanda Enterprise Edition (AEE) open source software, and is expanding by offering AEE in the form of an appliance. Zmanda worked closely with Novell's SUSE Appliance Program to develop the Zmanda Backup Appliance (ZBA) running AEE. ZBA's OS is SUSE Linux Enterprise. It is optimized to do one thing: back up and recover file systems and applications.
Expensive software or homegrown scripts are not IT's only backup choices. End users should consider open source-based backup appliances for simplicity, security, flexibility, and the ability to support complex backup environments.
Christine Taylor is an analyst with the Taneja Group research and consulting firm.