De Database Experts!
The data in your Oracle Databases are the crown jewels of your organization, without this data your applications will no longer work, and a large part or perhaps even your entire business operations will come to a standstill. It is therefore crucial to make sure that in all cases this data can be recovered in case the need arises. It is therefore a good idea for several reasons to integrate the Oracle Storage Cloud Service into your current backup procedure. In this article, the advantages and disadvantages of such an integration are successively discussed, as well as briefly touching on two scenarios about how such an integration can be realized in practice.
Storage in the Cloud is many times cheaper for small to medium-sized companies than on-premise SAN storage, the main reason being that you are only charged for the actual amount of storage that is purchased. See chart below:
Oracle also has an application on its website to calculate costs, see https://www.oracle.com/cloud/cost-estimator.html
As an indication, the prices for Object Storage on 30-06-2020 are listed below. Current prices can be found here .
Below is a calculation example; purchasing 10 TB of Database Backup in the Oracle Cloud costs roughly 47 euros on a monthly basis:
Many factors are involved in calculating what an average GB costs on an on-premise SAN (maintenance, raid levels, monitoring, maintenance contracts with suppliers, applying patches, personnel costs, end of life etc), but it is without more of a safe assumption to say that it is usually many times higher than the average price of a GB in the Oracle Cloud.
One unconscious click on a link in an email, or the opening of an attachment by an employee in your organization can nowadays already lead to your entire IT infrastructure, including fallback environment and backups, being encrypted and held hostage by ransomware, and as a result becomes completely or largely unusable. Examples of such scenarios and the dilemmas and problems this entails are unfortunately increasingly appearing in the media, and you will undoubtedly be familiar with them. This is why having off-site backups of your databases is so important.
This way you always have a backup of your database backups, an essential part of a solid and reliable backup strategy.
Oracle Cloud Storage integrates seamlessly with RMAN, the default backup and recovery tool for the Oracle Database, so minimal adjustments to your current backup scripts and procedures will be required to achieve said integration.
All data is stored encrypted by default, and there are no additional license costs involved (as is the case if you want to do / do this for your on-premise database backups). And you are the only one who can un-encrypt this data, there is no way for Oracle to view or read the data in your database backups.
You only pay for the amount of data that you actually store in the Oracle Cloud. This is in contrast to the storage on your SAN.
If your database backups sometimes go wrong, because disks are filling up, this is never an issue in the Oracle Cloud. Expanding backup file systems for the Oracle Database backups is not necessary in the Oracle Cloud, the amount of storage available for your database backups is in principle infinite.
If you regularly refresh your test databases with a copy of the production database, but this is still a manual operation with many steps and a long lead time, for example due to separate networks for your OTAP environment, even then the availability of a backup offers of your database in the Oracle Cloud, making this a more streamlined process. All that is then needed is internet access for the database servers in question to (only) the Oracle Cloud, this can be configured in the firewall via a whitelist.
If your organization is bound by legal obligations to store the content of certain databases for a longer period of time, for example a year or even a few years, Oracle offers the so-called Archive Storage option, which is also many times cheaper (and therefore slower). ) is then the Object Storage where the regular database backups end up. As a result, you no longer have to store these backups locally and store them in a safe place or archive them.
The costs for this form of storage are only 0.00233506 euros per GB per month on 30-06-2020, click here for the current prices. In this case, 10 TB of archive storage will cost you only 24 euros per month, see https://www.oracle.com/cloud/cost-estimator.html
The Oracle Cloud Storage is synchronized between three geographically separated independent data centers (so-called Availability Domains), so that the failure of an entire data center, or even two data centers, will not lead to unavailability of your Oracle Database backups.
However, it should be noted that Oracle’s recently opened data center in Amsterdam does not (yet) meet this requirement, so if this is a requirement for you, you can alternatively choose to store the data in the Oracle data centers in London or Frankfurt that do comply.
All forms of compression may be used for making your database backups, where with on-premise backups only the default standard compression is allowed (without purchasing the necessary license for this). In this way you can make maximum use of the available upload capacity of your internet connection, because the backup is first compressed to the maximum before it is uploaded to the Oracle Cloud. This also saves on the costs that are charged, since the database backups will take up less space.
As already mentioned, on-premise SAN storage is relatively expensive compared to storage in the Oracle Cloud, so if your SAN is almost constantly at its limit, or even needs to be replaced, then deploying Oracle Cloud Storage for your database backup ups are certainly an interesting proposition, with the added advantage that you also have off-site backups of your databases, something whose importance is often underestimated unfortunately.
If you regularly refresh your test databases with a copy of the production database, but this is still a manual operation with many steps and a long lead time, for example due to separate networks for your OTAP environment, even then the availability of a backup offers of your database in the Oracle Cloud, to make this a more streamlined process. All that is then needed is internet access for the database servers to (only) the Oracle Cloud, this can be configured in the firewall via a whitelist. In this way, the production database can be easily restored on a test server in one step.
Due to the low cost of storage in the Oracle Cloud, you can increase the retention of your Oracle Database backups if desired, so that for example you can also restore the database as it was 14 or even more days ago, where this parameter is set in practice. on premise environments with local SAN storage are usually 7 days or less.
If you now only make backups of your production databases due to lack of space, but it would actually be useful to also have backups available of your acceptance and test databases, then Oracle Cloud Storage can also be an interesting proposition, because of the low cost per GB.
If you have currently set up a fallback environment consisting of a primary and a standby database, you must pay license costs to Oracle for both of these databases. You can also choose to run your fallback database in the Oracle Cloud. In addition to the current location, you also write the archived logs (transaction logs) of your primary database to an NFS file system in the Oracle Cloud. Then you can, for example, start the standby database VM scripted automatically once every 24 hours, update it by applying the transaction logs, and then automatically stop it again.
In this way you no longer need to purchase a license for your standby database, because in the Oracle Cloud you only pay costs for running a database when it is actually up, rounded to the hour (so-called OCPU units). So if the standby database is updated in, say, 10 minutes after it has been started, and then stopped again, you will receive a bill from Oracle for using this database for 1 hour for that day. This quickly saves thousands if not tens of thousands of euros per year in license costs per year for your fallback environment.
DBA.nl has scripts available to set up and monitor such a configuration for you.
Obviously, there are also a number of drawbacks to integrating Oracle Cloud Storage into your current backup procedure. One of these is that making database backups to the Oracle Cloud will usually be slower than when they are made locally, since this depends on the upload speed of your organization’s internet connection. However, this can be fine-tuned to deal with this as efficiently as possible, so as already mentioned, maximum compression can be used for free so that less data needs to be uploaded than would normally be written locally. , and it is also possible to backup data files in parallel in pieces, see https://docs.oracle.com/en/cloud/paas/db-backup-cloud/csdbb/best-practices-optimize-cloud-backup-rates.html . In this way, a data file of, for example, 30 GB is chopped into pieces, and these are compressed in parallel, and also uploaded in parallel, instead of the entire data file being compressed first, and only then upload to the cloud.
Another disadvantage is that restoring a database from the Oracle Cloud will also be slower than when it is restored from local storage. If your internet connection is down, that is of course a problem anyway, no backups can be made to the Cloud, or databases can be restored from the Cloud.
It is also possible to purchase the so-called FastConnect option, so that there is always guaranteed a fast connection to the relevant data center of the Oracle Cloud, of 1 Gbit or 10 Gbit, but in practice this will mainly be useful for companies. with very large databases.
Broadly speaking, there are two possible scenarios for integrating Oracle Cloud Storage into your current backup procedure:
Option 1 of course has the major disadvantage that if for whatever reason you are temporarily unable to connect to the Oracle Cloud, you cannot make backups or perform restores.
Option 2 is therefore usually the wiser choice, with the additional advantage that you can reduce the retention of the backups you make locally to, for example, 2 days, in order to free up valuable space on your SAN that can then be used for other purposes. deployed. The retention for the backups that are in the Cloud can then be set to how it was for the local backups, or higher because of the lower costs.
DBA.nl is the all-round database expert specialized in setting up, maintaining and monitoring database environments. In addition, we provide advice and remove performance problems.
Since last June, we have switched to a working method based on customer teams within DBA.nl....
Details +
DBA.nl has launched a new service management system. The choice fell on Topdesk....
Details +
DBA.nl, the database experts, may continue to manage the database environment of RID de Liemers....
Details +