NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to Please jump across to the new site for the latest articles (and all old archived articles).



  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • Advertisements
  • This blog has moved!

    This blog has now moved to Please jump across to the new site for the latest articles (and all old archived articles).



  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Index backups for recovery

Posted by Preston on 2009-02-25

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?


5 Responses to “Index backups for recovery”

  1. VJ said

    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.



  2. Preston said

    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.

  3. VJ said

    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

    • Preston said

      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.

  4. VJ said

    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.


Sorry, the comment form is closed at this time.

%d bloggers like this: