Forum Stats

  • 3,825,763 Users
  • 2,260,558 Discussions
  • 7,896,662 Comments

Discussions

How is this backup strategy ?

T.Boyd
T.Boyd Member Posts: 161 Blue Ribbon
edited Jan 15, 2020 2:26AM in Recovery Manager (RMAN)

DB version : 19c

OS : Oracle Linux 7.7

I have a 2-Node RAC DB which serves a critical payment processing application.

This DB is currently running on version 11.2.0.4 and it will be upgraded to 19c this week. It will be around 7 TB in size.

The RTO of this DB is only 5 hours. i.e. In the event of a DB loss, the business wants the Restore + Recovery of this database to be completed in 5 hours.

Following is what I am planning:

Retention policy        : Recovery window of 7 DaysIncremental Backup type : DifferentialBackup schedule :----------------Full Backup (L0) ---- > Monday and Thursday early morning 1:00AMIncremental (L1) -----> Remaining days morning 1:00 AM (Sunday, Tuesday, Wednesday, Friday and Saturday )Archive Log backup and purge every 5 hours ---->  1AM, 6AM, 10AM, 3PM and 8PM everydayBackup hardware :Dell EMC DataDomain Backup Appliance with sufficient throughput

Any suggestions/comments on Retention policy, backup type, schedule, ...etc ?

T.Boyd

Best Answer

  • Dude!
    Dude! Member Posts: 22,829 Black Diamond
    edited Jan 14, 2020 5:31AM Answer ✓

    20 TB/h is 20580 GB/h, which is 5,6 GB/s. That means your network (SAN) can do 45 Gbps. Do you have a 100 GBit network? I suggest you do a RMAN restore or duplicate database from backup to verify how long it actually takes despite the specs.

    FRA usually tends and requires to be larger than your database. As a rule of thumb, it should be at least 3 times the size of your database to have enough space for archive logs, flashback logs, and store at least 2 full backups. You don't want to delete the previous backup before you have a complete and successful new backup.

    If the database is important, I suggest you have a few old backups just in case, for example to recover from logical errors. RMAN checks for physical errors, but does not protect from logical data corruption - RMAN can, however, check and report logical corruption.

Answers

  • Dude!
    Dude! Member Posts: 22,829 Black Diamond
    edited Jan 14, 2020 2:05AM
    Dell EMC DataDomain Backup Appliance with sufficient throughput 

    What do you consider sufficient throughput?

    7 TB in 5 hours with conventional backup is technically possible, but very likely won't give you plan B in case of trouble. How does the database access the datafiles? Perhaps you can do RMAN incremental merge and periodically recover an image copy of the database with incremental level backups, hence you can switch the database to the copy in a matter of seconds. Keep in mind that a reliable backup solution should not rely on the same storage facility like your live database. Perhaps your business can use a standby database that does not rely on any of the hardware you use for the production system.

    T.BoydT.Boyd
  • AJ
    AJ Member Posts: 1,351 Silver Trophy
    edited Jan 14, 2020 4:05AM

    Did you meet the RTO objective when testing restore of this database?

    AJ

  • T.Boyd
    T.Boyd Member Posts: 161 Blue Ribbon
    edited Jan 14, 2020 4:53AM

    Thank You Dude.

    What do you consider sufficient throughput?

    This particular model of Data Domain backup appliance has been configured with an average throughput of 20TB/hr.

    By 'How does the database access the datafiles?' , I assume where my datafiles are stored.

    It is stored in Hitachi VSP SAN storage

    Your Incremental Merge approach seems good. My DB size is 7 TB (Maybe 7.5 TB including Online Redo logs, Control files, .. ).

    So, I need to create a FRA diskgroup of 7.5 TB for this . Right ?

    But, my Hitachi SAN storage is expensive . I need to check with the business if they can afford it.

    Is Incremental Merge approach commonly used in Production ?

    Hi AJ

    Did you meet the RTO objective when testing restore of this database?

    Yes. The restore + recovery completed in under 3 hours with the current DataDomain appliance which is an older model with less throughput.

    Once the upgrade of this DB to version 19c , this DB will be connected to a newer backup appliance with 20TB/hr throughput. So, the recovery should be faster.

  • Dude!
    Dude! Member Posts: 22,829 Black Diamond
    edited Jan 14, 2020 5:31AM Answer ✓

    20 TB/h is 20580 GB/h, which is 5,6 GB/s. That means your network (SAN) can do 45 Gbps. Do you have a 100 GBit network? I suggest you do a RMAN restore or duplicate database from backup to verify how long it actually takes despite the specs.

    FRA usually tends and requires to be larger than your database. As a rule of thumb, it should be at least 3 times the size of your database to have enough space for archive logs, flashback logs, and store at least 2 full backups. You don't want to delete the previous backup before you have a complete and successful new backup.

    If the database is important, I suggest you have a few old backups just in case, for example to recover from logical errors. RMAN checks for physical errors, but does not protect from logical data corruption - RMAN can, however, check and report logical corruption.

  • Manu Alphonse
    Manu Alphonse Member Posts: 74 Bronze Badge
    edited Jan 15, 2020 2:26AM
    Incremental Backup type : Differential 

    To make recoveries faster , use Incremental Cumulative rather than Incremental differential .

    But, this will be at the expense of longer L1 backup windows and more backup media space consumption.

    T.Boyd