Cohesity DataProtect cheat sheet

Cohesity is a hyperconverged, scale-out data platform: each node contributes compute, SSD/flash, and HDD capacity, and the cluster spans them into one distributed filesystem (SpanFS) with a single namespace.

Data is written as immutable chunks/slices with content fingerprints; logical references (views, snapshots) point to physical chunks, so identical blocks are stored once and snapshots consume little incremental space.

A View is the logical data container presented over NFS, SMB, or S3; a Protection Group/Policy Job is the scheduling unit; a Snapshot is the point-in-time copy; a Replica is a secondary copy on a remote cluster or archive target.

Cohesity SpanFS distributes metadata and data across nodes and re-protects data after node or disk failure by rebuilding replicas/erasure-coded stripes to other nodes; a cluster tolerates node loss only while spare capacity and rebuild bandwidth exist.

Primary access protocols: NFS v3/v4, SMB (CIFS) 2/3, S3-compatible object, and iSCSI for block; management is through the Cohesity Helios cloud console or the on-cluster GUI/CLI (iris_cli).

Helios is the SaaS management plane for multi-cluster visibility, policy and reporting; data path stays on-premises on the cluster, so backups continue if Helios connectivity is lost.

Cohesity DataProtect is the backup/recovery service on the platform; SmartFiles/SmartTiering move cold data to archive targets (cloud or on-prem) while keeping metadata for instant recall.

Cluster roles include witness nodes for stretched/ROBO topologies and physical or virtual (CE) editions; capacity and performance scale by adding nodes to the same cluster, not by adding separate silos.

A Protection Source is the registered workload endpoint (vSphere vCenter, physical Windows/Linux server with agent, NAS share, SQL/Oracle, Microsoft 365, AWS/Azure, Kubernetes); registration requires credentials with least privilege to enumerate and snapshot objects.

A Protection Policy defines the schedule (start time, recurrence, interval), retention (keep for N days/weeks/months/years, or last N snapshots), and replication/archival targets; a Protection Group binds sources to a policy.

Retention rules can be layered: e.g. hourly for 24 hours, daily for 30 days, weekly for 8 weeks, monthly for 12 months; each tier is a separate retention rule, and the longest rule governs the oldest retained snapshot.

Change Block Tracking (CBT/RCT) enables incremental-forever backups: after the first full, only changed blocks are read; a CBT reset forces a new full and should be expected after VM migration or disk changes.

Consistency options: application-consistent (VSS for Windows/SQL/Exchange, pre/post scripts for Linux/Oracle) quiesce the app; crash-consistent captures the VM state without app quiesce.

RPO is set by schedule frequency; RTO is set by recovery method (instant volume mount/recovery vs full restore). Policy design should map each source tier to its required RPO/RTO.

Exclusions and filters reduce scope: per-disk exclusion for VMs, file path/type exclusions, and tag-based dynamic source selection so new VMs matching a tag are auto-protected.

SLA-based policies express objectives (e.g. bronze/silver/gold) rather than raw schedules; the platform derives run frequency, retention, and copies to meet the stated SLA.

Run types: full (all data), incremental (changed blocks since last), and log backup (transaction logs for SQL/Oracle, enabling point-in-time recovery); synthetic fulls assemble a new full from prior incrementals without re-reading the source.

Snapshot-based backup of VMs uses the hypervisor snapshot, reads changed blocks, then removes the snapshot; snapshot removal failure leaves orphaned snapshots and must be remediated before the next run.

Recovery options: full VM restore, instant recovery (run the VM directly from backup store, then Storage vMotion to production), file-level restore from a VM or filesystem snapshot, and application-item recovery (SQL database, Exchange mailbox, AD object).

Instant volume mount presents a backup as a datastore/LUN to the ESXi host for fast RTO; the recovered workload runs on the Cohesity cluster until migrated, so cluster performance is part of the RTO.

Restore points are chosen by timestamp; for databases with log backups, point-in-time recovery replays logs to a chosen second, so log chain integrity is critical.

Clone/reuse operations let you spin up a copy for test/dev or DR drills without touching production; these clones consume cluster capacity while active.

Verify recoverability regularly: run test restores, check job success and SLA compliance, and confirm that replication to the DR cluster completed for the required RPO window.

Job states include success, warning (partial objects skipped), and failure; a warning still means some data is unprotected, so treat warnings as actionable.

Immutability: snapshots written to a Cohesity cluster with a retention lock/WORM policy cannot be deleted or modified until expiry, even by an administrator; this defeats ransomware that targets backup data via stolen credentials.

Data Lock / compliance mode enforces retention that cannot be shortened; governance mode allows privileged override. Choose compliance mode where regulatory retention is required.

Multi-factor authentication, RBAC with least-privilege roles, and separate admin accounts for backup infrastructure reduce the blast radius of credential theft; backup admins should not be domain admins.

Air-gap strategy: replicate to a remote cluster or cloud archive in a separate security domain, so a compromised primary cannot delete the secondary copy.

Encryption: data at rest is encrypted on the cluster, and in-flight replication/archive traffic is encrypted; key management (internal or external KMS) determines whether a stolen disk is readable.

Anomaly detection monitors backup metadata and behavior (e.g. sudden data reduction, unusual deletion or encryption patterns) to flag possible ransomware before the retention window is consumed.

Compliance reporting maps policies to requirements (retention duration, encryption, access logs); audit logs record who deleted or changed a snapshot, policy, or user.

Recovery from ransomware requires clean copies: identify the last known-good restore point before encryption began, restore to an isolated network, and validate before rejoining production.

Health monitoring covers node/disk status, capacity usage, rebuild progress, job SLA compliance, and replication lag; alerting can route to email or SNMP/syslog targets.

Capacity planning: usable capacity is reduced by replication factor or erasure coding overhead and by reserved rebuild space; keep headroom (commonly ~20-30%) so a node failure can rebuild.

Cluster operations include adding/removing nodes, upgrading software (rolling, health-checked), rotating certificates, changing DNS/NTP, and managing users/roles; NTP skew breaks Kerberos and replication.

Log collection: use the support bundle/log collection feature and iris_cli commands to gather node and service logs before opening a case; correlate timestamps across nodes.

Common failure causes: expired source credentials, unreachable vCenter/proxy, full datastore or cluster, snapshot consolidation failures, network/firewall blocking data ports, and DNS/NTP misconfiguration.

Replication troubleshooting checks target cluster reachability, free capacity on the target, matching software versions, and bandwidth throttling windows.

Use CLI (iris_cli) for tasks not exposed in the GUI: cluster status, service restart, stats, and node-level diagnostics; the GUI and CLI act on the same distributed state.

Monitoring integrations: Helios dashboards aggregate multiple clusters; SNMP traps and syslog forward alerts to existing NOC/SIEM tooling for centralized operations.

Map each scenario to the layer it tests: source registration (credentials/connectivity), policy (schedule/retention), job execution (CBT/snapshot), or recovery (RTO method).

When a question asks for the fastest recovery, prefer instant recovery/mount over full restore; when it asks for the smallest backup footprint, prefer incremental-forever with synthetic fulls.

When a question asks how to survive ransomware or admin deletion, the answer involves immutability/WORM, a separate security domain, and a clean restore point.

When a question describes a failed job, check the most common causes first: expired credentials, unreachable vCenter, full capacity, snapshot consolidation, and NTP/DNS.

Distinguish RPO (data loss tolerance, set by frequency) from RTO (downtime tolerance, set by recovery method) in every policy or DR question.

Distinguish replication (a second copy for DR, near-real-time) from archival (long-term, cheaper, slower recall) when choosing a target for retention.

Retention rule answers: the longest applicable rule determines the oldest retained snapshot; layered rules stack rather than override.

Least privilege and separation of duties are the default correct answers for access-control questions on backup infrastructure.

RPO = maximum acceptable data loss; set by backup frequency and log backup interval. RTO = maximum acceptable downtime; set by recovery method.

Replication factor N stores N copies of each chunk; usable capacity ≈ raw capacity / N (before erasure coding and reserve).

Incremental-forever: one full + perpetual incrementals + periodic synthetic fulls; reduces source read load and storage churn.

VSS provides application-consistent snapshots on Windows; pre/post scripts provide the equivalent on Linux/Oracle.

WORM/retention lock prevents deletion until expiry; compliance mode cannot be shortened, governance mode can by privileged override.

Job warning ≠ success: some objects were skipped and remain unprotected until the next successful run.

NTP skew and DNS failure are frequent root causes of authentication and replication errors; verify both before deeper troubleshooting.

Helios is the management plane; the data path is on-cluster, so backups continue during Helios outages.

Instant recovery runs the workload from the backup store; plan the migration to production storage to complete the RTO.

View = logical data container exported over NFS/SMB/S3; Snapshot = point-in-time copy; Protection Group = sources + policy binding; Policy = schedule + retention + targets.

Chunk/slice = the physical unit SpanFS writes; fingerprints deduplicate identical chunks so repeated data is stored once.

SLA policy = objective-driven policy (bronze/silver/gold) that derives frequency, retention, and copies automatically.

CBT/RCT = changed block tracking; a reset forces a new full backup and lengthens the next run.

SmartTiering/archive = movement of cold snapshots to cheaper media while metadata stays on-cluster for recall.

Witness node = lightweight node used in stretched or ROBO topologies to maintain quorum.

iris_cli = the on-cluster command-line interface for status, diagnostics, and operations not exposed in the GUI.

Log backup = transaction-log capture enabling point-in-time recovery for SQL/Oracle; a broken log chain limits PITR to the last good log.

Before a backup window: confirm source credentials valid, vCenter/proxy reachable, cluster capacity above threshold, and NTP/DNS correct.

After a window: review job success/warning/failure, SLA compliance, replication lag, and any orphaned hypervisor snapshots.

Weekly: run a test restore of a critical workload and confirm the restore point is clean and bootable.

Monthly: verify immutability/retention-lock settings, review RBAC assignments, and confirm audit logs are being retained.

Quarterly: DR drill using replicated copies on the remote cluster, measuring actual RTO against the target.

On alert: collect logs first, correlate timestamps across nodes, then check the most common causes (credentials, connectivity, capacity, snapshot consolidation).

Capacity: keep rebuild headroom so a single node loss can re-protect data without degrading production performance.

Upgrades: rolling with health checks; verify replication partner version compatibility before upgrading one side.

Need a single file → file-level restore from a VM or filesystem snapshot; fastest and least disruptive.

Need a whole VM fast → instant recovery, then migrate to production storage to finish the RTO.

Need a database to a specific second → point-in-time recovery using log backups; requires an intact log chain.

Need a copy for testing → clone/reuse from a snapshot; consumes capacity only while active.

Need to survive ransomware → restore from an immutable copy in a separate security domain, to an isolated network, and validate before rejoining production.

Need long-term retention cheaply → archive to cloud/on-prem target; recall is slower than on-cluster restore.

Need DR with minimal data loss → replicate to a remote cluster; RPO is set by replication frequency and lag.

Need to prove compliance → map policy retention/encryption to the requirement and produce audit-log evidence.

Job fails at source enumeration → credentials expired or insufficient privilege; re-register or update credentials.

Job fails at snapshot creation → vCenter unreachable, VM stun/timeout, or datastore full; check vCenter tasks and datastore free space.

Orphaned snapshots remain → snapshot removal failed; consolidate in vCenter before the next run to avoid chain growth.

Replication lag grows → target capacity full, bandwidth throttle window, or version mismatch; check target free space and throttle settings.

Authentication errors across services → NTP skew or DNS failure; correct time sync and name resolution first.

Restore is slow → full restore over network; consider instant recovery/mount to meet RTO.

Capacity alert → rebuild reserve consumed or retention too long; review retention rules and archive cold snapshots.

Unexplained data reduction → possible ransomware or mass deletion; check anomaly alerts and identify the last clean restore point.

Immutability/WORM locks snapshots until expiry; compliance mode cannot be shortened, governance mode can by privileged override.

RBAC with least privilege and separation of duties: backup admins should not be domain admins.

MFA on administrative access reduces the impact of credential theft.

Encryption at rest on-cluster and in flight for replication/archive; key management determines readability of stolen media.

Air-gap: replicate to a separate security domain so a compromised primary cannot delete the secondary.

Anomaly detection flags unusual deletion/encryption patterns before retention is consumed.

Audit logs record who deleted or changed snapshots, policies, and users; retain them for compliance evidence.

Restore validation: restore to an isolated network and confirm clean before rejoining production.

Scale-out: add nodes to the same cluster for capacity and performance; do not create separate silos.

Rebuild: after node/disk failure, data is re-protected to other nodes; requires spare capacity and bandwidth.

Rolling upgrades with health checks; verify replication partner version compatibility before upgrading one side.

Certificate rotation, DNS/NTP changes, and user/role management are routine cluster operations.

Helios aggregates multi-cluster dashboards; data path stays on-cluster so backups continue during Helios outages.

SNMP traps and syslog forward alerts to NOC/SIEM tooling for centralized operations.

iris_cli exposes status, service restart, stats, and node diagnostics not always in the GUI.

Support bundles collect node and service logs; gather before opening a case and correlate timestamps.

Map each source tier to required RPO/RTO before choosing schedule and recovery method.

Layered retention rules stack; the longest applicable rule governs the oldest retained snapshot.

SLA policies express objectives (bronze/silver/gold) and derive frequency, retention, and copies.

Application-consistent (VSS/scripts) for databases and Exchange; crash-consistent only where app quiesce is unnecessary.

Tag-based dynamic source selection auto-protects new VMs matching a tag.

Exclusions reduce scope: per-disk, file path/type, and tag filters.

Replication for DR (near-real-time second copy); archival for long-term cheaper retention with slower recall.

Warnings are actionable: skipped objects remain unprotected until the next successful run.

Full = all data; incremental = changed blocks since last; log backup = transaction logs enabling PITR.

Synthetic full assembles a new full from prior incrementals without re-reading the source.

CBT/RCT reset forces a new full; expect longer next run after VM migration or disk changes.

Instant recovery runs the workload from the backup store; migrate to production storage to complete RTO.

Instant volume mount presents a backup as a datastore/LUN for fast RTO.

File-level restore is fastest for single-file needs; application-item recovery handles SQL/Exchange/AD objects.

Clones for test/dev consume cluster capacity while active.

Verify recoverability with test restores and confirm replication completed within the RPO window.

SpanFS is the distributed filesystem spanning nodes into one namespace with a single management plane.

Chunks are immutable and fingerprinted; deduplication stores identical chunks once.

View = logical container over NFS/SMB/S3; Snapshot = point-in-time copy; Protection Group = sources + policy.

Replication factor N stores N copies; usable capacity ≈ raw / N before erasure coding and reserve.

Witness nodes support stretched/ROBO topologies for quorum.

Physical and virtual (CE) editions scale by adding nodes to the same cluster.

Helios is the SaaS management plane; data path remains on-premises.

SmartFiles/SmartTiering move cold data to archive while metadata stays for instant recall.

RPO vs RTO: data loss tolerance vs downtime tolerance; do not swap them.

Replication vs archival: second copy for DR vs long-term cheaper retention with slower recall.

Compliance mode vs governance mode: cannot be shortened vs privileged override allowed.

Warning vs failure: warning means some objects unprotected, still actionable.

