There was a recent posting on the NetWorker mailing list regarding manual backups and whether they’re incrementals or not. The short answer of course is they’re not. The more challenging answer is whether or not you can actually generate a manual incremental backup.

You may think that as of 7.5 onwards, where the level is expressly ignored for manual backups, that this isn’t possible:

[root@tara ~]# save -l incr -b Default /tmp
Client initiated backup.Option '-l' is ignored and backup is performed at level adhoc

After all, in 7.4 and below, if you ran the above command anyway, you wouldn’t have actually got an incremental backup of /tmp anyway – sure, it would have been tagged as an incremental backup, but that’s not the way that non-complete backup is actually generated in NetWorker. You see, NetWorker needs a timestamp to base a non-full backup against. That timestamp is going to be the nsavetime of a previous backup. (For an incremental, it will be the nsavetime of whatever the most recent backup for the saveset was – for differentials, it may vary.)

I’ll walk through an example of getting an incremental manual backup. It will still be tagged in NetWorker as a manual backup (that just is unavoidable these days), but it will at least just be an incremental. To start with, I need a full backup of something. I’ve got a full backup of my /usr/share directory as its own saveset here:

[root@tara ~]# mminfo -q "name=/usr/share" -r volume,level,sumsize,nsavetime
 volume          lvl   size  save time
800803L4        full 1244 MB 1263844861

Now, in order to be able to run a ‘manual’ incremental backup against this, I need to run save with a -t (for time) option – and the time I use will be 1263844861, which will backup all changes to that directory since the last backup.

So the command becomes:

[root@tara ~]# save -q -LL -t 1263844861 /usr/share
66135:save: NSR directive file (/.nsr) parsed
save: /usr/share  251 KB 00:00:20    588 files
completed savetime=1263880379

Note there that I haven’t included a level. If I had, even with the “-t” option included, NetWorker would have still generated the warning/error about ignoring the level for client initiated backups. However, I can confirm that it’s effectively an incremental backup by checking mminfo and looking at the sumsize field again:

[root@tara ~]# mminfo -q "name=/usr/share" -r volume,level,sumsize,nsavetime
 volume          lvl   size  save time
800803L4        full 1244 MB 1263844861
800803L4      manual 251 KB 1263880379

As you can see, we’ve got a full backup, and a subsequent manual backup that is effectively an incremental against the full.

Where is this useful? I wouldn’t imagine that it’s something you should be making use of in normal operations. However, in an emergency, when there’s an upgrade about to be done and you need to walk someone through doing an incremental backup before the upgrade without giving them administrative access to the backup server, this would be the sort of technique that can come in handy.

 

When you run a manual backup in NetWorker (e.g., via the “save” command), NetWorker will by default give you a file-by-file listing of what is being backed up. In theory this is helpful for manual backups, because typically we do manual backups to debug issues, not as part of the production backup process.

If you’re wanting to do a manual backup and make it as high performance as possible, there’s an option you need to use: quiet. For the save command, it’s “-q”; for the GUI, it means going and bringing up a command prompt and learning how to use save*. You can’t turn off a file-by-file listing (currently at least) in the NetWorker user backup program.

So, backing up from a Solaris system to a Linux NetWorker server, using gigabit ethernet and the same backup device (ADV_FILE) each time, here’s some examples of the impact of viewing the per-file progress of the backup. (Each backup was run three times, with the run-time averaged.)

  1. Backing up 77,822 files:
    • Without per-file listing: 53 minutes, 11 seconds.
    • With per-file listing: 55 minutes, 35 seconds.
  2. Backing up 3,710,475 files:
    • Without per-file listing: 1 hour, 38 minutes, 30 seconds.
    • With per-file listing: 1 hour, 56 minutes, 9 seconds.

The time taken to print each file will be dependent on the performance of the console device you’re using. The above tests were run from an GigE ssh session from another host to the Sun client. (For instance, this problem also occurs in recoveries: I remember once running a recovery via a Sun serial console where I waited 6 hours for the recovery to complete only to discover when all the files stopped printing that the recovery had finished hours ago.)

The simple fact is – the more intensively you want to watch status of a backup (or for that matter, a recovery), the more you directly have an impact on its performance.


* Honestly, you should anyway – see here for a good reason.

 

NetWorker 7.5.1 oops sorry, SP1 has been released.

Previously we’ve seen scenarios where documentation has been updated on PowerLink for up to a couple of weeks before the release of the accompanying product. At the moment though instead we’ve got the reverse; 7.5.1 oops, sorry, SP1 software is available for download, but no notes … yet.

I’m downloading now for testing – I’ve currently held off recommending 7.5 to any customer as yet, preferring to have them stick to 7.4.4 wherever possible. Hopefully the release notes won’t be too far behind, as testing a new service pack without the release notes is a bit hit and miss.

Important edit – added later but top

Important! Covered in the release notes, which I know you read, right? If you use scripts that use mminfo, you really, really need to be across this. Look at the output from mminfo:

$ mminfo -s nox -q "client=archon,name=/Users/preston/tmp/"
 volume        client       date      size   level  name
Staging-03     archon    31/03/2009  45 MB  manual  /Users/preston/tmp/
Staging-03.RO  archon    31/03/2009  45 MB  manual  /Users/preston/tmp/

That’s right – if you do a manual backup, it doesn’t show up as a ‘blank’ level any more.

Edit

Things that drive me nuts:

  • Changes that don’t appear in the release notes.

Look at this in change to the ‘Sessions’ output in nsrwatch:

Sessions:
 50 MB are saved to pool 'Staging' (Staging-01) of aralathan:/
 nox:/d/03 saving to pool 'Staging' (Staging-03) 768 MB

Now, tell me where in the Release Notes that this is mentioned. I’ll give you a hint: nowhere.

I know some things get forgotten, but it is very frustrating when release notes have a “what’s new” section that doesn’t include everything that’s new!

Next Edit

Definitely mentioned in the release notes as a fixed bug, as a long-term nsradmin user, I’m relieved to see that the bug I logged last year has been fixed – that being nsradmin crashes when you resize the window. If you live in nsradmin like I do, this is a handy fix.

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha