Index Cache Sharing - Deprecation FAQ

Table of Contents

Does deprecation of shared index caching change the sizing requirements for index cache volumes?

The recommendations given in Index Cache - Prerequisites remain valid following this deprecation.

Does local disk-based index cache placement reduce index cache availability?

Index cache availability remains effectively unchanged. In the Index Cache Server design, the time required to copy the index set back to a MediaAgent's local drive was practically the same as the time required to restore the index set from a disk copy. In large environments that are most concerned with availability and failover in the backup infrastructure, most are using disk and/or deduplication libraries. This produces the same results from the archived index sets, without adding the cost and burden of managing secondary caches on an index cache server.

What happens if the index cache is not accessible to the MediaAgent during a backup job?

During a backup job, if the job is moved to an alternate MediaAgent by the GridStor policy, the alternate MediaAgent pulls the required index set from the original cache directly from the previous MediaAgent that initiated the job.

  • If the previous MediaAgent is not available, an alternate MediaAgent executes a standard Index Restore operation to recover the required index cycle set from the copy sets in the storage library.
  • During a browse or restore operation, if the index set is not found in the local index cache on the MediaAgent, it is automatically restored.

Where is index data stored?

When a backup job runs, index data is written in two places:

  • During the course of the job it is written to the index cache on the data mover MediaAgent. If The Secondary Index Server feature is configured, a copy of the index is automatically created on the designated secondary MediaAgent.
  • During the archive index phase it is written to backup storage as part of the backup data.

What advantages does a secondary copy of index data provide?

If the primary MediaAgent or Storage Library is not available, the index restore process automatically tries to restore the index from any other available secondary copies, to avoid starting a new index cycle. Multiple copies make data protection more redundant, efficient and robust. If configured, the Secondary Index Server feature automatically creates a secondary copy of every index.

Does GridStor need shared index cache?

This was a requirement prior to Version 10, but the MediaAgent direct access methods introduced in Version 10 removed the need for a network-based sharing approach, because index data is automatically pulled from the MediaAgent that last ran the backup. Setting up local index caching on each MediaAgent is sufficient.

What happens if a backup job fails over to another MediaAgent midway through the job?

In most cases, the backup job, on failing over, gets the index from the previous MediaAgent. If the failover was due to the MediaAgent itself going down, and the partial index cache created on the previous MediaAgent is no longer available, the backup job restarts.

What is the preferred load balancing setting to use with GridStor?

If the client and MediaAgent are on separate machines (that is, they are not in a LAN-free backup arrangement), the preferred load balancing setting for GridStor is round robin. Round-robin load balancing equally distributes backup jobs across all available MediaAgents, which in turn ensures balanced growth of index caches on all MediaAgents.

Round robin can be set even for LAN-free backups. The code is smart enough to automatically use LAN-free whenever it detects that the client and MediaAgent are collocated on the same box.