#3663 PR open: BACKUP=COH: fix agent identity handling and systemd unit detection

Labels: enhancement

sebastian-koehler opened issue at 2026-11-04 18:25:

Pull Request Details:

  • Type: Enhancement

  • Impact: Low (only affects recently added BACKUP=COH)

  • Reference to related issue (URL): n/a

  • How was this pull request tested?

    • End-to-end backup and rear recover with BACKUP=COH on RHEL 7.9, 8.10 and 9.8.

  • Description of the changes in this pull request:

    Aligns the COH (Cohesity DataProtect) backend with the other BACKUP backends and fixes two issues.

    • Renamed COH scripts, rewrote their headers to match other backends, tidied the COH block in default.conf
    • Fixed cohesity-agent systemd unit detection. systemctl list-unit-files always exits 0 on systemd 219, so the unit file is now detected on disk and bundled from both systemd directories.
    • Fixed the agent identity check. It now compares the plain hostname with the hostname in agent.cfg instead of hostname -f, and the IP handling is gone.
    • Added finalize/COH/default/900_copy_coh_agent_identity.sh.
      • If the identity was reset in the rescue system and the restored hostname matches, the new identity is copied onto the recovered system, so no re-registration is needed after reboot.

codacy-production commented at 2026-11-04 18:26:

Not up to standards ⛔

🔴 Issues 7 high · 4 medium >
> > **Alerts:** > ⚠ 11 issues (≤ 0 issues of at least minor severity) > > **Results:** > `11` new issues > > > > > > > > > > > > > > > > > > >
CategoryResults
BestPractice3 medium
ErrorProne1 medium
7 high
> > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3663/issues) >

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

jsmeix commented at 2026-11-05 09:28:

In general:

I recommend to not 'Error' out during "rear recover"
after the backup was restored because very most of
the system recovery is done at that stage where
in particular restoring the backup takes most time
so it could be bad for the user when ReaR
"just throws all that away" because of a late issue
which might not be a fatal error in the user's
specific environment - in particular because
after "rear recover" finished the user can manually
fix things in the recreated target system that is
mounted at /mnt/local from within the still running
ReaR recovery system.

See the last part of the initial comment in
finalize/Linux-i386/660_install_grub2.sh

# This script does not error out because at this late state of "rear recover"
# (i.e. after the backup was restored) I <jsmeix@suse.de> consider it too hard
# to abort "rear recover" when it failed to install GRUB2 because in this case
# the user gets an explicit WARNING via finalize/default/890_finish_checks.sh
# so that after "rear recover" finished he can manually install the bootloader
# as appropriate for his particular system.

and see the explanatory WARNING message in
finalize/default/890_finish_checks.sh
which describes what the user could do.

The 'finalize' stage is an exceptional case
where we intenitonally show only "WARNING" messages
also in case of errors in contrast to our normal style
according to
https://schlomo.schapiro.org/2015/04/warning-is-waste-of-my-time.html

Cf.
"learn the rules so you know how to break them properly"
in
https://github.com/rear/rear/wiki/Coding-Style#why

[Export of Github issue for rear/rear.]