backintime
backintime copied to clipboard
bit-team
GUI takes very long to read in Snapshot Directory
First of all: great software, saved my *** a couple of times, backups and restores work just great.
However, the longer I am using it, the more snapshots are made (naturally) and the UI gets slower and slower. Every time I start the GUI (I am running Ubuntu 18.04 and Budgie), it takes a minute or more to read in the catalog of snapshots and the UI is unresponsive to any clicks in the meantime (except the generic window controls, so I can still close the app).
Also, whenever I do something (like delete a snapshot or add an exclusion path) the whole procedure starts from scratch. In the beginning it was no problem to wait a few seconds, but now I have so many snapshots that it takes literally minutes. Is there anything I can do about that?
Yes, you can delete old snapshots. You don't need hundreds of old snapshots or new snapshots every hour.
Here are my settings, which work great:
Make a snapshot once a day and delete automatically like this:
So I have about 16 snapshots available, most of them from the last few days and the oldest from 1-2 years ago.
Ok thanks, I'll give the "smart remove" settings a shot. Would have preferred to keep all snapshots as Time Machine does, but that would probably take a database of some sort to avoid filesystem scanning.
When is "smart remove" triggered? I have configured it and waited a day for it to start removing old snapshots, but so far nothing happened. Can I trigger that manually?
It's definitely triggered after an automated backup. I don't think you can trigger it manually. If it runs the first time and you have thousands of backups, that will take a while... The experimental part (background remove) would run on the NAS itself much faster, but it doesn't work on my Synology, so you have to test that. If you check the box and save that setting, backintime is testing first if the option is possible.
Well, the "smart remove" rules definitely don't kick in. What's strange is that I have also an option to start the BackInTime GUI as root and then the "smart remove" settings are all different compared to when I start the GUI as my user. Anyway, I've configured the settings under root now to be identical to those of my user - perhaps now they will be activated.
Hi, @realulim, did Smart Remove work for you in the end?
Your regular user and the root user have different backintime profiles, and different snapshot management settings. You can use the same target drive/directory as your backup location, but the data will end up in separate folders.
Many users use their regular account to back up data from their home directory, and the root profile for system backups (excluding /home).
Smart remove works now, but I am still not sure whether it is running as root or my user, because the settings are identical for both. I actually want to do a system backup, so root would be my choice. But my Ubuntu Budgie desktop runs as my user, not as root. So how could BackInTime gain root access to the filesystem? IIRC it is not a system program, but runs under the user configuring it.
The system logs (journalctl -b | grep backintime) can tell you which user is running the backup jobs.
Backintime should have two entries in your Desktop Environment's application menus: Back In Time and Back In Time (root). Open each one and check to see which has all the snapshots saved.
It's normal that there may be separate profiles for root and your regular user, each separate jobs (called from their separate crontabs). But if you only need one, and it should cover your whole system, then set it up for root.
I'm closing the Issue, but feel free to continue the discussion if you have more questions :)
Well, the settings are the same for both root and my user and so it appears that both are running backintime. At least that is what it looks like in journcalctl and also if I open the backintime GUI from the application menu as user or as root, I have all the snapshots in both cases. So I suppose I should shut one of them off. Well, that's what I had before, I only had it running as my user, but then the smart remove didn't work. Perhaps I should try to only run it as root and see if smart remove continues to work.
I don't even know how to shut off a profile for one user. Both (root and my user) are running off the "main profile", which can't be deleted.
It might just be that you've been doing double backups all this time, one for each your normal user and root. If you examine the backup destination folder, you should see either:
- two sets of backups (using double the space, in total), or
- just one set of backups, which both users are writing into, because you've set the exact same destination path for both "Main profile"s.
To disable crontab runs, you can set the "Schedule" to "Disabled" in the profile settings. To completely remove a user's profile, you'd have to delete ~/.config/backintime/config (better just to move the file somewhere for testing).
I have just one backup folder, as both profiles have the same destination folder (they're identical). The output from journalctl also looks like there are competing backup jobs.
This does look pretty dumb on my part, but thanks a lot for your help. Originally I wanted to backup everything as root, but that didn't work, because Ubuntu starts as my user. So I configured the root user to use the Main Profile, which is configured identically to the Main Profile of my user, which means it backs up everything as my user, not as root.
Still, there are entries in the journalctl that are from root. It kind of makes me wonder how that can be, if the root profile is configured to run as my user. Could it be that smart remove perhaps didn't work at first, because it ran as my user and now it's working because it is running as root (even though root uses my user for the actual backup)?
I'm not sure I can follow your thinking. Here's how backintime works when combining a root profile with your user profile:
As your own user, you just run backintime-qt.
It will then read/modify the config file $HOME/.config/backintime/config. You can have many profiles in there, and they will be defined as profile1, profile2 etc. in $HOME/.config/backintime/config, and show up as separate profiles in the GUI.
You can then take either manual snapshots from the GUI (running as your user), or call backintime from the console, or use the GUI-supported scheduling, which ultimately calls backintime from your user's crontab (see the output of crontab -l).
To launch "Back In Time (root)", you execute /usr/bin/backintime-qt_polkit, which is a script that calls pkexec /usr/bin/backintime-qt. You will then have backintime-qt running, but as the root user*. It reads/modifies the config file /root/.config/backintime/config. This can also hold many profiles, but they will be separate from the ones for your user.
For taking backups as root, you either call a manual snapshot from the GUI (running as root), or call pkexec backintime, or use the GUI-supported scheduling, which ultimately calls backintime from root's crontab (see the output of pkexec crontab -l).
*(Note that for reasons I can't entirely explain, this is somewhat different from running sudo backintime-qt.)
Maybe this clears things up for you.
Ok, I have a preconfigured appliance here that already came with Ubuntu and Budgie and backintime icons on the launcher bar, so I didn't really check what they ran. Now I did check and the two icons indeed run the commands you specified and when I configure them from the GUI, then the user's (or root's) crontab is modified. This would explain why the backup off the root profile always runs as root, even though I haven't logged in as root. You see, I did get the information before that everything was based off the user running Budgie (the desktop manager) and I couldn't run backups as root, if Budgie runs as my user. I only could run backups manually from the root GUI, because in order to launch that I have to authenticate as root and that would allow it to run the backup.
But it seems that information was totally wrong and I can actually run backups from the root crontab and the GUI does not have to be running for that - very good. That makes life a lot simpler, although I still don't understand what the purpose is of configuring a different user in the profile (see screenshot - here I put in my user, although the job will be run as root).
But it seems that information was totally wrong and I can actually run backups from the root crontab and the GUI does not have to be running for that - very good. That makes life a lot simpler, although I still don't understand what the purpose is of configuring a different user in the profile (see screenshot - here I put in my user, although the job will be run as root).
That's a very good question, and it's very much backintime's fault, because this setting is enormously confusing. The only purpose of the "Benutzer:" field there is to name the path where the backups are stored. It has nothing to do with the user that runs the backup process. You can put pretty much anything in there.
I'm hoping to eliminate this setting in the future, because it has also annoyed and confused me in the past. The feature request for tracking this is #1304.