Start a Conversation

Unsolved

This post is more than 5 years old

2054

April 22nd, 2016 13:00

index: retention

Hello,


This is maybe a bit lame question , do I need any client index backup except the last one? We have some clients where there are a few backups with 10Y retention, so I have the index backup for every day since we started using networker... (for some systems the sum of index backups is more than 10T..).


TIA

Istvan

2 Intern

 • 

14.3K Posts

April 23rd, 2016 12:00

In theory, last one should do just fine under ideal conditions that in case you need to restore it this index will be available and healthy.  Since that is usually not the case, you might wish to limit retention of index backups not to be 10y for example, but rather 2-3 weeks (or whatever works for you).

116 Posts

April 23rd, 2016 14:00

How can I limit the retention of index backups? If it's done by the savegroup then the retention will be the retention of the client within the group. That case I have to use no index save for each savegroup and make index backups individually. I don'T like this idea, because these index backups could be useful when I have to recover the server...

If I'll have only 2-3 weeks retention for every index backup then I have to make sure that if a client is not doing backups any more then the last indexes are kept.

Is it not better to run a script which removes all indexes which are eg. older than 3 weeks + also check that eg. 10 versions should be kept?

2 Intern

 • 

14.3K Posts

April 23rd, 2016 15:00

You have several options. For example it is still a custom to have index group and you can different retention there. Or you can have dedicated pool for index and bootstrap and set retention on pool level (which will override retention set elsewhere). You can script it too, but I prefer always solution coming from normal application setup whenever possible.

116 Posts

April 24th, 2016 22:00

If I set the retention for the pool, how can I keep the last index backup of a client eg. when I make a final backup before power off which should be kept eg. for 1 year?

116 Posts

April 25th, 2016 01:00

Oh, I see now... pool retention forces the retention settings during backup but ss retention is still effective - right?

2 Intern

 • 

14.3K Posts

April 25th, 2016 01:00

If you set retention on pool, that retention will be used automatically.  If you wish to change it, you can manually change it. I use standard retention for everything (in my case 14 days).  If I need to keep something longer, I only extend b/r policy for that specific thing and this is kept longer in online index.  Since all clients (in my case) are part of the index group, they get backed up at least once daily and that means online index backup is made daily and I can go back at any time I need with at least 14 copies to choose from.

2 Intern

 • 

14.3K Posts

April 25th, 2016 01:00

If you will use pool retention, then pool retention will override any retention you set previously on client.

For example, if you have clientA with b/r 1 month, but you assign this backup to run to pool 1y where you set r policy to be 1y then backup for that clientA to pool 1y will have retention of 1y regardless of 1 month set on client.

If you have uniform backup retention, then best thing is to have that set everywhere and for ad hoc backups requiring higher retention, create separate client with such retention and place it to appropriate pool.  I personally have retention of 14 days for example and I use DD as target.  Anything outside that retention, goes to tape and I have pool for each retention (typically 3 months, 1 year and 7 years).  While online index will reflect for how long this is kept, index itself I save only with standard backup retention.

My impression is that you wish to shrink usage of /nsr/index and therefore you would like to remove some older backups from index (but keep them in mdb).  If you do this, and this can easily be done, then you would need to keep backup of online index for longer for sure (so that you can restore back index that you removed).

No Events found!

Top