Author: Cord Oestmann
Earlier this month, Oracle announced the General Availability of the latest software release (23.1) of its flagship Database backup and recovery solution, the Zero Data Loss Recovery Appliance (RA for short). Rather than going through the key new features, I wanted to offer a commentary on some of those features that caught my attention in the first part of the release announcement. I recommend that you read the RA Product Management team’s Part 1 Blog on the release announcement for the features discussed below, or see the technical documentation in the latest Recovery Appliance Administrator’s Guide.
Arguably, the most high-profile feature is the introduction of the Space-Efficient Encrypted Backups. I have recently done quite a bit of research into compliance and the role of cyber security, and it won’t surprise anyone that effective data encryption is one of the most highly effective barriers against external malicious attacks; encrypted backups are useless for exfiltration purposes. However, using encryption to scramble data has also the less desirable side effect of reducing the effectiveness of data compression to reduce the storage footprint of data, with the ever-increasing size of data volumes, not an insignificant drawback. It is, therefore, a very welcome development to see data encryption being given prominence in the improvement of operational efficiency of the RA. In a nutshell, the RA and Oracle Database development teams have collaborated to provide an out-of-the-box mechanism to (decrypt,) compress and encrypt backup data. This works for both unencrypted or Transparent Data Encryption (TDE) encrypted databases and produces data in a format that allows the RA to operate as normal. The key benefits of this approach are:
- Encrypted backup data on the RA is stored much more space efficiently (estimated to be reducing the storage footprint of the data by a factor of 3).
- The reduced data footprint improves data backup and recovery rates as less data is traveling across the
backup network. - No changes are required to any of the RA and downstream functionality.
- The barrier/storage cost to adopting encryption as a standard for database backup data is reduced as less
storage is required per database. - Using the RA RMAN module on the database server to handle the compression, encryption, and decryption ensures a perfect separation of duties as it keeps the keys away from the RA.
This is all very helpful, and the fact that the functionality has already been in operation under production conditions for some months, as part of the Oracle Database Autonomous Recovery service in Oracle Cloud Infrastructure (OCI), where databases are TDE encrypted by default, provides additional reassurance for would-be adopters of the new functionality. This is particularly relevant when it comes to the question of the additional backup/recovery overhead on the database servers executing the encryption/compression/decryption steps, something that according to some informal feedback from within Oracle has proved acceptable in OCI (in the low single digit percentage, with the usual caveat that mileage will vary).
So far, so good, but as in many situations it is not just what is being announced that may interest or concern the user/practitioner, but what is not mentioned. Concentrating on the RMAN functionality is all very well, but what about any redo data that is being streamed from the source database? Depending on how busy your database is, this can represent a considerable amount of data to be stored. The short answer to the question is that there is no change to the current functionality for that part of the solution. This is due in part, I suspect, because that flow of redo data does not go through any further processing on the source database before being sent to the RA, unlike the backup data which passes through the RA Serial Backup Library (SBT) module in RMAN where RA specific functionality resides.
The other aspect to be mindful of is that this enhanced functionality is only available with Oracle Database versions 19c (19.18) or higher. The reason for that is that the functionality requires core Oracle Database changes, which have only become available in that version of the database. Arguably, this is a limitation entirely justifiable on the grounds that any earlier releases of the Oracle Database are already out of support but from personal experience I know only too well how many customers struggle to keep pace with the Oracle recommended upgrade schedule and get caught out by such restrictions.
The second feature described in the announcement blog is the extension of the Auto-tuned Reserved Space feature (first introduced in 21.1) to cover Immutable Backups. This is much more of a tidy-up of what might be seen as an operational anomaly or gap, i.e. the requirement to issue an admin-initiated command to reserve more space on the RA for immutable backups when capacity was still available on the appliance. Less of an issue if the RA administrator(s) look after a handful of databases, but certainly not operationally scalable. Note that this will not help with the situation where the whole of the appliance has run out of storage capacity – something a reasonably competent RA administrator should be able to avoid through pretty basic capacity management and the setting of threshold alerts. While the feature doesn’t itself grab the headlines, I think its significance is very much in re-enforcing the overall direction of the appliance’s operational model towards metadata-driven automation.
I hope you find these musings helpful and stay tuned for a similar discussion of some of the remaining new features, which will be presented by the RA Product Management team in Part 2 of their blog.
Interested to know more?
If these thoughts and observations have pricked your interest and you would like to better understand how Oracle Recovery Appliance can help to shape your Oracle Database backup and recovery and improve your operational resilience and cyber security posture, Contact Us.
Contact us today to arrange an assessment or email:
Cord Oestmann
Principal Solution Architect at Vertice
