Когда вы останавливаете процесс с помощью Ctrl-Z, он не "знает", что он был приостановлен, если он явно не контролирует сигналы.
Таким образом, другими словами, существует небольшой риск или отсутствие риска того, что данные на другом конце будут повреждены.
Я говорю "мало или нет", потому что всегда существует риск того, что канал связи каким-то образом прекратит работу, если работа будет приостановлена на слишком длительный срок. Например, есть тайм-ауты, неявные во многих реализациях NAT, поэтому, если на пути есть маршрутизатор NAT, вы можете столкнуться с проблемами, если будете делать паузу в течение длительных периодов времени. Я не могу точно сказать, как долго это "слишком долго", но если вы просто прерываете работу, чтобы поставить ее на задний план в течение нескольких секунд, я бы сказал, что риск тайм-аута почти равен нулю.
Я не думаю, что тип файла источника или назначения имеет значение здесь; опять же, некоторые источники и места назначения могут не любить паузы. Я не принимаю во внимание ошибочные реализации; ядрам с ошибками может не понравиться остановка процесса, но я никогда не видел это на практике.
В вашем случае разумным шагом может стать использование rsync; в сочетании с Ctrl-Z вы получаете действительно хороший уровень контроля - как способность останавливаться, так и возможность перезапустить неудачную передачу (которая, как я понимаю, я предполагаю, будет неудачной по причинам, отличным от остановки процесса).
Здесь есть один важный момент: если вы останавливаете задание в интерактивной многокомандной строке, иногда запускается следующее задание, или возобновление забывает о дополнительных заданиях. Вы можете проверить это с помощью чего-то вроде: echo 1; спать 10; эхо 2; Отобразите 3 и остановите задание, пока идет сон, и посмотрите, все ли числа напечатаны в правильном порядке и в нужное время. Это не относится к сценариям оболочки; сценарий оболочки Ctrl-Zed возобновится с того места, где вы его остановили.
