To prepare for disaster, you should periodically back up the infrastructure when it changes. If the infrastructure does not change very frequently, you should back up the Symantec applications at least monthly. You should test the integrity of the backup and restore procedure as frequently as the organization workload permits.
On the Information Server, you must back up the Information Server database. The database is a Microsoft SQL Server 2005 Express or Microsoft SQL Server 2005 database. The database is named BV. Symantec Technical Support has a backup script that automates this backup procedure. The backup should be stored off-site.
If this backup file is subsequently restored to a different computer, the stored credentials data are invalid. All of the credential data must be reentered manually. This behavior is a security feature that is used to prevent an attacker from using a copy of the backup to retrieve your credentials. If you are safe from such an attack, you can keep the credential data active even when moved to a different computer. Symantec Technical Support has the BVCryptoKeyMover tool and can assist you to locate and use this tool.
If you employ any RMS Schedules to run queries or task lists automatically, you must back up the associated Scheduled Tasks files. The Symantec Information Server uses the Windows Scheduled Tasks subsystem to execute any schedules that users create. The associated files are found in %SYSTEMROOT%\Tasks\.
If you use bv-Control for Windows, you must back up the Enterprise Configuration Service (ECS) database, which contains all query engine settings. The database is in the Symantec\Control Compliance Suite\ECS\DATA directory on the ECS host computer.
The RMS bv-Control for UNIX snap-in contains a listing of UNIX target computers. The file that is the most critical is the scoping.mdb file. This file is typically located in the C:\Program Files\Common Files\BindView\bv-Control\UNIXShared folder, even if other CCS Data Collector files are located on another partition. For UNIX targets that have been configured to run with an agentless connection, this file should be copied to a protected archival location.
If this file becomes corrupt or unusable, you can do the following:
Use the RMS Console to create a query in the UNIX > Targets data source. The query should include the Target Name, Description, Operating System, Operating System Version, SSH Version, and SSH Port No fields.
UNIX targets that have been registered with an agent must be reregistered with the new Information Server. You can run the .setup.sh script on each UNIX target to perform the registration. You can also configure the bv-Config for UNIX to perform the registration. During the registration process for the agent, an option lets you register an additional Information Server. This option lets more than one Information Server use the UNIX target. The Information Server and the UNIX agent exchange encryption keys. In consequence, agents cannot reconnect to the new console when you restore the scoping.mdb database.