Red Hat

Hello All,

I am transfering a gzipped file from LINUX to LINUX using scp -C comand.
It is a nightly job, called by crontab. After copy finishes, the file sizes are different between source and destination. Say .gz file is 14782805941 bytes on source and 13496172544 bytes on destination. When I gunzip it I get an error message "unexpected end of file'.
However, when i type EXACTLY the same command from prompt, scp runs ok and both files are the same size.
I run md5sum check against both files.
Everything is ok when I start scp manually, and I get corruption when same command is ran by crontab.

What could that be?? I really really need to fix it because it is actually the database backups, and untill I fix this problem i have to database backup!

Thanks in advance!

Did you check without enabling the compression i.e without the -C switch with SCP? Can you post the crontab entry for this?

Is it a root cron?

To admin_xor:

Here is my entry:

Code:

20 3 * * 1,2,3,4,5,6 /data05/oradata/dpdump/cpFromDB.sh > /data05/oradata/dpdump/cpFromDB.log  2>&1

cpFromDB.sh

Code:

scp -C root@xxx.xx.xxx.3:/data05/oradata/dpdump/*.gz /data05/oradata/dpdump/.
ssh -l root xxx.xx.xxx.3 rm -f /data05/oradata/dpdump/*.gz /data05/oradata/dpdump/db*.log

And I am going to test without the compression right now.

Thanks!

---------- Post updated at 10:26 AM ---------- Previous update was at 10:08 AM ----------


I would think so, since the job is running as root.

Have you considered rsync? More checks and balances than using scp.

(Only asked about root in case there was a different ulimit).

Have you tried putting a say sleep 30 between the scp and the ssh ? I'm serious (the second command deletes the source file and the slave process could still be running).

I agree that the compression is pointless on a compressed file. Also that rsync is preferred if both computers support the command.

I just ran a test, I used cron to SCP a file twice - with and without the -C switch. Both runs were ok, and the file sizes are equal. However, this test file was much smaller than the real one. The real one was 15GB, while the test file was only 30MB.

So, could it be that the size of a file is causing a problem?

I might be able to run the large file only over the weekend, other wise it is getting in a way of our backup process.

---------- Post updated at 11:58 AM ---------- Previous update was at 11:54 AM ----------


------------
I will put sleep in the code. It will run tonight, and result I will see Monday morning. It could be a very good catch, deletes before the previous process finishes.