Oracle RMAN Backup And Restore

RMAN: (Oracle 8)

RMAN (Recovery Manager) is a utility provided by Oracle Database to perform backup, restore, and recovery operations.
It is a command line tool.

Features of RMAN in Oracle 19c

Comprehensive Backup Capabilities:

Full and incremental backups.
Block-level backups for efficient data storage.
Archived redo log backups.
Fast Recovery Area (FRA) integration for centralized backup storage.

Efficient Recovery Options:

Point-in-time recovery (PITR).
Complete and incomplete recovery.
Flashback database capabilities for quick undo of changes.

Multitenant Database Support:

RMAN fully supports container databases (CDBs) and pluggable databases (PDBs).
Provides flexibility to back up and recover individual PDBs or entire CDBs.

Automatic Space Management:

Manages disk space in the FRA.
Automatically deletes obsolete backups and archived logs.

Data Deduplication and Compression:

Backup optimization through block-level deduplication.
Built-in compression algorithms to reduce storage requirements.

Encryption and Security:

Transparent data encryption (TDE) support for securing backups.
Password-protected backups to ensure secure access.

Cross-Platform Transportable Backups:

Enables transferring backups between platforms with different endianness.
Useful for migrations and hybrid cloud environments.

Integration with Oracle Data Guard:

Seamless integration for managing backups in primary and standby environments.
Simplified switchover and fail-over operations.

Parallelism and Scalability:

Parallel backup and recovery operations to improve performance.
Supports large databases and complex environments.

Incremental Backup Merging:

Merges incremental backups into image copies for faster recovery.
Reduces the need for repeated full backups.

Advanced Monitoring and Reporting:

Provides detailed backup and recovery reports.
Integration with Oracle Enterprise Manager for centralized management.

Support for Cloud Environments:

Direct integration with Oracle Cloud for backing up to Object Storage.
Simplified migration of on-premises backups to the cloud.

RMAN Architecture:

 

 

 RMAN Architecture Components

RMAN Client:

• The interface (command-line or GUI) where RMAN commands and scripts are executed.
• Communicates with the target database to perform backup, recovery, and maintenance tasks.
• Can also be used via Oracle Enterprise Manager (OEM) for a GUI-based interaction.

Target Database:

• The database being backed up or restored.
• RMAN connects directly to the target database instance to perform its operations.

Recovery Catalog (Optional):

A separate schema in an Oracle database that stores RMAN metadata, such as backup records, scripts, and configurations.

Benefits of using a recovery catalog:

• Centralized management of RMAN metadata for multiple databases.
• Enables storage of historical data beyond the retention of the target database control file.
• Provides a backup script repository.

RMAN Repository:

Contains metadata about RMAN backups, including:

• Backup file locations.
• Backup completion times.
• Database structural information.

Stored either in:

• Control File: Default location within the target database.
• Recovery Catalog: A dedicated repository in another Oracle database (optional but recommended for large or complex environments).

Media Management Layer (MML):

Interfaces with third-party backup tools (e.g., for tape storage or cloud storage).
RMAN uses Oracle’s SBT (System Backup to Tape) interface to integrate with MML.

Fast Recovery Area (FRA):

A designated disk location for RMAN backups, archived redo logs, and other recovery-related files.
Simplifies file management by automating the retention and deletion of obsolete files.

Auxiliary Instance:

A temporary database instance used for certain RMAN operations, such as:

• Database Duplication: Creating a clone of the database.
• Tablespace Point-in-Time Recovery (TSPITR): Recovering individual tablespaces without affecting the rest of the database.

Workflow of RMAN Architecture

Connection Establishment:

RMAN connects to the target database, auxiliary instance (if applicable), and optionally to the recovery catalog.

Command Execution:

RMAN commands are issued from the RMAN client.
Commands are translated into SQL operations that interact directly with the Oracle database engine.

Metadata Updates:

RMAN records metadata about backups and recovery operations in the control file or recovery catalog.

Backup Storage:

Backup data is stored in:

• Disk (e.g., FRA or external storage).
• Tape (via MML integration).
• Cloud storage (e.g., Oracle Cloud Object Storage).

Recovery Operations:

During recovery, RMAN reads the metadata repository to locate and restore backup files.
It automates the restoration of datafiles, control files, and archived redo logs as needed.

RMAN Logical Components

Channels:

Logical connections used by RMAN to read/write to/from storage devices.

Types of channels:

• Disk Channels: For disk-based backups.
• SBT Channels: For tape or cloud-based backups via MML.

Channels can be configured for parallelism to improve performance.

Backup Sets and Image Copies:

• Backup Sets: Compact RMAN - specific format that includes one or more datafiles.
• Image Copies: Exact byte-for-byte copies of database files, useful for fast recovery.

Control File Auto-backup:

Ensures that critical RMAN metadata is automatically backed up in the control file.

Integration with Other Oracle Features

Automatic Storage Management (ASM):

RMAN works seamlessly with ASM to manage database storage and backups.

Oracle Data Guard:

RMAN supports backup and recovery operations in primary and standby databases.

Oracle Enterprise Manager (OEM):

Provides a GUI interface for RMAN operations, simplifying management and monitoring.

Flashback Technology:

RMAN integrates with Flashback Database for fast point-in-time recovery.

RMAN Modes:

1.Catalog Mode:

Uses a Recovery Catalog to store RMAN metadata.

2.No-Catalog Mode:

Relies on the Control File of the target database to store RMAN metadata.

1.Catalog Mode

In catalog mode, RMAN metadata (e.g., backup details, configuration, and scripts) is stored in a Recovery Catalog, which is a dedicated schema in a separate Oracle database.

Advantages:

Centralized Management:

A single recovery catalog can manage RMAN metadata for multiple databases.

Historical Metadata:

Maintains backup metadata beyond the control file’s retention period.
Useful for long-term archival and auditing purposes.

Resilience:

Recovery catalog acts as an additional repository for metadata, ensuring RMAN metadata is available even if the control file is lost or overwritten.

Storage of RMAN Scripts:

You can store RMAN scripts in the recovery catalog, making it easier to reuse and manage complex scripts across databases.

Support for Cross-Database Backup Management:

Especially useful in environments with many databases or Data Guard configurations.

Enhanced Reporting:

Provides detailed reporting on backup history, especially for databases with long retention periods.

Disadvantages:

Additional Maintenance:

Requires setting up and maintaining a separate database/schema for the recovery catalog.

Dependency on the Recovery Catalog:

If the recovery catalog is unavailable or corrupted, it could impact operations. However, RMAN can still work with the control file as a fallback.

Resource Overhead:

Slightly increases resource usage due to the need to manage and query an additional repository.

2.No-Catalog Mode

In no-catalog mode, RMAN metadata is stored in the Control File of the target database. This is the default mode when no recovery catalog is configured.

Advantages:

Simplicity:

No additional setup is required. RMAN uses the control file by default.

Low Overhead:

No need to allocate resources for a separate recovery catalog database/schema.

Suitable for Smaller Environments:

Works well for databases with simpler backup and recovery needs.

Quick Start:

Ideal for environments where backups need to be set up quickly without configuring additional components.

Disadvantages:

Limited Metadata Retention:

The control file has a finite size, and older metadata is overwritten when space runs out.
Backup history is lost if metadata is overwritten.

No Centralized Management:

Each database maintains its own metadata, which can complicate management in multi-database environments.

Vulnerability:

If the control file is lost and there’s no recovery catalog, RMAN metadata is irretrievably lost unless restored from a backup.

No Persistent RMAN Scripts:

Cannot store and reuse RMAN scripts in no-catalog mode.

RMAN:

• No Archivelog
• Archivelog

Step 1: enable the archive:

shut immediate
startup mount
alter database archivelog;
alter system set log_archive_dest_1='location=/u01/app/oracle/oradata/pearl/arch/' scope=both;
alter system set db_recovery_file_dest_size=10g scope=both;
alter system set db_recovery_file_dest='/u02/backup' scope=both;
alter database open;

Step 2:

[oracle@localhost ~]$ . .env_chennai
[oracle@localhost ~]$ rman
RMAN> connect target /

RMAN Configuration:

RMAN> SHOW RETENTION POLICY;
RMAN> SHOW RETENTION POLICY FOR DB_UNIQUE_NAME ALL;
RMAN> SHOW DEVICE TYPE;
RMAN> SHOW DEVICE TYPE FOR DB_UNIQUE_NAME prod3;
RMAN> SHOW DEFAULT DEVICE TYPE;
RMAN> SHOW CHANNEL;
RMAN> SHOW MAXSETSIZE;
RMAN> SHOW BACKUP OPTIMIZATION;
RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
RMAN> SHOW CONTROLFILE AUTOBACKUP;
RMAN> SHOW COMPRESSION ALGORITHM;
RMAN> SHOW ENCRYPTION ALGORITHM;
RMAN> SHOW ALL FOR DB_UNIQUE_NAME ALL;
RMAN> SHOW ALL FOR DB_UNIQUE_NAME 'STANDBY';
RMAN> show all;

1.Retention Policy

Redundancy: Retains a specified number of backups.

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

Recovery Window: Retains backups needed for recovery within a specified number of days.

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

No Retention Policy: To retain all backups indefinitely:

CONFIGURE RETENTION POLICY TO NONE;

2.Default Device Type

Disk: Backups are written to disk.

CONFIGURE DEFAULT DEVICE TYPE TO DISK;

Tape: Backups are written to a tape device.

CONFIGURE DEFAULT DEVICE TYPE TO SBT_TAPE;

3.Parallelism

Controls the number of channels (threads) used for backup or restore operations.

Disk Parallelism:    Enable 4 parallel channels for disk backups.

CONFIGURE DEVICE TYPE DISK PARALLELISM 4;

Tape Parallelism:     Enable 2 parallel channels for tape backups.

CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 2;

4.Control File Auto-Backup

Enables automatic backup of the control file and SPFILE.

ON: Automatically backs up the control file.

CONFIGURE CONTROLFILE AUTOBACKUP ON;

OFF: No automatic backup.

CONFIGURE CONTROLFILE AUTOBACKUP OFF;

Set Auto-Backup Format:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/control_%F';

5.Backup Optimization

Skips files that are already backed up and unchanged.

ON: Enables optimization.

CONFIGURE BACKUP OPTIMIZATION ON;

OFF: Disables optimization.

CONFIGURE BACKUP OPTIMIZATION OFF;

6.Compression

Compresses RMAN backups to reduce storage requirements.
Compression Algorithms: BASIC, LOW, MEDIUM, HIGH.

Enable Compression:

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE COMPRESSION ALGORITHM 'BASIC';

Disable Compression:

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET;

7.Encryption

Encrypts backups to secure sensitive data.

• Transparent Encryption: Uses Oracle Wallet.
• Password Encryption: Requires a password.
• Dual Mode: Combines transparent and password encryption.

Transparent Encryption:

CONFIGURE ENCRYPTION FOR DATABASE ON;

Password Encryption:

SET ENCRYPTION ON IDENTIFIED BY 'password';

8.Archive Log Deletion Policy

Specifies when archive logs can be deleted.

• BACKED UP: Deletes logs after a specific number of backups.
• APPLIED ON STANDBY: Deletes logs after they are applied on standby.

Delete Logs After Backup:

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;

Disable Deletion Policy:

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

9.Snapshot Control File

Specifies the location of the snapshot control file used during backups. Ensures backups run smoothly even with frequent structural changes.

