The primary purpose of RMAN backups is to protect your data. If a media failure or disaster occurs, then you can restore your backups and recover lost changes.

You can also make backups to preserve data for long-time archival, as explained in "Making Database Backups for Long-Term Storage", and to transfer data, as explained in the chapters included in Transferring Data with RMAN.

You can back up all or part of your database with the BACKUP command from within the RMAN client.

In many cases, after your database has been configured in accordance with your backup strategy, you can back up the database by entering the following command at the RMAN prompt:

RMAN> BACKUP DATABASE;

RMAN uses the configured settings, the records of previous backups, and the control file record of the database structure to determine an efficient set of steps for the backup. RMAN then performs these steps.

As explained in "About RMAN File Management in a Data Guard Environment", you can run RMAN backups at any database in a Data Guard environment. Any backup of any database in the environment is usable for recovery of any other database if the backup is accessible. You can offload all backups of database files, including control file backups, to a physical standby database and thereby avoid consuming resources on the primary database.

The BACKUP command takes a DEVICE TYPE clause that specifies whether to back up to disk or tape device.

BACKUP 
   DEVICE TYPE DISK
   DATABASE;

RMAN can create backups on disk as image copies or as backup sets.

BACKUP AS COPY
  DEVICE TYPE DISK 
  DATABASE;

BACKUP AS BACKUPSET 
  DATABASE;

BACKUP AS BACKUPSET 
  DEVICE TYPE DISK 
  DATABASE;

BACKUP AS BACKUPSET 
  DEVICE TYPE SBT 
  DATABASE;

RMAN provides a range of options to name the files generated by the BACKUP command.

1. If a FORMAT parameter is specified on the BACKUP command, then this setting controls the generated file name.

   For example, you can direct the output to a specific location, as shown in the following command:

   BACKUP DATABASE 
     FORMAT "/disk1/backup_%U";  # specifies a location on the file system
   

   In this case, backups are stored with generated unique file names with the prefix /disk1/backup_. The %U substitution variable, used to generate a unique string at this point in the file name, is required.

   You can also use the FORMAT parameter to name an ASM disk group as the backup destination, as shown in the following example:

   BACKUP DATABASE 
     FORMAT '+dgroup1';  # specifies an ASM disk group
   

   No %U is required in this case because Automatic Storage Management (ASM) generates unique file names as needed. However, you can specify %U if desired.

   Note:

   If you specify FORMAT when a fast recovery area is enabled, then RMAN obeys the FORMAT setting. If no location is specified in the FORMAT clause, then RMAN creates the backup in a platform-specific location.

2. If a FORMAT setting is configured for the specific channel used for the backup, then this setting controls the generated file name.
3. If a FORMAT setting is configured for the device type used for the backup, then this setting controls the generated file name.
4. If a fast recovery area is enabled during a disk backup, and if FORMAT is not specified, then RMAN creates the backup with an automatically generated name in the fast recovery area.
5. If no other conditions in this list apply, then the default location and file name format of the backup are platform-specific.

RMAN attaches a character string called a tag to every backup it creates, as a way of identifying the backup. You can either accept the default tag or specify your own with the TAG parameter of the BACKUP command.

This section contains the following topics:

• About Backup Tags

• Specifying Tags for Backup Sets and Image Copies

When creating backup sets, you can use RMAN support for binary compression of backup sets by including the AS COMPRESSED BACKUPSET option to the BACKUP command.

BACKUP 
  AS COMPRESSED BACKUPSET 
  DATABASE PLUS ARCHIVELOG;

A multisection backup enables large data files to be divided into sections that can be backed up in parallel across multiple channels. This provides faster backup performance and better recovery times.

While an image copy is being created, RMAN uses multiple channels to write files sections. However, the output of this operation is one copy for each data file.

You can perform a whole database backup with the database mounted or open.

1. Start RMAN and connect to a target database and a recovery catalog (if used) as described in "Making Database Connections with RMAN".
2. Ensure that the database is mounted or open.
3. Issue the BACKUP DATABASE command at the RMAN prompt.

   The simplest form of the command requires no options or parameters:

   BACKUP DATABASE;

   The list of files (data files, control file, server parameter file) backed up depends on the keyword used with the BACKUP command.

   The following example backs up the database, switches the online redo logs, and includes archived logs in the backup:

   BACKUP DATABASE PLUS ARCHIVELOG;
   

   By archiving the logs immediately after the backup, you ensure that you have a full set of archived logs through the time of the backup. In this way, you guarantee that you can perform media recovery after restoring this backup.

You can back up one or more tablespaces with the BACKUP TABLESPACE command or one or more data files with the BACKUP DATAFILE command.

1. Start RMAN and connect to a target database and a recovery catalog (if used).

   See Also:

   Making Database Connections with RMAN for information about connecting to a target database

2. If the database instance is not started, then either mount or open the database.
3. Run the BACKUP TABLESPACE command or BACKUP DATAFILE command at the RMAN prompt.

BACKUP
  DEVICE TYPE sbt
  TABLESPACE users, tools;

BACKUP 
  DEVICE TYPE sbt 
  DATAFILE 1,2,3,4 
  DATAFILECOPY '/tmp/system01.dbf';

You can back up the control file when the database is mounted or open. RMAN uses a snapshot control file to ensure a read-consistent version.

If the CONFIGURE CONTROLFILE AUTOBACKUP command is set to ON (by default it is OFF), then RMAN automatically backs up the control file and server parameter file after every backup and after database structural changes. The control file autobackup contains metadata about the previous backup, which is crucial for disaster recovery.

If the autobackup feature is not set, then you must manually back up the control file in one of the following ways:

• Run BACKUP CURRENT CONTROLFILE.

• Include a backup of the control file within any backup by using the INCLUDE CURRENT CONTROLFILE option of the BACKUP command.

• Back up data file 1, because RMAN automatically includes the control file and server parameter file in backups of data file 1.

  Note:

  If the control file block size is different from the block size for data file 1, then the control file cannot be written into the same backup set as the data file. RMAN writes the control file into a backup set by itself if the block size is different. The V$CONTROLFILE.BLOCK_SIZE column indicates the control file block size, whereas the DB_BLOCK_SIZE initialization parameter indicates the block size of data file 1.

RMAN automatically backs up the current server parameter file in certain cases. The BACKUP SPFILE command backs up the parameter file explicitly. The server parameter file that is backed up is the one currently in use by the instance.

1. Start RMAN and connect to a target database and a recovery catalog (if used) as described in Making Database Connections with RMAN.
2. Ensure that the target database is mounted or open.

   The database must have been started with a server parameter file. If the instance is started with a client-side initialization parameter file, then RMAN issues an error if you execute BACKUP ... SPFILE.

3. Execute the BACKUP ... SPFILE command.

   The following example backs up the server parameter file to tape:

   BACKUP DEVICE TYPE sbt SPFILE;

You can only back up a database in NOARCHIVELOG mode when the database is closed and in a consistent state.

SHUTDOWN IMMEDIATE; 
# Start the database in case it suffered instance failure or was 
# closed with SHUTDOWN ABORT before starting this script. 
STARTUP FORCE DBA; 
SHUTDOWN IMMEDIATE; 
STARTUP MOUNT;
# this example uses automatic channels to make the backup
BACKUP 
  INCREMENTAL LEVEL 0
  MAXSETSIZE 10M
  DATABASE
  TAG 'BACKUP_1';
# Now that the backup is complete, open the database. 
ALTER DATABASE OPEN; 

RMAN and Oracle Enterprise Manager Cloud Control provide full support for backup and recovery in a multitenant environment.

The multitenant architecture enables an Oracle Database to function as a CDB. You can back up and recover a whole CDB, the root only, or one or more pluggable databases (PDBs). You can also back up and recover individual tablespaces and data files in a PDB.

You might want to perform nightly backups of the whole multitenant container database (CDB) by using an incremental backup strategy, or you might want to make frequent separate backups of individual PDBs and do less frequent backups of either the whole CDB or of the root.

In terms of the ability to recover from data loss, separately backing up the root and all PDBs, including the CDB seed, is equivalent to backing up the whole CDB. The main difference is in the number of RMAN commands that you must enter and the time to recover. Recovering a whole CDB requires less time than recovering the root plus all PDBs.

If the compatibility parameter for CDBs and PDBs is set to 12.2 or higher, RMAN also enables you to perform sparse backups on your CDB and PDB. These backups copy the latest updates from the delta storage space assigned to each database.

Backing up a whole multitenant container database (CDB) is similar to backing up a non-CDB. When you back up a whole CDB, RMAN backs up the root, all the pluggable databases (PDBs), and the archived redo logs.

1. Start RMAN and connect to the root as a common user with the SYSBACKUP or SYSDBA privilege and to a recovery catalog (if used) as described in Making Database Connections with RMAN.
2. Ensure that the database is mounted or open.
3. Issue the BACKUP DATABASE command at the RMAN prompt.

   The simplest form of the command requires no options or parameters:

   BACKUP DATABASE;

   The list of files backed up depends on the keyword used with the BACKUP command.

   The following example backs up the CDB, switches the online redo logs, and includes archived logs in the backup:

   BACKUP DATABASE PLUS ARCHIVELOG;
   

   By archiving the logs immediately after the backup, you ensure that you have a full set of archived logs through the time of the backup. In this way, you guarantee that you can perform media recovery after restoring this backup.

You can use RMAN to make a backup of only the root. Because the root contains critical metadata for the whole CDB, Oracle recommends that you back up the root or back up the whole CDB at regular intervals.

1. Start RMAN and connect to the root as a common user with the SYSBACKUP or SYSDBA privilege as described in Connecting as Target to the Root.
2. Enter the following command:

   BACKUP DATABASE ROOT;

Oracle Enterprise Manager Cloud Control (Cloud Control) can be used to back up the root.

1. From the Database Home page, select Backup & Recovery from the Availability menu, and then select Schedule Backup.
2. If you have not logged in to the database previously, then the Database Login page is displayed. Log in to the database using Named or New credentials and then click Login.

   Cloud Control displays the Schedule Backup page.

3. From the Customized Backup section, choose Container Database Root, and then click Schedule Customized Backup.

   The Schedule Backup Wizard appears and displays the Options page.

4. Complete the wizard by navigating the remainder of the pages to back up the root. For more information about each page of the wizard, click Help.

RMAN enables you to back up one or more PDBs in a CDB using the BACKUP command.

1. Start RMAN and connect to the PDB as a local user with the SYSBACKUP or SYSDBA privilege and to a recovery catalog (if used), as described in Connecting as Target to a PDB.
2. Issue a BACKUP DATABASE command at the RMAN prompt.

   BACKUP DATABASE;

Oracle Enterprise Manager Cloud Control (Cloud Control) can be used to perform backups of pluggable databases (PDBs).

Because tablespaces in different PDBs can have the same name, to eliminate ambiguity you must connect directly to a PDB to back up one or more of its tablespaces.

1. Do one of the following:

   • Start RMAN and connect to the root as a common user with the SYSBACKUP or SYSDBA privilege.

   • Start RMAN and connect to the PDB as a local user with the SYSBACKUP or SYSDBA privilege.

2. Issue a BACKUP DATAFILE command.

   BACKUP DATAFILE 10, 13;

Several features of RMAN backups are specific to archived redo logs. For example, you can use BACKUP ... DELETE to delete one or all copies of archived redo logs from disk after backing them up to backup sets.

This section contains the following topics:

• About Archived Redo Log Failover

• About Online Redo Log Switching

In a CDB, archived redo logs can be backed up only when you connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.

When you connect to a PDB as a local user with SYSDBA or SYSBACKUP privilege, you cannot back up or delete archived redo logs.

If your archived redo logs are being copied to multiple destinations, when you connect to the root and backup archived redo log files, RMAN includes only one copy of the archived redo log files in a backup. You can switch archived redo log files when you connect to root of a CDB. Therefore, the information in "About Archived Redo Log Failover" and "About Online Redo Log Switching" is applicable when you connect to the root. However, you cannot backup or switch archived redo log files when connected to a PDB.

To back up archived logs, use the BACKUP ARCHIVELOG command.

1. Start RMAN and connect to a target database and a recovery catalog (if used) as described in Making Database Connections with RMAN.
2. Ensure that the target database is mounted or open.
3. Execute the BACKUP ARCHIVELOG or BACKUP ... PLUS ARCHIVELOG command.

   The following example backs up the database and all archived redo logs:

   BACKUP DATABASE PLUS ARCHIVELOG;
   

   The following example uses a configured disk or SBT channel to back up one copy of each log sequence number for all archived redo logs:

   BACKUP ARCHIVELOG ALL;
   

   You can also specify a range of archived redo logs by time, SCN, or log sequence number, as in the following example:

   BACKUP ARCHIVELOG 
     FROM TIME  'SYSDATE-30'
     UNTIL TIME 'SYSDATE-7';

You can indicate that RMAN should automatically skip backups of archived redo logs.

1. Start RMAN and connect to a target database and a recovery catalog (if used) as described in Making Database Connections with RMAN.
2. Ensure that the target database is mounted or open.
3. Ensure that appropriate channels are configured for the backup.
4. Execute the BACKUP ARCHIVELOG command with the NOT BACKED UP clause.

   BACKUP ARCHIVELOG ALL NOT BACKED UP 2 TIMES;

You can back up archived redo logs in a multitenant container database (CDB) by using the BACKUP ARCHIVELOG command.

The BACKUP ARCHIVELOG ... DELETE INPUT command deletes archived log files after they are backed up. This command eliminates the separate step of manually deleting archived redo logs.

1. Start RMAN and connect to a target database and a recovery catalog (if used) as described in Making Database Connections with RMAN.
2. Ensure that the target database is mounted or open.
3. Run the BACKUP command with the DELETE INPUT clause.

   Assume that you run the following BACKUP command:

   BACKUP DEVICE TYPE sbt 
     ARCHIVELOG ALL 
       DELETE ALL INPUT;
   

   In this case, RMAN backs up only one copy of each log sequence number in these archiving locations. RMAN deletes all copies of any log that it backed up from both the fast recovery area and the other archiving destinations.

   If you specify DELETE INPUT rather than DELETE ALL INPUT, then RMAN only deletes the specific archived redo log files that it backed up. For example, RMAN deletes the logs in /arc_dest1 if these files were used as the source of the backup, but leave the contents of the /arc_dest2 intact.

In a CDB, you can delete archived redo logs after they are backed up by using the BACKUP ARCHIVELOG ... DELETE INPUT command.

RMAN incremental backups provide multiple benefits.

The primary reasons for making incremental backups part of your strategy are:

• Faster daily backups if block change tracking is enabled (see "Using Block Change Tracking to Improve Incremental Backup Performance")

• Ability to roll forward data file image copies, thereby reducing recovery time and avoiding repeated full backups

• Less bandwidth consumption when backing up over a network

• Improved performance when the aggregate tape bandwidth for tape write I/Os is much less than the aggregate disk bandwidth for disk read I/Os

• Possibility of recovering changes to objects created with the NOLOGGING option

  For example, direct load inserts do not create redo log entries, so their changes cannot be reproduced with media recovery. Direct load inserts do change data blocks, however, and these blocks are captured by incremental backups.

• Ability to synchronize a physical standby database with the primary database

  You can use the RMAN BACKUP INCREMENTAL FROM SCN command to create a backup on the primary database that starts at the current SCN of the standby database, which you can then use to roll forward the standby database. See Oracle Data Guard Concepts and Administration to learn how to apply incremental backups to a standby database.

Choose a backup strategy according to an acceptable MTTR (mean time to recover).

For example, you can implement a three-level backup scheme so that a level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is taken daily. In this strategy, you never have to apply more than a day of redo for complete recovery.

When deciding how often to take level 0 backups, a general rule is to take a new level 0 backup whenever 20% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 backup is appropriate. The following SQL query determines the number of blocks written to an incremental level 1 backup of each data file with at least 20% of its blocks backed up:

SELECT   FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, 
         BLOCKS, DATAFILE_BLOCKS 
FROM     V$BACKUP_DATAFILE 
WHERE    INCREMENTAL_LEVEL > 0 
AND      BLOCKS / DATAFILE_BLOCKS > .2
ORDER BY COMPLETION_TIME;

Compare the number of blocks in level 1 backups to a level 0 backup. For example, if you create only level 1 cumulative backups, then take a new level 0 backup when the most recent level 1 backup is about half the size of the level 0 backup.

An effective way to conserve disk space is to make incremental backups to disk, and then offload the backups to tape with the BACKUP AS BACKUPSET command. Incremental backups are generally smaller than full backups, which limits the space required to store them until they are moved to tape. When the incremental backups on disk are backed up to tape, the tape is more likely to stream because all blocks of the incremental backup are copied to tape. There is no possibility of delay due to time required for RMAN to locate changed blocks in the data files.

