Welcome! » Log In » Create A New Profile

Freeing up index disk space

Posted by Michael Leone 
Michael Leone
Freeing up index disk space
November 14, 2018 09:59AM
I am confused about something. I have a client that has something like
100G under the index folder. Yet both the browse and retention for this
client are set to 30 days.

Now, I do mark the end of month savesets to have a 7 year
browse/retention, but even so, this seems excessive. (granted that are
lots and lots of small files on this client - over a million, which may
have something to do with it).

So, how can I go about cleaning up space? Ordinarily, I would change the
browse and retention dates to be like yesterday, and then "nsrim -X", so
they clean up and expire. But except for those EOMs, this client already
has a short browse/retention.

Hints welcomed. If I have to find the earliest EOMs that are still within
retention period and change those dates, and clean up like above, I will.
(and I think that's what I will need to do) But if there's something else
to try, I'd like to hear it.

Thanks


--
Michael Leone
Network Administrator, ISM
Philadelphia Housing Authority
1800 South 32nd Street
Phila, PA 19145
Hours: 8AM - 4PM EST
Tel: 215-684-4180
Cell: 215-252-0143
<mailto:michael.leone@pha.phila.gov>




--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
Re: Freeing up index disk space
November 14, 2018 10:59AM
In regard to: [EMC-DataProtection-L] Freeing up index disk space, Michael...:

> Now, I do mark the end of month savesets to have a 7 year
> browse/retention, but even so, this seems excessive. (granted that are
> lots and lots of small files on this client - over a million, which may
> have something to do with it).

You've just answered your question. A client with lots of small files
is going to have more index data in the client file index than one with
fewer but larger files. If you have 7x12x 1 million file entries, you're
going to have a big index.

> Hints welcomed. If I have to find the earliest EOMs that are still within
> retention period and change those dates, and clean up like above, I will.
> (and I think that's what I will need to do) But if there's something else
> to try, I'd like to hear it.

You can try the standard index check trio of commands that you would run
before a server software upgrade, but I doubt they're going to reclaim
much space. The way to reduce the size of your client file index is to
track metadata for fewer files.

Under NetWorker < 9.x, you could always split your browse and retention,
so that e.g. browse is 4 years but retention is 7, but the changes at 9.x
probably eliminate that as an option.

The solution, as sad as it is, is probably just buy bigger disks for
your NetWorker index volume.

Tim
--
Tim Mooney Tim.Mooney@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


--
This list is hosted as a public service at Temple University by Stan Horwitz
If you wish to sign off this list or adjust your subscription settings, please do so via http://listserv.temple.edu/archives/emc-dataprotection-l.html
If you have any questions regarding management of this list, please send email to owner-emc-dataprotection-l@listserv.temple.edu
This message was imported via the External PhorumMail Module
Re: Freeing up index disk space
November 14, 2018 11:59AM
Of course the size alone does not matter - it is the number of entries and their frequency (daily fulls?).
We also have one client with an index slightly bigger 100GB. And we just have one full/month which we keep for 18 months. Compared to your 7 years, a full backup of this server creates even more entries in the CFI than yours.
So - the number itself does not really scare me.

The first you should do is to verify what you really have.
If you want to shrink your CFI size you might set a save set to recoverable or even to recyclable (tape save sets only!):

nsrmm -o recoverable|recyclable -S ssid[/cloneid]

Instead of rebuilding the CFI (scanner -i) I would recover the whole save set to a temp directory and get my files from here. Saves a lot of time.

Another method to recover the data makes sense if the directories follow a certain structure (it is easy to remember the pathname). In such case you could directly recover even from a recyclable save set if you know the absolute pathname:

recover [options] -S ssid -a <absolute_pathname>

Keep in mind that NW will read the complete save set, though.
Sorry, only registered users may post in this forum.

Click here to login