Linux client installed and online but not backing up?

I installed the Linux client on a small X86 Mint (Ubuntu) system and a RaspberryPi-Zero running Pi-OS (both using block mode snapshots), rebooting after the install was complete. Both systems showed up as “online” in the server status window - but I can’t get them to run either a full file or image backup.

I had adjusted the file backup parameters for each Linux client on the server (changing the defaults which were set up for Windows to “/home/*” for a default directory) and then used the server status window’s “With Selected” option to queue full file and image backups. No backups are started or performed however and the next time I refresh the server status window there is no message about these processes still being queued. The logs display does not show that any backup was ever started on the Linux systems.

I saw in another post that someone had explictly set the included and excluded files on their Linux client, so I tried that too (using “/” for the included and then a short list of excluded directories), but still no backups were started for these clients.

I looked through the manual to see what the various command line options for the Linux client were, but since my browser won’t allow an automated search of the large document couldn’t find where this was actually discussed.

I am presuming that the Linux clients are actually running correctly, because they are showing up “online” in the Urbackup server status window. Puzzled that they are not running any backups. Any thoughts or suggestions would be greatly appreciated! Thank you!

Although it may be obvious, I forgot to mention that my Linux clients are in the same local network as the Urbackup server is.

I would try to determine if it’s a problem with the configuration, or in scheduling. Can you start a backup manually and does it run? If that works, but backups don’t happen as scheduled, I’d check to make sure the clients are online at the time of the scheduled backup (not sleeping or hibernating or something like that). If your client is on a laptop, do you have it configured to go to sleep when you close the lid? That would stop backups from occurring if the lid was closed at backup time. Do you have any scheduled sleep times, like going to sleep after XXX minutes of idle time? Also, do you have a small backup window set and several other clients that are competing to get started at the same time? Check how many backups you are allowing to be running simultaneously and how long your backup window is.

Thanks for your reply!

Neither of my two Linux systems have any sleeping or hibernations intervals set up, nor are any of them running on a laptop.

I logged into one of my Linux systems (found where the client executable was hidden) and tried to manually start a backup like this:

/usr/local/bin/urbackupclientctl start -f
Waiting for server to start backup… done
Timeout while waiting for server to start backup

Never saw anything on the server status window change either as I did that. The status window is showing the “last seen” value for the client as nearly 12 hours ago, although they are connected and able to communicate (http and ssh) within the same local network.

The client status command returns:

/usr/local/bin/urbackupclientctl status
{
“capability_bits”: 69632,
“finished_processes”: [],
“internet_connected”: false,
“internet_status”: “connected_local”,
“last_backup_time”: 0,
“running_processes”: [],
“servers”: [{
“internet_connection”: false,
“name”: “192.168.2.10”
}
],
“time_since_last_lan_connection”: 13451
}

I also ran a client list-backupdirs command too:

/usr/local/bin/urbackupclientctl list-backupdirs
PATH NAME FLAGS CONFIGURED ON SERVER


/home/* rootfs follow_symlinks,symlinks_optional,share_hashes Yes

Which shows the value for the default directory to back up that I’d set via the server’s web interface for that client system.

I’ve left all the communications port numbers, clean up and backup time windows, and most of the other parameters (aside from the max backups to keep) as their installed defaults. The max simultaneous backups is set to 10, well above what the 3 clients I’ve got should be doing.

The server has been working perfectly for the one Windows system I have set up to use it, so I’m not sure why the Linux client can’t seem to connect (even though it display as “online”) right now.

I’ll keep playing around with the client, to see if I can figure out anything else. Thanks again for your help!

O.K., I restarted the Urbackup server (service on Windows) and tried another manual backup start from one of the Linux clients. Nothing changed on the server’s Status or Activities windows but I now see this in the Logs display for that client:

Level Time Message
Errors 12/24/22 14:38 Constructing of filelist of “david-minix” failed: no backup dirs. Please add paths to backup on the client (via tray icon) or configure default paths to backup.
Errors 12/24/22 14:38 Backup had an early error. Deleting partial backup.

But there are defined default backup directories that the client picked up from the server:

/usr/local/bin/urbackupclientctl list-backupdirs
PATH NAME FLAGS CONFIGURED ON SERVER


/home/* rootfs follow_symlinks,symlinks_optional,share_hashes Yes

I then tried to look up the command line help for the “set-settings” command of the client, to see if I could try to explictly define the directories to back up any better there. Unfortunately the command line help didn’t really give enough specific details to tell me how to do that… I’ll go rummage the manual again to see if there is a config file that the client uses, and find where it’s hidden.

Two steps forward, one step back…

Just changed the default directories to back up on the server from “/home/*” to “/home” and then manually started a full backup from the client. It looks like it did it (a full file backup)!

Not sure what I have to do to get it to do a full image backup now, as the command line client’s “start” command doesn’t specifically have an option to tell it what type of backup to perform, other than “full” or “incremental”.

Once again, two steps forward, but not there yet - but progress nonetheless…

The full image backup failed on the Raspberry Pi-zero with this:

2022-12-24 16:24:58(info): Starting unscheduled full file backup…
2022-12-24 16:24:58(info): Last virtual full index unfinished. Performing incremental (virtual full) indexing…
2022-12-24 16:24:58(error): Creating snapshot of “/home” failed
2022-12-24 16:24:58(error): Snapshotting device /dev/root via dm…
2022-12-24 16:24:58(error): /dev/root is not a device mapper device. Cannot snapshot via dm.
2022-12-24 16:24:58(error): Creating snapshot of “home” failed.
2022-12-24 16:24:58(info): Indexing of “home” done. 1 filesystem lookups 0 db lookups and 0 db updates
2022-12-24 16:24:58(info): raspberrypi: Loading file list…
2022-12-24 16:24:59(info): raspberrypi: Started loading files…
2022-12-24 16:24:59(info): Waiting for file transfers…
2022-12-24 16:24:59(info): Referencing snapshot on “raspberrypi” for path “home” failed: FAILED
2022-12-24 16:25:00(info): Waiting for file hashing and copying threads…
2022-12-24 16:26:00(info): Writing new file list…
2022-12-24 16:26:00(info): All metadata was present
2022-12-24 16:26:00(info): Transferred 3.09863 KB - Average speed: 22.888 KBit/s
2022-12-24 16:26:08(info): Time taken for backing up client raspberrypi: 1m 10s
2022-12-24 16:26:08(info): Backup completed with issues

I told it to do block mode snapshots when I installed the Linux client, but from these errors there’s still something wrong with it. (And yeah, I did reboot after the install to allow it to convert the drive somehow - to enable the block mode snapshots). I have no idea what is actually wrong or how to try to fix it…

I’ll research the errors some more and see if any solutions turn up.

/usr/local/bin/urbackupclientctl list-backupdirs
PATH NAME FLAGS CONFIGURED ON SERVER

/home/ rootfs follow_symlinks,symlinks_optional,share_hashes Yes*

Yes, the above is incorrect. But you figured that out and got it running. :+1:

As far as your image backups on Linux, I can’t offer any insight there. I thought image backups were not supported on Linux. But apparently they must be these days. That’s news to me.

Thanks for your response - happy holidays!

Although I worked on server apps on Linux for several years and run a few home systems that use it, I’m no expert in most of it - and am clueless about the “device mapper” stuff that is showing up in the image backup error messages:

Level Time Message
Errors 12/24/22 16:24 Creating snapshot of “/home” failed
Errors 12/24/22 16:24 Snapshotting device /dev/root via dm…
Errors 12/24/22 16:24 /dev/root is not a device mapper device. Cannot snapshot via dm.
Errors 12/24/22 16:24 Creating snapshot of “home” failed.

The Wikipedia article I found about device mappers on Linux was pretty vague and did not suggest anything I could make sense out of tio try to fix this type of error.

I would have thought that the Urbackup installer would have downloaded the necessary packages - which I think it probably did, as the installer had me reboot to “convert” the drives somehow so the device mapper layer could work on them. O.K., so if the “dm” software was installed and my logical drive (an SD card on my Pi’s) was “converted” to use it - why didn’t that work (either on the Pi’s or the Minix PC which also has an SSD for its disk space)?

I’m wondering if I should just disable trying to do any image backups on my Linux systems, since right now they are all getting these same types of “device mapper” errors - with me without a clue as to how to try to fix them…

If you get snapshot working on a ext4 on your rpi I would love for you to share how you did that here. :slight_smile:

I don’t do image backups, only files. The snapshot mechanics works on my btrfs drive, but nomatter what I try I can’t get any snapshot mechanic to play with urbackup and ext4 and since I backup from both btrfs and ext4 I constantly got the exact same errors you did (on the ext4 partitions), but the file backup works anyway.
I added the ext4 mount to be excluded and now I only get “info” level on my bugs, same errors, but at least I wont have to see a red “ERROR” on my logs page for every backup.

I made a wall of text here on this forum about my setup process and experience. Maybe nothing to help you there, but the process of excluding (witch is not mentioned in the documentation) is explained there because I cant pull the exact directories from memory to type here.

Hey, thanks for your informative reply! Very helpful to hear that the snapshot issues I’m seeing aren’t unique.

I’ve turned off image backups on all my Linux systems (2 and a half Pi’s (the zero counts as the half) and the x86 Minix) which is probably not a big problem since they’re pretty easy to rebuild from scratch if necessary. I can also externally copy the SD cards that the Pi’s use for their storage too, although that takes a little while and isn’t very convient. :crazy_face:

I’m glad that both the image and file backups are working well on my wife’s Windows laptop, since like most systems that come with Windows pre-installed (or that it upgrades to from a pre-installed version) - it’s impossible to find the actual product key to activate it again if you ever need to. (Any that I’ve found with the various utilities look valid, but always fail to work if you’re trying to reactivate the product in a real case). Don’t need that headache, ever!

When I was a mainframe systems programmer early in my career, we had a mantra that was “you can never have too many backups”, so anything that Urbackup can do to help on all my systems is useful! I used the original version of CrashPlan to backup my systems to my local main server (and then back it up to their cloud) for a few years, until they took that free, local, secondary functionality away to sell more individual system licenses. Urbackup helps restore that useful ability once again!

Thanks again for your post! Have a wonderful New Year!

I am of the same opinion (although I was a Unix geek rather than a mainframe geek!)

A problem that I sometimes worry about now is if I get run over by a truck tomorrow, will my wife be able to retrieve her accidentally deleted files from backup or restore an image to a new SSD/HDD? I can just imagine her turning off my desktop and servers to save power since I was no longer around to use them. And then wondering why urbackup is offline. I have not found a self-hosted backup system (e.g., urbackup or others) that I’m 100% confident that a non-computer-geek could walk into and use. And the commercial offerings are really no better. I can’t imagine trying to restore a multi-terrabyte image over the internet to a new HDD. Maybe a computer geek could accomplish it, but I have my doubts about anyone else.

After doing research, I decided that urbackup was the best overall solution. But rather than trying to teach my wife how to use it at more than the very basic client level, I created documentation on how the server is set up on my Linux box with an additional note to “find a Linux guru to help you” - along with a few names of my friends who might fit the bill.

Yeah, I’m in exactly the same situation if I wasn’t around to keep the household IT infrastructure going - pretty quickly nothing would work and no other family members would have a clue how to fix it. My main Windows server hosts our security camera hub, media server, Urbackup server, and is the main repository of our family pictures and videos. My multiple Pi’s run our in house security camera displays, which I finally set up an Ansible script to automatically apply maintence to. I like your idea of just writing up some documentation so a tech guru could find and manage everything in a pinch. Heck, even my brother could step in and help out if he had that.

I was in the hospital “all summer long” a few years ago, literally nearly dying from a spider bite infection that put me in a medically induced coma for over a month with a long recovery from surgical wounds after that. When I finally got back home two and a half month later, nothing was working anymore - we even had lost Internet and wi-fi service because someone who shall remain nameless had unplugged everything to reorganize the room and then had no idea how to reconnect it again. Good documentation is a great idea, now I just have to find the time to create it! :grimacing:

Thanks for your post, have a great New Year!

Well, this thread turned “dark”, discussing how your relatives would be able to access the backups if you are no longer there, heartwarming and morbid at the same time. :open_mouth:

I have a network drive (on my win computer) that my pi mounts at startup (or with sudo mount -a since it’s in fstab) then Image File Utilities is your friend. I write the backup directly to my computer via the network (samba). Amazing little script that backs up your raspberry completely and shrinks the image, lets you pass arguments to add extra space in the img file after shrinking it to a minimum and stuff like “don’t autoexpand on boot” etc. It backs up with rsync so only the first takes “time”, after that it uses incremental copy. Could be good to know it does NOT backup mounted drives by default.

Similarly, if you run on another sbc with lets say armbian or any other linux distro, I recommend gddrescue to back up, then pishrink to shrink the image.
Next backup you mount the img-file (sudo mount -o loop,offset=4194304 /path/to/image.img /mnt/loop) with the correct offset, fdisk -l the img-file, calculation for offset goes: start(8192) x blocksize(512) = offset(4194304) and rsync / to /mnt/loop. Works like a charm.

I then backup the image file with urbackup, redundancy is the shit. xD

I have all my settings/database (for urbackup) on a mounted drive, so the img file wont contain those files for me, those files are ALSO being backed up by urbackup, (I dont trust the SINGLE backup of the database urbackup does itself, what if the database is already corrupted when making that backup?) so each backup it increases by the size of the database files, but I’m fine with that, it will take a LONG time before my 6TB disk gets even close to full.