Objectivity/DB Administration : Administration Tasks : Backup and Restore
11 
Backup and Restore
This chapter describes how to use Objectivity/DB administration tools to back up and restore a federated database. You can run these tools either from the command line or within a shell script, and they include options that allow you to customize backup and restore tasks for special needs. Objectivity/DB also supports full user access (read and update) during backup.
This chapter describes:
General information about backup and restore.
Developing a backup strategy.
Backing up data and restoring from a backup.
Managing backup history.
Processing data during backup and restore.
Customizing your backup scheme for greater administrative control.
About Backup and Restore
You need to back up critical user data so it can be restored if the original data becomes unusable. Possible scenarios include:
A catastrophic event (such as an accidental erasure or a disk crash) destroys part or all of the federated database.
The logical state of the federated database is corrupted. Data in the federated database is incorrect and the transaction that created the problem has already committed.
The physical state of the federated database is corrupted, making user data inaccessible.
You want to go back to using a previous version of Objectivity/DB software after upgrading to a new release of Objectivity/DB.
In most cases, you can accommodate these scenarios by performing a series of basic backups, which are described in the following subsections. Objectivity/DB also supports customized backups for sites that want greater control over backup administration; see Customized Backups.
Basic Backups
A backup (also called a backup event) is a recorded description of a federated database at a particular point in time—a description that enables you to later reproduce that federated database as it was when the backup was taken.
A backup is physically stored as one or more files (also called volumes) on a backup medium, which is normally a disk directory.
A basic backup refers to a backup whose administrative details are managed by Objectivity/DB. For example, Objectivity/DB uses its own conventions for naming a series of backup volumes. A system of basic backups may have up to 3 backup levels and is implicitly organized by Objectivity/DB into administrative structures called backup sets.
Backup Levels
A basic backup can be taken at one of the three backup levels shown in Table 11‑1.
Table 11‑1: Basic Backup Levels 
This Level
Backs Up
full
The entire federated database (including all databases and all containers within each database regardless of whether they have been updated).
incremental
All containers updated since the most recent full backup.
subincremental
All containers updated since the most recent incremental backup.
The smallest portion of data that can be archived to a backup medium is a container.
An incremental backup subsumes any previous incremental backup up to the most recent full backup. Thus, if you take two successive incremental backups in a row, the second one includes all of the containers recorded in the first, plus any containers that were modified since the first was taken.
Similarly, a subincremental backup subsumes any previous subincremental backup up to the most recent incremental backup; if you take two successive subincremental backups in a row, the second one includes all of the containers recorded in the first, plus any additional containers that were modified since the first was taken.
You can customize your system of backups by introducing up to ten backup levels; see Customized Backups.
Backup Sets
Within a system of basic backups, Objectivity/DB implicitly creates logical groupings called backup sets for administrative purposes. Each backup set consists of a single full backup and any incremental and subincremental backups that are based on it.
You can customize your system of backups by creating your own backup sets for separately administered group of backup events. For example, each backup set can represent an entire month of federated database backup events. See Customized Backups.
Point of Restore
The point of restore is the point in time to which the federated database is restored. Each backup event represents a possible point of restore.
Full Restore
Objectivity/DB always restores an entire federated database to guarantee the referential integrity of the relationships (associations) between databases and the logical integrity of the data within and across databases. Consequently:
Specifying a full backup as the point of restore is sufficient to reconstruct an entire federated database.
Specifying an incremental backup as the point of restore causes Objectivity/DB to restore data from both the specified incremental backup and the full backup on which it is based.
Specifying a subincremental backup as the point of restore causes Objectivity/DB to restore data from the specified subincremental backup, as well as the incremental and full backups on which it is based.
Backup Diary
When you first back up a federated database, Objectivity/DB creates a container and objects within the federated database to help administer data backups and restorations. These objects are collectively called the backup diary.
Objectivity/DB uses the diary to keep track of all backup and restore events, creating objects to represent each event. The diary is used internally by Objectivity/DB tools such as QueryBackupSet, and is not available for direct user access. It is archived during each backup to ensure the ability to recover from its accidental deletion or corruption.
User Access During Backup and Restore
Objectivity/DB allows full user access (both read and write) during backups. By contrast, once you initiate a restore, Objectivity/DB prevents other users from accessing the federated database until it is entirely restored.
Possible Start Delay Due to User Access
To obtain a consistent inventory of the containers to be recorded, a backup will delay its start if any user application is currently in a transaction that has created or deleted a container. The backup proceeds with its inventory as soon as such transactions abort, commit, or checkpoint. (The backup reports an error and quits if it times out while waiting for the transactions to end; the timeout period is 10 minutes.)
During the backup inventory, no user application can create or delete a container, but this delay is very brief and normally has no noticeable impact on the user application.
Increased Space Requirements Due to User Access
To allow full access during a backup while maintaining data consistency, Objectivity/DB retains the old versions of any containers modified while the backup is in progress. (Normally, old versions of containers are deleted as soon as transactions commit.) Other users access the most recent versions of the containers while the Objectivity/DB backup tool records the state of the federated database as it was when the backup began.
This has important implications for the amount of free disk space required to execute a backup. Namely, while a backup is in progress, the federated database grows in size as users update its containers. The extra versions of a container are purged (and the space is recycled for reuse) the first time the container is updated after the backup is complete and all locks on the extra versions have been released.
Backup Boot File
Whenever you take a full backup of a particular federated database, you establish its backup boot file, which is the boot file that identifies the federated database in all subsequent backup and restore operations within the same backup set.
When a federated database has only one boot file, that boot file is the backup boot file. When a federated database has multiple boot files, you must choose one specific backup boot file for the full backup and any incremental and subincremental backups based on it.
When taking the first full backup in a backup set, you specify a backupBootFilePath that describes the current location of the backup boot file. The backupBootFilePath is saved as specified in the backup, where it serves as a key for validating subsequent requests for incremental backups and restore operations. For example, whenever you request a restore operation in the same backup set, you must match the saved key by specifying the exact same backupBootFilePath. The restore operation uses the backupBootFilePath simply to verify that the requested federated database is the one archived in the designated backup; the operation does not interpret the path as the location of an existing boot file or as the location in which a boot file is to be restored.
Developing a Backup Strategy
To ensure the safety of critical data, you should develop a backup strategy before problems arise. Developing a backup strategy involves:
Estimating the disk space required to perform and store backups.
Defining a backup schedule.
Note:Always perform a full backup before a software upgrade in case you need to restore the data to its prior format because of problems with the software upgrade.
Estimating the Disk Space Required for Backups
The amount of free disk space required to execute a full, online backup of a federated database can be as much as two times (2X) the current size of the database. This figure has two components: 1X represents the space required to store the backup volumes and 1X represents the potential increase in database size while the backup is in progress.
Note:The 1X figure given for database growth during a backup assumes that every container is updated while the backup is in progress. This may or may not be a reasonable assumption for your federated database backup. For a discussion of database growth during an online backup, see Increased Space Requirements Due to User Access.
You can decrease the space required to store a backup in two ways:
Process the backup volumes as they are produced to compress them or move them to another medium; see Processing Backup Files.
Note: Objectivity/DB allows you to override the default storage capacity (1 MB) of the backup volumes. When moving backup volumes from disk to another backup medium, you can decrease the amount of disk space required for temporary storage by decreasing the backup volume capacity.
Execute an incremental backup. Containers that have not been updated are not archived.
You can decrease the amount of database growth during a backup in two ways:
Perform the backup when usage is light. This slows the rate of database growth.
Execute an incremental backup. This decreases the total time required to perform the backup and thus the time during which the database can grow.
Defining a Backup Schedule
A backup schedule defines how much data is archived at what times. It provides a means of administering data backups and informs users when backups will occur. Informed users can request changes to the backup schedule to improve the security of critical data given their pattern of usage.
For a small federated database, daily full backups can be practical. For a large federated database, however, daily full backups are impractical because of the time required to complete a full backup, and the space needed to execute and store full backups. Therefore, most backup schedules involve:
A full backup at the beginning of the week (or some other defined cycle).
Incremental backups during the week (or cycle).
For example, as a normal routine, you might perform a full backup each Sunday and incremental backups every weekday.
Guidelines for Defining a Backup Schedule
To help you choose the length of the cycle, and the frequency of incremental and subincremental backups, observe the following guidelines:
Match the backup frequency to the rate at which critical data is updated. Ideally, you should make sure that every modified container with critical user data is in at least one backup.
Avoid frequent full backups if the amount of data to be archived is large.
Build in some redundancy by taking several successive incremental (or subincremental) backups of critical data. Doing so preserves most of the modified containers in multiple backup files, reducing the risk of losing many days’ updates if one of the backup files is damaged.
Example Backup Schedule
Table 11‑2 shows a sample schedule for a federated database that is updated daily during the week.
Table 11‑2: Sample Weekly Backup Schedule 
Day
Level
Days’ Changes Backed Up
Sunday
full
(full backup creates a new baseline)
Monday
incremental
Monday
Tuesday
subincremental
Tuesday
Wednesday
incremental
Monday–Wednesday
Thursday
subincremental
Thursday
Friday
subincremental
Thursday-Friday
Performing a Backup
Warning:Do not backup a federated database while either Tidy or oogc is running, because these tools may delete objects referenced by the backup.
The basic way to back up a federated database is to:
1. (Recommended) Run CleanupFd to ensure that locks left by any incomplete transactions are released.
2. Run Backup with the following options:
An option specifying the backup level (-full, -incremental, or -subincremental)
The -destination option specifying the directory for the backup files
The -bootFile option specifying the backupBootFilePath for the federated database (see Backup Boot File).
Example This command runs a full backup of the federated database whose backup boot file is mfgFd, and stores the backup files in the directory /fdb/backups. Because the command is executed in the directory containing the backup boot file, the backupBootFilePath is the file’s simple name.
objy Backup -full -destination /fdb/backups -bootFile mfgFd
 
