Enterprise Edition Home | Express Edition Home | Previous Page | Next Page   Overview of the ON-Bar Backup and Restore System > Backing Up with ON-Bar > Backing Up Storage Spaces and Logical Logs >

ON-Bar Backup Examples

The following sections contain examples of ON–Bar syntax for backing up storage spaces.

Performing a Level-0 Backup of All Storage Spaces

To perform a standard, level-0 backup of all online storage spaces and used logical logs, use one of the following commands: 

onbar -b
onbar -b -L 0

ON–Bar never backs up offline storage spaces, temporary dbspaces, or temporary sbspaces.

Important:
Save your logical logs so that you can restore from this backup.

Performing a Level-0 Backup of Specified Storage Spaces

To perform a level-0 backup of specified storage spaces and all logical logs (for example, two dbspaces named fin_dbspace1 and fin_dbspace2), use the -b option as the following example shows. You could also specify the -L 0 option, but it is not necessary. 

onbar -b fin_dbspace1 fin_dbspace2

Performing an Incremental Backup

An incremental backup backs up all changes in the storage spaces since the last level-0 backup and performs a level-0 backup of used logical logs. To perform a level-1 backup, use the -L 1 option, as the following example shows: 

onbar -b -L 1

Backing Up a List of Storage Spaces Specified in a File

To back up a list of storage spaces specified in a file and the logical logs, use the following command: 

onbar -b -f /usr/informix/backup_list/listfile3

The format of the file is as follows:

Figure 10 shows a sample file that contains a list of storage spaces to be backed up (blobsp2.1, my_dbspace1, blobsp2.2, dbsl.1, rootdbs.1, and dbsl.2). You can also use this file to specify a list of storage spaces to be restored.

Figure 10. Sample File with a List of Storage Spaces 
blobsp2.1
# a comment                     ignore this text

       /usr/informix/my_dbspace1           # back up this dbspace
; another comment
blobsp2.2                      /usr/informix/dbsl.1
/usr/informix/rootdbs.1  dbsl.2  ; backing up two spaces

How to Avoid Repeatedly Archiving Read-Only Storage Spaces

Because the contents of read-only (static) storage spaces do not change, you do not need to archive them as often as other storage spaces. Use the -S option with the ON-Bar backup command to avoid repeatedly archiving read-only storage spaces.

The following information assumes that your system contains a mixture of storage spaces that you have designated as read-only using the onutil ALTER DBSPACE STATIC command, and dbspaces that you have not designated as read-only (also called operational dbspaces).

By default, the onbar -b command backs up all storage spaces in the system, including read-only dbspaces.

The onbar -b -S command backs up all operational dbspaces, whether or not an earlier archive of those dbspaces exists. This command also backs up read-only storage spaces that have not been backed up previously. This command does not back up read-only storage spaces for which an unexpired archive that was performed after the storage space became read-only already exists.

The semantics of the -S option are not changed by the -L option that allows incremental backups. Thus, the command onbar -b -S -L 1 performs the following tasks:

The semantics of the -S option also remain unchanged if a read-only storage space is explicitly specified to the ON-Bar backup command, as part of a dbspace list in the command or as part of a dbspace list in a file specified by the -f option. For example, if the storage space dbs_static has been flagged as read-only and has already been backed up since being flagged read-only, the command onbar -b -S dbs_static does not back up the dbs_static storage space again.

Although use of the -S option can greatly improve backup performance in a system containing large amounts of static data, you should still force backups of read-only dbspaces with some regularity by omitting the -S option. Otherwise, you run the risk of having only a single backup of your static data, and risk data loss if a restore is necessary but the single backup becomes unreadable.

If you have a large number of read-only dbspaces, consider backing up a subset of your read-only dbspaces as part of your regular backup cycles. To do so, run the ON-Bar backup command without the -S option and specify the subset of read-only dbspaces to back up, either in the command or with the -f option. Cycling through different subsets of your read-only dbspaces as part of your regular backup schedule provides you the performance advantages of not backing up all read-only storage spaces in each backup, while minimizing the risk of data loss in the event backup media becomes unreadable.

Backing Up Specific Tables

To back up a specific table or set of tables in ON-Bar, store these tables in a separate dbspace and then back up this dbspace.

Extended Parallel Server

Tip:
If your tables are read-only and not modified, consider placing them in read-only (static) dbspaces. Use the -S option to the ON-Bar backup command to avoid repeatedly archiving read-only dbspaces.
End of Extended Parallel Server

Warning:
If you need to restore only that table, you must warm restore the entire dbspace to the current time (onbar -r). This procedure does not allow you to recover from accidentally dropping or corrupting a table because it would be dropped again during logical restore.

Retrying Skipped Storage Spaces During a Backup

You cannot back up storage spaces that are down or temporarily inaccessible. If a storage space is down, ON–Bar skips it during the backup and writes a message to the activity log. Take one of the following actions:

Performing a Whole-System Backup (IDS)

To perform a serial, level-0 backup of all online storage spaces and logical logs, use one of the following commands: 

onbar -b -w
onbar -b -w -L 0

For more details, see Performing a Whole-System Restore (IDS).

Backing Up Smart Large Objects in Sbspaces (IDS)

You can back up smart large objects in one or more sbspaces or include them in a whole-system backup. In a level-0 backup, the entire sbspace is backed up. In a level-1 or level-2 backup, the modified sbpages in the sbspace are backed up.

The following example performs a level-0 backup of the s9sbpace sbspace: 

onbar -b -L 0 s9sbspace

When you turn on logging for a smart large object, you must immediately perform a level-0 backup to ensure that the object is fully recoverable. For details on logging sbspaces, see the IBM Informix: Administrator's Guide.

Using Fake Backups in a Data Warehouse (IDS)

The High-Performance Loader (HPL) in Express mode loads tables in read-only mode. A backup changes the table to update mode. Use one of the following commands: 

onbar -b      # the recommended way
onbar -b -F

Warning:
It is recommended that you use fake backups on test systems, not on production systems. You cannot restore data from a fake backup. (If you performed a fake backup, you must reload the table to be able to restore the data.)

Backing Up Blobspaces in a Logging Database (IDS)

Follow these steps when you back up blobspaces in a database that uses transaction logging:

  1. Before you back up a new blobspace, make sure that the log file that recorded the creation of the blobspace is no longer the current log file.

    To verify the logical-log status, use the onstat -l or xctl onstat -l command. To switch to the next log file, use the onmode -l command.

    Blobspaces are not available for use until the log file is not the current log file. For more information on verifying the logical-log status, see onstat -l. For information on switching log files, see the onmode section in the IBM Informix: Administrator's Reference.

  2. If you update or delete simple large objects in a blobspace, you must back up all the log files, including the current log file. If the blobspace is online, use the onbar -b -l -c command.

    When users update or delete simple large objects in blobspaces, the blobpages are not freed for reuse until the log file that contains the delete records is freed. To free the log file, you must back it up.

  3. Back up the blobspaces with the onbar -b or onbar -b -w command.

Warning:
If you perform a warm restore of a blobspace without backing up the logical logs after updating or deleting data in it, that blobspace might not be restorable.

Backing Up Logical Logs When Blobspaces Are Offline (IDS)

To back up the logical logs when a blobspace is offline, use the onbar -b -l -O or onbar -b -O command. If this backup is successful, ON–Bar returns 178.

To salvage the logical logs, use the onbar -b -s -O command.

Warning:
If you back up logical logs that contain changes to a blobspace while it is offline, the simple large objects in that blobspace will not be restorable. If an offline blobspace has not changed, it will be restorable.

Assigning a Name to a Backup Session (XPS)

To assign a name to a backup session, use the following command: 

onbar -b -q session1

To monitor the backup session, use the onstat -g bus command.

Performing a Physical Backup (XPS)

Use the -p option to perform either a level-0 or incremental backup of storage spaces only without also backing up the logical logs, as the following command shows. In the backup command, you can list the storage spaces on the command line or in a file. 

onbar -b -p

To restore data, you must have previously backed up the logical logs. For more information, see Backing Up Logical Logs on Extended Parallel Server.

Backing Up a Dbslice (XPS)

You can specify storage spaces individually or with a dbslice name. Specifying storage spaces with a dbslice name simplifies backup commands. The dbslice name is translated to the names of its component storage spaces. If you back up a dbslice, ON–Bar backs up all the storage spaces in that dbslice.

To back up all dbspaces in a dbslice named fin_slice, use the following command: 

onbar -b fin_slice
Enterprise Edition Home | Express Edition Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]