Yes, it is a bit strange to see it aborted after 3 minutes. It looks like server side action, but no idea why. If you try again do you see it fail again? Unless someone stop it and unless there is anything else in the log everything remains upon guessing. However, if it happens again enable debug mode and I guess log should have more details then.
I would also try to avoid NSR_COMPRESSION as it is usually CPU intensive on client side - if you have enough horse power then fine...
On secont try, here is what I've found in lotus.log file:
(pid = 5880) (date = 2006-07-23 18:16:35) Could not open file E:\Lotus\Domino\data\P21\PStatMail.ns5, error = bmlOpenForRead: Could not open file: E:\Lotus\Domino\data\P21\PStatMail.ns5. (pid = 5880) (date = 2006-07-23 18:16:35) Skipping file: E:\Lotus\Domino\data\P21\PStatMail.ns5, Failed to open the file, error = bmlOpenForRead: Could not open file: E:\Lotus\Domino\data\P21\PStatMail.ns5.
07/23/06 18:16:48 nsrmmd #1: save set NOTES: for client lotusdomino was aborted and removed from volume diskpool.001 07/23/06 18:16:48 nsrd: media info: save set NOTES: for client lotusdomino was aborted and removed from volume diskpool.001 07/23/06 18:16:48 nsrd: lotusdomino:NOTES: done saving to pool 'diskpool' (diskpool.001) 60 GB 07/23/06 18:16:48 nsrd: lotusdomino:NOTES: saving to pool 'diskpool' (diskpool.001)
After 60GB!!! of data
Is there any timeout? Lotus databases are quite large (about 20GB each)
"Yes, it is a bit strange to see it aborted after 3 minutes. It looks like server side action, but no idea why."
It also happened after transferred currently of data.
"If you try again do you see it fail again?"
Yes.
"Unless someone stop it and unless there is anything else in the log everything remains upon guessing."
No, As You see server retires NOTES: save set, which is curently being backuped (I currently waiting for completion), so group wasn't aborted and there is no failed save set in the group's details.
" However, if it happens again enable debug mode and I guess log should have more details then."
Ok, how can I turn debug mode and which Networker daemon?
"I would also try to avoid NSR_COMPRESSION as it is usually CPU intensive on client side - if you have enough horse power then fine..."
Ok, if it fails now, I'll try turn it off, but Lotus server is rather powerful
I assume above NSR parameters are from config file which is called via backup command, right?
In that case obviously SKIPDBERRORS does not apply to error you listed above (as it is critical and not non-critical). Can you have DB admin check that file? I can't say if this error is the problem as previously it failed much earlier. One way of perhaps seeing that is by doing manual save from client of smaller parts one after another (thus identifying faulty db files).
When I said debug I was referring to debug of module itself - check admin guide pg 143&144 for NSR_DEBUG_FILE and NSR_DEBUG_LEVEL options.
Ok, after some more observations, here is what I've found: 1. As You've seen this problem apperas ranadomly (after 2GB or 50GB or 64GB) 2. NSR_COMPRESSION doesn't work IMO. I've backuped 16GB NSF file with comperssion set to true and it has 16GB on backup disk. 3. When I removed following parameter NSR_BACKUP_ALL_EXTENSIONS = TRUE, backup of 84GB has been successful!!!. 4. The problem is that we have some more files which don't have typical file extensions such as *.ns5 and *.ns4. As You see NML 3.0 can't backup this files, but they are used by Lotus Domino 7.
As for compression part - perhaps DB data is already in shape that cannot be compressed. Try to make zip copy and see how much it gets compressed.
As for backup part problem, I would suggest to open this with support at this point - they should be in position to get this fixed once they confirm what you claim (perhaps it is already known issue - you never know).
Unfortunately I have to raise this thread from the dead, but has this problem been addressed and / or solved in some way?
Currently with the NMDA Module 1.2 backing up with NSR_BACKUP_ALL_EXTENSIONS:"TRUE" still produces errors similar to those above. In my case the backup process trips over transaction log files of Notes (*.txn) as well as some regular Logfiles (*:log)
ble1
4 Operator
•
14.4K Posts
0
July 23rd, 2006 08:00
I would also try to avoid NSR_COMPRESSION as it is usually CPU intensive on client side - if you have enough horse power then fine...
abartosz
1 Rookie
•
7 Posts
0
July 23rd, 2006 09:00
(pid = 5880) (date = 2006-07-23 18:16:35) Could not open file E:\Lotus\Domino\data\P21\PStatMail.ns5, error = bmlOpenForRead: Could not open file: E:\Lotus\Domino\data\P21\PStatMail.ns5.
(pid = 5880) (date = 2006-07-23 18:16:35) Skipping file: E:\Lotus\Domino\data\P21\PStatMail.ns5, Failed to open the file, error = bmlOpenForRead: Could not open file: E:\Lotus\Domino\data\P21\PStatMail.ns5.
There is no other errors
abartosz
1 Rookie
•
7 Posts
0
July 23rd, 2006 09:00
07/23/06 18:16:48 nsrmmd #1: save set NOTES: for client lotusdomino was aborted and removed from volume diskpool.001
07/23/06 18:16:48 nsrd: media info: save set NOTES: for client lotusdomino was aborted and removed from volume diskpool.001
07/23/06 18:16:48 nsrd: lotusdomino:NOTES: done saving to pool 'diskpool' (diskpool.001) 60 GB
07/23/06 18:16:48 nsrd: lotusdomino:NOTES: saving to pool 'diskpool' (diskpool.001)
After 60GB!!! of data
Is there any timeout? Lotus databases are quite large (about 20GB each)
Regards
abartosz
1 Rookie
•
7 Posts
0
July 23rd, 2006 09:00
"Yes, it is a bit strange to see it aborted after 3 minutes. It looks like server side action, but no idea why."
It also happened after transferred currently of data.
"If you try again do you see it fail again?"
Yes.
"Unless someone stop it and unless there is anything else in the log everything remains upon guessing."
No, As You see server retires NOTES: save set, which is curently being backuped (I currently waiting for completion), so group wasn't aborted and there is no failed save set in the group's details.
" However, if it happens again enable debug mode and I guess log should have more details then."
Ok, how can I turn debug mode and which Networker daemon?
"I would also try to avoid NSR_COMPRESSION as it is usually CPU intensive on client side - if you have enough horse power then fine..."
Ok, if it fails now, I'll try turn it off, but Lotus server is rather powerful
Thanks again.
ble1
4 Operator
•
14.4K Posts
0
July 23rd, 2006 11:00
In that case obviously SKIPDBERRORS does not apply to error you listed above (as it is critical and not non-critical). Can you have DB admin check that file? I can't say if this error is the problem as previously it failed much earlier. One way of perhaps seeing that is by doing manual save from client of smaller parts one after another (thus identifying faulty db files).
When I said debug I was referring to debug of module itself - check admin guide pg 143&144 for NSR_DEBUG_FILE and NSR_DEBUG_LEVEL options.
abartosz
1 Rookie
•
7 Posts
0
July 23rd, 2006 23:00
1. As You've seen this problem apperas ranadomly (after 2GB or 50GB or 64GB)
2. NSR_COMPRESSION doesn't work IMO. I've backuped 16GB NSF file with comperssion set to true and it has 16GB on backup disk.
3. When I removed following parameter NSR_BACKUP_ALL_EXTENSIONS = TRUE, backup of 84GB has been successful!!!.
4. The problem is that we have some more files which don't have typical file extensions such as *.ns5 and *.ns4. As You see NML 3.0 can't backup this files, but they are used by Lotus Domino 7.
ble1
4 Operator
•
14.4K Posts
0
July 24th, 2006 01:00
As for backup part problem, I would suggest to open this with support at this point - they should be in position to get this fixed once they confirm what you claim (perhaps it is already known issue - you never know).
StefanHa1
8 Posts
0
June 12th, 2012 05:00
Unfortunately I have to raise this thread from the dead, but has this problem been addressed and / or solved in some way?
Currently with the NMDA Module 1.2 backing up with NSR_BACKUP_ALL_EXTENSIONS:"TRUE" still produces errors similar to those above. In my case the backup process trips over transaction log files of Notes (*.txn) as well as some regular Logfiles (*:log)