How to stop worrying about backing up, or Oracle Zero Data Loss Recovery Appliance
Wait, wait. I did not write in the heading "How to do without backup." You can't do without backup, any freshman knows about it. But to forget about backup forever is, perhaps, the dream of any IT manager. But this dream still seemed unrealizable. Because even if your enterprise has a well-established backup, you remember it immediately after a big failure, and not a kind word. You will say not something like “It’s great that we have a backup every night,” but rather: “How many hours did it take after the backup?”
Let's see what the key goals of database backup are, and why none of the solutions that existed until now have met these goals.
Business requires that systems never lose business-critical data, and that redundancy does not affect the operation of business applications. Accordingly, solutions must ensure recovery of databases after failures.
')
But backing up the database requires a special approach, it is not enough to treat the database as a set of files. And therein lies the problem of traditional database backup solutions - they do not satisfy the need to protect critical data, because they view the database as a set of files that need to be copied, rather than as a transactional system with specific requirements for data integrity, performance and accessibility. Just copying the database files is not enough, because it does not guarantee the integrity of the database. After recovering from such a copy, the database may simply not open to users.
In addition, the traditional approach does not allow backing up data in real time so that it does not affect system performance. It is necessary to find temporary “windows” for backup — anywhere in the countries living in one or two time zones, but this, you know, is not about us. Moreover, it is not only that the volume of databases grows, as on steroids, but also the number of bases is multiplied uncontrollably. And how, it is asked, with such number of systems to create a uniform reservation policy? And the scaling of the backup system itself in such conditions becomes a hell.
So, we figured out, "who is to blame." We have three main problems - the risk of data loss when backing up databases in the form of files, a decrease in the performance of the enterprise information system due to backups, the difficulty of creating a centralized backup service due to the large number of corporate databases. We proceed to the question "what to do."
Oracle company solved this question simply and naturally. First, in order not to lose data and minimize the impact on performance, it is necessary to treat it as a transactional, rather than a file, system, and to reserve transaction logs. Secondly, in order to ensure scalability, the backup service must be provided with an appliance hardware and software system. The resulting solution, which provides redundancy without data loss, is called the Oracle Zero Data Loss Recovery Appliance.
Recovery Appliance protects all Oracle databases of your data center, supporting all editions, all versions of Oracle Database from 10.2 to 12.2 on any platforms. To ensure reliable database recovery, the Recovery Appliance constantly checks data integrity. Data Recovery is also being done by the Recovery Appliance, and backups to tapes, if it is practiced in your organization, will also perform the Recovery Appliance, freeing up your industrial servers for basic work. All that is needed to connect the database server to the Recovery Appliance is to install a backup and recovery utility called Recovery Manager (RMAN) on it. No additional software responsible for backing up data on the server side will work.
The Recovery Appliance also stores the Recovery Catalog - this is information about all backups made, it is needed for the incremental backup and restore procedures. After a full backup is performed, the DeltaPush process sends only database changes to the Recovery Appliance, which means minimal impact on the productivity of the working servers (Fig. 1). Transaction logs are reserved between increments.
Clear? The Recovery Appliance always stores the latest versions of databases, while minimizing the amount of information transferred from the database to the backup system. All tested and compressed database changes are located on the Recovery Appliance in a special storage called the Delta Store. With the help of the Delta Store Recovery Appliance, you can quickly recreate a complete copy of the database at any time, quickly adding up all the “deltas”. All this is managed through Enterprise Manager.
In addition, the Recovery Appliance can autonomously, asynchronously, copy data to tape and to the backup data center. There is no need to load working database servers, data is copied from the Recovery Appliance (Fig. 2). You can restore the RMAN database both from a Recovery Appliance, mainly or in a backup data center, as well as directly from a tape library.
The architecture, due to which unprecedented high speed of backup is achieved, is called Delta-Only. RMAN never backs up duplicate blocks, undo blocks for completed transactions, or unused blocks. Only changes are stored in Delta Store, only changes are replicated, data is compressed at the block level.
My favorite new term, which appeared thanks to the Recovery Appliance - "virtual full copy of the database." If you carefully read the beginning of the article, you already understood everything about it - first, a full backup is made only once, and then, thanks to incremental copies, the Recovery Appliance can re-create a “virtual full database” on the fly. At the same time, by saving transaction logs from the database directly in real time, zero data loss is provided (Fig. 3).
And this is not the same as the sum of a full copy with all incremental, cumulative and differential when using traditional systems. A full virtual copy combines the blocks of a full backup copy with incremental copies, i.e. just contains links to the right version of the blocks. As a result, it is equivalent to a full backup. Saving disk space and time - you know what. A complete virtual copy and transaction log since the last incremental backup make up the necessary and sufficient set for quickly restoring the database to any point in time. You will never have to do a full backup again; there is simply no point.
The actual process of restoring a file database is called “restore”, and the procedure for reflecting the latest changes from the transaction log in it is “recovery”. And since transaction logs are accumulated in the intervals between all incremental backups, you can quickly restore the database as of any time in the past. And you do not need, as before, to merge full and incremental copies, using working servers - the virtual backup contains links to all blocks, the necessary blocks are simply retrieved from Delta Store.
Recovery Appliance is configured, according to all good tone rules, by means of policies. Policies determine how many days you need to keep backup copies on disk, how many days on tape, how many days on backup data center. There may be several policies - for example, for noncritical, critical and most critical databases. The set of policies standardizes the entire backup policy in the enterprise (Figure 4). Thanks to this, it becomes very easy to manage the backup schedule - for example, if it suddenly turns out that you need to store backup copies of financial data for a month, not a month, you simply assign 365 days instead of 30 for the corresponding policy - and all the databases that are managed by this policy will have a new backup policy, which is very convenient. Recovery Appliance will keep statistics of disk subsystem utilization and forecast how long it will last.
Backup policies also determine for which data replicas need to be created in the backup data center, and for organizations that have several data centers, each of which has active databases, the replicas can be bidirectional (Figure 5).
For organizations with an extensive structure, a consolidation scheme is configured — the Recovery Appliance in each branch sends data to the Recovery Appliance in the main data center (Figure 6). Moreover, database recovery can be performed both from the main and backup Recovery Appliance - this may be required if one of the local data centers has failed.
It is very important that the management of the Recovery Appliance backup process, all databases, all replicas and copies to tape is managed through a single Enterprise Manager interface. All copies are registered in the Recovery Catalog, and the database administrator sees all the ways in which he can restore the database.
The basic package of the Zero Data Loss Recovery Appliance is called the Base Rack and consists of two servers that perform backups (each with five 10Gb Ethernet ports, two 40Gb InfiniBand ports, and optionally two 16Gb Fiber Channel ports for connecting a tape library), and three storage servers that store backups (each with twelve 4 TB disks with a rotation speed of 7200 revolutions per minute). The volume of disk storage, taking into account the mirror redundancy of blocks, is 42 TB. You can expand disk storage up to 18 storage servers, such a version is called Full Rack, or, in Russian, a full server cabinet with a storage capacity of 320 TB and backup speed is 12 TB / hour. This is enough, I suppose, to back up any database, and for backing up a large number of databases inside the data center, this hardware can be scaled up to Full Rack, or even up to 18 Full Rack 18 such cabinets with a backup speed of 216 TB / hour.
The system is running Zero Data Loss Recovery Appliance Software, which is licensed for each disk of storage servers. All other software, including Oracle Secure Backup, Oracle Database, Oracle Partitioning, etc. - unlike, say, a solution using Oracle Data Guard - you get a Recovery Appliance inside for free.
I highly recommend reading the materials under the links www.oracle.com/recoveryappliance , www.oracle.com/goto/ha and www.oracle.com/goto/maa .
And be sure to sign up for our online training.
Let's see what the key goals of database backup are, and why none of the solutions that existed until now have met these goals.
Business requires that systems never lose business-critical data, and that redundancy does not affect the operation of business applications. Accordingly, solutions must ensure recovery of databases after failures.
')
But backing up the database requires a special approach, it is not enough to treat the database as a set of files. And therein lies the problem of traditional database backup solutions - they do not satisfy the need to protect critical data, because they view the database as a set of files that need to be copied, rather than as a transactional system with specific requirements for data integrity, performance and accessibility. Just copying the database files is not enough, because it does not guarantee the integrity of the database. After recovering from such a copy, the database may simply not open to users.
In addition, the traditional approach does not allow backing up data in real time so that it does not affect system performance. It is necessary to find temporary “windows” for backup — anywhere in the countries living in one or two time zones, but this, you know, is not about us. Moreover, it is not only that the volume of databases grows, as on steroids, but also the number of bases is multiplied uncontrollably. And how, it is asked, with such number of systems to create a uniform reservation policy? And the scaling of the backup system itself in such conditions becomes a hell.
So, we figured out, "who is to blame." We have three main problems - the risk of data loss when backing up databases in the form of files, a decrease in the performance of the enterprise information system due to backups, the difficulty of creating a centralized backup service due to the large number of corporate databases. We proceed to the question "what to do."
Oracle company solved this question simply and naturally. First, in order not to lose data and minimize the impact on performance, it is necessary to treat it as a transactional, rather than a file, system, and to reserve transaction logs. Secondly, in order to ensure scalability, the backup service must be provided with an appliance hardware and software system. The resulting solution, which provides redundancy without data loss, is called the Oracle Zero Data Loss Recovery Appliance.
Recovery Appliance protects all Oracle databases of your data center, supporting all editions, all versions of Oracle Database from 10.2 to 12.2 on any platforms. To ensure reliable database recovery, the Recovery Appliance constantly checks data integrity. Data Recovery is also being done by the Recovery Appliance, and backups to tapes, if it is practiced in your organization, will also perform the Recovery Appliance, freeing up your industrial servers for basic work. All that is needed to connect the database server to the Recovery Appliance is to install a backup and recovery utility called Recovery Manager (RMAN) on it. No additional software responsible for backing up data on the server side will work.
The Recovery Appliance also stores the Recovery Catalog - this is information about all backups made, it is needed for the incremental backup and restore procedures. After a full backup is performed, the DeltaPush process sends only database changes to the Recovery Appliance, which means minimal impact on the productivity of the working servers (Fig. 1). Transaction logs are reserved between increments.
Clear? The Recovery Appliance always stores the latest versions of databases, while minimizing the amount of information transferred from the database to the backup system. All tested and compressed database changes are located on the Recovery Appliance in a special storage called the Delta Store. With the help of the Delta Store Recovery Appliance, you can quickly recreate a complete copy of the database at any time, quickly adding up all the “deltas”. All this is managed through Enterprise Manager.
In addition, the Recovery Appliance can autonomously, asynchronously, copy data to tape and to the backup data center. There is no need to load working database servers, data is copied from the Recovery Appliance (Fig. 2). You can restore the RMAN database both from a Recovery Appliance, mainly or in a backup data center, as well as directly from a tape library.
The architecture, due to which unprecedented high speed of backup is achieved, is called Delta-Only. RMAN never backs up duplicate blocks, undo blocks for completed transactions, or unused blocks. Only changes are stored in Delta Store, only changes are replicated, data is compressed at the block level.
My favorite new term, which appeared thanks to the Recovery Appliance - "virtual full copy of the database." If you carefully read the beginning of the article, you already understood everything about it - first, a full backup is made only once, and then, thanks to incremental copies, the Recovery Appliance can re-create a “virtual full database” on the fly. At the same time, by saving transaction logs from the database directly in real time, zero data loss is provided (Fig. 3).
And this is not the same as the sum of a full copy with all incremental, cumulative and differential when using traditional systems. A full virtual copy combines the blocks of a full backup copy with incremental copies, i.e. just contains links to the right version of the blocks. As a result, it is equivalent to a full backup. Saving disk space and time - you know what. A complete virtual copy and transaction log since the last incremental backup make up the necessary and sufficient set for quickly restoring the database to any point in time. You will never have to do a full backup again; there is simply no point.
The actual process of restoring a file database is called “restore”, and the procedure for reflecting the latest changes from the transaction log in it is “recovery”. And since transaction logs are accumulated in the intervals between all incremental backups, you can quickly restore the database as of any time in the past. And you do not need, as before, to merge full and incremental copies, using working servers - the virtual backup contains links to all blocks, the necessary blocks are simply retrieved from Delta Store.
Recovery Appliance is configured, according to all good tone rules, by means of policies. Policies determine how many days you need to keep backup copies on disk, how many days on tape, how many days on backup data center. There may be several policies - for example, for noncritical, critical and most critical databases. The set of policies standardizes the entire backup policy in the enterprise (Figure 4). Thanks to this, it becomes very easy to manage the backup schedule - for example, if it suddenly turns out that you need to store backup copies of financial data for a month, not a month, you simply assign 365 days instead of 30 for the corresponding policy - and all the databases that are managed by this policy will have a new backup policy, which is very convenient. Recovery Appliance will keep statistics of disk subsystem utilization and forecast how long it will last.
Backup policies also determine for which data replicas need to be created in the backup data center, and for organizations that have several data centers, each of which has active databases, the replicas can be bidirectional (Figure 5).
For organizations with an extensive structure, a consolidation scheme is configured — the Recovery Appliance in each branch sends data to the Recovery Appliance in the main data center (Figure 6). Moreover, database recovery can be performed both from the main and backup Recovery Appliance - this may be required if one of the local data centers has failed.
It is very important that the management of the Recovery Appliance backup process, all databases, all replicas and copies to tape is managed through a single Enterprise Manager interface. All copies are registered in the Recovery Catalog, and the database administrator sees all the ways in which he can restore the database.
The basic package of the Zero Data Loss Recovery Appliance is called the Base Rack and consists of two servers that perform backups (each with five 10Gb Ethernet ports, two 40Gb InfiniBand ports, and optionally two 16Gb Fiber Channel ports for connecting a tape library), and three storage servers that store backups (each with twelve 4 TB disks with a rotation speed of 7200 revolutions per minute). The volume of disk storage, taking into account the mirror redundancy of blocks, is 42 TB. You can expand disk storage up to 18 storage servers, such a version is called Full Rack, or, in Russian, a full server cabinet with a storage capacity of 320 TB and backup speed is 12 TB / hour. This is enough, I suppose, to back up any database, and for backing up a large number of databases inside the data center, this hardware can be scaled up to Full Rack, or even up to 18 Full Rack 18 such cabinets with a backup speed of 216 TB / hour.
The system is running Zero Data Loss Recovery Appliance Software, which is licensed for each disk of storage servers. All other software, including Oracle Secure Backup, Oracle Database, Oracle Partitioning, etc. - unlike, say, a solution using Oracle Data Guard - you get a Recovery Appliance inside for free.
I highly recommend reading the materials under the links www.oracle.com/recoveryappliance , www.oracle.com/goto/ha and www.oracle.com/goto/maa .
And be sure to sign up for our online training.
Source: https://habr.com/ru/post/258323/
All Articles