concurrent execution of dietpi-backup after lost ssh connection

[peaceman1920]

concurrent execution of dietpi-backup after lost ssh connection

[peaceman1920]

First results:

• "screen" is great! must now get used to it.
• first part of my new backup-setup works great (speeded up Raspi4 backup with factor 100, even connected via USB2)

[peaceman1920]

so far so good - nice to have such a qualified support

[MichaIng]

I guess the flag folder is still present, could not be removed by the original dietpi-backup instance due to a SIGKILL or so. Usually when a SSH session is lost, it should send a graceful SIGTERM. Which SSH server are you using?

This should solve it:

rmdir /tmp/DietPi-Backup

[peaceman1920]

Hi, I'm using this great software: https://github.com/asbru-cm/asbru-cm it's very useful if one has more than one server
in the basement.

This is what I got:

root@rasp4-DietPi-server:# rmdir /tmp/DietPi-Backup
rmdir: konnte '/tmp/DietPi-Backup' nicht entfernen: Das Verzeichnis ist nicht leer
root@rasp4-DietPi-server:~#

english: couldn't delete directory: directory not empty

the ssh server is the one installed by DietPi - Dropbear I guess.

[MichaIng]

Try this instead:

rm -R /tmp/DietPi-Backup

The backup process was terminated due to the SSH session loss. Such can be generally avoided by using e.g. GNU/screen: https://packages.debian.org/screen
It creates a detachable shell which survives connection losses and and be reattached any time later.

However, no worries about the long backup run: All files which have been copied already remain copied and won't be copied again. Basically the backup continues where it stopped.

I'll try to replicate the hard kill in case of Dropbear connection loss. Probably it is SIGKILLed because rsync wants to finish the whole process, which takes longer than Dropbear allows. I could imaging that it sends a SIGTERM first, allowing some time for graceful process termination, but a SIGKILL after some timeout.

[peaceman1920]

Great support!

• It worked, many thanks (till now i solved it the brutal way: Pi reboot)
• I'll give screen a try and familiarize myself with it - seems to be what I need and was looking for
• backup took too long anyway, maybe because of the nfs share (?); I've read some comments about difficulties with nfs and rsync sometimes (actually I could get it starting only after adding the parameter "no_root_squash" in the exports file of the nfs server)
• I'm working on another backup-setup (better filter for DietPi-Backup => only on physically attached SSD I can boot from in case of emergency, all other files handled by syncthing between my several servers and desktops) - should result in much better speed (and reliability too)

Many thanks for your great and rapid support!