User manual

Appendix F: Disaster Recovery with Third-Party Software
264 Cobalt RaQ XTR User Manual
The backup makes copies of the archives:
/var/cobalt/backups/cce.tar
/var/cobalt/backups/cobalt.sql
When the backup is complete, the post-backup script
cobalt_postbackup
deletes the archives.
During the disaster-recovery process, the entire RaQ XTR server must be
restored. This restores the archives to the directory
/var/cobalt/backups.
When the backup is complete, you must reboot the RaQ XTR; the server does not
reboot automatically. During the reboot process, the
cobalt_restore
startup
script detects the archives and restores the configuration databases. At this point,
everything should be in a consistent state and disaster recovery is complete.
Legato NetWorker works in a different manner: it recovers the databases during
the file recovery phase since this service permits per-file scripting at both backup
and recover time. The postgresasm and cceasm scripts are used for this purpose.
Locking the UI databases
For all types of backup, the databases for the user interface are locked for as short
a period of time as possible. For Arkeia and NetBackup, the UI is locked during
the pre-backup creation of the database archives. NetWorker locks the UI only
during the backup of the individual databases.
This is also true for modifications to system configurations that do not use the
Cobalt UI. After disaster recovery, the machine may be in an inconsistent state if
the configuration databases and the system configuration files do not agree.
This begs the question: “So why not lock the UI until the backup ends?”
Unfortunately, that would entail shutting down CCE for the duration of the
process and locking
postgres
for an unknown duration while the machine writes
to the backup server. Because this would affect both the responsiveness of the UI
and, potentially, WebMail, Cobalt decided against locking the UI for the duration
of the backup process.
Cobalt recommends that you schedule backups for times when it is unlikely that
system configuration changes are in progress. Partly for this reason, most backup
systems automatically schedule backups for the early hours in the morning.
☞
Important: Changes to the machine configuration should not be
made during the backup of the machine; otherwise, the
configuration of the machine and the configuration databases may
not be synchronized after the disaster-recovery process is complete.