You may perform only one backup on a federated database at a time. You use different options if you want to customize your system of backups; see Performing a Customized Backup.
If a Backup Fails
Because backups of corrupted federated databases often fail, you can use routine backups as opportunities to check for database corruption. If you run Backup from a backup script, make sure that the script checks the tool’s return status.
The Backup tool cannot recover from errors that occur during its execution. If a backup fails at any time during the backup process, you must restart the backup. An aborted backup event has no effect on the existing federated database.
Restoring From a Backup
You restore a federated database by running Restore with options specifying the point of restore and the -bootFile option specifying the backupBootFilePath you specified when creating the backup (see Backup Boot File).
Restoring a federated database restores its individual files—that is, its data files and backup boot file. You can restore a federated database’s files to their original locations.
The following subsections describe:
Specifying the Point of Restore.
Restoring Files to Their Original Locations.
If a Restore Fails.
Usually you restore from the most recent backup event. However, if you want to restore a federated database because you have detected corruption, try to determine when the corruption occurred and restore from the most recent backup before the time of corruption. If you cannot determine when the corruption occurred, you can restore from a recent backup and then test the restored federated database for corruption—for example, using the oocheck tool (available from Objectivity Customer Support).
Restoring a federated database automatically consolidates fragmented space, so it is normal for the restored files to be significantly smaller than the original files.
Specifying the Point of Restore
When the point of restore is represented by a basic backup, you specify it with the -time option indicating the time at which the backup was taken, and the -source option indicating the directory that contains the backup files to be restored.
You use different options if you want to restore from a customized backup; see Restoring a Customized Backup.
You express the -time option as an integer YYYYMMDDHHmm containing up to 12 digits that represent component times as follows:
YYYY
Year.
MM
Month of the year (01 to 12). For example, 02 is February.
DD
Day of the month (01 to 31).
HH
Hour of the day (00 to 23). For example, 00 is 12:00 A.M. midnight, 01 is 1:00 A.M., 13 is 1:00 P.M., and 23 is 11:00 P.M.
mm
Minute of the hour (00 to 59).
For example, 201005150030 specifies 12:30 A.M. the morning of May 15, 2010.
If no backup in the specified directory corresponds exactly to the specified time, Restore searches the directory and selects the latest backup that was started prior to the specified time. Thus, if you specified 201005150000, but no backup was taken starting at 12:00 A.M. (midnight) on May 15, Restore would select the last (or only) backup taken on May 14, 2010 (if such a backup exists in the desired directory).
If the selected backup is incremental (or subincremental), Objectivity/DB automatically restores the full (and incremental) backup(s) on which the selected backup is based. However, the files for these backups must reside in the same location as they did when they were first created, because Objectivity/DB finds them by consulting the archived backup diary.
Restoring Files to Their Original Locations
You typically restore a federated database’s data files to the same physical locations (host and directory) where they resided when they were archived. When you do this, the backup boot file is restored to the current working directory.
To restore a federated database’s files to their original directories:
1. Verify that the backup files and the original directories exist and are accessible.
2. Run Restore with point-of-restore options (page 123) and the -bootFile option specifying the backupBootFilePath for the federated database.
Example This command restores the federated database identified as mfgFd from the backup that was started on or before February 6, 2010 at 3:30 A.M. and that was archived to the /fdb/backups directory. The restored files are placed on the hosts and directories from which they were archived.
objy Restore -time 201002060330 -source /fdb/backups -bootFile mfgFd
 
