WHen you stop a process with Ctrl-Z, it does not "know" that it has been paused unless it explicitly monitors signals.
So, in other words, there is little or no risk that the data at the other end will be corrupted.
I say "little or no" because there is always a risk that the communication path will timeout in some way if the job is paused for too long. For instance, there are timeouts implicit in many NAT implementations, so if there is a NAT router in the path you may see issues if you pause for long periods of time. I can't really say how long is "too long", but if you are merely interrupting the job to put it in the background within a few seconds, I'd say this timeout risk is almost nil.
I don't think the source or destination file type matters here; again, certain sources and destinations may not like pauses. I'm not taking buggy implementations into account here; buggy kernels might not like a process being stopped, but I've never seen it in practice.
A smart move in your case might be to use rsync; coupled with Ctrl-Z you get a really fine degree of control - both the ability to stop, and the ability to restart a failed transmission (which, to be clear, I am assuming would fail for reasons other than the process being stopped).
There is one important point here - if you stop a job in an interactive multi-command line, sometimes the next job will start or resuming will forget about the additional jobs. You could test this with something like:
echo 1; sleep 10; echo 2; echo 3
and stop the job while the sleep is happening, and see whether you get all the numbers printed in the right order with the right timing. This does not apply to shell scripts; a Ctrl-Zed shell script will resume from where you stopped it.
