HyperBac Keys

JcheongJcheong Posts: 2
edited August 23, 2010 1:00AM in SQL HyperBac 5
Here are a few issues I have with the way HyperBac is searching for AES Keys.

By Design it, if AES Key is not available, which is default install, it will create one "AES_256.key" in default "C:\Program Files\Red Gate\HyperBac\keys".

Well, there is a lot of situation where database is not being restored at the same server, and a lot of cases that a single server is used to restore multiple databases from various servers.

HyperBac store the AES key filename into encrypted backup hbe files. For decryption, it look for the same key filename at the 1st level of the directory configured. It would be nice for it not to use key filename to decrypt. Instead, search all key files within the key folder and also include subfolder search.

That way, I can organize my keys like
C:\Program Files\Red Gate\HyperBac\keys\Server1_AES_256.key
C:\Program Files\Red Gate\HyperBac\keys\Server2_AES_256.key
where key filename change ok as long as the content of the key file has the right AES key


C:\Program Files\Red Gate\HyperBac\keys\Server1\AES_256.key
C:\Program Files\Red Gate\HyperBac\keys\Server2\AES_256.key
where key filname change is not ok, but, it search for subfolders for match


  • Options

    Thanks for your feedback. The way customers typically handle this is to synchronize one key across all machines which will need to share data with one another. For instance take a 'master' key from one system (eg a Log Shipping primary node) and copy it to the keys directory of all other systems where backups or restores will occur. Some customers which are providers for many other companies where the key sharing/synchronizing approach is not feasible, have handled this through scripting. But your point is taken and is something that will be investigated by the product team for future releases.
    Jeffrey Aven
    Product Management - HyperBac Technologies
    Red Gate Software
Sign In or Register to comment.