I’m trying to use dietpi-backup via ssh over wifi connection. On the previous versions of DietPi it worked fine, on the latest version it stops wifimonitor service which (I suppose) disconnects me from RPI3, so I can’t see the progress. Is there a workaround?
I’ve tried
nohup dietpi-backup 1 &
but it can’t seem to find dietpi-backup
Hi,
dietpi-wifi-monitor?
If so, try commenting out the following line in /DietPi/dietpi/dietpi-services
#'dietpi-wifi-monitor'
If that resolves it, let me know and i’ll remove it by default in v159 update.
Yay! It worked perfectly! Thanks a lot! 
Excellent,
I’ll see if we can fix this permanent in DietPi
https://github.com/Fourdee/DietPi/issues/1288
Today, I’ve tried to update to v159 and I’ve got this:
DietPi-Services
─────────────────────────────────────────────────────
Mode: stop
Please wait...
[Ok] stop : cron
[Ok] stop : proftpd
[Ok] stop : nginx
[Ok] stop : php5-fpm
[Ok] stop : mysql
[Ok] stop : fail2ban
[Ok] stop : avahi-daemon
[Ok] stop : rpimonitor
dietpi-wifi-monitor
And Wi-FI dropped again 
Whole log: https://pastebin.com/MUSDe7fR
But I definitely have it commented out in that services file you mentioned above:
'home-assistant'
'openbazaar'
#'dietpi-wifi-monitor'
'docker'
'bdd'
'minio'
Dietpi-update work fine though.
UPDATE: And it broke the nextcloud again. I guess I’ll have to wait until we could solve this wi-fi dropping during update.
Are you sure, you didn’t update your system after commenting out dietpi-wifi-monitor and beginning the dietpi-update?
Had a simmilar issue before reading this topic and the bug on github with v158 but after commenting out, the update to v159 completed successfully over SSH.
However, after the update, dietpi-wifi-monitor wasn’t commented out anymore so the next software-installation dropped the Wifi-connection as usual. Seems like the /DietPi/dietpi/dietpi-services file gets replaced by the update to v159.
Yup, I’m absolutely sure.
monzon@MZ-Cloud:~ $ cat /DietPi/dietpi/dietpi-services | grep wifi
#'dietpi-wifi-monitor'
First post! Go me!
I am having the same problem. It drops all my running services and I stuck waiting fro it to finish or kill it. I am logged in as dietpi and then sudo to run dietpi-backup. The backup itself is fine. It’s anything I may potentially be using at that moment will go offline. It will say unmasking the service then stopping. They don’t return until the backup finished. This is tedious because because of the dry run then the backup.
I also noticed. That Dietpi reclaims services that I purposely did not install through the script. My Samba config is annoying so I just brought it over and did a standard apt install. I am currently enjoying the warning messages that my shares are offline because Dietpi claimed the service. Those shares aren’t even on the machine nor backed up. Without digging into script I haven’t figured out why but I assumed that Dietpi would only manage services it installed. For example. I did not install Qbittorrent through the script. I found it’s just easier to bring my config over and relaunch. Dietpi does not stop that service.
Finally. I know it seems like complaints. More of hey, this isn’t what I am used to. So bear with me. Retired IT so just blunt to get the facts.
I use Cockpit. Dietpi does mask services. Such as Qbittorrent-Nox. I login as root there. Tell it not to mask the service. It should be noted the service is running but it shows as masked. I have done this multiple times over the last 5 days just to make sure I’m not losing my mind.
I don’t mind digging in the scripts if I can be pointed to the right direction. Once my current backup finishes. I’ll check /DietPi/dietpi/dietpi-services after this and I’ll read the links in this thread.
Thanks!
Just open dietpi-services, select the service in question and deselect it from being DietPi controlled. This way services should stay online during backup.
Our aim is to stop all known services, even if not installed with our script, to ensure a consistent backup. Especially for database this is important to ensure a clean state, otherwise you could run into consistency issues on a restore. Just one example.
I was coming back to edit. You beat me. I see how it works. Thanks for the quick response. I’ll keep reading and digging around. I’m just used to slapping on a server image and going from there. I was being lazy and going for the one and done approach. Which does work.
In my case. I’m used to my way and trying to make it work the way I am used to is self defeating. But I will say the system is very slick and the performance gains have been impressive. Even my most barebones install can’t beat the performance bump. So I’m willing to tough it out and learn to play with others. 
Thanks again!
One hint, be carefull with these old post. Thinks might have changed in meantime. Like location for our script. They have been moved to /boot since a while 
Have a look to our online docs for some more deatils DietPi Documentation - DietPi.com Docs
It’s actually the Exclude option which is relevant here. Systemd controlled means that systemd starts the service at boot, but dietpi-services still starts/stops it on maintenance tasks. Include/Exclude is what adds/removes services from being started/stopped by DietPi competely.
However, during a backup it is very reasonable to stop non-critical services. This topic here was about the WiFi monitor being stopped, which stopped the WiFi connection itself that time it seems (that isn’t the case nowadays). So that was indeed bad as it may break the backup in the middle when run from SSH or makes it impossible if an NFS share is the target. But stopping services like Samba server and web applications make much sense, so that the backup is not potentially done during file uploads/downloads, limiting bandwidth of network and/or drive, and causing inconsistencies if some files are from before a services task started and others from after that task finished, having a potentially broken state when the backup is restored. Another point is CPU and especially RAM usage peaking during the backup, leading either potentially to OOM kills or system instabilities when other services are having usage peaks concurrently.
If you have scheduled uploads/downloads to/from the Samba server, possibly they can be rescheduled to run in a different time frame than the backup. For manual usage, probably rescheduling the daily cron job (if you use daily backup) to somewhere in the night where everyone is asleep via dietpi-cron could help.