Monday, October 6, 2014

What The Walking Dead Teaches Us about Backup

If you’re a fan of the television series, The Walking Dead, you’re probably anticipating Season 5 starting October 12.

Rumor has it that things won’t be any better for our heroes this season. Could there be something after the zombie apocalypse? No one knows; but what we do know is that individual groups escaped from the prison after its downfall, attempting to survive as they follow a line of railroad tracks to a supposed safe zone named Terminus.

But could this plot also apply to enterprise backup?

Season 5 of The Walking Dead opens with the Termites holding Rick, Daryl, Michonne, and most of the others in a railroad car. But, like the Termites situation, is it possible that your data protection strategy is being held hostage?

For example: how do you protect large, high I/O, or non-Windows VMs with agentless backup?

While application-aware agentless backup seems ideal, it’s far from reality. If you don’t have permanent agents, you may have to deal with account management issues. This means setting Local Admin privileges for each and every VM. Wouldn't this become unmanageable as you scale your environment?

Further, if you run more than just Windows Servers, how do you backup Oracle, SAP, and DB2 in Linux or UNIX environments with Windows-only Volume Shadow copy services?

And what about capacity? How do you keep costs low if your backup software is highly dependent upon 3rd party hardware products for deduplication or separate software components to forecast storage consumption? Often, these costs are overlooked during a proof-of-concept.

Bottom-line: The Walking Dead teaches us to survive in the most extreme conditions. While you probably won't need to recover your data due to a zombie apocalypse, your backup strategy needs to be smarter than a mindless zombie. In the words of The Governor from The Walking Dead, "You can’t think forever. Sooner or later, you gotta make a move."

What’s your move?

Monday, September 29, 2014

A New Way to Think About Oracle Backups

It’s no secret that protecting Oracle Database systems can be complex. Companies often dedicate a team of Oracle database administrators (DBAs) to create, test, and schedule Recovery Manager (RMAN) scripts for backup, recovery, archiving, and business continuance.

But isn't there a better way?

Yes there is. And it doesn't matter if it’s a single instance, Real Application Cluster (RAC), or ExaData system. On-premise or in the cloud. Or both.

If you’re just beginning to build out a new Oracle Database environment, imagine:

  • Meeting (or exceeding) business service level agreements through tiered backup, restore, and archive with deep RMAN, RAC, and ExaData integration
  • Removing the need for DBAs to manage RMAN scripts

If expanding or upgrading Oracle Database, you can: 

  • Reduce complexity and speed protection by eliminating duplicate processes with integrated Oracle Log management
  • Avoid purchasing a separate archiving product

Finally, if your mandate is to “move to the cloud”, you can:

  • Reduce storage overhead by tiering infrequently accessed data to AWS S3, Glacier, or Microsoft Azure
  • Protect data starting from the source with in-stream encryption and then extend encryption to data “at-rest” in the cloud

This is the new way to think about Oracle data protection. Want to know more?

Monday, September 22, 2014

Why We Love to DASH (And You Should, Too!)

Nobody likes slow backups.

Take, for example, “Synthetic Full” backups. This type of backup allows for the creation of a new “full” backup image by combining a previous full backup with the associated incremental backups – essentially implementing an “Incremental Forever” strategy.

Generally speaking, a synthetic full means less time is needed to perform a backup and system restore times are reduced.

However, this is not always the case.

When you introduce deduplicated data with a standard synthetic full backup, it requires reading, rehydrating, and reduplicating; all of which is time-consuming and resource-intensive. So how do you reduce your backup time from several hours to just a few minutes?

Meet DASH (or, "Deduplication Accelerate Streaming Hash").

At its lowest level, Simpana software is just combining the previous backups (since all of the blocks of a DASH Full backup already live on the disk media). Simpana simply creates a backup image that has pointers to existing disk blocks, updates the reference counts of these blocks in the Deduplication Database (DDB), and updates the objects in the Index Cache.

This is fast. Very fast.

In fact, we see 90% less disk I/O and significantly fewer system resources being consumed on the Media Agent with DASH Full backups.

There's also absolutely no difference between a DASH Full and a regular full backup. In other words, restore operations are unaffected.

Bottom-line: we love fast backups. And we love dedupe. Together, we believe you'll love backups that are fast AND efficient. For more information, visit