Comparing Oracle Database Backup Service (ODBS) and Oracle Secure Backups (OSB) to Amazon Web Services (AWS)
This is part 3 of a 3 part series on "Getting Started with Oracle Cloud Backups".
- Part 1 covers setting up RMAN to backup directly to the new Oracle Cloud Database Backup Service (ODBS).
- Part 2 covers setting up RMAN to backup directly to the cloud using Amazon Web Services (AWS) Simple Storage Service (S3).
- Part 3 compares and contrasts the two services.
Overview
Oracle recently announced their Oracle Database Backup Service (ODBS) as part of their big push to the Cloud. However while the name is new, the technology really isn't. It's effectively just a re-brand of their Oracle Secure Backup Cloud Module which was introduced years ago, initially with the ability to backup to the Amazon Simple Storage Service (S3). The functional and non-functional differences are minor but are summarized in this article.
Use Case
Both services probably appeal mostly to small or medium sized business looking for off-site backups for whatever reason (such as DR or regulatory requirements). Keep in mind that a service like this probably isn't a full replacement for your onsite primary backup storage device. But it very well could replace your old-style off site backup or tape vaulting vendor, which usually involves a physical pickup of backup tapes and transportation to a storage location on a daily, weekly, or in some cases monthly basis. And while the restore times are certainly going to be considerably slower than restoring from on-premise disk based devices, it's undoubtedly faster than bringing back tapes from an offsite storage location through a vendor service (time of which is usually measured in days with ad-hoc recall requests often being at an additional expense). The specifics of how to technically get started with implementing either service is discussed in the
previous articles of this series.
Decision Criteria Checklist
Many factors come into consideration when deciding on whether to allow a business critical database to travel off-site and when selecting the appropriate vendor or service to do so. The following generic checklist is simply a guide of suggested criteria that one may consider:
- Storage costs (metered or flat rate; progressive or flat incremental rates)?
- Ease of installation (outages required or not)?
- Effects on internal processes (i.e. does the module need to be reinstalled when home cloning; changes to RDBMS software installation processes)?
- Ease of use?
- Changes required to existing scripts/processes (i.e. complicated changes to RMAN commands or scripts; changes or integration with 3rd party backup tools required)?
- Is backed-up data secured at rest (at vendor data center)?
- Is backed-up data secured in flight (transfer to or from vendor data center through the public internet)?
- Upload and download performance (is there an effect on Recovery Time Objectives)?
- Is transferring the additional data going to effect the organization internet performance or costs from their ISP?
- Additional licensing costs?
Pros and Cons
The answers to some of the above criteria quests are going to be site and/or database specific. Others have been discussed in more details in the other articles in this series. However, the pros and cons of each service can be summarized as follows:
| OSDB Pros |
OSDB Cons |
| No upfront costs (no additional licenses required) |
No security through keys/credentials - instead must use "users" correlated to actual named users and email addresses |
| Reasonable and competitive metered rates |
Navigating between services, accounts, and domains not as simple as it should be |
| Security at-rest and in-flight through mandatory encryption and HTTPS transfer |
WebUI doesn’t show details beyond overall "space used" (i.e. doesn't show files or per database space usage) |
| Advanced RMAN compression option included (without requiring the Advanced Compression Option) |
Can't specify Oracle data center used, just the key geographical region (i.e. North America) |
| Data is triple mirrored in Oracle Data Center |
No ability to replicate data between Oracle data centers |
| OSB & AWS Pros |
OSB & AWS Cons |
| Ability to create unique IDs and keys for each DB being backed up (credentials independent of named users) |
Requires licenses for the "Oracle Secure Backup Cloud Module", which is licensed on a RMAN per-channel basis |
| Billing calculator for easy cost estimation |
By default data is neither secure at-rest or in-flight (though both can be enabled) |
| Additional options with S3 such as more specific data center selection and cross-region replication |
|
It should be noted that while the Oracle Secure Backup Cloud Module is licensed on a
per "stream" or per RMAN channel basis, those RMAN channels are
not dedicated to one database. Rather, they are concurrently in-use channels. So if you had licenses for 10 "streams" (channels) those could be used by concurrently by 10 different databases each only using one RMAN channel or one database using 10 RMAN channels or any combination there of. And while both provide use of backup encryption and advanced compression options as part of "special-use licensing", it should be noted that these options are available only for the cloud based (or in the case of OSB, SBT based) backups. Regular disk based backups of the same database(s) would still require the Advanced Security Option for RMAN backup encryption and the Advanced Compression Option for anything other than "BASIC" RMAN backup compression. The AWS solution also provides (by default) the option of not securing the data at rest or in flight. Not encrypting RMAN backups is beneficial when trying to take advantage of storage based deduplication which is not relevant here. Hence I struggle to think of a strong business use case for not wanting to encrypt backups all else being equal? Similarly why one may want to choose HTTP over HTTP for critical business data?
Testing
One possible requirement may be the need to use both services concurrently for test/evaluation purposes. Fortunately, since the module (library, configuration, and wallet) files are all uniquely named, it's absolutely possible to use both services concurrently, even from within the same RMAN session. For example:
RMAN> run {
2> allocate channel odbs type sbt
3> PARMS='SBT_LIBRARY=libopc.so,SBT_PARMS=(OPC_PFILE=/u01/app/oracle/product/12.1.0/dbhome_2/dbs/opcCDB121.ora)';
4> backup tablespace users;
5> }
allocated channel: odbs
channel odbs: SID=270 device type=SBT_TAPE
channel odbs: Oracle Database Backup Service Library VER=3.15.1.16
Starting backup at 10-SEP-15
channel odbs: starting full datafile backup set
channel odbs: specifying datafile(s) in backup set
input datafile file number=00006 name=/u01/app/oracle/oradata/CDB121/users01.dbf
channel odbs: starting piece 1 at 10-SEP-15
channel odbs: finished piece 1 at 10-SEP-15
piece handle=2tqgq3t5_1_1 tag=TAG20150910T114021 comment=API Version 2.0,MMS Version 3.15.1.16
channel odbs: backup set complete, elapsed time: 00:00:15
Finished backup at 10-SEP-15
released channel: odbs
RMAN> run {
2> allocate channel aws_s3 type sbt
3> PARMS='SBT_LIBRARY=libosbws.so,SBT_PARMS=(OSB_WS_PFILE=/u01/app/oracle/product/12.1.0/dbhome_2/dbs/osbwsCDB121.ora)';
4> backup tablespace users;
5> }
allocated channel: aws_s3
channel aws_s3: SID=270 device type=SBT_TAPE
channel aws_s3: Oracle Secure Backup Web Services Library VER=3.15.7.14
Starting backup at 10-SEP-15
channel aws_s3: starting full datafile backup set
channel aws_s3: specifying datafile(s) in backup set
input datafile file number=00006 name=/u01/app/oracle/oradata/CDB121/users01.dbf
channel aws_s3: starting piece 1 at 10-SEP-15
channel aws_s3: finished piece 1 at 10-SEP-15
piece handle=2uqgq3un_1_1 tag=TAG20150910T114111 comment=API Version 2.0,MMS Version 3.15.7.14
channel aws_s3: backup set complete, elapsed time: 00:00:15
Finished backup at 10-SEP-15
released channel: aws_s3
RMAN>
However, if the wrong SBT library is being used by certain RMAN commands trying to access the backup pieces, the following RMAN error will be returned:
RMAN-06207: WARNING: 2 objects could not be deleted for SBT_TAPE channel(s) due
RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status
RMAN-06210: List of Mismatched objects
RMAN-06211: ==========================
RMAN-06212: Object Type Filename/Handle
RMAN-06213: --------------- ---------------------------------------------------
RMAN-06214: Backup Piece 2qqgq3ik_1_1
RMAN-06214: Backup Piece c-3847224663-20150910-01
The issue with the above example DELETE BACKUP command is resolved by simply allocating a channel using the proper library for the proper vendor. Running similar backups as the above commands but on an entire CDB (using the RMAN command "BACKUP AS COMPRESSED BACKUPSET DATABASE;") rather than just one tablespace in order to have a larger source or amount of data to process shows some interesting results:
SQL> SELECT status, input_type,
2 backed_by_osb, compression_ratio,
3 input_bytes_display, output_bytes_display,
4 input_bytes_per_sec_display, output_bytes_per_sec_display,
5 time_taken_display
6 FROM v$rman_backup_job_details
7 ORDER BY start_time;
STATUS INPUT_TYPE BAC COMPRESSION_RATIO INPUT_BYTES OUTPUT_BYTES INPUT_BPS OUTPUT_BPS TIME_TAKEN
---------- ------------- --- ----------------- -------------- -------------- -------------- -------------- ----------
COMPLETED DB FULL YES 6.60411404 4.47G 692.75M 1.59M 245.88K 00:48:05
COMPLETED DB FULL YES 6.60794224 4.47G 692.50M 1.96M 303.43K 00:38:57
The interesting points are:
- The backups to OSDB (top line in red) consistently took longer on my system than the backups to AWS (blue second line). Would need longer term testing to see whether this is an anomaly or a pattern. Backup performance time would need to be evaluated in detail when selecting a service.
- Both are recorded in the catalog as using OSB (the "backed_by_osb" column). This is no surprise as the OSDB module is simply a copy of the OSBWS module as is apparent by the API version numbers.
Conclusion
From an RMAN functional perspective the two are almost identical. As would be expected since the ODBS module and libopc.so library is essentially just a clone of the OSB module and libobws.so library. With a re-branding and slight modification simply to differentiate it and to conveniently provide Oracle an exemption from their own licensing requirements. Which is not uncommon from Oracle - after-all they do like to provide exceptions to themselves, allowing them to promote their products and services over their competition. From a data management perspective the Amazon S3 is far ahead with additional features, such as regional replication and more granular storage location options. Something Oracle very well may catch up on but at time of writing does not yet provide. Hence, I think the choice really comes down to priorities. Additional storage/data management options vs. additional licensing costs. For many smaller customers price is a key concern and therefore the Oracle solution likely preferable as essentially it is the same as the OSB & AWS solution but without the license requirement.
Discover more about our expertise in Oracle and Cloud.
