#3638 PR merged: Support for Cohesity DataProtect with BACKUP=COH

Labels: enhancement, fixed / solved / done, external tool

sebastian-koehler opened issue at 2026-09-14 20:15:

  • Type: New Feature
  • Impact: Normal. Adds a new, opt-in backup method (BACKUP=COH). There is no effect on existing methods or users who do not set it.
  • Reference to related issue (URL): N/A
  • How was this pull request tested?
    Validated end-to-end against a live Cohesity 7.4.1 cluster, covering both a recovery host that keeps the original hostname/IP and one that comes up with different network settings through a Physical Server File & Folder recovery.
  • Description of the changes in this pull request:
    Adds a new BACKUP=COH method for bare-metal recovery of physical servers protected by Cohesity DataProtect. Since the Cohesity agent cannot pull backups on its own and only accepts connections from the cluster, the approach is:
    • rear mkrescue bundles the installed Cohesity agent, including binaries, configuration, runtime state, required libraries and commands, and the systemd unit, into the rescue image.
    • rear recover rebuilds the disk layout, then checks the recovery host's hostname/IP against the values stored in the agent configuration. If they have changed, the agent identity is reset automatically. Files are renamed with a _rear suffix rather than deleted so the agent can register as a new host. If the hostname/IP is unchanged, the same reset is offered as an optional step. Either way, the original server's registration is never touched.
    • The agent is started so the Cohesity cluster can reach it, and rear recover pauses while the actual restore is driven from the Cohesity Data Cloud console or REST API. A normal physical server recovery is used if the identity was kept, or a Physical Server File & Folder recovery if it was reset.

codacy-production commented at 2026-09-14 20:16:

Not up to standards ⛔

🔴 Issues 14 high · 9 medium >
> > **Alerts:** > ⚠ 23 issues (≤ 0 issues of at least minor severity) > > **Results:** > `23` new issues > > > > > > > > > > > > > > > > > > >
CategoryResults
BestPractice8 medium
ErrorProne1 medium
14 high
> > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3638/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.

gdha commented at 2026-09-15 13:55:

@sebastian-koehler Nice to have a new BACKUP scheme ;-)
Remark:
In Bash, the 'local' keyword is only valid within functions. Using 'local' outside functions results in errors, which can cause scripts to fail or behave unexpectedly.
Please fix this first - thanks.

jsmeix commented at 2026-09-16 07:08:

No!

local is valid in ReaR scripts and
local should be used in ReaR scripts, see
https://github.com/rear/rear/wiki/Coding-Style#variables
(excerpt)

All scripts in usr/share/rear/
are sourced from within the Source() function
so you can and should use local for local variables in scripts.

We had and still have plain wrong variable handling
in our scripts because local is not used.
We have an old case where a dev or device named
variable gets overwritten because the same name
is used without local in a nested place
but at the time when I noticed that issue
I failed to get that mess sorted out
because I was busy with something else.
Only by luck that overwriting does not cause harm
because the overwritten original value is not needed
but things will fail when someone changes the code
so that the original value will be needed.

What is wrong is that dumb Codacy Static Code Analysis bot
which has no global understanding of what it analyzes
so it produces all the time way too many false alarms
which do not help but only cause confusion and
may even lead to false "fixes" (like here).

Same for that bot's "missing shebang" warnings.
We could add shebangs to all our scripts
to silence this false alarm of that dumb bot.
But we cannot not use local in our scripts
because that would cause errors in our code.

I would prefer the Codacy Static Code Analysis bot
gets simply switched off - at least until someone
could somehow make that bot behave reasonably useful
in practice - i.e. with almost zero false alarms.

jsmeix commented at 2026-09-16 07:11:

The only correct Codacy Static Code Analysis bot warning is

Declare and assign separately to avoid masking return values.

also see
https://github.com/rear/rear/wiki/Coding-Style#variables
(excerpt)

Variables that are used only locally should be lowercased
and must be marked with local like:

