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.