CBT reset vs normal incremental: reset forces a new full.

Instant recovery vs full restore: fastest RTO vs network-bound full copy.

Helios outage vs data path outage: backups continue because data path is on-cluster.

Least privilege and separation of duties are default correct answers for access-control questions.

Health monitoring: node/disk status, capacity usage, rebuild progress, job SLA compliance, replication lag.

Alert routing: email, SNMP traps, syslog to NOC/SIEM.

Capacity headroom (commonly ~20-30%) so a node failure can rebuild without degrading production.

Replication lag is an RPO risk; check target capacity, throttle windows, and version match.

Anomaly detection flags unusual deletion/encryption patterns before retention is consumed.

Audit logs record who deleted or changed snapshots, policies, and users.

Test restores and DR drills measure actual RTO against target.

Collect logs before opening a case; correlate timestamps across nodes.

Register vCenter, physical servers (agent), NAS shares, SQL/Oracle, Microsoft 365, AWS/Azure, Kubernetes as protection sources.

Credentials need least privilege to enumerate and snapshot objects; expired credentials are a top failure cause.

Tag-based dynamic selection auto-protects new VMs matching a tag.

Per-disk and file path/type exclusions reduce scope and storage.

Application-consistent via VSS (Windows/SQL/Exchange) or pre/post scripts (Linux/Oracle).

Crash-consistent only where app quiesce is unnecessary.

Verify vCenter/proxy reachability and DNS/NTP before the backup window.

A CBT reset after VM migration or disk change forces a new full.

Layered retention rules stack; the longest applicable rule governs the oldest retained snapshot.

Retention can be expressed as keep for N days/weeks/months/years or last N snapshots.

WORM/retention lock prevents deletion or modification until expiry, even by an administrator.

Compliance mode cannot be shortened; governance mode allows privileged override.

Archive moves cold snapshots to cheaper media while metadata stays on-cluster for recall.

Replication to a separate security domain provides an air-gap against primary compromise.

Audit logs record retention and deletion changes for compliance evidence.

Map policy retention and encryption to the regulatory requirement and produce audit-log evidence.

Usable capacity ≈ raw / replication factor, minus erasure coding overhead and rebuild reserve.

Keep rebuild headroom (commonly ~20-30%) so a node failure can re-protect data.

Scale by adding nodes to the same cluster; do not create separate silos.

Deduplication via chunk fingerprints stores identical blocks once.

Snapshots consume little incremental space because they reference existing chunks.

Clones for test/dev consume cluster capacity while active.

Archive/SmartTiering frees on-cluster capacity for hot data.

Rebuild bandwidth competes with production I/O; plan windows accordingly.

Success = all objects protected as scheduled.

Warning = some objects skipped; they remain unprotected until the next successful run.

Failure = job did not complete; check credentials, connectivity, capacity, snapshot consolidation.

SLA compliance tracks whether the policy objective was met, not just job exit code.

Replication lag is a separate RPO risk from job success.

Orphaned hypervisor snapshots indicate snapshot removal failure; consolidate before next run.

Log chain integrity limits PITR to the last good log backup.

Treat warnings as actionable, not as success.

File-level restore: single file/folder; fastest, least disruptive.

Full VM restore: complete copy over network; slower, network-bound.

Instant recovery: run VM from backup store; fastest RTO, then migrate to production.

Instant volume mount: present backup as datastore/LUN to ESXi for fast RTO.

Application-item recovery: SQL database, Exchange mailbox, AD object.

Point-in-time recovery: replay logs to a chosen second; requires intact log chain.

Clone/reuse: copy for test/dev or DR drill; consumes capacity while active.

DR from replica: restore on remote cluster; RPO set by replication frequency and lag.

Retention duration: map policy retention rules to the regulatory requirement.

Encryption: at rest on-cluster and in flight for replication/archive.

Access control: RBAC least privilege and separation of duties.

Audit logging: record who deleted or changed snapshots, policies, and users.

Immutability: WORM/compliance mode for mandated retention.

Reporting: Helios dashboards aggregate multi-cluster compliance status.

DR evidence: DR drill results measuring actual RTO against target.

Restore validation: isolated-network restore and clean confirmation before rejoining production.

Expired source credentials or insufficient privilege at enumeration.

Unreachable vCenter/proxy or blocked data ports by firewall.

Full datastore or full cluster capacity.

Snapshot consolidation failures leaving orphaned snapshots.

NTP skew breaking Kerberos and replication.

DNS failure breaking name resolution across services.

Replication partner version mismatch after one-sided upgrade.

Bandwidth throttle window causing replication lag.

Helios is the SaaS management plane for multi-cluster visibility, policy, and reporting.

Data path stays on-premises on the cluster; backups continue during Helios outages.

Helios dashboards aggregate compliance and SLA status across clusters.

On-cluster GUI and iris_cli act on the same distributed state.

SNMP traps and syslog forward alerts to NOC/SIEM tooling.

Support bundles collect node and service logs before opening a case.

Rolling upgrades with health checks; verify replication partner compatibility first.

Certificate rotation, DNS/NTP changes, and user/role management are routine operations.

Primary target: on-cluster storage for fast restore.

Replication target: remote cluster in a separate security domain for DR and air-gap.

Archive target: cloud or on-prem cheaper media for long-term retention with slower recall.

Cloud archive recall is slower than on-cluster restore; plan RTO accordingly.

Replication frequency and lag set the DR RPO.

Retention rules apply per target; the longest rule governs the oldest snapshot.

Bandwidth throttling windows protect production WAN during replication.

Verify target free capacity before the backup window.

MFA on administrative access reduces the impact of credential theft.

RBAC least privilege and separation of duties: backup admins should not be domain admins.

Encryption at rest and in flight; key management determines readability of stolen media.

Immutability/WORM locks snapshots until expiry.

Air-gap replication to a separate security domain defeats primary compromise.

Anomaly detection flags unusual deletion/encryption patterns.

Audit logs record snapshot, policy, and user changes.

Restore to an isolated network and validate clean before rejoining production.

Identify the last known-good restore point before encryption began.

Check anomaly alerts and audit logs for mass deletion or encryption patterns.

Restore from an immutable copy in a separate security domain.

Restore to an isolated network and validate before rejoining production.

Do not trust the primary cluster if credentials were stolen; verify secondary copies.

Confirm retention locks prevented deletion of clean snapshots.

Rotate credentials and review RBAC after the incident.

Document RTO achieved and update the DR plan.

Each node contributes compute, flash, and HDD capacity to the cluster.

SpanFS spans nodes into one namespace with a single management plane.

Data is re-protected after node/disk failure by rebuilding to other nodes.

Rebuild requires spare capacity and bandwidth.

Replication factor N stores N copies of each chunk.

Erasure coding reduces overhead versus full replication.

Scale by adding nodes to the same cluster.

Witness nodes support stretched/ROBO topologies for quorum.

RPO = maximum acceptable data loss; set by backup frequency and log backup interval.

RTO = maximum acceptable downtime; set by recovery method.

Instant recovery minimizes RTO but the workload runs on the cluster until migrated.

Full restore is network-bound and slower than instant recovery.

Replication frequency and lag set the DR RPO.

Log backup interval sets the PITR granularity for databases.

SLA policies express objectives and derive frequency, retention, and copies.

DR drills measure actual RTO against the target.

Audit logs record who deleted or changed snapshots, policies, and users.

Retain audit logs for compliance evidence.

Map policy retention and encryption to the regulatory requirement.

Immutability/compliance mode provides evidence of mandated retention.

Helios dashboards aggregate multi-cluster compliance status.

DR drill results provide evidence of RTO achievement.

Test restore results provide evidence of recoverability.

Support bundles and logs provide evidence for incident investigation.