-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate backintime with systemd for scheduling, snapshot control and logs #669
Comments
I've no experience with systemd timers, yet. But I'll have a look. Gnome GUI is gone. Current master only has one Qt5 GUI. New schedules would need to go into |
I have created some examples to run on my laptop. My Back In Time configuration have a number of profiles, but basically I use first for testing. Two files were created manually at ~/.config/systemd/user.
and backintime-job-1.timer:
After placing such files I have executed One profit of using such a way is that per-user systemd configuration can be backuped by Back In Time itself without system read privileges! |
Thank you @zimy for this. I've also been using systemd to schedule BIT backups recently, using a slightly different approach which I thought I'd share (apologies if no-one wants to see this). Here are my user units:
Except for the Descriptions, the system units are the same. All unit files are installed under the appropriate subdirectories in I set these units up to emulate the behaviour listed on the FAQ page under "How does the 'Repeatedly (anacron)' schedule work?", which I've then overridden as needed using drop-ins to set my own schedules and other parameters (as I have disabled BIT's scheduling and just let systemd manage it). I made these into template units as I have multiple system-level backup profiles, making it easy to instantiate these (i.e. The service units are listed as "indirect" as they are meant to be triggered by the timer, but can still be started directly (e.g. Update 2017-02-19: I saw a social media post recently which pointed out that timer units should be
Update 2017-04-21: For some reason forking type doesn't seem to work reliably anymore with "backup-job" (it looks like the forking doesn't happen -- or else exit immediately -- and then systemd fails unit when its start timeout is hit). As a workaround, I'm using "backup" with the default (simple) type. Not sure if that should be reported here or not. Separately (and just for anyone interested), systemd.exec(5) contains options that service units can use for |
Hi, just wondering how things are going about this issue. Backintime is very handy compared to all other similar software I know and this systemd option is awaited to ingrate it in the SolusOs repository. (see https://dev.solus-project.com/T729 and https://dev.solus-project.com/T1942 ). Thank a lot for your work anyway. |
Bump... another Solus user expressing interest for backintime supporting systemd timers. (I used & loved backintime on my old system.) |
I hardly find time to provide support for BiT. New features like this are nearly impossible for me at the moment. Sorry |
Sorry for reviving this, but it seems that BIT is putting the cronjob back in my crontab, even though I had commented it out to use my systemd-timer instead. Is there an easy way around this? Otherwise the systemd-timer is somewhat pointless, when BIT is also creating a snapshot according to the cronjob. |
@dataprolet wrote:
If I understand correctly, you can just set the schedule to |
Thank you, that's easier than I though! |
From what I see here, logging to the systemd journal would be the only thing that might require changes to backintime. Everything else can be accomplished by writing unit files that contain calls to the The backintime project might ship such unit files, but we'd have to find someone to write, test and maintain(!) them, given that systemd is … shall we say: a moving target. Keeping this open with the
Discussion
|
I don't know about using systemd journals for storing logs, but some distros (Fedora for example) no longer ship or enable cron by default. They prefer scheduling tasks now using systemd.timer. I found this out when trying to schedule automated backups with BiT . This creates some unneeded new user friction in configuring BiT. It might also become a problem if some distros decide to drop cron altogether. With that in mind I would like to see BiT at least support scheduling via systemd.timer as a built in option (in the same way that cron is). |
Thanks for reporting this. Which version of Fedora was that? |
Although it is correct that fedora does not ship and enables cron by default, it should be installed together with backintime. Since cronie is a dependency and backintime can't be installed without it. On the overall development of the distro and on the scheduling system I can't really add a lot of details. Since I just use fedora as a desktop OS I don't make use of a lot of scheduling. However, I have a scheduled task of backintime, which I set up so long ago that I don't remember any particular problems. |
If Fedora is without cron, than I assume that scheduling BIT doesn't work there. |
Whenever backintime is installed, also cron gets installed on fedora. So it should actually work, I think. I would like to get some information, what exactly were the additional steps @xalmat had to do to get it working. |
See #610 which is about fcron support and re-designing the related to code to encapsulate the underlying scheduling technic. |
Multiple topics here. systemd-timers: I don't see that we do support it in the near feature. Cron run everywhere, systemd don't. It is a matter of resources. But if there is a contributor willing to implement systemd-timer support I am happy to guide you through the contribution process. About logging: This was a bug that is fixed now. BIT use syslog which goes into Closing this issue after a cool off periode. |
Closing this ticket based on the comment above. Feel free to reopen Best regards, |
It would be nice to have ability to fetch backup logs using say
journalctl -u backintime-john -e -f
, run backup withsystemctl start backintime-john-profilename
, enable time-based backup usingsystemctl enable backintime-john-profilename.timer
So probably creating systemd units at user or system scope for running backup jobs and systemd.timer for running it repeatedly may be useful.
Can you please also recommend how to modify backintime gnome GUI sources to play with such a functionality by myself?
The text was updated successfully, but these errors were encountered: