The following steps can be used to try to resolve the issue and/or identify the wrong index and expire it:
a) See if the dbchecker utility can fix the issue:
- Stop NV
- Run the following command several times until the result shows no more rows deleted:
'C:\Program Files (x86)\Dell\NetVault Backup\util\nvmeddbcheck' compact
- Start NV and see if crashes persist
b) If crashes persist or the above command fails, Stop NV and temporarily disable index compression which should allow NetVault to remain online and stable.
To disable index compression edit 'C:\Program Files (x86)\Dell\NetVault Backup\config\mediamgr.cfg'
- Change 'Days of inactivity before an index is compressed (0 = never)' from default 30 to 0
- Change 'Hours between scans for indexes to be compressed (0 = never)' from default 12 to 0
- Start NV and confirm compression being disabled allows for NV to work as normal without crashes
c) If disabling compression helps bring some stability, we can then work to identify the saveset that corresponds to the offending row and note where the backup is located (which device).
If we can find the saveset, we can try to retire it so the offending row is deleted from the db, then we can scan it to recreate the row from the index on media.
If the row is still corrupt after scan, then the index is the one that is corrupt and we should discard that backup.
**Procedure to identify the problem saveset number:
- Tech Support should analyse the media manager trace to identify the last index file processed successfully.
- Knowing the file name of the last successfully processed index, we can workout the next index file name as being the culprit. Note that index file names are in Hexadecimal values.
- Once we get the problem index filename we can convert its path from hex to decimal to get the saveset number as per KB https://support.quest.com/netvault-backup/kb/95708/how-to-find-the-saveset-number-for-a-backup-index
- Once we have the saveset number we can find it and expire it from Explore Storage
