Index Cache - FAQ
- Why is the index getting restored very often?
- How do I identify files and folders associated with the index?
- How is the index maintained during backups?
- Can an index cache be placed on a network drive?
- What local index cache configuration is recommended?
- How is the index processed during browse and restore?
- Must the MediaAgents participating in GridStor be running the same software version?
- Can index cache directory be hosted on same volume as other data?
- Does upgrading change index retention time?
- Why is the index cache full even after setting aggressive retention rules?
- What happens to an incremental backup when the prior index is not in the local index directory?
Several conditions can cause frequent index restores. The index gets restored when:
- Index retention criteria make the existing index age out. These criteria may be more strictly set than actually necessary. See Retention Parameters.
- Space is not sufficient on the disk hosting the index cache, causing frequent event-driven cleanup operations. See How Does Index Cache Cleanup Work?.
- A new index becomes useless because the job that was creating it got killed before it was finished.
- An index grew larger than 2 GB, and was automatically renamed.
Use the Find Data option in the CommCell Console, with *.* as the filter criteria.
Whenever a backup is initiated, the system performs these steps to create or maintain the index:
- For Full or Synthetic Full backups, a new index is created for each job. For incremental and differential backups, the index from the last successful job is reused.
- Records the changes to the data objects (such as files and subdirectories, database objects, and mailbox objects) in the subclient along with information about where it is stored in the media..
- After the backup completes, the system archives the index directory.
SnapProtect software Version 10 no longer supports the Index Cache Server or Index Cache Using Network Share features that allowed placing an index cache on a networked resource. Existing network-based index caching arrangements continue to operate as they were configured, but if you create a new index cache, it must be on a local drive. If you modify an existing network-based index cache, you must move it to a local drive.
Optimal performance is realized with solid-state drive (SSD) technology for your local index cache disk. This is particularly important for:
- NAS filers running NDMP backups
- Backing up large file servers
- Ensuring maximum performance when it is critical
During a browse or restore operation, the system processes the index as follows:
- The system returns the list of files for browsing by reading the most recent version of the index. If the most recent version does not contain the necessary information, the index prior to the most recent is read, and so on, until all the necessary information is obtained.
- The index is used to access the appropriate archive file to restore the data. If the index is either not available in the index cache, or not accessible to a browse or restore operation, a caution icon is displayed at the root level while performing the browse.
If the required index is not obtained, the system returns partial results based on available index data, and an icon similar to the warning message is shown.
Yes. MediaAgents that participate in GridStor should be upgraded together, so that all MediaAgents in the group are running the same version of SnapProtect software.
It is possible to host index cache data with other data. However, we recommend that the index cache is hosted on a dedicated volume. Index caching requires significant disk space and drive activity, and if it shares the disk used by the system, or even other data, indexing performance will be reduced.
If you have changed your Index retention time value from its default, the new value is retained following an upgrade.
The index takes up significant disk space, so if it is available in primary storage, it is not required to maintain the index cache for a longer time. The required index can be quickly restored from the MediaAgent itself. If you still need to maintain the Index for longer term, you may do so by changing the value of Index retention time. See Retention Parameters.
The aged Index files may not be getting pruned. Verify this by analyzing the index cache cleanup report on the MediaAgent computer:
This report displays a list of index files that were not cleaned up during the cleanup operation, along with a reason for their retention. See Index Cache Cleanup Report.
If the prior index is not on the local drive of the MediaAgent that is running an incremental backup job, the prior index is copied to that MediaAgent from another source, and the incremental backup proceeds. The order in which the prior index is obtained is:
- If the prior index is available from the MediaAgent on which it was created or last updated, it is copied from that MediaAgent.
- If the index is not available on the prior MediaAgent, is it restored from the storage media to which it was written (such as a tape).