Hey, i just wanted to exclude /var/lib/flatpak, but not /var/lib/flatpak/overrides, so what i set on this client was /var/lib/flatpak/* as an entry under “Excluded files (with wildcards):” and set /var/lib/flatpak/overrides/* under “Included files (with wildcards):”. Then i started an incremental backup.
And the resulting backup is empty.
If i remove the include again the backup seems to work again, but with an another issue:
Side problem: since the new backup refers to the last backup (which is 0bytes), it starts backing up everything, in this case ~1.7TB. Also i cannot remove the last backup (i understand why, by design) but that seems very inefficient. So basically i have found a potential bug and have a question; how to prevent this re-sync of everything (eventually there will be no significant disk usage, since all the hashes will point out the data can be linked), possibly by deleting this last faulty backup of 0 bytes so the next backup refers to an actual good backup? Possibly by stopping urbackupsrv, removing that empty folder from the backups folder, updating the link “current” to the right last one, running urbackupsrv --remove-unknown and then starting urbackupsrv again? I am hesitant to do that, please let me know.
As a workaround to the bug i will simply create another backupdir that only includes /var/lib/flatpak/overrides
Edit: the asterisks at the end of the paths made them show up italic, so i fixed that.
The manual says that once you put something in the exclude your include gets ignored. Or something like that.
I have a feeling that if one were to specify at the client (not using the server web gui) you could do it.
What I did was have a virtual sub client include the bits I wanted and the main excludes the bit I dont want.
Another trick was to use the pre-backup scripts/hooks.
Hey thanks for responding. I read over the part again at UrBackup - Server administration manual and the part after (3.3.4) that about the exclusions, cant spot it, maybe its mentioned somewhere else?
So if i understand right, you created a second virtual client for the same client machine? Is that possible? Sounds like a bit of a hack to accomplish this goal. Do you have 2 instances of the backend running on that client?
I think the trick to just add another backupdir to the list that only specifies that “overrides” folder i want to include will do the trick. Im gonna try to trick urbackupsrv into referring to the last good backup, either way its going to re-download everything anyway.
In any case, if it still didn’t include the directory in the backup i suppose that isnt a big issue, but excluding everything from there on, also other “Backupdirs” is a problem of course.
I dont have the client gui installed on the client, i suppose it can be done via a urbackupclientctl --set-setting --key “something?” --value “/var/lib/flatpak/overrides/*” but there we have the problem there is no documentation for that tool, only some help from the command line, so i would not know what key i could use for that.
Hol’ up, i just stopped urbackupsrv, then i noticed there were 2 recent backups made for that client (based on the folders found in the backup store):
So i started it again and now…i can delete the empty backup?
Weird.
Hmmm, it seems that messes up the link:
Gonna see what happens when i change that to the last succesful backup. Afaik i was never suppose to be able to remove that last (incremental) backup.
well fml, i stopped urbackupsrv again, removed the btrfs subvolume that corresponded with that last failed backup, updated the symlink to point to the last good one from yesterday, ran urbackupsrv remove-unknown (saw it removing entries from the db that related to that last failed backup), started urbackupsrv again, initiated an incremental backup, but:
.
Well anyway, i tried.
Gonna run a test on a vm soon to see if the behavior i deemed a bug is reproducible.
Yes. A virtual sub client IS ALWAYS for the same machine. Just different (or even same) paths for what you want backed up. Eg. My (only) windows client has music making programs n data files in C:. But my D: drive has basically static sounds and samples on it. So “musicpc” backup C drive daily and “musicpc[ddrive]” gets backed up monthly. “ddrive” was the name I put in the sub client field and the created backup folder on the server gets the client name and the sub client name enclosed in square brackets all concatenated together.
BTW ZFS doesn’t permit square brackets so if you wanted to use zfs on the backup server with virtual sub clients - it wouldn’t work.
Hope this helps. (Not that I’m saying you are using zfs - just info for the future. BTRFS is really really perfect as it saves huge amounts of space, always “saves only changes” with updates BUT they “appear” as full backups due to btrfs cleverness.)
Cheers for bringing this to my attention, i noticed the term “virtual” a couple of times in the command line parameters, and thought it was something different, see:
how it mentions those with on one hand “client name” but also “
Virtual client name”? I thought that option allows one to start a backup for client B
from client A, and the password file was probably there to service the authorization for that. Combine that with the field “Client name” on the server that is under the settings section “Client” (empty by default) and i thought that is more like an
alias for a client. So on the first hand a client has a hostname, then the client has a client name in urbackup (display name) that does not need to be the same, but is per default, hence: option to set a virtual name. Hell even recently i noticed that if you change the hostname of a machine, the name in the backupsrv gui will change too, so that further confirmed my believe this “virtual client” is nothing more than an alias, something to keep those display names constant in the web gui, for when the hostname changes often.
That was until just now when you explained and i started searching for the word “virtual” in the server administration manual and there it was: UrBackup - Server administration manual key word here is virtual SUB client, which makes sense and thanks for explaining, that is very useful to have different settings(inclusions and exclusions!), schedules, archiving, etc for one and the same host for subsets of data, like you described in your scenario, great stuff!
