Indexing Version 2: Index Backup
For Indexing Version 1, backups of the index data were performed as part of the backup job. With Indexing Version 2, indexes are backed up separately using a dedicated subclient that is created by the system on the MediaAgent client.
When there are Indexing V2 enabled clients backed up to a MediaAgent, a dedicated subclient called IndexBackup is created on the MediaAgent to back up all Version 2 indexes on the MediaAgent. The IndexBackup subclient is automatically created a few hours after the first backup of an Indexing V2 enabled subclient occurs. Backups of the IndexBackup subclient also occur automatically when the Index Backup criteria are met.
The IndexBackup subclient has these characteristics:
- All content in the currently defined Index Directory is predefined as the content of this subclient. This cannot be changed.
- It backs up the index database using the File System agent on the Indexing MediaAgent, using the first suitable Storage Policy that it finds on that MediaAgent.
- It performs only full backups of the index databases.
- It cannot be deleted.
- The IndexBackup subclient appears 24 hours after a successful data protection job using Indexing Version 2 completes on the MediaAgent.
This is the storage policy used when backing up the Indexing V2 index. It has these characteristics:
- By default, the MediaAgent selects one of the storage policies that already exists for normal, primary backup operations. To see which policy is associated to your IndexBackup subclient, see Configuring the IndexBackup Storage Policy.
- You can change it to a different storage policy. See Changing the IndexBackup Storage Policy.
Note: If you backup data to tape libraries in your CommCell environment, then you should create a separate storage policy for index backups that uses a disk library.
An index backup job runs by default every 8 hours, driven by the schedule policy named System Created for IndexBackup subclients, which is created by the system specifically for backing up indexes. When this job runs, every Version 2 index that meets the index backup criteria is compacted, then backed up to storage.
Warning: Do not delete the schedule System Created for IndexBackup subclients. Deleting the schedule policy can interfere with the creation of index backup subclients.
To change the repeat interval for this backup job, see Modifying a Schedule.
The default criteria for performing an index database backup is 1 million changed objects or 30 days, whichever comes first. You can set the parameters that control the number of changed objects, or the number of days, since the last backup, to meet your specific needs.
The logic that controls aging of index backups follows these rules, in order:
- If no secondary copy is associated with the index backup storage policy, three versions of the index are kept on the primary backup storage. When a fourth version is created, the oldest version is aged off of the backup media when aging operation is performed.
- If a secondary copy is associated with the index backup storage policy, retention follows these two cases:
- If all index data on the primary copy gets copied to secondary storage, the latest three versions of indexes are present on both primary storage and secondary storage.
- A version of an index on the primary copy gets pruned only when there are more than three versions of that index on the secondary storage.
- If only part of the index data on the primary copy gets copied to secondary storage, secondary storage has the latest three versions of indexes that are copied to it. Indexes present only on primary storage are not aged from primary storage until more than three versions of the index exist on the primary storage.