local foo="default_value"
local bar baz
bar="$( COMMAND1 )"
baz="$( COMMAND2 )" || Error "COMMAND2 failed"

Avoid
local bar="$( COMMAND1 )"
because set -e will not exit
if COMMAND1 exits with a non-zero status.

Also
local baz="$( COMMAND2 )" || Error "COMMAND2 failed"
will not error out if COMMAND2 failed.

See https://github.com/koalaman/shellcheck/wiki/SC2155

jsmeix commented at 2026-09-16 07:15:

Off the top of my head I don't know
if the Codacy Static Code Analysis bot warnings

Use '[:lower:]' to support accents and foreign alphabets.
Use '[:upper:]' to support accents and foreign alphabets.

are valid for

echo "$current_hostname" | tr 'A-Z' 'a-z'
echo "$cfg_hostname" | tr 'A-Z' 'a-z'

because I don't know if a hostname may contain
"accents and foreign alphabets"?

I asked Google AI:
"which characters are allowed for a hostname?"
and it replied

Standard hostnames may contain only
ASCII letters (a–z), digits (0–9), and hyphens (-).

According to that those Codacy warnings are invaild here
which proves that the Codacy Static Code Analysis bot
does not even have a locally focussed "understanding"
of what it analyzes - i.e. here it does not understand
that it is about a hostname.

jsmeix commented at 2026-09-16 09:33:

@sebastian-koehler
could you provide some technical explanation
what a Cohesity DataProtect backup actually is and
how it works from a general technical point of view?

I fail to see this information on
https://www.cohesity.com/platform/dataprotect/

sebastian-koehler commented at 2026-09-17 14:29:

@sebastian-koehler could you provide some technical explanation what a Cohesity DataProtect backup actually is and how it works from a general technical point of view?

I fail to see this information on https://www.cohesity.com/platform/dataprotect/

Cohesity DataProtect with ReaR

Cohesity DataProtect provides policy-based backup and recovery for supported workloads. A protection policy defines the source, schedule, retention, and storage target. Backup data is transferred to a Cohesity cluster and stored as snapshots.

Backup processing

  • The client or workload is registered as a protection source.
  • A protection job runs according to its assigned policy.
  • Data is read directly from the workload or through a locally installed agent.
  • The backup stream is sent to the DataProtect cluster.
  • The cluster deduplicates and compresses the backup data.
  • Encryption protects data in transit and at rest.
  • Snapshots can be configured as immutable, preventing modification or deletion during the defined retention period and improving cyber resilience.
  • Recovery operations read the required snapshot and restore the selected files, volumes, or workload data.

ReaR integration

For the ReaR workflow, the lightweight Cohesity agent is installed locally on the Linux client and performs either a file system based or block based backup.
The agent can perform source-side deduplication to reduce network transfer. Backup data is stored on the DataProtect cluster in deduplicated, compressed, encrypted, and optionally immutable snapshots.

jsmeix commented at 2026-09-18 09:33:

@rear/contributors
please have a look here (as time permits).
Perhaps you spot issues that I overlooked?

jsmeix commented at 2026-09-28 09:45:

@sebastian-koehler
if you like you may add your technical explanation
what a Cohesity DataProtect backup is and how it works
in your
https://github.com/rear/rear/pull/3638#issuecomment-5716076134
to your
doc/user-guide/19-Cohesity-COH.md
documentation.

Such a generic description directly in ReaR
helps others who will at some later time
have to adapt and enhance the current
Cohesity DataProtect code in ReaR
but who do not use Cohesity DataProtect,
in particular us ReaR upstream maintainers
when we try to fix issues in third-party backup code
that had become somewhat bitrotted over longer time
(at least I had some not-so-fun with that in the past).

jsmeix commented at 2026-09-28 09:47:

@rear/contributors
unless there are objections
I would like to merge it on Wednesday (30. Sept.) afternoon.

jsmeix commented at 2026-09-30 13:06:

@sebastian-koehler
thank you for your valuable contribution to ReaR!

[Export of Github issue for rear/rear.]