Obtaining Catalog Information
To display the catalog information for an archived federated database, run Restore with the ‑dumpCatalog option, the point-of-restore options, and the backupBootFilePath for the federated database.
Warning:Do not run Restore with the -dumpCatalog option in a directory that contains a system-database file for the federated database. Doing so overwrites and then deletes any system-database file in the current working directory.
Example This command displays catalog information for the federated database identified as mfgFd from the specified point of restore.
objy Restore -time 201002060330 -source /fdb/backups -dumpCatalog -bootFile mfgFd
 
If a Restore Fails
A restore operation fails in any of the following circumstances:
If the destination locations for the restored files are inaccessible.
If any of the required backup files cannot be found.
If you are restoring data files to their original locations, and you run Restore in a directory that already contains a file with the same name as the backup boot file.
This restriction safeguards the backup boot file from accidentally being overwritten by a restored version of the file.
The Restore tool cannot recover from errors that occur during its execution—for example, if backup volumes cannot be located or if a destination directory does not exist. If a restore fails at any time during the restore process, you must restart the restore. However, a failed restore can leave behind both files and locks. Therefore, before you restart the restore, delete any files that were restored before the failure occurred and restart the lock server.
Managing Backup History
You can display the backups for a federated database and delete unwanted backups.
Displaying Backup History
You can list some or all of the backups for a specified federated database. To do so, run QueryBackupSet:
If you have taken basic backups, you can specify the -time option to display information about the latest full backup started on or before the specified time, along with any incremental backups based on it.
The value of the -time option is an integer YYYYMMDDHHmm containing up to 12 digits that represent component times; for details, see Specifying the Point of Restore.
If you have created explicit backup sets for a customized system of backups, you can specify the -set option to display information about the backups in the specified set.
You can omit both the -time or the -set option to display information about all basic and customized backups.
You can execute this command when a lock server is not running or to bypass a running lock server; to do so, use the -standalone option.
Deleting Unwanted Backups
You can delete an unwanted backup set and the corresponding information in the backup diary. To do this, run DeleteBackupSet, with the -set option specifying the name of the set to be deleted.
If you want to delete a basic backup, you must first use QueryBackupSet to get the name of the implicitly created backup set containing the backup.
For consistency, you may delete only entire backup sets, not individual backups in a set.
Processing Backup Files
You can run custom programs or shell scripts to pre- or post-process backup files while a backup or restore is in progress. To do this, run Backup and Restore with various -procfiles options followed by the name of your program or shell script.
Although you can use this feature with any program or shell script you choose, the most common application involves conserving disk space by:
Compressing backup files as Backup produces them
Uncompressing backup files before Restore reads them and recompressing them after Restore restores them
Your custom program or script should exit with a value of zero upon successful completion, and nonzero otherwise. Backup and Restore terminate with an error message if the system call to run the program or shell script returns a nonzero value.
Processing Backup Files During a Backup
To run a program or script after Backup completes writing each backup file, you use Backup with the -procfiles option followed by the program or script name. During the execution of Backup, the name of the file just written and the total size in bytes of the backup files written so far are passed to the program or script as command-line arguments.
Processing Backup Files During a Restore
To run a program or script before Restore opens each backup file for restore, use Restore with the -procfilesbef option followed by the program or script name. The name of the file about to be restored is passed to the program or script as a command-line argument.
You can also run the same or a different program or script after Restore finishes restoring each backup file by using the -procfilesaft option followed by the program or script name. The name of the file just restored is passed to the program or script as a command-line argument.
Example Assume that mycompress is a user-defined program that compresses a single file, and myuncompress is a user-defined program that uncompresses a single file.
The following backup compresses each backup file as soon as it is produced:
objy Backup -full -destination /fdb/backups -procfiles mycompress -bootFile mfgFd
 
The following restore uncompresses each backup file before it is restored and to recompress it after it is restored:
objy Restore -time 201002060330 -source /fdb/backups -procfilesbef myuncompress -procfilesaft mycompress -bootFile mfgFd
 
Customized Backups
You can customize your backup scheme for more fine-grained administrative control. A system of customized backups allows you to:
Use up to ten backup levels.
Explicitly create and name any number of backup sets.
Explicitly associate each backup with a backup set.
Explicitly specify a naming prefix for sets of backup files.
In contrast, a system of basic backups has up to 3 backup levels and relies on Objectivity/DB to create and name backup sets and files implicitly.
Backup Structures
Customized backups require you to manipulate lower-level administrative structures explicitly. Consequently, you should become familiar with the terms in this section.
Backup Events and Backup Sets
An individual backup, regardless of its level, is called a backup event. Backup events are grouped into backup sets for administration purposes. You can define the semantics for your backup sets. For example, one backup set can represent an entire month of federated-database backup events.
The Objectivity/DB backup and restore tools require you to reference customized backup events by their encompassing set names. Each backup set must have a unique name, and each backup event must have a unique name within the scope of its encompassing set.
Backup Medium and Backup Volumes
The backup medium is the medium used to store the physical backup of a federated database. You normally write backup files to your disk.
Each backup event is stored as one or more files, or backup volumes. When you initiate a backup event, you specify both a volume name prefix and the backup volume capacity. The name of each backup volume consists of the volume name prefix plus a sequential numeric value. For example, if you assign the volume name prefix myVol, the Objectivity/DB backup tool assigns the first volume of a federated database backup the name myVol_1. If a second volume is generated, it is given the name myVol_2. Multiple volumes are generated only if the backup size exceeds the backup volume capacity.
During a backup, you cannot append data to an already existing backup volume. Consequently, each backup volume contains data from at most one federated database and at most one backup event.
Figure 11‑1 shows the relationships among the backup medium, sets, events, and volumes. Keep in mind that sets and events are only logical constructs. The physical entities are the medium and the volumes.
Figure 11‑1 Backup Medium, Sets, Events, and Volumes
Backup Levels
Objectivity/DB supports both full and incremental backups with a system of ten user-specified backup levels. You specify the desired level of backup when you run the Objectivity/DB backup tool.
During a full (or level-0) backup, the entire contents of a federated database are archived to the backup medium. During an incremental backup (backup levels 1 through 9), only a specific portion of the data is archived to the backup medium: those containers that have changed since the most recent lower-level backup.
Table 11‑3 summarizes which containers are backed up at each backup level.
.
Table 11‑3: Backup Levels 
Use This Level
To Back Up
0
Entire federated database (including all databases and all containers within each database regardless of whether they have been updated).
1
All containers updated since the most recent level‑0 backup
2
All containers updated since the most recent backup of level‑1 or level‑0
3
All containers updated since the most recent backup of level‑2, level‑1, or level‑0
n
All containers updated since the most recent backup of level‑n–1, level‑n–2, …, or level‑0
Table 11‑4 shows which days’ changes are recorded in a 4-level series backups (assuming that the backups occur after business hours on the days indicated).
Table 11‑4: Successive Backups Using a Combined Strategy 
Day
Level
Days’ Changes Backed Up
Sunday
0
Entire federated database
Monday
1
Monday
Tuesday
1
Monday and Tuesday
Wednesday
1
Monday–Wednesday
Thursday
2
Thursday
Friday
3
Friday
Saturday
3
Friday and Saturday
Basic and customized backup levels correspond as follows:
A full backup (taken with -full) and is internally a level 0 backup.
An incremental backup (taken with -incremental) and is internally a level 3 backup.
A subincremental backup (taken with -subincremental) is internally a level 6 backup.
Full Restore
Objectivity/DB always restores an entire federated database to guarantee the referential integrity of the relationships (associations) between databases and the logical integrity of the data within and across databases. Consequently, specifying a backup event whose level is greater than 0 as the point of restore causes Objectivity/DB to restore multiple backup events, including the point of restore itself, the last full backup before the point of restore, and any relevant intermediate backups.
Defining a Backup Schedule For 10 Backup Levels
When developing a backup schedule for up to 10 backup levels, use the guidelines in Guidelines for Defining a Backup Schedule.
Example Backup Schedules
Table 11‑5 shows a sample schedule for a federated database that is updated daily during the week. The schedule reduces the risk of losing many days’ updates if one of the backup volumes is damaged (This is because most modified containers appear on multiple backup volumes and because the number of events that Objectivity/DB must access during a restore is minimized.) Depending upon the size of the database, a level‑0 backup could occur either at the beginning of each month or at the beginning of each week.  
Table 11‑5: Backup Schedule Minimizing the Risk of Losing Data 
Day
Level
Days’ Changes Backed Up
Sunday
1 (or 0)
Since last full backup (or full backup)
Monday
6
Monday
Tuesday
6
Monday–Tuesday
Wednesday
6
Monday–Wednesday
Thursday
6
Monday–Thursday
Friday
6
Monday–Friday
Table 11‑6 shows a moderately low-risk backup schedule for an entire month under the assumption that archiving once a week to a previous level‑0 backup is too time consuming. In this example, the schedule in Table 11‑5 has been modified so that Sunday backups archive only the previous week’s changes.
 
Table 11‑6: Modified Low-Risk Backup Schedule Decreasing the Time Required to Perform Sunday Backups 
Day
Level
Days’ Changes Backed Up
End of month
0
Full backup
Weekdays of 1st week (daily)
6
1st weekday–day of backup
1st Sunday
2
Since last full backup
Monday—Friday of 2nd week (daily)
6
Monday–day of backup
2nd Sunday
3
Since 1st Sunday
Monday—Friday of 3rd week (daily)
6
Monday–day of backup
3rd Sunday
4
Since 2nd Sunday
Monday—Friday of 4th week (daily)
6
Monday–day of backup
4th Sunday
5
Since 3rd Sunday
If user access is heavy at all times during weekday business hours, then archiving the updates occurring over smaller periods of time may be necessary in order to decrease the time and space devoted to the weekday backups. The schedule in Table 11‑7 illustrates such a strategy.
Table 11‑7: Backup Schedule for a Heavily Used Federated Database 
Day
Level
Days’ Changes Backed Up
Sunday
1 (or 0)
Since last full backup (or full backup)
Monday
2
Monday
Tuesday
4
Tuesday
Wednesday
6
Wednesday
Thursday
8
Thursday
Friday
2
Monday–Friday
This schedule entails more risk than the schedule presented in Table 11‑5. For example, to restore from a backup performed on Tuesday, Wednesday, or Thursday, Objectivity/DB must access backup volumes from three (Tuesday) to five (Thursday) backup events, as opposed to two for the schedule in Table 11‑5. Moreover, until the Friday backup is complete, an updated container appears on only one backup volume during the week.
To contrast the safety of the two schedules, consider the following scenario:
Federated database corruption is detected during a failure of the Friday backup.
One of the Tuesday backup volumes is damaged.
For the schedule in Table 11‑5, the restore from the Thursday backup event is successful. Only Friday updates are lost. For the schedule in Table 11‑7, you must restore from the Monday backup. Updates made from Tuesday through Friday are lost.
Creating Backup Sets
All backup events must be associated with a particular backup set. You can associate a backup event with an existing backup set or you can create a new backup set using CreateBackupSet.
The name of each backup set for a particular federated database must be unique. The backup set information is maintained in the backup diary as part of the federated database and is archived during each backup event to protect against its accidental deletion or corruption.
Example This command creates a backup set named septemberBackups in the federated database named mfgFd:
objy CreateBackupSet -set septemberBackups -bootFile mfgFd
To execute this command when a lock server is not running or to bypass a running lock server, add the -standalone option.
 
See Managing Backup History for information about displaying and deleting backup sets.
Performing a Customized Backup
You back up a federated database using the Objectivity/DB backup tool, Backup, with options specifying where to store the physical backup and how to identify the backup for future reference. You must include the backup set name, the backup event name, the volume name, and the full directory pathname where the backup volumes are to be stored. When taking an incremental backup (that is, a backup whose level is greater than 0), you must place it in the same backup set as the full (level-0) backup on which it is based.
You must specify the federated database’s backup boot file; see Backup Boot File.
Example This command runs a full backup (level-0) of the mfgFd federated database to the mfgset backup set and names the backup event weeklyBackup. The storage location for the backup volumes is indicated using the -device option followed by the pathname /dba/mfgFd/backups.
objy Backup -set mfgset -backupName weeklyBackup -volume vol020401 -backupLevel 0 -device /dba/mfgFd/backups -bootFile mfgFd
 
You can process files as you take a customized backup by adding the -procfiles option; see Processing Backup Files During a Backup.
Restoring a Customized Backup
You restore a federated database by running Restore with options specifying the point of restore. For a customized backup, these options are the backup set name, the backup event name, the volume name, and the full directory pathname. In all other respects, restoring a customized backup is the same as restoring a basic backup; see Restoring From a Backup.
Example This command restores the mfgFd federated database from the Monday backup, which is a member of the dailyBackups backup set. The restored files are placed on the hosts and directories from which they were archived.
objy Restore -set dailyBackups -backup Monday -volume fdbVol -device /fdb/backups -bootFile mfgFd
 
You can process files as you restore a customized backup by adding the -procfilesbef and -procfilesaft options, which are described in Processing Backup Files During a Restore.