Unsolved
This post is more than 5 years old
2 Intern
•
308 Posts
1
7935
June 14th, 2016 01:00
The Overview of Networker Client File Index
The Overview of Networker Client File Index
Introduction
This article provides the brief introduction about the Networker Client File Index(CFI) and several steps to reduce the size of CFI.
Detailed Information
The NetWorker server maintains tracking information for save sets in both the client file indexes (CFIs) and in the media database.
Client File Index (CFI)
A CFI stores information about each file backed up by a NetWorker client. There is one CFI per physical NetWorker client. The stored information includes file characteristics such as owner, size, permissions, and modification and access times, as well as the timestamp of when the file was backed up. All files in a given save set have the exact same backup timestamp. This information is used to support browsable recoveries, which allow you to easily recover a client to a specific point in time.
As a save set ages, its CFI records are automatically purged to save space. The length of time that the records are retained is determined by the Browse policy attribute in the client resource. CFIs may require large amounts of space on the NetWorker server. Each record in a CFI uses approximately 160 bytes. The default path of a CFI is /nsr/index/hostname_of_client/db6.
Over time, the size of the online indexes on the NetWorker server can become prohibitively large. Reduce the size of these indexes by using the solutions suggested below. To reduce the size of the client file index. You can reduce the size of the client file indexes on the NetWorker server by using one or more of these methods:
Check 1: Remove save sets that comprise the oldest backup cycle from the client file index. Client file index entries for a full save set cycle include the last full backup and any dependent incremental or level saves. When you remove the oldest cycle, you free up disk space.
1. From the Administration window, click Media.
2. Click Indexes.
3. Right-click the appropriate client, then select Show Save Sets.
4. Select the save set with the oldest cycle to remove, then click Remove Oldest Cycle.
5. When prompted, click Yes to confirm the removal.
Results: After the Remove Oldest Cycle operation has finished, NetWorker updates the statistics in the Index Save Sets dialog box to reflect the current state of the client file index.
Check 2: Delete volume-based entries from the client file index. You can use NMC or the nsrmm command to delete volumes from the media database and client file indexes. The NetWorker server first cross-checks the indexes before it purges a volume. As a result, the volume might still appear in the Volumes window in NMC for a brief period of time.
1. From the Administration window, click Media.
2. Click Volumes.
3. Right-click the volume with the entry to delete from the online indexes, then select Delete.
4. Select one of these options to determine how volume entries will be removed:
- File and Media Index Entries.
- File Index Entries Only.
Check 3: Adjust the Browse Policy and Retention Policy attributes of clients backing up to the NetWorker server to shorten the period of time that entries remain in the client file indexes. This solution works only for client backups that occur after you change these policy attributes.
Check 4: Modify the browse time associated with a particular save set by using the nsrmm -w command. Unless the associated save set contains a large number of files, this method may not be a practical method to reduce the index size.
Use the nsrmm program to modify the browse and retention time of a save set after the backup has occurred. Use nsrmm with these options.
-e retention_time updates retention time
-w browse_time updates browse time
Use the -e and -w options with the nsrmm option -S (to specify a save set ID).
Note: The retention time must be later than the browse time, and the browse time must be later than the insertion time. The insertion time is the time that the save set record was most recently introduced into the save set database.
When the -e and -w options are used with nsrmm, these must be true:
- Retention-time is greater than the browse-time.
- Browse-time is greater than the insertion-time.
Both the browse and the retention time must be entered in time and date formats accepted by the nsr_getdate program. The EMC NetWorker Command Reference Guide.
KB Reference: Solving the Client File Index Riddle
Author: Fenglin Li
iEMC APJ
Please click here for for all contents shared by us.
bingo.1
2.4K Posts
0
June 14th, 2016 02:00
With respect to 'Check 4'...
Please be precise - we have to distinguish between a 'policy' and 'dates' :
- A policy is a relative period. It is only valid for future backups. And it is a resource.
- Dates are absolute timestamps. This is what is actually stored in the media db. The MDB does not know a policy at all.
If the backup has finished, the policies will be added to the current time and resulting dates will be stored in the MDB.
nsrmm can only change the entries in the MDB which are browse and retention dates for existing backups.
ECN-APJ
2 Intern
•
308 Posts
0
June 15th, 2016 21:00
bingo
Thanks for the comments, we've corrected the words.
Flynnryder
4 Posts
0
February 22nd, 2023 03:00
What is the maximum size allowed for client file index?
barry_beckers
393 Posts
0
February 22nd, 2023 04:00
as large as the NW server can hold in its filesystem that holds the /nsr/index directory (but you can even have individual client indices put unto another filesystem). I can't recall having seen numbers of the max size of an individual client index or the max size of the amount of files it can contain. We have some systems that have millions and millions of files.
However as there is a huge restraint on speed making backups of such dense filesystems, the possible issue of very large clinet indices "solves" itself when shifting those to BBB (block based backups) as then there is no longer a client index maintained.
This however leads to people who are actually responsible for the data in question and might need to restore it, if the need arises, cannot simply see what files and directories where there. It will need to have the backup mounted as iscsi device to sift through the files of a specific backup to see what was there at the time.
if needing to restore more than ten thousands of files, the advice is anyways to perform a whole (destructive) volume restore, ideally to another filesystem than where the original data is, as then you can compare things and pick out specific data, files or directories, or even the whole volume.
So the benefit of BBB for backup and restore speeds, has its challenges compared to regular filesystem backups wrg to seeing what is in backup (you can't see any files nor directories anymore in the client index). Backups being reported as always being a full is another, depending on the billing method you use. That one can be holding you back more than anything technically...