Hi to all,
I have latest urbackup server running in a debian 10 KVM, this server has a lot of backup schedules… so sometimes, for maintenance purposes, I have to reboot this server but the problem is that very often this happens while a backup is running, the command I run to reboot the server is
"shutdown -r now"
and this obviously doesn’t wait for urbackup to end his job… so I’m scared about inconsistency in the affected backups… do you think that there is a better way to reboot this server?
Yeah, it won’t. I’m not really sure there’s a way to do what you’re describing. The man page lists a “run” command to start the server but no command to stop it, so I guess the intended way to stop is to stop the service.
You could try to check if a backup is running before shutting down the server.
This can be achieved by querying the urbackup sqlite database from eg. a shutdown bash script.
You can try to run this command from a shell, it should return a string containing a CSV of clients that are currently backing up:
sqlite3 /var/urbackup/backup_server.db 'SELECT group_concat(B.name) FROM backups A LEFT JOIN clients B ON A.clientid=B.id WHERE A.done=0;'
Note: the path to backup_server.db can be different on Debian.
I set the “Max simultaneous backups” to 0 under Settings->Server and monitor the Activities tab until there are no more backups running. Then I stop the Jail running under FreeNAS. Set “Max simultaneous backups” back to its original value when you want to start backups again.
how about create a cron job to restart the server? and schedule it on a free time of your backups? Just set up the clean up time window, backup window, archive window, leaving free time to restart the machine at cron job schedule.
FWIW, I used to run my UrBackup server on a Raspberry Pi. And the device would hang every now and then. I’d say probably a dozen times over the years I used this setup for UrBackup. The only remedy was to yank the power cord, then plug it back in. This is the least elegant way of rebooting something. But even given this last resort method, never once did I have any problem with UrBackup (or the rest of the Pi for that matter). Yes, the UrBackup’s that were in the middle of processing failed, but the next days scheduled backups proceeded successfully without a hitch. I would not recommend this method of rebooting, I mention it only as a point of reference regarding what has happened in my experience in this most dreaded reboot scenario.
Now I run UrBackup server on a much more capable Linux box via Docker. To “reboot” UrBackup, I stop and start the entire container like this: