We use cookies to improve your experience on our site and enable certain core website functionalities. For more information, visit our Privacy Policy page.

Accept
  • Insights

Backup/Restore of iManage 8.5 IDOL Indices

Brian Podolsky

2 min read

All Insights

For those of you interested in running the iManage 8.5 IDOL Indexer, Autonomy recently released a new revision of the WorkSite Indexer Administrator’s Guide (8.5).   It is available on the iManage support site, and includes an updated Chapter 6 on “WorkSite Indexer Maintenance.”    The document goes into explicit detail on how to properly back up and restore an 8.5 IDOL index.    (Note: you must exclude the entire WorkSite Index folder structure from normal backup agents, as this could corrupt the indices).

In summary, there are 3 types of items that need to be backed up, and then restored:

    1. All WorkSite Indexer configuration files (*.cfg)

 

    1. All WorkSite Connector files (*.db)

 

    1. All WorkSite Content index backups (the actual indices themselves)

The first two can be configured as simple robocopies of the production *.cfg and *.db files into a similar backup folder structure.    The third can be scheduled by updating each WorkSite Content *.cfg file to include particular options in the [Schedule] section.  The key thing to remember about the WorkSite Content is that the backup will be just about as large as your production WorkSite Content, so you would want to either make sure there is enough local hard drive space or available space on an accessible SAN LUN to store the backup copy as it is put onto tape.  This is something that needs to be considered when estimating the storage requirements of the system.

To restore the index from the backup, you need to ensure that the *.cfg files are in place.  If they are not, then copy these from your backup location into the appropriate production folders.  The next step is to restore the appropriate WorkSite Connector *.db files.     These aren’t really database files, but rather a timestamp to tell IDOL from which document modification date to start rebuilding the index.  For example, indexing all documents that were modified after 5pm last Tuesday.   Unfortunately, the timestamp looks like gibberish to the human eye, if you ever have to modify it.   From the Administrator’s Guide:

If no db file back up exists from the same time as the index data back up, the timestamp of the Connector db file can be manually modified to coincide with the time of the index data to be restored.

The WorkSite Connector db time should always be set to a time immediately before the index data back up in order to ensure that the WorkSite Connector begins indexing from a time that is synchronized with the index data. Setting the date time too early can result in unnecessary re-indexing and therefore impact disk space as well as performance; setting the date time too late can result in a gap of new content and edits that is not indexed.

For reference, the timestamp value stored in the WorkSite Connector db file is in EPOCH format (time since 12:00 a.m. January 1, 1970 in milliseconds). For example, a timestamp of “1256942003000” in the file translates to “22:33 UTC October 30th, 2009” in a standard date notation.

Figuring out how many milliseconds after midnight on January 1, 1970?  That sounds pretty daunting.  But there are conversion tools available online to help with this.     After each *.db file is in place, each WorkSite Content engine would need to be restored using the /DREINITIAL command pointing to the backed up Index.

Further details are available in the documentation, but the key takeaway is to avoid using Backup Exec or a SAN snapshot and expect a healthy restored index.  There are special steps that need to be taken to ensure a reliable backup.