I Have two AIX 5.3 servers. I want to move a 45GB file from Server B to Server A. Can I achieve this with using Tivoli? Or how could I achieve this, by mounting a directory from server B to server A?
Any help apreciated!
Yes, either of these ways would get the file moved to Server A, depending on your Tivoli setup the NFS mount will likely be the slower option.
OK, I will take a look at the NFS mount. Could I do the Tivoli option on the command line or the web interface?
I am sure you can use either interface, I can't give you much guidance on the command line as I use the web interface primarily. If you decide to choose the Tivoli option you will need to make changes to your dsm.sys file for the redirected restore. So backup the file from Server B and then modify the dsm.sys file on Server B so when you attempt the restore it will restore to Server A instead of Server B.
---------- Post updated at 01:49 PM ---------- Previous update was at 01:34 PM ----------
One other thought, depending your network speed I am not sure that you wouldn't be almost as well off using scp with the -C flag (Compression enables) in lieu of NFS. Depending on if the file is already compressed. Your call.
I tared the file and tried to scp the file over but ran into permission issues. The directory that the file sits in is an oracle dir. When I try to run the scp2 command I get the following error:
scp2: warning: stat: BAN8TEST.tar (src): unspecified failure (server msg: 'syserr: Value too large to be stored in data type, file: /u02/oradata/BAN8TEST.tar')
I think it's telling me that the destination directory is to small for this file. But the direcory is big enough at least 4x's.
My command:
scp2 BAN8TEST.tar ServerA:/u02/ban8_dbf
I do not recognize that error. Not sure what scp2 is, maybe scp using protocol 2 or something. I just started at 20Gig scp copy from AIX to AIX and did not get any errors but your doing twice the file so could be a scp limitation. That error doesn't strick me as a ulimit error but double check the ulimit settings for the that FS. If you have time try using bzip2 -9 or gzip to compress the tar ball and then copy it over.
Why not copy the file to a tape or dual layer dvd (assuming the file will compress to 9gb)
When you mentioned to alter my dsm.sys file are you suggesting that I remove the 'ServerB" name and replace it with 'ServerA' name?
Do you know it I can have both nodes under the same dsm.sys
here'ss an example of my dsm.sys:
************************************************************************
* Tivoli Storage Manager *
* *
* Sample Client System Options file for AIX and SunOS (dsm.sys.smp) *
************************************************************************
* This file contains the minimum options required to get started
* using TSM. Copy dsm.sys.smp to dsm.sys. In the dsm.sys file,
* enter the appropriate values for each option listed below and
* remove the leading asterisk (*) for each one.
* If your client node communicates with multiple TSM servers, be
* sure to add a stanza, beginning with the SERVERNAME option, for
* each additional server.
************************************************************************
SErvername ServerB
COMMMethod TCPip
TCPPort 1500
TCPServeraddress 192.168.1.5
PASSWORDAccess generate
DOMAIN all-local
I don't think you can have both nodenames in the same dsm.sys file and be active. Meaning that I think you will need one of them commented out. We have two TSM servers here so I have to be concerned about the TCPPort and TCPServeraddress but if you only have one TSM server than you don't need to worry about anything but the nodename.
OK, after using bzip2 on the file I was able to scp2 it to ServerA. Your solution worked and helped. Thank you very much!!
Check the ulimit for filesize on the target system. It may be that this will not allow a 45GB file to be created.
The default max is 2 GB
set unlimits from /etc/security/users file it should help
If the two servers are on the same LAN and the connection is at least one hundred Mbits/sec there appears to be no reason to do anything other than rcp (or scp) the file. In this circumstance compression just wastes time.
If you look at previous posts in this thread you will see that scp was suggested and tried, it did not work. Most likely due to a ulimit problem. Making ulimit changes were suggested as an alternative compressing the file was suggested. I don't see it as a waste of time if it works.
If compressing it and copy the file worked, there may be a limit in a firewall between the two servers.
Don't knock it if it works.