There’s been some discussion in the EMC Community Forum lately as to whether it would be handy to have a directive preview option in NMC. I’d suggest it is, but if you need this now then you don’t have anything to wait for, so long as you’re willing to work on the command line.

The way you do this is via the save command, invoking with the switches “-n” and “-v”. Of course, these can be used in the same argument (-nv or if you prefer, -vn). The “-n” option tells NetWorker not to actually perform the backup, while the “-v” option tells NetWorker to be verbose as it walks the filesystem. This verbosity will tell you what application specific module (ASM) NetWorker is going to invoke against each file/directory encountered.

For instance, let’s consider a save against the /root folder on a backup server where I’ve got a directive that’s configured to skip everything in there. The start of the output looks like the following:

[root@tara ~]# save -b Default -nv /root
3817:save: Using tara.pmdg.lab as server
70342:save: save: got prototype for /
70342:save: save: got prototype for /
70342:save: save: got prototype for /dev/
70342:save: save: got prototype for /
70342:save: save: got prototype for /dev/
70342:save: save: got prototype for /
70342:save: save: got prototype for /opt/
70342:save: save: got prototype for /
70342:save: save: got prototype for /
70342:save: save: got prototype for /
70342:save: save: got prototype for /
70342:save: save: got prototype for /
70342:save: save: got prototype for /media/
70342:save: save: got prototype for /proc/sys/fs/
70342:save: save: got prototype for /var/lib/nfs/
chdir(/root)
Name=`/root/', name=`/root/', fname=`./'
32240:save: found protofile spec for /:
mntasm : backup4
70342:save: save: got prototype for /
66135:save: NSR directive file (/.nsr) parsed
70342:save: save: got prototype for /root/
66135:save: NSR directive file (/root/.nsr) parsed
walk(/root/, ./)
walk(/root/.nsr, .nsr)
uasm -s /root/.nsr
walk(/root/.odbc.ini, .odbc.ini)
uasm -s /root/.odbc.ini
walk(/root/backup.log, backup.log)
32246:save: matched internal `skip' on `backup.log' for `/root/backup.log'
walk(/root/micromanual-nsradmin, micromanual-nsradmin)
32246:save: matched internal `skip' on `micromanual-nsradmin' for `/root/micromanual-nsradmin'
walk(/root/lose-files.sh, lose-files.sh)
32246:save: matched internal `skip' on `licenses.sh' for `/root/lose-files.sh'

As you can see by the above, we get a file-by-file analysis of the walk process, and that includes the ASM that will be invoked against that file. For instance, looking at the ‘backup.log’ file, we see:

walk(/root/backup.log, backup.log)
32246:save: matched internal `skip’ on `backup.log’ for `/root/backup.log’

So the first line tells us that it’s encountered a file called ‘backup.log’, with a full path of ‘/root/backup.log’. The second line tells us that it’s matched the (internal) ASM, ‘skip’, on the file ‘backup.log’ for the path ‘/root/backup.log’ – i.e., it’s effectively telling us that it will skip that file.

While it may be messy, it is a valid and usable technique to see what your directives are going to do.

 

One of the most common mistakes made by people new to NetWorker when setting up directives is using the skip directive when what they actually need to use is the null directive.

Both directives can be used to prevent the backup of nominated content on a client, but using skip in situations where null should be used can result in very dicey recovery situations.

If you’re wanting to (no pun intended) “skip the working” here, this is the rule you should typically follow:

  • If wanting to exclude directories, use null.
  • If wanting to exclude files, use skip.

However, it’s not as cut and dried as the above suggests, so I recommend you keep reading.

The difference between null and skip is simple yet important at the same time, and it strongly affects how recoveries work, for it plays a factor in how NetWorker updates indices. One of the best ways I have of describing this is that:

  • The skip directive acts as an opaque shutter on the indices;
  • The null directive acts as a window on the indices.

This means that if you use skip against different directories in the same tree for different backups, each recovery you run aftwards will only show what wasn’t skipped. If you use null however, then each recovery will show both what has been null’d, and what wasn’t.

The best way to see how this works is by example, so I’ve prepared in my server’s home directory two subdirectories:

  • /home/preston/test_null
  • /home/preston/test_skip

In each directory, I’ve created and populated 2 subdirectories, “01″ and “02″. So the full structure is:

  • /home/preston/test_null/01
  • /home/preston/test_null/02
  • /home/preston/test_skip/01
  • /home/preston/test_skip/02

In each case, “.nsr” client side directives were setup in the ‘parent’ directories – /home/preston/test_null and /home/preston/test_skip.

For the first backup, the directives were to “null” or “skip” the 02 directories and allow the 01 directories to be backed up. For the second backup, the directives were to “null” or “skip” the 01 directories, allowing the 02 directories to be backed up.

Here’s what it looked like for the test_null directory:

# cd /home/preston/test_null
# ls -l
total 8
drwxr-xr-x 2 root root 4096 Jul  6 18:23 01
drwxr-xr-x 2 root root 4096 Jul  6 18:23 02

# cat .nsr
<< . >>
null: 02

# save -b Default -e "+2 weeks" .
<output removed>
# recover -s nox
Current working directory is /home/preston/test_null/
recover> ls
 01     .nsr

# NOTE: Reverse contents of .nsr
# cat .nsr
<< . >>
null: 01

# save -b Default -e "+2 weeks" .
<output removed>
# recover -s nox
Current working directory is /home/preston/test_null/
recover> ls
 01     02     .nsr

As you can see above, even after the second backup, where the ’01′ directory was most recently excluded, both directories are shown in the recovery browser.

Here’s what it looked like for the test_skip directory:

# cd /home/preston/test_skip
# ls -l
total 8
drwxr-xr-x 2 root root 4096 Jul  6 18:28 01
drwxr-xr-x 2 root root 4096 Jul  6 18:28 02

# cat .nsr
<< . >>
skip: 02

# save -b Default -e "+2 weeks" .
<output removed>
# recover -s nox
Current working directory is /home/preston/test_skip/
recover> ls
 01     .nsr

# NOTE: Reverse contents of .nsr
# cat .nsr
<< . >>
skip: 01

# save -b Default -e "+2 weeks" .
<output removed>
# recover -s nox
Current working directory is /home/preston/test_skip/
recover> ls
 02     .nsr

As you can see, that’s a substantial difference in what is shown for recovery purposes. Indeed, to be able to recover the “01″ part of the test_skip directory, we need to explicitly target a time between when the first backup was run, and when the second backup was run:

# mminfo -q "name=/home/preston/test_skip" -r "name,savetime(23)"
 name                               date     time
/home/preston/test_skip         07/06/2009 06:29:53 PM
/home/preston/test_skip         07/06/2009 06:31:17 PM

# recover -s nox
Current working directory is /home/preston/test_skip/
recover> ls
 02     .nsr
recover> changetime 18:30
6497:recover: time changed to Mon 06 Jul 2009 06:30:00 PM EST
recover> ls
 01     .nsr

As you can see, there’s substantial difference between skip and null. For this reason, please ensure you pick the right mechanism for excluding content from backup!

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha