HyperBac for SQL Server - Product FAQs

What is HyperBac for SQL Server and what does it do?

HyperBac is an enterprise backup, recovery, import and export solution, for your SQL Server databases developed by original developers of LiteSpeed.

Working with your existing backup techniques (TSQL, SQL Enterprise Manager, Management Studio, BCP or DTS), HyperBac uses high performance lossless compression to reduce the size of your backup data sets by up to 95% and the time taken to perform your backups by up to 75%.

HyperBac also delivers a breadth of unique differences including:

1.     Integrates seamlessly with native TSQL or Maintenance Plans.
2.     ZIP compatible format option gives customers true vendor independence
3.     Integrated AES encryption secures your online backups against theft or loss
4.     Backup Explorer module gives administrators the ability to SELECT * from backup, treating the backup file as an online read-only database. This delivers the capacity for granular recovery of date without costly restore operations.
5.     Seamless compression of trace file information for those customers looking to better and more efficiently meet SOX compliance requirements

The HyperBac benefit (and hence its capacity to scale to enterprise use) is that it provides the appropriate balance between maximizing compression, ensuring transaction throughput and minimizing operation times.

In practical terms, this means that HyperBac ensures a high transaction throughput during operation, no CPU bottlenecks and a shorter window of operation.

How does HyperBac for SQL Server deliver its compression?

Unlike alternate solutions such as LiteSpeed, SQL safe or SQL Backup, HyperBac for SQL Server has a zero touch deployment. This specifically means the following:

1.     No hooks or links into your SQL Server instances
2.     No extended stored procedures or command substitution

HyperBac simply installs on the server where your SQL Server instances are running and once installed, it simply listens for backup and restore traffic going to or from a destination that it is configured to recognize.

A HyperBac destination can be a file extension or just a directory. For example, by default HyperBac uses the .HBC file extension to compress the backup. Similarly the .ZIP extension will produce a compressed backup in ZIP format.

When SQL Server sends a backup stream to a HyperBac destination, then HyperBac will intercept that stream, compress it (according to the configuration used) and then let it go to disk.

The process is equally seamless and transparent when restoring the data.

How does HyperBac’s architecture benefit the database administrator?

There are many technical and commercial benefits that HyperBac delivers above and beyond existing solutions, such as LiteSpeed. Let’s consider three scenarios to help explain these advantages.

Standardization

Let’s say that you have 10 servers in you environment and you only intend to use HyperBac on 5 of those machines.

Your scripts are already defined and you do not want to manage two sets of scripts, one for those machines with HyperBac and one for those machines without HyperBac.

Well, you can consider the problem solved. Create one script to backup all your backups to a common destination (or file extension), lets say you create the .BAK extension as your standard.

Apply this script to all machines and where HyperBac is installed, configured and running the backups will be compressed. Where it’s not, the backups will be untouched.

Data Integrity

If HyperBac is not running, then your backups will still execute. You will simply get a native uncompressed backup file as a result. If you experienced the same issue with the likes of Litespeed, then it is more likely your backup operation will fail and you will not have an archive to turn to.

Version Control

Because HyperBac does not use command substitution or extended stored procedures, you are not tied to a specific version of SQL Server.

Let’s say for example that you are running SQL Server 2000 with a specific version of LiteSpeed. To upgrade to SQL Server 2005, then you’d need to upgrade your installation of LiteSpeed. This adds cost and time to the migration process.

If you were running HyperBac in the same situation, then you can simply upgrade to SQL Server 2005 and leave HyperBac untouched. This saves time, money and headache.

What else can I compress with HyperBac?

Because HyperBac is architected to work at the file system layer, it can integrate into many more operations than it’s competitors such as LiteSpeed for example.

1.     You can seamlessly compress logical operations such as bcp, DTS, SSIS etc.
2.     You can seamlessly integrate into native log shipping operations.
3.     You can seamlessly compress trace files
4.     You can seamlessly compress data replicated between two instances

This makes HyperBac the most extensible solution for SQL Server backup compression on the market today.

What technical advantages will HyperBac for SQL Server deliver?

Do more with existing infrastructure resources

Solution performance means that there is less contention for resources on the system(s) during backup operations. The advantage here is that you can avoid or avert the need to re-schedule or partition your backup operations to cater for end user requirements.

Similarly, as your data storage grows, so will your backup times. HyperBac gives you immediate relief from these growing pains.

No change management

As well as prolonging the value of your existing infrastructure. HyperBac also allows you to maintain existing procedures and scripts for as long as possible. The advantage there is no change management risk.

As importantly, you don’t have to hire specific skills to run the application or introduce unnecessary training to learn the solution. You continue to work with you native SQL Server tools.

Example:

Your backup window can no longer accommodate your nightly incremental backups. The issue is serious as other batch transactions such as general ledger consolidations and invoice runs cannot be re-scheduled or changed.

One unpalatable response to this situation is to split the backups and target different database objects for different nights. This means risk and greater loss of data in the event of disaster.

A far more appropriate option in this circumstance is to deploy HyperBac to reduce both your backup times to cater for the existing window. The additional benefit is that your backup will be significantly compressed, freeing physical storage resources as well.

Do I to change my existing backup scripts or methods?

No. Unlike every other third party SQL Server backup product on the market.

With HyperBac for SQL Server there are no extended stored procedures to implement, nor does HyperBac employ command substitution or maintenance plan conversion. It uses your actual scripts, jobs and procedures.

HyperBac's unique, ground breaking architecture is simply designed to work with your existing TSQL BACKUP scripts, BCP or DTS jobs or SQL Server Database Maintenance Plans. The only thing required is to configure HyperBac for your backup or export output file.

Example 1 - Working with specific file extensions

•     You perform a backup to a file called mybackup.bak

•     Just change the filename to any of:

       -   mybackup.hbc (to compress) or
       -   mybackup.hbe (to compress and encrypt) or
       -   mybackup.zip (to compress to ZIP format)

These are some of the default file extensions that are shipped with HyperBac for SQL Server. That is all that is required. Change the file extension and HyperBac will recognize it as a HyperBac backup operation. In fact, you can configure HyperBac to nominate any file extension you wish.

Example 2 - Working with specific directories or paths

Let's take the above example and say that you write your backups to the following path and file C:\mydatabase\backup\mybackup.bak

If you don't want to change your scripts at all, then you can configure HyperBac to recognize the path c:\mydatabase\backup. That means that all files written to that path (irrespective of their name or extension) will either be compressed and/or encrypted, depending upon what you choose.

That's it, no script or database maintenance plan conversion, command substitution or extended stored procedures to deploy.

Will I need to change my disaster recovery policies or procedures?

No. But it will give you options that you previously didn't have.

1.     By reducing your backup size you can keep more backups online. That gives your flexibility and options during recovery.
2.     Backup Explorer’s gives you SELECT from backup capability so that you can recover as little as one row of data without having to perform lengthy restore operations.
3.     Save time during recovery, because you won't have to rely on fetching tapes from off site locations.
4.     As importantly you can almost eliminate the inherent risk associated with failed tape media.

You'll also reduce risk. Why? Because you'll have more backup sets online and on your site, which can be validated at greater frequency. This is not always possible or feasible with off-site archives.

Will HyperBac for SQL Server impact the integrity of my database backups?

Not at all.

HyperBac works with the existing native interfaces to read and write data to and from your database. You are still running the native SQL Server commands (such as TSQL BACKUP or bcp.exe) at all times.

Therefore HyperBac does not interfere with normal database operation in any way. As importantly, HyperBac will operate independently of the database release you have deployed.

In fact HyperBac could give you the opportunity to improve backup integrity. Because your backup window will shrink by up to 70%, you will have the time to validate the backup after completion. This provides an additional layer of surety to your backup operations.

Where does HyperBac for SQL Server install?

HyperBac is a server side, service-based solution. It is deployed on the same machine that SQL Server is installed on. Importantly, nothing is installed within SQL Server and there are no components to manage or upgrade when you upgrade versions of SQL Server or install additional instances of SQL Server.

We use network storage to hold our backups, are we still able to use HyperBac?

Absolutely.

HyperBac for SQL Server is a disk based backup solution and it will seamlessly work with local or remote DASD, SAN or NAS devices.

Can I restore or import HyperBac created archives without HyperBac?

Yes, you have a number of options here.

As well as being able to restore HyperBac backups seamlessly using native SQL Server tools (RESTORE and bcp) on any server with HyperBac installed. You have three additional options.

1.     HyperBac provides a "free restore" policy for SQL Server, whereby machines which only do restores are licensed for free.
2.     HyperBac backups can be written directly to a ZIP compatible format, with performance equivalent to or better than all other solutions. This gives you complete third party vendor independence allowing you to migrate, extract and restore to any server of your choosing at any point in time on any system.
3.     HyperBac is shipped with royalty free command line and graphical extraction utilities which can be used to extract compressed or encrypted archives created with HyperBac at any time.

What operating system and SQL Server versions are supported?

HyperBac is supported for SQL Server 2000 and above, including full support for SQL Server 2000, SQL Server 2005 and SQL Server 2008. Supported operating systems are Windows Server 2003, Windows Server 2008, Windows 2000, Windows XP and Windows Vista (32 and 64-bit).

Does HyperBac for SQL Server support backups direct to tape?

Not at present. HyperBac for SQL Server is a high performance disk based backup product designed to perform compressed backups to local or remote DASD, NAS or SAN devices, which can then be ported to tape for offline storage or archival purposes.

Disk based backups provide database administrators with fast, reliable recovery online points. HyperBac's compression is superior to the hardware compression which is common on many tape devices, so a disk to tape backup strategy will generally yield a 50% reduction in tape storage costs as well as a 75-90% reduction in DASD, NAS or SAN requirements.