This section describes:
Notes on backing up and restoring multiplex servers and databases.
Special restrictions that apply to backup and restore operations in a multiplex environment
You can also use the restore operation to re-create a multiplex on a different system when no problems have occurred.
You can execute the BACKUP and RESTORE SQL commands only on the coordinator node. For complete syntax, see BACKUP statement and RESTORE statements in Chapter 1, “SQL Statements,” in Reference: Statements and Options. To back up the IQ store and catalog store on a multiplex database, log in to the coordinator using an account with DBA or backup authority. During restore operations, the database can be running only if you restore a backup of read-only files. When restoring files in a read-only dbspace, the dbspace must be offline.
Back up the IQ store as described in “Types of backups” in Chapter 12, “Data Backup, Recovery, and Archiving,” in System Administration Guide: Volume 1. The last step of both IQ-level and system-level restore operations is to propagate changes by synchronizing the secondary servers.
You may want to preserve the server.dbrlog.NNN files (stored in the write server’s directory under /repDirs/logfiles on UNIX or \repDirs\logfiles on Windows).
If you are using virtual backup, you must add to your system backup specification all the main store dbfiles that are specified in the backup. Use the stored procedure sp_iqfile to create the system backup list.
Use the stored procedures sp_iqbackupsummary, sp_iqbackupdetails, and sp_iqrestoreaction, the system views SYSIQBACKUPHISTORY and SYSIQBACKUPHISTORYDETAIL, and the db_backupheader utility to track backups and plan restore actions.
If you use symbolic links for raw device names, as Sybase recommends, make sure the system backup utility follows the symbolic link and backs up the device.
