HyperBac for IBM DB2

HyperBac is an enterprise backup and archival solution, for your DB2 environment. Working with your existing backup techniques (BACKUP or EXPORT), Hyperbac uses high performance lossless compression to reduce the size of your backup data sets by up to 90% and the time taken to perform your backups by up to 50%.

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 operation window.

HyperBac works with the resultant backup information stream and thus it seamlessly integrates with DB2's native backup procedures. To that extent, the database administrator does not need to change their existing scripts or deal with another application layer to use HyperBac.

As importantly, HyperBac does not directly read or write data from or to your DB2 database, therefore you can be assured of information integrity at all times.

In addition archive files created by HyperBac can be converted to native backup files (physical or logical) at any time on any system, offering peace of mind for customers as well as a viable alternative recovery path should the restore or import occur on a system which does not have HyperBac installed.

Last but certainly not least, HyperBac has integrated AES (128/192/256 bit) encryption to protect your backup sets.

HyperBac for DB2 delivers a number of technical advantages. 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.

As your data storage grows, so to will your backup times. HyperBac gives you immediate relief from these growing pains. 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 reduced change management risk and need for support.

Consider the following simple 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.

Not at all.

HyperBac for DB2 is simply configured to work with your existing scripts or with DB2 Command Center wizards. Integration is as simple as follows.

Let's say that you write your backups to the following path /mydatabase/backup/

You can configure HyperBac to recognize the path /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.

No.

But it will give you options that you previously didn't have. By reducing your backup size you can keep more backups online. That gives your flexibility and options during recovery. As importantly, it saves you time during recovery, because you won't have to rely on fetching tapes from off site locations.

You'll 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. As importantly you can almost eliminate the inherent risk associated with failed tape media.

Not at all.

HyperBac works with the existing native tools to read and write data to your database. For example, if you are using the Command Center wizards, then all you need to do is point your backup output to a HyperBac recognized path. The fact remains that you are still running the DB2 BACKUP or EXPORT command 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.

HyperBac is a server side solution, deployed on the same machine as your actual database instance.

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

Not at present.

HyperBac for DB2 fully supports all methods of disk based database backups and exports, which produce compressed disk images which can then be moved on to tape for archival or offline storage 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.

Yes, and it is absolutely free.

HyperBac is shipped with an extractor utility, which is a simple command line utility for Linux and Unix installations. Similarly, it is available as a graphical tool as well as a command line utility for Windows installations.

In short, the extractor allows you to take an existing HyperBac backup and transform it into the native database format. There are many benefits to this facility.

1. You can transport compressed and/or encrypted backups (securely and without unnecessary bandwidth demand) to remote sites and then simply use the extractor utility to transform the backup set to native format. This has application to those who replicate testing or development environments.

2. The extractor utility can expedite and lower the cost of server migrations or consolidations.

3. The extractor also serves to give you peace of mind. You can continue to work with HyperBac backup sets irrespective of whether or not the product is deployed. In short, we recognize the importance of vendor independence as much as you.

These are just three examples; however there are many more that simply depend upon your imagination and business circumstance.

HyperBac for DB2 delivers results in an improvement in transaction throughput by up to 10 times during the backup process in contrast to comparable conventional backup operations. This is due to the substantial reduction in write disk I/O during the HyperBac backup process.

With regard to performance on DB2 systems, HyperBac delivers significant compression and takes no more time than the native BACKUP process. Similarly, HyperBac delivers greater compression (up to 30% more) than the native BACKUP compression and performs its operation in 50% of the time.

Simply use the API's as you had before, but without the DB2BACKUP_COMPRESS flag. All that you need to do is write the backup to a path that is registered by HyperBac.

No. This is a specific requirement of the DB2 native process. In fact, you don't have to worry about the compression library or what it means to your process when using HyperBac.

To use HyperBac, use the DB2 BACKUP command or db2backup API and write the backup to a path that is recognized by HyperBac. Compression and encryption (the latter is not available within DB2) is seamlessly delivered.

This also removes the risks and issues faced when performing a DB2 compressed restore to a different server. Circumstances have arisen where the target compression library did not match that used during the DB2 compressed backup, hence causing issues. With HyperBac, this is not an issue or hindrance to you.

The DB2 BACKUP and RESTORE commands are single platform commands. That is, if you have backed up on Solaris, then you must restore to Solaris.

There are alternative DB2 methods to allow you to migrate or restore across different hardware platform, but they are much slower in comparison.

By using HyperBac, you can backup using the DB2 BACKUP command to a HyperBac enabled path or directory (giving you significant compression and encryption) and then migrate and restore the data on an alternate server.

In all cases you are using the DB2 BACKUP and RESTORE commands. You can also take advantage of the HyperBac Extractor utility if the destination server is not licensed for HyperBac.

Yes.

You can backup any object level that DB2 permits you to backup or export using HyperBac. You will achieve the same benefits for compression and encryption as you would for physical HyperBac backup operations.

Yes.

Using HyperBac does not limit the type of backup you perform, the media to which you write it or the vehicle you use to perform the operation.

The points to consider when you make this decision are that HyperBac does not disrupt your existing processes when deployed. Similarly, HyperBac delivers greater compression than the native DB2 BACKUP command, allows you to continue using the native command, offers encryption as a value add and lastly, HyperBac backups can be restored across different hardware platforms, which is also a value add for DB2.

HyperBac for DB2 supported DB2 7 and above.

You can deploy HyperBac for DB2 on Windows 2000 and above, Solaris 8 - 10 and all Linux distributions (2.4 kernel level and above).

HyperBac for DB2 is licensed by the physical server. That is, the machine(s) on which you are running your database instance. HyperBac is essentially priced and licensed to give you exceptional value for money and pay back it's investment in months.

Let's quickly explain what HyperBac does NOT impose upon you.

1. No additional charges are required for the number of databases or instance on the server.

2. No additional charges are required in accordance with the size of your backup. Whether its 1 gigabyte or 20 terabytes then the investment is the same.

HyperBac for DB2 is designed to save you money and time. The licensing model is also designed to reflect that ideal.

No need to.

Just as HyperBac works with the native DB2 commands such as the BACKUP and RESTORE, it will equally work with other agent based products such as Tivoli Storage Manager (TSM). If your present backup solution writes to disk, then HyperBac will simply integrate with it without you having to change the application or underlying infrastructure.

HyperBac for DB2 is not designed to displace existing backup techniques rather it is designed to enhance them.

HyperBac for DB2 contributes to a better operational environment for your business. For you, this means lowering the cost of managing your database environment. That could include reduced tape usage; smaller infrastructure requirements, lower support costs and/or deferred infrastructure spend.

Further to this, HyperBac gives you greater surety. By reducing you backup size and window, you can eliminate contention with processes that compete for scarce system resources. Such tasks may include nightly financial batch operations or end user access for transaction processing. With HyperBac you will not have to shuffle resources to meet your backup objectives. More online recovery points also give you surety with regard to the restore process and for disaster recovery planning.

With regard to your customers (whether they are internal or external) HyperBac helps ensure that your existing infrastructure will continue to meet stated service levels for performance and access. That ultimately means greater customer satisfaction and retention.

From a commercial viewpoint, HyperBac is designed to provide you with significant savings on your backup operations. These savings may include, but aren't limited to; lower tape usage, reduced support or personnel costs or even deferred investment in infrastructure spend to accommodate data growth.

HyperBac for DB2 is priced such that it delivers a payback within months just on the savings you redeem on tape usage alone.