Setting OnUnitActiveSec=3h in a systemd timer ensures your backup service triggers automatically every three hours. This configuration provides frequent data protection without the overhead of continuous monitoring. It is ideal for systems where data changes rapidly but does not require real-time replication, balancing resource usage with recovery point objectives.
Understanding OnUnitActiveSec Behavior
TheOnUnitActiveSec directive in a systemd timer unit specifies the time interval after the previous activation of the associated service unit before it is activated again. Unlike OnCalendar, which schedules events based on absolute clock time (such as 3:00 AM daily), OnUnitActiveSec relies on relative timing from the last successful run. When you set this value to 3h, the system calculates the next execution time based on when the backup process actually completed or failed, rather than a fixed schedule.
This approach prevents backup jobs from overlapping if one takes longer than expected. If a backup runs for two hours and finishes, the timer will wait an additional hour before triggering the next instance. However, if the backup fails immediately, the timer may trigger again sooner depending on other settings like RandomizedDelaySec. Understanding this dynamic scheduling is crucial for maintaining consistent backup intervals without creating resource contention.
Configuring the Timer Unit
To implement a three-hour backup cycle, you must create or modify a timer unit file. These files are typically located in/etc/systemd/system/ or /usr/lib/systemd/system/. The structure requires linking the timer to a specific service unit that performs the actual backup work. Below is a standard configuration example for a backup timer named backup.timer linked to backup.service.
[Unit]
Description=Backup Timer Service
Requires=backup.service
[Timer]
OnUnitActiveSec=3h
Persistent=true
RandomizedDelaySec=5m
[Install]
WantedBy=timers.targetOnUnitActiveSec=3h sets the core interval. The Persistent=true directive is critical; it ensures that if the system was powered off during a scheduled window, the backup will run immediately upon bootup rather than waiting for the next full cycle. Adding RandomizedDelaySec=5m helps prevent thundering herd problems if multiple similar timers are active on the same host by slightly varying the start time.
After editing the file, you must reload the systemd daemon and enable the timer using the following commands:
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timersystemctl status backup.timer. This output will show the "Next Elapsed" time, confirming that the relative timer is correctly calculating the three-hour window from the last activity.
Optimizing Backup Performance
Frequent backups every three hours can place significant I/O load on your storage subsystem. To mitigate performance issues, consider implementing differential or incremental backup strategies rather than full copies each time. Tools likersync are highly efficient for this purpose because they only transfer blocks that have changed since the last synchronization.
For more details on how rsync handles idempotency and efficiency, you might find our guide on Is rsync idempotent? helpful. Additionally, ensuring you have sufficient disk space is vital; running out of space during a mid-cycle backup can corrupt data. Check our article on Determining If Enough Space is Available in Destination Drive for rsync Dry Run to learn how to validate capacity before execution.
If your backup includes large directories that rarely change, excluding them can drastically reduce runtime. Our tutorial on Shell Command to Tar Directory Excluding Certain Folders provides techniques for filtering out unnecessary data, which complements the frequency settings of your timer.
Monitoring and Troubleshooting
Even with automated timers, manual oversight is necessary to ensure reliability. Usejournalctl -u backup.service to review logs for errors such as permission denied, connection timeouts, or disk write failures. If the timer triggers but the service hangs, check system resources using top or iostat to identify bottlenecks.
It is also important to test the restoration process periodically. A backup that never fails is not necessarily a good backup if it cannot be restored. Refer to our comprehensive guide on Creating Backups and Snapshots in Linux for best practices on verification and snapshot management. Regular testing ensures that your three-hour interval strategy meets your business continuity requirements.
Frequently Asked Questions
What happens if the backup service crashes?
If the service fails, the timer still respects the OnUnitActiveSec interval from the moment the failure occurred. You should configure Restart=on-failure in the service unit to attempt immediate retries before the timer resets the clock. This prevents long gaps in protection due to transient errors.
Can I combine OnUnitActiveSec with OnCalendar?
Yes, you can specify multiple On... directives in a single timer unit. The timer will activate the service whenever any of the conditions are met. For example, you could trigger a full backup weekly via OnCalendar and incremental updates every three hours via OnUnitActiveSec.
How do I stop the timer from running while I am manually backing up?
You can temporarily disable the timer using systemctl stop backup.timer before starting your manual job. Once the manual backup completes, restart the timer with systemctl start backup.timer. Alternatively, use systemctl mask backup.timer to completely disable it until you explicitly enable it again.
Does RandomizedDelaySec affect the 3-hour interval?
No, RandomizedDelaySec adds a small random offset (up to the specified seconds) to the delay calculated by OnUnitActiveSec. It does not change the base three-hour period but helps distribute load across multiple systems by preventing simultaneous starts.
Is it safe to run backups every three hours on a busy server?
It depends on the backup method. Using efficient tools like rsync with hard links or snapshots minimizes I/O impact. However, frequent full filesystem copies may degrade performance. Monitor CPU and disk latency to ensure the interval aligns with your server's capacity.