I am actually more interested in a real-time (or close to it) logging view. The original monster saveset was too big to finish and would bomb out. The new saveset with the skip directives also bombs out - but it may be bombing out for a different reason. So I was hoping to confirm that it does indeed follow the skip directives and not falling over for the same old reason.
This change I made with the new client and the skip directives is all pretty new also, so backup history from mminfo isn't telling me what I need to know right now. So far I tried running this backup once (last night) and it croaked.
Hope that makes sense - if I can provide more background info please let me know.
I don’t believe directive actions are logged in the daemon.raw/.log file. You may see something in the savegrp log but I have always found the easiest way to be confident it is working is to run an mminfo command and check the size of the saveset (or look in savegrp completion report which should also report the size and number of files).
mminfo -q "client=" -r "name, ssid,totalsize,savetime" should give you a history of the backups and allow you to see when the directive was put in place or give you confidence that since you started to backup this monstrosity its size is not 5.5TB.
What kind of directives are you using? I did a quick test here with a local directive and I get the message in the savegrp.log - 'NSR directive file (C:\Program Files\Common Files\nsr.dir) parsed. Not sure if this is early enough in the process that it would give you the real-time information you are looking for, but you could test it to see.
Hi Bobby, thanks for the reply - I am skipping three directories, thusly: <
> skip: .?* *
This syntax works for other clients. I figure it would work for this new client but I wanted to see it working during the backup, since if it doesn't work, the backup will run for about a million years unless I abort it!
And thanks for the tip re: the savegrp.log - I am seeing the directive getting parsed in the logs like you mentioned, but I was hoping for a more verbose listing - something that would tell me what directory was being skipped.
All good here - logging is moot, since I was trying to run server-side directives on a NDMP backup, whihc I have just learned is not possible.
It is possible, but not via NW directives. Most filers, like Celerra and NetApp, have their own syntax to exclude files for example that can be used to achieve pretty close to what directive would give you.
Hello there: I read with big curiosity this story. I got the same problem trying to skip savesets in a NMDP backup and didn't work using a Skip Directive with the format
<<"/vol/ora_data">>
+skip: *.*
<< "/vol/ora_ctrl ">>
+skip: *.*
I see that the directive doesn't work.
Do you have an example about how to perform a skip saveset backup in NMDP?
Directive is applied to client side (no matter if it is used as so called server side directive) and NDMP as you know has different stream than NW one and there is no client. That means some features, like backup application based directives, can't be used. This is truth for all backup application. With that said, that does not mean you can't use something similar. Filer vendors have realized what monster they created so each of them implemented mechanism for their own NDMP implementation to exclude files (or/and directories). For example, if memory serves me well, on NetApp you would use EXCLUDE=*.jpg to exclude all jpgs from volume you backup. At the time when I used it, this implementation was rather poor in terms what you could achieve so for current mechasnim and syntax you must check vendors documentation. As to how you use it with NW, it is simple; just as you would place other NDMP variables in application information, so you would include this one too.
gfreeman3
13 Posts
0
April 1st, 2010 10:00
Hi Bill,
Thanks for the quick reply!
I am actually more interested in a real-time (or close to it) logging view. The original monster saveset was too big to finish and would bomb out. The new saveset with the skip directives also bombs out - but it may be bombing out for a different reason. So I was hoping to confirm that it does indeed follow the skip directives and not falling over for the same old reason.
This change I made with the new client and the skip directives is all pretty new also, so backup history from mminfo isn't telling me what I need to know right now. So far I tried running this backup once (last night) and it croaked.
Hope that makes sense - if I can provide more background info please let me know.
Thanks again!
- Greg
masonb
445 Posts
1
April 1st, 2010 10:00
Greg,
I don’t believe directive actions are logged in the daemon.raw/.log file. You may see something in the savegrp log but I have always found the easiest way to be confident it is working is to run an mminfo command and check the size of the saveset (or look in savegrp completion report which should also report the size and number of files).
mminfo -q "client=" -r "name, ssid,totalsize,savetime" should give you a history of the backups and allow you to see when the directive was put in place or give you confidence that since you started to backup this monstrosity its size is not 5.5TB.
Regards,
Bill Mason
coganb
736 Posts
1
April 2nd, 2010 04:00
What kind of directives are you using? I did a quick test here with a local directive and I get the message in the savegrp.log - 'NSR directive file (C:\Program Files\Common Files\nsr.dir) parsed. Not sure if this is early enough in the process that it would give you the real-time information you are looking for, but you could test it to see.
-Bobby
gfreeman3
13 Posts
0
April 5th, 2010 11:00
Hi Bobby, thanks for the reply - I am skipping three directories, thusly: <
This syntax works for other clients. I figure it would work for this new client but I wanted to see it working during the backup, since if it doesn't work, the backup will run for about a million years unless I abort it!
And thanks for the tip re: the savegrp.log - I am seeing the directive getting parsed in the logs like you mentioned, but I was hoping for a more verbose listing - something that would tell me what directory was being skipped.
I may be out of luck but I appreciate the help!
- Greg
gfreeman3
13 Posts
0
June 18th, 2010 11:00
All good here - logging is moot, since I was trying to run server-side directives on a NDMP backup, whihc I have just learned is not possible.
ble1
4 Operator
•
14.4K Posts
0
June 18th, 2010 15:00
It is possible, but not via NW directives. Most filers, like Celerra and NetApp, have their own syntax to exclude files for example that can be used to achieve pretty close to what directive would give you.
antolino62
1 Message
0
February 8th, 2012 21:00
Hello there: I read with big curiosity this story. I got the same problem trying to skip savesets in a NMDP backup and didn't work using a Skip Directive with the format
<<"/vol/ora_data">>
+skip: *.*
<< "/vol/ora_ctrl ">>
+skip: *.*
I see that the directive doesn't work.
Do you have an example about how to perform a skip saveset backup in NMDP?
Will appreciate your hint.
Best Regards
Jose Ramirez
ble1
4 Operator
•
14.4K Posts
0
April 25th, 2012 01:00
Hi Jose,
Directive is applied to client side (no matter if it is used as so called server side directive) and NDMP as you know has different stream than NW one and there is no client. That means some features, like backup application based directives, can't be used. This is truth for all backup application. With that said, that does not mean you can't use something similar. Filer vendors have realized what monster they created so each of them implemented mechanism for their own NDMP implementation to exclude files (or/and directories). For example, if memory serves me well, on NetApp you would use EXCLUDE=*.jpg to exclude all jpgs from volume you backup. At the time when I used it, this implementation was rather poor in terms what you could achieve so for current mechasnim and syntax you must check vendors documentation. As to how you use it with NW, it is simple; just as you would place other NDMP variables in application information, so you would include this one too.