Skip to content

RMAN BACKUP

    Recovery Manager (RMAN) is fully integrated with the Oracle Database to perform a range of RMAN Backup and Recovery activities

    Backing Up a Database

    The BACKUP command backs up all data files, the current control file, the server parameter file, and archived redo log files to the default storage device:

    % rman
    RMAN> CONNECT TARGET /
    RMAN> BACKUP DATABASE PLUS ARCHIVELOG;

    Backing Up a Sparse Database

    This example uses the BACKUP command to backup a sparse database in the backup set format and the archive log.

    RMAN> BACKUP AS SPARSE BACKUPSET DATABASE PLUS ARCHIVELOG;

    Backing Up Multiple PDBs

    This example connects to the root using operating system authentication and then creates backups of the PDBs hr_pdb an sales_pdb.

    %rman
    RMAN> CONNECT TARGET /
    RMAN> BACKUP PLUGGABLE DATABASE hr_pdb, sales_pdb;
    

    Performing a Cumulative Incremental Backup

    This example backs up all blocks changed in the database since the most recent level 0 incremental backup. If no level 0 backup exists when you run a level 1 backup, then RMAN makes a level 0 backup automatically. Any inaccessible files are skipped.

      BACKUP 
      INCREMENTAL LEVEL 1 CUMULATIVE
      SKIP INACCESSIBLE 
      DATABASE;

    Distributing a Backup Across Multiple Disks

    This example backs up tablespaces to two different disks and lets RMAN perform automatic parallelization of the backup. The %U in the FORMAT string is a substitution variable that generates a unique file name for each output image copy.

    RUN
    {
      ALLOCATE CHANNEL dev1 DEVICE TYPE DISK FORMAT '/disk1/%U';
      ALLOCATE CHANNEL dev2 DEVICE TYPE DISK FORMAT '/disk2/%U'; 
      BACKUP AS COPY
        TABLESPACE SYSTEM, tools, users, undotbs;
    }

    Identifying Data File Copies by Tag

    In this example, you back up data file image copies to tape. The BACKUP command locates all data file copies with the tag LATESTCOPY, backs them up to tape, and names the backups using substitution variables. The variable %f specifies the absolute file number, whereas %d specifies the name of the database. After the data file copies are on tape, the example deletes all image copies with the tag LATESTCOPY.

    BACKUP 
      DEVICE TYPE sbt
      DATAFILECOPY 
        FROM TAG 'LATESTCOPY'
      FORMAT 'Datafile%f_Database%d';
    DELETE COPY TAG 'LATESTCOPY';

    Backing Up and Deleting Archived Redo Log Files

    This example assumes that you have two archiving destinations set: /disk2/PROD/archivelog/ and /disk1/arch/. The command backs up one archived redo log for each unique sequence number. For example, if archived redo log 1000 is in both directories, then RMAN only backs up one copy this log. The DELETE INPUT clause with the ALL keyword deletes all archived redo log files from both archiving directories after the backup.

    BACKUP DEVICE TYPE sbt
      ARCHIVELOG LIKE '/disk%arc%'
      DELETE ALL INPUT;
    

    Sample output for the preceding command appears as follows:

    Starting backup at 12-MAR-13
    allocated channel: ORA_SBT_TAPE_1
    channel ORA_SBT_TAPE_1: SID=150 device type=SBT_TAPE
    channel ORA_SBT_TAPE_1: Oracle Secure Backup
    channel ORA_SBT_TAPE_1: starting archived log backup set
    channel ORA_SBT_TAPE_1: specifying archived log(s) in backup set
    input archived log thread=1 sequence=4 RECID=4 STAMP=616789551
    input archived log thread=1 sequence=5 RECID=5 STAMP=616789551
    input archived log thread=1 sequence=6 RECID=6 STAMP=616789554
    input archived log thread=1 sequence=7 RECID=7 STAMP=616789731
    input archived log thread=1 sequence=8 RECID=8 STAMP=616789825
    input archived log thread=1 sequence=9 RECID=10 STAMP=616789901
    input archived log thread=1 sequence=10 RECID=12 STAMP=616789985
    channel ORA_SBT_TAPE_1: starting piece 1 at 12-MAR-13
    channel ORA_SBT_TAPE_1: finished piece 1 at 12-MAR-13
    piece handle=0vice0g7_1_1 tag=TAG20130312T105917 comment=API Version 2.0,MMS Version 10.1.0.3
    channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:25
    channel ORA_SBT_TAPE_1: deleting archived log(s)
    archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_4_2z45sgrc_.arc RECID=4 STAMP=616789551
    archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_5_2z45sgrc_.arc RECID=5 STAMP=616789551
    archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_6_2z45sl3g_.arc RECID=6 STAMP=616789554
    archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_7_2z45z2kt_.arc RECID=7 STAMP=616789731
    archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_8_2z4620sk_.arc RECID=8 STAMP=616789825
    archived log file name=/disk1/arch/archiver_1_8_616789153.arc RECID=9 STAMP=616789825
    archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_9_2z464dhk_.arc RECID=10 STAMP=616789901
    archived log file name=/disk1/arch/archiver_1_9_616789153.arc RECID=11 STAMP=616789901
    archived log file name=/disk2/PROD/archivelog/2013_03_09/o1_mf_1_10_2z4670gr_.arc RECID=12 STAMP=616789985
    archived log file name=/disk1/arch/archiver_1_10_616789153.arc RECID=13 STAMP=616789985
    Finished backup at 12-MAR-13
     
    Starting Control File and SPFILE Autobackup at 12-MAR-13
    piece handle=c-28643857-20130312-02 comment=API Version 2.0,MMS Version 10.1.0.3
    Finished Control File and SPFILE Autobackup at 12-MAR-13

    Scripting Incrementally Updated Backups

    By incrementally updating backups, you can avoid the overhead of making full image copy backups of data files, while also minimizing media recovery time. For example, if you run a daily backup script, then you never have more than one day of redo to apply for media recovery.

    Assume you run the following script daily. On first execution, the script creates an image copy backup of the database on disk with the specified tag. On second execution, the script creates a level 1 differential incremental backup of the database. On every subsequent execution, RMAN applies the level 1 incremental backup to the data file copy and then makes a new level 1 backup.

    RUN
    {
      RECOVER COPY OF DATABASE 
        WITH TAG 'incr_update';
      BACKUP
        INCREMENTAL LEVEL 1
        FOR RECOVER OF COPY WITH TAG 'incr_update'
        DATABASE;
    }

    Backing Up Disk-Based Backup Sets to Tape

    Assume your goal is to keep recent backup sets on disk and older backup sets on tape. Also, you want to avoid keeping copies of the same backup set on disk and tape simultaneously. This example backs up backup sets created more than two weeks ago to tape and then deletes the backup pieces from disk.

    BACKUP
      DEVICE TYPE sbt 
      BACKUPSET
        COMPLETED BEFORE 'SYSDATE-14' 
      DELETE INPUT;

    Duplexing a Database Backup

    This example uses the COPIES parameter to create two compressed backups of the database, with each backup on a separate disk. The output locations are specified in the FORMAT parameter.

    BACKUP AS COMPRESSED BACKUPSET
      DEVICE TYPE DISK 
      COPIES 2
      DATABASE
      FORMAT '/disk1/db_%U', '/disk2/db_%U';

    Specifying How Channels Divide Workload

    This example explicitly parallelizes a backup by using the CHANNEL parameter to specify which channels back up which files and to which locations.

    RUN
    {
      ALLOCATE CHANNEL ch1 DEVICE TYPE sbt
        PARMS 'ENV=(OB_DEVICE_1=stape1)';
      ALLOCATE CHANNEL ch2 DEVICE TYPE sbt
        PARMS 'ENV=(OB_DEVICE_1=stape2)';
      BACKUP 
        (DATABASE        # ch1 backs up database to tape drive stape1
          CHANNEL ch1)
        (ARCHIVELOG ALL
          CHANNEL ch2);  # ch2 backs up archived redo log files to tape drive stape2
    }

    Creating an Incremental Backup for Refresh of a Standby Database

    In this example, your goal is make an incremental backup of the primary database and use it to update an associated standby database. You start the RMAN client, CONNECT to the primary database as TARGET, and then connect to the recovery catalog. The BACKUP command creates an incremental backup of the primary database that can be applied at a standby database to update it with changes since the specified SCN.

    RMAN> CONNECT TARGET /
    
    connected to target database: PROD (DBID=39525561)
    
    RMAN> CONNECT CATALOG [email protected]
    
    recovery catalog database Password: password
    connected to recovery catalog database
    
    RMAN> BACKUP DEVICE TYPE DISK
    2> INCREMENTAL FROM SCN 404128 DATABASE
    3>  FORMAT '/disk1/incr_standby_%U';

    Specifying Corruption Tolerance for Data File Backups

    This example assumes a database that contains five data files. It uses the SET MAXCORRUPT command to indicate than only one corruption is tolerated in each data file. Because the CHECK LOGICAL option is specified on the BACKUP command, RMAN checks for both physical and logical corruption.

    RUN
    {
      SET MAXCORRUPT FOR DATAFILE 1,2,3,4,5 TO 1;
      BACKUP CHECK LOGICAL
        DATABASE;
    }

    Creating a Consistent Database Backup for Archival Purposes

    This example uses a keepOption to create an archival backup set that cannot be considered obsolete for one year. The example backs up the database, archives the redo in the current online logs to ensure that this new backup is consistent, and backs up only those archived redo log files needed to restore the data file backup to a consistent state.

    The BACKUP command also creates a restore point to match the SCN at which this backup is consistent. The FORMAT parameter must be capable of creating multiple backup pieces in multiple backup sets.

    BACKUP DATABASE
      FORMAT '/disk1/archival_backups/db_%U.bck' 
      TAG quarterly
      KEEP UNTIL TIME 'SYSDATE + 365'
      RESTORE POINT Q1FY06;

    Exempting Copies from the Retention Policy

    The following example copies two data files and exempts them from the retention policy forever. The control file and server parameter file are also backed up, even with autobackup off.

    KEEP FOREVER requires a recovery catalog.

    SHUTDOWN IMMEDIATE;
    STARTUP MOUNT;
    BACKUP
      KEEP FOREVER
      FORMAT '?/dbs/%U_longterm.cpy'
      TAG LONGTERM_BCK
      DATAFILE 1 DATAFILE 2;
    ALTER DATABASE OPEN;

    Backing Up Files That Need Backups

    Assume that you back up the database and archived redo log files every night to tape by running the following command.

    BACKUP
      MAXSETSIZE 500M
      DATABASE PLUS ARCHIVELOG;
    

    The preceding command sets an upper limit to the size of each backup set so that RMAN produces multiple backup sets. Assume that the media management device fails halfway through the backup and is then restarted. The next day you discover that only half the backup sets completed. In this case, you can run the following command in the evening:

    BACKUP 
      NOT BACKED UP SINCE TIME 'SYSDATE-1'
      MAXSETSIZE 500M
      DATABASE PLUS ARCHIVELOG;
    

    With the preceding command, RMAN backs up only files not backed up during in the previous 24 hours. When RMAN determines that a backup from the specified time window is available, it displays output like the following:

    skipping datafile 1; already backed up on 18-JAN-13
    skipping datafile 2; already backed up on 18-JAN-13
    skipping datafile 3; already backed up on 18-JAN-13
    

    If you place the NOT BACKED UP SINCE clause immediately after the BACKUP command, then it affects all objects to be backed up. You can also place it after individual backupSpec clauses to cause only backups for those objects described by the backupSpec to be subject to the limitation.

    Using NODUPLICATES To Back Up Data File Copies

    This example creates a data file copy of data file 2 named /disk2/df2.cpy. The example then backs up this data file copy to the /disk1 and /disk3 directories. The NODUPLICATES option on the final BACKUP command indicates that only one copy of data file 2 is backed up.

    BACKUP AS COPY
      DATAFILE 2
      FORMAT '/disk2/df2.cpy' TAG my_tag;
    BACKUP AS COPY
      DATAFILECOPY '/disk2/df2.cpy' 
      FORMAT '/disk1/df2.cpy';
    BACKUP AS COPY
      DATAFILECOPY '/disk1/df2.cpy' 
      FORMAT '/disk3/df2.cpy';
    BACKUP
      DEVICE TYPE sbt
      DATAFILECOPY ALL NODUPLICATES; # backs up only copy of data file 2

    Copying Archived Log From Operating System File to ASM

    BACKUP AS COPY REUSE 
    ARCHIVELOG LIKE "/ade/b/369893928/oracle/work/arc_dest/arcr_1_11_686060575.arc"
    AUXILIARY FORMAT "+RCVAREA";

    Multisection Backup of Data Files as Image Copies

    This example creates a multisection backup of the data file users_df.dbf. The backup is created as image copies and each backup piece cannot exceed 150MB.

    BACKUP AS COPY
    SECTION SIZE 150M
    DATAFILE '/oradata/dbs/users_df.dbf';
    

    Multisection Incremental Backup of Database as Backup Sets

    This example creates a multisection incremental backup of the database as backup sets. The incremental backup includes all data file blocks that changed at SCN greater than or equal to 8564. The FORMAT clause is mandatory when you use INCREMENTAL FROM SCN to create a multisection incremental backup.

    BACKUP
    FORMAT '/tmp/datafiles/db_incr_ms_%U'
    INCREMENTAL FROM SCN 8564
    SECTION SIZE 400M
    DATABASE;
    

    Multisection Incremental Backup of Tablespaces

    This example creates a multisection incremental backup of the tablespace orders as backup sets. Before creating the backup, three channels are explicitly allocated using the ALLOCATE CHANNEL command. Therefore, RMAN uses these channels to write, in parallel, to the backup pieces.

    run {
       ALLOCATE CHANNEL MY_CH1 TYPE DISK;
       ALLOCATE CHANNEL MY_CH2 TYPE DISK;
       ALLOCATE CHANNEL MY_CH3 TYPE DISK;
       BACKUP
         INCREMENTAL LEVEL 1
         AS COMPRESSED BACKUPSET
         SECTION SIZE 100M
         TABLESPACE sales;
        };
    

    Cross-Platform Backup of the Entire Database

    This example creates a cross-platform backup of the entire database for transport to the Linux x86 64-bit platform. The source platform is Microsoft Windows IA (32-bit) and the backup is stored in a backup set named full_db.bck. The database must be placed in read-only mode before the backup is created.

    BACKUP
        TO PLATFORM='Linux x86 64-bit'
        FORMAT '/tmp/xplat_backups/full_db.bck'
        DATABASE;
    

    Cross-Platform Backup of a Consistent Tablespace

    This example backs up the tablespace example for cross-platform transport. The tablespace must be placed in read-only mode before the backup is performed. The backup set containing the tablespace data is called example_readonly.bck. The metadata required to plug this tablespace into the target database is stored in the backup set example_dmp.bck.

    BACKUP
       FOR TRANSPORT
       FORMAT '/tmp/xplat_backups/example_readonly.bck'
       TABLESPACE example
       DATAPUMP FORMAT '/tmp/xplat_backups/example_dmp.bck';
    

    Cross-Platform Backup of a Tablespace Using Multiple Backup Sets

    This example creates a cross-platform backup of the tablespace example using multiple backup sets. Ensure that the tablespace is read-only before you create the backup. Because FILESPERSET is set to 1, each backup set contains only one input file. The backup sets use unique names that begin with db_multiple_.

    BACKUP
       FOR TRANSPORT
       FILESPERSET 1
       FORMAT '/tmp/xplat_backups/db_multiple_%U'
       TABLESPACE example
       DATAPUMP FORMAT '/tmp/xplat_backups/db_multiple.dmp';
    

    Cross-Platform Backup of a Tablespace Using Multiple Backup Pieces

    This example creates a cross-platform backup of the tablespace example. The backup uses multiple backup pieces because MAXPIECESIZE is set in the ALLOCATE CHANNEL command. Ensure that the tablespace is in read-only mode before the backup is created.

    RUN
    {
       ALLOCATE CHANNEL c1 DEVICE TYPE disk MAXPIECESIZE 301464;
       BACKUP
          FOR TRANSPORT
          FORMAT '/tmp/xplat_backups/example_multi-piece.bck'
          TABLESPACE example
          DATAPUMP FORMAT '/tmp/xplat_backups/example_multi-piece_dmp.bck';}
    

    Cross-Platform Inconsistent Backup of a Tablespace

    This example creates a cross-platform level 0 incremental backup of the tablespace example. The tablespace is in read-write mode at the time of creating the backup and, therefore, you use ALLOW INCONSISTENT to create an inconsistent backup.

    Note that inconsistent backups of tablespaces cannot be used to directly plug the tablespace into the destination database. You must use an incremental backup of the tablespace that is created when the tablespace is read-only to make the tablespace consistent. 

    BACKUP
        FOR TRANSPORT
        ALLOW INCONSISTENT
        INCREMENTAL LEVEL 0
        FORMAT '/tmp/xplat_backups/example_inconsist.bck'
        TABLESPACE example;
    

    Cross-Platform Incremental Backup of a Tablespace

    This example creates a cross-platform level 1 incremental backup of the tablespace example. The tablespace is placed in read-only mode before this backup is created. This backup contains changes made to the tablespace after the most recent incremental backup was created. The backup is stored in a backup set called example_inconsist_incr.bck. The metadata required to plug the tablespace into the destination database is stored in the backup set example_incr_dmp.bck.

    You can use this level 1 incremental backup, along with the level 0 incremental backup created, to transport the tablespace example to a different platform. On the destination database, you first restore the level 0 incremental backup created to create a set of foreign data files. These foreign data files are inconsistent because the tablespace was in read/write mode when the level 0 incremental backup was created. You then apply a level 1 incremental backup to the foreign data files. Next, you plug the tablespace in to the destination database by restoring the backup set specified in the DATAPUMP clause.

    In most scenarios, after creating the level 0 incremental backup, you create multiple level 1 incremental backups with the tablespace is placed in read/write mode. The final incremental level 1 backup is created with the tablespace placed in read-only mode. These incremental backups that are created and applied over time help minimize the data divergence between the source and destination database.

    BACKUP
       FOR TRANSPORT
       INCREMENTAL LEVEL 1
       TABLESPACE example
       FORMAT '/tmp/xplat_backups/example_inconsist_incr.bck'
       DATAPUMP FORMAT '/tmp/xplat_backups/example_incr_dmp.bck';
    

    Also See:

    Oracle RMAN