bit-team
Integrate backintime with systemd for scheduling, snapshot control and logs
It would be nice to have ability to fetch backup logs using say journalctl -u backintime-john -e -f , run backup with systemctl start backintime-john-profilename, enable time-based backup using systemctl 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?
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 common/config.py defined in dict SCHEDULE_MODES and have their setup in method Config.cronLine. GUI changes would need to be done in qt/settingsdialog.py lines 303-385
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.
Systemd user process is started with user's first session creation and dies as last session dies, so following tasks will run when you are logged in. To spawn systemd --user at boot user shoud call loginctl enable-linger to be backed up when not logged in.
Two files were created manually at ~/.config/systemd/user. backintime-job-1.service:
[Unit]
Description=Run backintime job 1
[Service]
ExecStart=/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup
Type=oneshot
and backintime-job-1.timer:
[Unit]
Description=backup of home dir and some configurations
[Timer]
OnCalendar=hourly
Persistent=true
[Install]
WantedBy=default.target
After placing such files I have executed systemctl --user daemon-reload and systemctl --user enable backintime-job-1.timer to make systemd --user seeing them and considering timer activated.
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:
[Unit]
Description=Backup using Back In Time user profile id %I (service unit)
Documentation=man:backintime(1)
[Service]
Type=simple
ExecStart=/usr/bin/backintime --profile-id %I backup
[Install]
DefaultInstance=1
[email protected]
[Unit]
Description=Backup using Back In Time user profile id %I (timer unit)
Documentation=man:backintime(1)
[Timer]
OnCalendar=*:00/15
[Install]
DefaultInstance=1
WantedBy=timers.target
Except for the Descriptions, the system units are the same. All unit files are installed under the appropriate subdirectories in /usr/lib/systemd/.
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. systemctl enable [email protected] [email protected] .. [email protected]). The profile ID seemed like the easiest string to use for my use case.
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. systemctl start [email protected]) and will make a single unscheduled backup if BIT deems this appropriate.
Update 2017-02-19: I saw a social media post recently which pointed out that timer units should be WantedBy=timers.target, and indeed this is recommended in systemd.special(7). I updated my local units on that basis, and felt I should update this comment (since the report is open).
~~Update 2017-03-20: Updated with workaround for v1.1.14 per #720. This option comes from systemd.exec(5).~~ Fixed; removed.
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 CPUSchedulingPolicy=, CPUSchedulingPriority=, IOSchedulingClass=, IOSchedulingPriority= and Nice=.
Thank you both @zimy and @aexoxea! I'll have a look soon on how I can implement this.
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:
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.
If I understand correctly, you can just set the schedule to Disabled in the GUI and use your timer to call the backintime command to take snapshots.
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 backintime command.
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 https://github.com/bit-team/backintime/labels/Discussion Label.
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).
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. @xalmat could you perhaps give me a little bit more details on which additional steps are needed? Perhaps there is something we can do about it on the packaging side of backintime.
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.