Each of these on their own represents significant benefit to the average NetWorker site, and I’d like to spend some time discussing the functionality they bring.<\/p>\n
[Edit\/Aside: You can find the documentation for NetWorker 7.6 SP1 available in the updated Documentation area on nsrd.info<\/a>]<\/p>\n In some senses, cloning has been the bane of the NetWorker administrator’s life. Up until NW 7.6 SP1, NetWorker has had two forms of cloning:<\/p>\n A lot of sites use scripted cloning, simply due to the device\/media contention frequently caused in per-group cloning. I know this well; since starting working with NetWorker in 1996, I’ve written countless numbers of NetWorker cloning scripts, and currently am the primary programmer for IDATA Tools, which includes what I can only describe as a cloning utility on steroids (‘sslocate’).<\/p>\n Will those scripts and utilities go away with scheduled cloning? Well, I don’t think they’re always going to go away \u2013 but I do think that they’ll be treated more as utilities rather than core code for the average site, since scheduled cloning will be able to achieve much of the cloning requirements for companies.<\/p>\n I had heard that scheduled cloning was on the way long before the 7.6 SP1 beta, thanks mainly to one day getting a cryptic email along the lines of “if we were to do scheduled cloning, what would you like to see in it…” \u2013 so it was pleasing, when it arrived, to see that much of my wish list had made it in there. As a first-round implementation of the process, it’s fabulous.<\/p>\n So, let’s look at how we configure scheduled clones. First off, in NMC, you’ll notice a new menu item in the configuration section:<\/p>\n This will undoubtedly bring joy to the heart of many a NetWorker administrator. If we then choose to create a new scheduled clone resource, we can create a highly refined schedule:<\/p>\n Let’s look at those options first before moving onto the second tab:<\/p>\n Once you’ve got the basics of how often and when the scheduled clone runs, etc., you can move on to selecting what<\/em> you want cloned:<\/p>\n <\/a> I’ve only just refreshed my lab server, so you can see that a bit of imagination is required in the above screen shot to flesh out what this may look in a normal site. But, you can choose savesets to clone based on:<\/p>\n or<\/em><\/p>\n When specifying savesets based on group\/client\/level\/etc., you can also specify how far back NetWorker is to look for savesets to clone. This avoids a situation whereby you might say, enable scheduled cloning and suddenly have media from 3 years ago requested.<\/p>\n You might wonder about the practicality of being able to schedule a clone for specific SSID\/CloneID combos. I can imagine this would be particularly useful if you need to do ad-hoc cloning of a particularly large saveset. E.g., if you’ve got a saveset that’s say, 10TB, you might want to configure a schedule that would start specifically cloning this at 1am Saturday morning, with your intent being to then delete the scheduled clone after it’s finished. In other words, it’s to replace having to do a scheduled cron or at job just for a single clone.<\/p>\n Once configured, and enabled, scheduled cloning runs like a dream. In fact, it was one of the first things I tackled while doing beta testing, and almost every subsequent day found myself thinking at 3pm “why is my lab server suddenly cloning? \u2013 ah yes, that’s why…”<\/p>\n There’s not a huge amount to cover in terms of AFTD enhancements \u2013 they’re effectively exactly the same enhancements that have been run into NetWorker 7.5 SP3, which I’ve previously covered here<\/a>. So, that means there’s a better volume selection criteria for AFTD backups, but we don’t yet have backups being able to continue from one AFTD device to another. (That’s still in the pipeline and being actively worked on, so it will come.)<\/p>\n Even this one key change \u2013 the way in which volumes are picked in AFTDs for new backups \u2013 will be a big boon for a lot of NetWorker sites. It will allow administrators to not focus so much on the “AFTD data shuffle”, as I like to consider it, and instead focus on higher level administration of the backup environment.<\/p>\n (These changes are effectively “under the hood”, so there’s not much I can show in the way of screen-shots.)<\/p>\n When I first learned NetBackup, I immediately saw the usefulness of checkpoint restarting, and have been eager to see it appear in NetWorker since that point. I’m glad to say it’s appeared in (what I consider to be) a much more usable form. So what is checkpoint restarting? If you’re not familiar with the term, it’s where the backup product has regular points at which it can restart from, rather than having to restart an entire backup. Previously NetWorker has only done this at the saveset level, but that’s not really what the average administrator would think of when ‘checkpoints’ are discussed. NetBackup, last I looked at it, does this at periodic intervals – e.g., every 15 minutes or so.<\/p>\n Like almost everything in NetWorker, we get more than one way to run a checkpoint:<\/p>\nScheduled Cloning<\/h3>\n
\n
![\"Scheduled](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2010\/09\/sch_clone_menu.png\" "\\"Scheduled")
<\/a><\/p>\n![\"Scheduled](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2010\/09\/sch_clone_1.png\" "\\"Scheduled")
<\/a><\/p>\n\n
![\"Scheduled](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2010\/09\/sch_clone_2.png\" "\\"Scheduled")
<\/a><\/p>\n\n
\n
AFTD Enhancements<\/h3>\n
Checkpoint Restarting<\/h3>\n
![\"Checkpoint](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2010\/09\/checkpoint.png\" "\\"Checkpoint")
<\/a><\/p>\n