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?

 

My colleague Brian Norris has an excellent suggestion in his blog about periodically capturing the client IDs within the NetWorker datazone.

I plan on making his suggestion slightly redundant for users of IDATA Tools – I plan to update the client-report utility to include the client ID to assist with this very strategy.

 

There was recently a discussion on the NetWorker mailing list that was sparked by someone asking what sort of LTO-4 library would be recommended by the community.

This led to some very interesting and useful feedback to the person posing the question. A lot of people had feedback about different libraries they’d used – both good and bad – and questions to ask, such as slot count and CAP/Mail slot size. I felt it was also important to weigh in on media movement speed, as I think this is often something which is disregarded when evaluating libraries – even though it often can play a factor in backup throughput, usability and perceived performance.

Rather than summarise myself, here’s what I had to say on the topic then:

Too often people worry about the speed and capacity of the media, and forget about the incidental factors, such as robotic movement times and even load/seek time on the media. These can play an important factor in backup and  – more importantly, really – recovery schedules. When it comes to measuring backup performance, the sequence of “returning to slot, picking next tape, placing in drive” can actually start to make a significant impact on what I refer to as your overnight “backup bandwidth”. If it takes say, 70 seconds for one library to do it and your drives write at 160MB/s, then that’s a 10GB interruption to your backups. If another library can do the same thing in 30 seconds, that’s just a 4.7GB interruption to your backups. (I’m deliberately excluding load/unload times of the media, because in a realistic comparison it would be the same drives in both libraries…)  Repeat that say, 30 times a night, and suddenly you’re deciding whether you can afford to lose 300GB in backup time a night or 141GB in backup time a night. For bigger sites, these numbers can actually become very important.

If you are considering a new tape library, be sure to ask about not only the “easy” numbers, such as how much it costs, how much maintenance costs, and how fast the drives read/write, but also the more challenging numbers – how much time it takes to move media around.

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha