Correct way to reboot an urbackup server

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?
many thanks

I’m not sure if it matters, but if you’re worried, you can always stop the UrBackup service first, it ought then to stop gracefully.

Sorry I can’t give you the command to do so (at least not for a Linux box “NET STOP UrBackupWinServer” on Windows) & the administration manual seems to lack a command line reference

1 Like

thank you

“sudo systemctl restart urbackupsrv”

if you want to just stop, then: “sudo systemctl stop urbackupsrv”


Thank you but I think that this Will not wait the end of any running backup process

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.

1 Like

If you really want to wait out running backups, regardless that there’s actually no need to, you can go to the server settings & disable both file & image backups.

Running backups should complete but no new backups start.

After restarting you’d have to enable them again.

1 Like

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( FROM backups A LEFT JOIN clients B ON WHERE A.done=0;'

Note: the path to backup_server.db can be different on Debian.

1 Like

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.

how to problem resolve urbackup server stop and start why reset and new session start and identity key change

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:

docker container stop urbackup
docker container restart urbackup

I use the official UrBackup Docker image. Which was initially brought up with:

docker-compose up -d

…and the following entry in docker-compose.yml:

    image: uroni/urbackup-server:production
    container_name: urbackup
    restart: unless-stopped
    network_mode: host
      - /backups/urbackup/database:/var/urbackup
      - /backups/urbackup/backups:/backups
      - ./app_data/urbackup/www:/usr/share/urbackup
      - PUID=1009
      - PGID=1008
      - TZ=America/Denver