Another strategy is to use incrementally updated backups, as explained in "Incrementally Updating Backups". In this strategy, you create an image copy of each data file, and then periodically roll forward this copy by making and then applying a level 1 incremental backup. In this way you avoid the overhead of making repeated full image copies of your data files, but enjoy all of the advantages.

In a Data Guard environment, you can offload incremental backups to a physical standby database. Incremental backups of a standby and primary database are interchangeable. Thus, you can apply an incremental backup of a standby database to a primary database, or apply an incremental backup of a primary database to a standby database.

1. Start RMAN and connect to a target database and a recovery catalog (if used).

   See Also:

   Making Database Connections with RMAN

2. Ensure that the target database is mounted or open.
3. Execute the BACKUP INCREMENTAL command with the desired options.

   Use the LEVEL parameter to indicate the incremental level. The following example makes a level 0 incremental database backup.

   BACKUP
     INCREMENTAL LEVEL 0
     DATABASE;
   

   The following example makes a differential incremental backup at level 1 of the SYSTEM and tools tablespaces. It only backs up those data blocks changed since the most recent level 1 or level 0 backup.

   BACKUP
     INCREMENTAL LEVEL 1
     TABLESPACE SYSTEM, tools;
   

   The following example makes a cumulative incremental backup at level 1 of the tablespace users, backing up all blocks changed since the most recent level 0 backup.

   BACKUP
     INCREMENTAL LEVEL 1 CUMULATIVE
     TABLESPACE users;

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

1. Create a full image copy backup of a data file with a specified tag.
2. At regular intervals (such as daily), make a level 1 differential incremental backup of the data file and use the same tag as the base data file copy.
3. Apply the incremental backup to the most recent backup with the same tag.

The block change tracking feature for incremental backups improves backup performance by recording changed blocks for each data file.

This section contains the following topics:

• About Block Change Tracking

• Enabling and Disabling Block Change Tracking

• Disabling Block Change Tracking

• Checking Whether Change Tracking Is Enabled

• Changing the Location of the Block Change Tracking File

You can use BACKUP... KEEP to create a backup that is both all-inclusive and exempt from the backup retention policy.

The backup is all-inclusive because every file needed to restore and recover the database is backed up to a single disk or tape location. The KEEP option also specifies that the backup is exempt from the retention policy either forever or for a specified period. The general name for a backup created with BACKUP ... KEEP is an archival backup.

As explained in "About Data Archival", one purpose of a backup and recovery strategy is to preserve data. You can use BACKUP ... KEEP to retain a database backup for longer than the time dictated by the retention policy. For example, you can back up the database on the first day of every year to satisfy a regulatory requirement and store the media off-site. Years after you make the archival backup, you can restore and recover it to query the data as it appeared at the time of the backup.

Another purpose of an archival backup is to create a backup that you want to restore for testing purposes and then delete. For example, you can back up the database, restore the database in a test environment, and then discard the archival backup after the test database is operational. A related purpose is to create a self-contained backup that you can delete after transferring it to another user or host. For example, another user might want a copy of the database for reporting or testing.

You can exempt a backup from the retention policy by using the KEEP option with the BACKUP command.

You can also use the KEEP and NOKEEP options of the CHANGE command to change the status of an existing backup. Backups with KEEP attributes are valid backups that can be recovered like any other backups.

You can specify an end date for an archival backup with the KEEP UNTIL TIME clause, or specify that the backup is kept FOREVER. If you specify UNTIL, then RMAN marks the backup as obsolete when the UNTIL time has passed, regardless of any configured retention policy. For example, if you specify KEEP UNTIL TIME '01-JAN-13', then the backup is obsolete one second after midnight on January 1, 2013. If you specify an UNTIL TIME of 9:00 p.m, then the backup is obsolete at 9:01 p.m.

When you specify KEEP on the BACKUP command, RMAN generates multiple backup sets. Note the following characteristics of the BACKUP ... KEEP command:

• It automatically backs up the data files, control file (even if the control file autobackup is disabled), and the server parameter file.

• It automatically generates an archived redo log backup to ensure that the database backup can be recovered to a consistent state.

• If the FORMAT, POOL, or TAG parameters are specified, then they are used for all backups. For this reason, the FORMAT string must allow for the creation of multiple backup pieces. Specifying the %U substitution variable is the easiest way to meet this requirement.

• It supports an optional RESTORE POINT clause that creates a normal restore point, which is a label for an SCN to which the backup must be recovered to be made consistent. The SCN is captured just after the data file backups complete. RMAN resynchronizes restore points with the recovery catalog and maintains the restore points while the backup exists.

Typically, you make an archival backup to tape. Because your data protection backups are most likely to be on a set of tapes that remain accessible and are recycled, it is advisable to reserve a set of tapes for the archival backup.

You can write the archival backup to this special set of tapes and then place them in off-site storage. You can vary the procedure for creating an archival backup by creating a stored script or shell script that updates dynamically. When you run the script, you can dynamically set the name of the restore point, backup format, and so on.

One purpose of an archival backup is to create a test database.

BACKUP DATABASE
  FORMAT '/disk1/oraclebck/%U' 
  TAG TESTDB 
  KEEP UNTIL TIME 'SYSDATE+1' 
  RESTORE POINT TESTDB06;

You can use the BACKUP BACKUPSET command to back up backup sets produced by other backup jobs. You can also use BACKUP RECOVERY AREA to back up recovery files created in the current and all previous fast recovery area destinations.

Recovery files are full and incremental backup sets, control file autobackups, data file copies, and archived redo logs. SBT and disk backups are supported for BACKUP RECOVERY AREA. For disk backups of the recovery files, you must use the TO DESTINATION option.

The preceding commands are especially useful in the following scenarios:

• Ensuring that all backups exist both on disk and on tape.

• Moving backups from disk to tape and then freeing space on disk. This task is especially important when the database uses a fast recovery area so that the space can be reused as needed.

You can also use the BACKUP COPY OF command to back up image copies of data files, control files, and archived redo logs. The output of this command can be either backup sets or image copies, so you can generate backup sets from image copies. This form of backup is used to back up a database backup created as image copies on disk to tape.

Use the BACKUP BACKUPSET command to copy backup sets from disk to tape.

1. If you are backing up a subset of available backup sets, then execute the LIST BACKUPSET command to obtain their primary keys.

   The following example lists the backup sets in summary form:

   RMAN> LIST BACKUPSET SUMMARY;
   
   List of Backups
   ===============
   Key TY LV S Device Type Completion Time #Pieces #Copies Comp Tag
   --- -- -- - ----------- --------------- ------- ------- ---- ---
   1   B  F  A DISK        28-MAY-13       1       1       NO   TAG20070528T132432
   2   B  F  A DISK        29-MAY-13       1       1       NO   TAG20070529T132433
   3   B  F  A DISK        30-MAY-13       1       1       NO   TAG20070530T132434
   

   The following example lists details about backup set 3:

   RMAN> LIST BACKUPSET 3;
   
   List of Backup Sets
   ===================
   
   BS Key  Type LV Size       Device Type Elapsed Time Completion Time
   ------- ---- -- ---------- ----------- ------------ ---------------
   3       Full    8.33M      DISK        00:00:01     30-MAY-13
           BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20070530T132434
           Piece Name: /disk1/oracle/dbs/c-35764265-20070530-02
     Control File Included: Ckp SCN: 397221       Ckp time: 30-MAY-13
     SPFILE Included: Modification time: 30-MAY-13
     SPFILE db_unique_name: PROD
   

2. Execute the BACKUP BACKUPSET command.

   The following example backs up all disk backup sets to tape and then deletes the input disk backups:

   BACKUP BACKUPSET ALL
     DELETE INPUT;
   

   The following example backs up only the backup sets with the primary key 1 and 2 to tape and then deletes the input disk backups:

   BACKUP BACKUPSET 1,2
     DELETE INPUT;

3. Optionally, execute the LIST command to see a listing of backup sets and pieces.

   The output lists all copies, including backup piece copies created by BACKUP BACKUPSET .

Use the BACKUP command to back up image copies to tape.

1. Issue the BACKUP ... COPY OF or BACKUP DATAFILECOPY command.

   The following example backs up data file copies that have the tag DBCopy:

   BACKUP DATAFILECOPY FROM TAG DBCopy;
   

   The following example backs up the latest image copies of a database to tape, assigns the tag QUARTERLY_BACKUP, and deletes the input disk backups:

   BACKUP DEVICE TYPE sbt
     TAG "quarterly_backup"
     COPY OF DATABASE 
     DELETE INPUT;
   

2. Optionally, issue the LIST command to see a listing of backup sets. The output lists all copies, including backup piece copies created by the BACKUP command with the BACKUPSET clause.