We have come to the conclusion that encrypting the data when it is being saved to disk might be causing this but the theory has not been tested because at some point the data will have to be encrypted so here is the question:
Can you tell staging to encrypt the data as it copies it to tape?
If not then the only other way would be 2 seperate backups, server to disk then disk to tape but I am not sure I want to go that route because I will loose browse and retention times.
Any suggestions on a best practice for this?
Thanks
The reason I say it might be the encryption is that we have noticed heavy swapping during the backups
This is nothing but the memory leak issue with the process nsrexec. This version has many other issues also. I recommend you to upgrade this client only to the version 8.0.1.3 build 155 and have a try. You will definitely be happy . I will wait for your response.
I have narrowed down the problem to doing the backups to disk.
The backups are twice as fast sending them straight to tape encrypted as they are sending them to disk un-encrypted.
Un-encrypted backups sent to tape take 1/3 the time as un-encrypted backups sent to disk.
Sending the backups to tape do not cause any other issues either, sending them to disk causes many issues with slow system performance all the way to users not being able to log in.
It doesn't make any sense that backing up to disk should take longer than tape, the whole purpose was to have a faster backup.
All the backup disks and LPARs use the same san
Any ideas what I can do to fix this so I can backup to disk.
lalexis
2 Intern
•
253 Posts
0
May 15th, 2013 04:00
We have come to the conclusion that encrypting the data when it is being saved to disk might be causing this but the theory has not been tested because at some point the data will have to be encrypted so here is the question:
Can you tell staging to encrypt the data as it copies it to tape?
If not then the only other way would be 2 seperate backups, server to disk then disk to tape but I am not sure I want to go that route because I will loose browse and retention times.
Any suggestions on a best practice for this?
Thanks
The reason I say it might be the encryption is that we have noticed heavy swapping during the backups
1goyalp
18 Posts
0
May 15th, 2013 13:00
Hi Larry,
This is nothing but the memory leak issue with the process nsrexec. This version has many other issues also. I recommend you to upgrade this client only to the version 8.0.1.3 build 155 and have a try. You will definitely be happy
. I will wait for your response.
lalexis
2 Intern
•
253 Posts
0
May 16th, 2013 08:00
That solved the memory issue, I think I have some other issues on the server itself because it still has performance problems during a backup
lalexis
2 Intern
•
253 Posts
0
May 17th, 2013 05:00
When I did the upgrade it changed my rc.nsr file so now Networker does not see my jukebox.
The irony is that my backup with the old rc.nsr is on tape.
Does anyone have a good rc.nsr file that works with the latest release?
Thanks
lalexis
2 Intern
•
253 Posts
1
May 17th, 2013 05:00
Luckily I was able to power up an old server long enough to get these 3 lines to add to the rc.nsr
rmdev -l smc0
mkdev -l lus
export LIBPATH=/usr/ccs/lib/libc.a
That did the trick and my jukebox is back online
lalexis
2 Intern
•
253 Posts
0
May 29th, 2013 04:00
I have narrowed down the problem to doing the backups to disk.
The backups are twice as fast sending them straight to tape encrypted as they are sending them to disk un-encrypted.
Un-encrypted backups sent to tape take 1/3 the time as un-encrypted backups sent to disk.
Sending the backups to tape do not cause any other issues either, sending them to disk causes many issues with slow system performance all the way to users not being able to log in.
It doesn't make any sense that backing up to disk should take longer than tape, the whole purpose was to have a faster backup.
All the backup disks and LPARs use the same san
Any ideas what I can do to fix this so I can backup to disk.