Процесс Rsync внезапно прерывается во время резервного копирования через SSH

У меня есть сценарий резервного копирования rsync для передачи данных между двумя серверами Ubuntu (расположенными в разных странах). Резервное копирование данных довольно велико с точки зрения количества файлов. Его общий размер составляет около 17 ГБ. Скрипт запускается на приемник сервер. Итак, это в основном вытащить. Аутентификация с открытым и закрытым ключом, используемая для входа.

Скрипт работает нормально; резервное копирование успешно выполняется уже много месяцев.

В последнее время, в течение последних 6 дней или около того, резервное копирование не выполнялось. Процесс rsync длится около 45 минут. А потом просто заканчивается. Понятия не имею, почему это останавливается. Насколько я могу судить, он даже не завершает построение и сканирование списка файлов. У меня вывод cron направлен в файл журнала. В журнале все, что я вижу: receiving file list ... done. Но я вижу, что в место назначения резервной копии ничего не было перенесено.

Если я запустил скрипт вручную, примерно через 45 минут я просто увидел это: ./sync.sh: line 51: 9078 Killed $RSYNC $OPTIONS $SOURCE $DESTINATION

Как и где я вижу причину сбоя? Как мне узнать, какой сервер на самом деле убивает процесс, отправитель или получатель?

В тянущий машина (на которой выполняется скрипт) - это младшая коробка. Это виртуальная машина KVM с 256 МБ ОЗУ. Итак, мне интересно, не занимает ли построение файловой структуры слишком много оперативной памяти, что приводит к ошибке OOM. Но как мне проверить, так ли это? Более того, не было значительного увеличения файлов, чтобы это могло вызвать внезапный сбой.

Любые советы будут оценены.

Спасибо.

Обновление 1

Как было предложено @APZ, я добавил еще пару подробных флагов (всего 3) и запустил скрипт вручную, перенаправив вывод в файл. Вот результат в конце:

(.... lots of file names....)
received 5795917 names
done
recv_file_list done
get_local_name count=5795917 /storage/  <======== Reached here after about 40 minutes. Was stuck here for about 10 minutes or so.
[Receiver] _exit_cleanup(code=14, file=main.c, line=788): about to call exit(14)

rsync: fork failed in do_recv: Cannot allocate memory (12)
rsync error: error in IPC code (code 14) at main.c(788) [Receiver=3.0.9]

Чтобы ответить @TimHaegele, насколько я знаю, хост виртуальной машины (Prometeus / IperWeb) не ограничивает CPU, IO или что-то еще. Хотя я мог бы их спросить. Они очень высоко оценены.

В моей установке Ubuntu на виртуальной машине настроен своп на 512 МБ. Может быть, я могу увеличить это до 2 ГБ или около того? Место на диске не проблема.

Когда rsync запущен, это результат работы free -m:

             total       used       free     shared    buffers     cached
Mem:           239        236          2          0          0          3
-/+ buffers/cache:        232          7
Swap:          511        510          1

Основываясь на этих доказательствах, будет ли по-прежнему иметь значение изменение настроек SSH Daemon, как предлагается?

Обновление 2

Похоже, что все согласны с тем, что проблема в нехватке памяти. Итак, я добавил новый файл подкачки размером 2 ГБ и активировал его. Итак, теперь у меня всего 2,5 ГБ подкачки.

Затем я снова запустил сценарий (вручную). На этот раз он длился более 90 минут. К этому времени он пересылал файлы. Но вдруг процесс остановился. В логах я вижу, что он завершился со следующей ошибкой:

Invalid packet at end of run (4330026) [sender]
[generator] _exit_cleanup(code=12, file=io.c, line=1532): about to call exit(12)
rsync error: protocol incompatibility (code 2) at main.c(695) [sender=3.0.7]
rsync: writefd_unbuffered failed to write 23 bytes to socket [generator]: Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at io.c(1532) [generator=3.0.9]
[receiver] _exit_cleanup(code=19, file=main.c, line=1316): about to call exit(19)
rsync error: received SIGUSR1 (code 19) at main.c(1316) [receiver=3.0.9]

Как видите, машина-отправитель имеет версию 3.0.7, а получатель (съемник) - 3.0.9. Я не совсем понимаю, в чем ошибка.

Тем временем я увидел комментарий @APZ и изменил свой скрипт, чтобы заменить --delete-after с участием --delete-delay. Я снова запускаю его. Вернусь с обновлениями.

Обновление 3

Добавление дополнительных свопов и использование --delete-delay вместо того --delete-after похоже, добился цели. Обычное задание cron, похоже, тоже работает нормально.

Также я следил Эта статья чтобы запустить rsync с sudo на отправляющей машине. Это также удалило Permission denied (13) предупреждения во время передачи.

Спасибо всем за помощь.

P.S .: Все, кто участвовал в этом Q&A, давали полезные предложения. К сожалению, я могу отметить только один правильный ответ.