We want to be able to do index recoveries, right? If something terrible happens on the backup server, being able to recover the indices is pretty important.
There’s something which is often forgotten however when it comes to index backups, and if you don’t know about it, you may get stung.
In some environments, when a client is decommissioned, the client is deleted from the resource database but the index is left in place. (I’m not a fan of this – if you want to continue to recover from a client, you should leave the client configured!)
NetWorker will only do index maintenance tasks on clients that are configured. These maintenance tasks are:
- Backup
- Recovery
- Upgrade
If you really want to be able to recover from clients at a future date, even if you’re not actively backing them up now, do you really want to risk that the indices for those clients are no longer available?
Hi,
It’s a really useful insight on index management in NetWorker. In my environment, a separate pool index is configured with one didicated tape for this, and still /nsr/index keep on growing only. Still i want to mention that, daily backups are recovarable upto 1 month and weekly for 3 months, and monthly are for 10 years. sometime the client ask me to do expire index for some client machines to manage /nsr/index space… I’m always getting fears , with the doubt whether i’m able to recover data, if i expire clients.
thanks
regards
VJ
I’ve seen many a situation where indices/clients are deliberately removed while still within their retention span, with intention to re-add them should recovery be necessary. It’s not what I’d deem a good solution – it’s like what I say about end users thinking that backup = archive (e.g., “I’m running out of space! I know, I’ll delete half the contents of my home directory then request it be recovered later!”)
The most critical issue caused by this though is that indices won’t be backed up, recovered or migrated between major versions, which can later be the source for major problems.
Hi Preston
i follow 3 pools and 3 groups, and 3 schedules in my NetWorker production setup namely weekly full,daily Incr and index pool. where, daily incr group is levels 1 2 3 4 from mon to thurs and Every friday is Full backup. Index pool is for backing up index and savesets copied to one separate Tape. Is this setup proper one ? Which is the command in NetWorker to backup the indexes only either incr and Full ?
Thanks & regards
VJ
Personally I never break up the fulls and incrementals into different groups. I think that technique originates from systems that don’t support backup dependencies; since incrementals depend on the fulls for complete filesystem recovery, logically it makes more sense to keep them in the same group.
My next suggestion is that using differential levels as you’re doing – 1 2 3 4, unnecessarily complicates the appearance of the schedule, and using 4 x incremental levels instead would be a simpler appearance.
Thus, I’d use a schedule of:
Sun – Incr
Mon – Incr
Tue – Incr
Wed – Incr
Thu – Incr
Fri – Full
Sat – Incr
I also tend not to split off index backups from regular backups, but this is as much as anything a personal configuration choice so if you want your indices going to separate pools, by all means continue to do so.
Indices will get appropriate level backups with each client backup that occurs. If you want to force a full index backup though for all machines, and you have all machines in a group, you can run (from the command line):
savegrp -O -l full groupName
where “groupName” is the name of the index group (or other group that has all clients in it). The -O option saves only bootstrap/index information, not the actual client data itself.
Thanks Preston.
Thanks for your inputs and best practices.
As now, It’s some big difficulty for me to change from full and incr running on two different groups, i would like to continue. Importantly now i changed the Incr group schedule is like incr incr incr incr from mon,tue,wed and thurs and Friday Full for WeekFull group schedule.
need your help again,if this alright.
–VJ