Previous Chapter : Next Chapter : Top
BACKUP.UNET uses a number of tables to control and maintain the networked backup environment. These tables together make up the BACKUP.UNET catalog.
The tables are used by the BRP and/or IOP daemons. The majority of the tables are maintained locally and are therefore different on each host. Three tables Sys, SysPool, and Pool are global tables maintained by the syncro servers and as such, should be identical on every host.
When the daemons are started, the tables are checked for consistency and the global tables are synchronized with the syncro server. Any modification to global tables is first made to the syncro server hosts and then to the other hosts when they access the tables. For more information on the syncro server hosts, see Chapter 14, BACKUP.UNET Daemon Reference.
A number of utility programs exist that can be used to synchronize, repair, and edit these tables in the event a problem should arise. For more information on these utilities, see page 12 6, BACKUP.UNET Table Repair Procedures and Chapter 13, BACKUP.UNET Utility Reference.
The BACKUP.UNET catalog can take up a large amount of disk space. Space consumed varies, based on the number of files that are backed up. A good rule of thumb is 112 bytes per file for a full backup and 40 bytes per file for an incremental backup. For example, if BACKUP.UNET were to back up 1000 files (five full and 20 incremental backups), the total catalog size would be about 1.5 Mbytes.
Each BACKUP.UNET table in the $NBK/nbk-TABLES' sub directory consists of three files:
For example, 'Pool.dat', 'Pool.lok', and 'Pool.idx' make up the pools table.
This directory holds the CISAM tables used by BACKUP.UNET. These tables make up the BACKUP.UNET catalog. The catalog contains online data information that describes backed up data, and information on volume, device, and system management.
The 'nbk-TABLES' directory contains two kinds of information:
WARNING: Do not edit the contents of these tables. Changing the contents of these tables can crash the system. If you think these tables need to be changed, contact MTI Customer Service for assistance.
---------------------------------------------------
Table Name Description Used By
---------------------------------------------------
Sys System table. Containseach BRP/IOP
system in BACKUP.UNET.
Pool Pools table. Contains each BRP/IOP
available pool.
SysPool System to Pool table. Relates BRP/IOP
which system services which
pool.
---------------------------------------------------
.
-------------------------------------------------------------
Table Name Description Used By
-------------------------------------------------------------
BFI Backup File Instance table. Stores BRP
the backup file instance and is the
basis of the catalog. Stores the
INODE information and which vol
ume of a dump the file is on.
Link Link table. This table points to the BRP
BFI record where the data is stored
if a file is linked.
Overflow Overflow table. If the filename is BRP
too long for the BFI, the remaining
part of the name is stored in this
table.
Dumpseq Dump Sequence table.Contains a BRP
list of files logically associated with
a backup, by directory and in alpha
betical order. BRP
Event
Event Event table. Records the history of BRP
all backups that have been run.
DumpVol Dump Volume table. Relates the BRP
volumes to the backup, and which
segment was used.
Vol Volume table. Records all the details IOP
of a backup volume. IOP
Dev Device table. Contains the
devices available on this host.
Dev Device table. Contains the devices IOP
available on this host.
PoolDev Pool to Device table. Associates IOP
devices to pools.
Operator Operator table. Contains the users BRP
who are operators and administra
tors for this host.
Configure Configuration table. Maintains con BRP
figuration cards used by the com
mand line interface.
-------------------------------------------------------------
BACKUP.UNET stores information about its backups in online tables. These tables contain data and information about backup volumes used in a backup cycle. To manage catalog storage space you can offline the backup information or use the nbk.sqztbl utility.
Between the time a backup volume is created and it is recycled (if ever), you may want to free disk space used by backed up data files. This process is called offlining. You can offline backup information either automatically or manually.
To recreate the data information in the tables once it has been offlined, the volumes must be explicitly onlined. Onlining is the process of recreating the the backup data information for a specified backup from the appropriate backup volumes. You must online the backup data information before you can restore from it.
Three BACKUP.UNET utilities, NBKdb_index, NBKdb_fixup, and dbcheck help you repair or rebuild damaged or corrupted table index files.
To view the contents of a table or check the validity of a table that you suspect may be out of sync, use the dbcheck utility and specify the -i option.
To rebuild an index or regenerate empty tables (both data, '.dat' and index, '.idx' portions) use the NBKdb_build utility (refer to page 13-7 for more information). During BACKUP.UNET installation, an index is built automatically.
If an index (.idx) file is damaged or corrupted to the extent that it cannot be used, or cannot be repaired with the dbcheck utility, rebuild the index using the following steps:
If a host stops abruptly or the daemons are arbitrarily killed, then the index (.idx) may be out of sequence with the data (.dat). Use the dbcheck utility with the -y option, specifying the table to be repaired.
Note: If an '.idx' file is damaged or corrupted to the point where it cannot be used, or cannot be repaired with the dbcheck utility, you can rebuild the file using the NBKdb_index utility (refer to page 12 6).