Quando você interrompe um processo com Ctrl-Z, ele não "sabe" que foi pausado, a menos que monitore explicitamente os sinais.
Então, em outras palavras, há pouco ou nenhum risco de que os dados do outro lado estejam corrompidos.
Eu digo "pouco ou não" porque há sempre o risco de que o caminho de comunicação tenha um tempo limite se o trabalho for pausado por muito tempo. Por exemplo, há timeouts implícitos em muitas implementações de NAT, portanto, se houver um roteador NAT no caminho, talvez você veja problemas se pausar por longos períodos de tempo. Eu não posso dizer quanto tempo é "muito longo", mas se você está apenas interrompendo o trabalho para colocá-lo em segundo plano em poucos segundos, eu diria que esse risco de tempo limite é quase nulo.
Eu não acho que o tipo de arquivo de origem ou destino seja importante aqui; novamente, certas fontes e destinos podem não gostar de pausas. Não estou levando em consideração implementações com bugs aqui; kernels com bugs podem não gostar de um processo ser interrompido, mas eu nunca vi isso na prática.
Uma mudança inteligente no seu caso pode ser usar o rsync; Juntamente com Ctrl-Z, você obtém um controle muito bom - tanto a capacidade de parar quanto a capacidade de reiniciar uma transmissão com falha (o que, para ser claro, estou supondo que falhará por outras razões além do processo ser interrompido).
Há um ponto importante aqui - se você interromper um trabalho em uma linha de multi-comandos interativa, às vezes o próximo trabalho será iniciado ou retomado, esquecendo os trabalhos adicionais. Você poderia testar isso com algo como: eco 1; dormir 10; eco 2; eco 3 e pare o trabalho enquanto o sono está acontecendo, e veja se você obtém todos os números impressos na ordem certa com o tempo certo. Isso não se aplica a scripts de shell; um script de shell Ctrl-Zed será retomado de onde você o parou.