Cassini uses Guru connections to backup all objects created on the tester including Test Data, Calibration Data, changes to Testplans and configurations. Backup connection is configured by having a Backup or Datalog type entry in the Guru Address Book Editor application. The green system button does NOT indicate backups are occurring, only that an Update Guru is connected. While not recommended, it is possible to configure different servers for Update and Backup, and not having a Backup entry or using command line flags to ignore any configuration is also valid reasons for a backup to no be created.
When an object is created or imported with Guru Browser, a local attribute is set with the name of the target destination (local.ri.sys.Copy1). If multiple "Backup" or "Datalog" connection types are listed, each relevant connection is added (Copy1, Copy2, etc..). This allows Guru to transfer the files when the system is not busy without impacting testing. After the file has been copied, the "local.ri.sys.Copy#" flag is removed.
To Configure a Backup Connection
See Guru Address Book, Updating Guru Connections for instructions on setting up two or three entries, one for Update, another for Backup, and possibly a third for Datalogs. For most environments, these should be the same Guru Server. When a Cassini system is first connected to a backup Guru Server, the operator must manually initiate a backup to force all objects created by this system before the connection was made to be transferred to the backup server. See "Force Backup with Sync Util" section below for that procedure.
Browsing Objects To Be Backed Up
All guru objects with "ri.local.COPY" attribute with the value being the name of the Guru connection that it will be copied to at the next backup attempt. Use Cassini's Browse Guru interface to quickly view these objects.
1. From a running Cassini window, launched from a Short Cut. Choose Program > Browse Guru
2. Then from Guru Browser on choose Keys > Key1=Copies menu.
3. Any objects have not yet been backed up will be listed under the name(s) of the Guru Address Book connections in the top left panel. Selecting the connection name in the left, the ObjClass in the middle, and then the Title on the right will display all of the objects attributes in the bottom panel. (See Figure 1) If nothing is listed, then all objects have been backed up. (See Figure 2)
4. If the System button is green, it is expected that these objects are sent to the target Guru server at the next connection attempt. The time depends on how often the connection failed prior to the last attempt. To prevent multiple clients from overwhelming a server when it comes online, the clients have a progressive delay that increases the duration of the next attempt. Choose System > Backup to force an immediate connection attempt.
5. If the listed objects do not disappear, then open the Guru Messages window by choosing System > Messages and look for and resolve any network errors. Contact [email protected] for more troubleshooting steps.
Figure 1: Guru Browser on local - Pending Objects to 'R&D' Guru Connection
Figure 2: Guru Browser on local - No Objects Pending Backup
Force Backup (New Tester Delivered)
Launch Sync Util and connect to the Guru Server and Sync Up. See "How to Sync Guru Objects (Force Backup)" in Using Sync Util to Backup and Update Local Guru.
Backups can be temporarily disabled by appending " -RiNoBackup" to the StartApp.cmd command to launch Guru in a mode that does not attempt to make backup connections or by removing the address book entry and restarting Guru. This configures Guru to NOT set the local.ri.sys.Copy1 attribute, thus when a connection is re-added or standard StartApp.cmd command is used to launch Guru, those objects are NOT automatically backed up. See Force Backup above to use the Sync Util to transfer newly created files (while configured to work without a backup).
See also Temporarily Disable Connections to Guru Server (Guru Server Commands) http://roos.com/docs/RBEH-AVDUPG?Open
Removing Local Journal
Guru uses journal stores attributes for every object on the local Guru to improve startup times. If the OS or disk write fails while writing to this journal it may get corrupted and cause unexpected behaviors like missing objects or incorrect attributes. This can be resolved by removing the contents of D:/RiGuru/local directory, that contains main and local journal files and their backups. The "main" files can be safely discarded and rebuild from the .GAB files in the repository. The "local" journal only stores attributes that start with "local." that are used primarily for backing up Guru objects and flagging objects as processed by Guru Agent. The local attributes are not shared with Guru Server and so do not require an update to be written to, improving the overall performance of Guru. This has the side effect of any objects that were flagged to be backed up are no longer flagged. The net result is that a user MUST use the Sync Util to copy the new objects to the Guru server.
Renaming Guru Connection
Another way that objects can be listed with a local.ri.sys.Copy1 attribute is if the backup guru was renamed prior to a network connection being established. This has the effect of orphaning the local guru objects with that attribute until a connection is added. The connection name must match the value of "local.ri.sys.Copy1" or the local.jrn and local.bak files must be removed and Guru restarted for this to be resolved. Force Backup with Sync Util may copy the objects, but the local Copy1 attribute will remain until Guru backs up the object directly.