clean files under index

[xcai1]

I have a disk space issue. I see these files under /nsr/index/apora/db6:
Jul 1 20:13 42c5dc1f.rec
Jul 1 20:13 42c5db71.k0
Jul 1 20:13 42c5db71.k1
Jul 1 20:13 42c5db71.rec
Jul 1 20:13 42c5d3ac.k0
Jul 1 20:13 42c5d3ac.k1
The files are generated everyday, so I have files from Jul 1 to today. I see another client only keeps from Sep. 25 to today. What will be affected if I delete the files on APORA (client name) from Jul 1 to Sep. 24? Or can I use some Legato command to clean them?

Sally

 

[605]

What you see are the database files for a client's file index. Each backup save set creates 3 files:
id_#.rec the database file
id_#.k0 \ the internal search table (index
id_#.k1 / files) for the records

The period these files are stored depends on the client's browse policy - different clients may have different policies/periods.

So you either shorten the browse policy or you add more disk space. Or you relocate a client's index to another location, which is very easy. But this is almost the same as adding more disk space.

However, deleting these file will result in the inability to do file level recoveries because the file information does not exist any longer. This is exactly what NW does automatically if it deletes a backup cycle.

 

[mlmmilkyway]

hi,
The clients must have two different browse/retention policy. If you change apora browse policy to match the other client, those older indexes should be removed by doing a nsrck. You could also the use indexes gui select apora and click on remove oldest instances. That should remove the older indexes also but one at a time. The retention policy is how long do I keep the backups, and the browse policy is how long do I keep the indexes online to easily retrieve a lost file. The retention policy should always be equal to or greater than the browse policy. If you need a file older that the browse policy you will have to restore the index to retrieve but you do save disk space.

Mark

 

[605]

hi mlmmilkyway,

sorry to say that but your statement is just incomplete.
For a file recovery without an existing CFI you have 3 choices:
- you can rebuild the CFI info with scanner (what you meant)
but you can also
- do a save set recovery to a temporary directory and recover your file(s) from here or
- if you know the filename or pathname you can use the recover option -a
recover -S ssid -a absolute_path[filename]

So i would consider to rebuild my CFI as last alternative.

 

[xcai1]

Thanks everyone. My client wants me to restore a directory /apps/Data/rdm/rdm25/vaults/tstvault on Feb 26, 2005. I see someone archived the old index files somewhere, so I have copied back these index files to /nsr/index/apora/db6/:
Feb 26 2005 4220029f.k0
Feb 26 2005 4220029f.k1
Feb 26 2005 4220029f.rec
Feb 26 2005 422002a1.k0
Feb 26 2005 422002a1.k1
Feb 26 2005 422002a1.rec
What else should I do? need I run "nsrck -L? -t date <clientname>"?

Sally

 

[605]

The key is the media db - copying the CFI files to the original location will not help at all.

The easiest may to do it is:
- find out the SSID and the volume
- mount the volume (if no jukebox)
- start this command
recover -S ssid -a /apps/Data/rdm/rdm25/vaults/tstvault