Set Custom Location:

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/backup/snapshot_control.f';

10.RMAN Channels

Configures channels for backup and restore operations. Backups are stored with a unique name in the specified location.

• Manual Configuration: Specifies specific channels.
• Parallelism Configuration: Sets default parallelism.

Configure Channel:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/%U';

Allocate Channel Temporarily:

ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup/temp_%U';
BACKUP DATABASE;
RELEASE CHANNEL c1;

11.Default Backup Format

Specifies the naming format for backup pieces.  Generates uniquely named backups with database name and timestamp.

Set Custom Format:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/%d_%T_%U.bkp';

12. Duplexing Backups

Creates multiple copies of backup sets.

• Single Copy (Default): Creates one copy.
• Multiple Copies: Creates up to 4 copies.

Enable Duplexing:

CONFIGURE BACKUP COPIES FOR DEVICE TYPE DISK TO 2; // Stores two copies of each backup for added redundancy

13. Debugging and Logging

Logs RMAN output to a file for troubleshooting.

Enable Logging:

rman target / log=/backup/rman_log.log

RMAN Commands:

How to connect RMAN

Run .bash_profile (OR) Environment Variable

Connecting RMAN with ControlFile Recover

rman target /

Connecting RMAN with Recovery Catalog

rman target / catalog rc_user/rc_user_password@rc_tns_name

How to connect CDB and PDB in RMAN

Connect to the ROOT CDB:

rman target=/

Connect to PDB:

rman taget=sys@pdb_name

BACKUP Commands:

Full BACKUP CDB and Non-CDB Level:

backup database;
backup database plus archivelog;

Take backup on differen location: use- format '/backup/%U'
Like:

backup database plus archivelog format '/backup/%U';

Full BACKUP ROOT-CDB Only

backup database root;
backup database root plus archivelog;

Full BACKUP PDB Level:

backup pluggable database pdb1,pdb2 plus archivelog;

Incremental Level 0 BACKUP:

backup incremental level 0 database plus archivelog;

Incremental BACKUP for ROOT-CDB:

backup incremental level 0 database root plus archivelog;

Incremental BACKUP for PDB Level:

backup incremental level – pluggable database pdb1,pdb2 plus archivelog;

Incremental Level 1 BACKUP:

backup incremental level 1 database plus archivelog;

Incremental BACKUP for ROOT-CDB:

backup incremental level 1 database root plus archivelog;

Incremental BACKUP for PDB Level:

backup incremental level 1 pluggable database pdb1,pdb2 plus archivelog;
(OR)
backup incremental level 1 pluggable database pdb1 plus archivelog;

Tablespace Level BACKUP:

backup tablespace system;

Tablespace Level BACKUP-PDB:

backup tablespace pdb1:system;

List out the Datafile number and location

report schema;

Data file BACKUP:

backup datafile 32;

Archive Log BACKUP:

backup archivelog all;

Delete the BAckup:

delete backup tag tag_id;
delete noprompt backup tag tag_id;

Restore and Recovery Commands:

Recover the SPFile:

restore spfile from 'take lastest control file backup piece';

Recover the ControlFile:

restore controlfile from autobackup; –AUTOBACKUP OF CONTROL FILE IS ENABLED
restore controlfile from 'take lastest control file backup piece'; –use Backup piece

Restore and Recover the Full Database from Full Backup:

restore database;
recover database;

Restore and Recover the Full Database from Level 0 and Level 1 Backup:

restore database from tag='level 0 backup tag';
recover database from tag='level 1 backup tag';

Point in time Recovery in Tablespace:

recover tablespace tbs_name until time "to_date('2024-10-15 12:20:30','YYYY-MM-DD HH24:MI:SS')";

Point in time Recovery in Table:

recover table muthu.emp until time "to_date('2024-10-15 12:20:30','YYYY-MM-DD HH24:MI:SS')";