ExaGrid Data Recovery
ExaGrid appliances are purpose-built backup storage targets that combine a fast, non-deduplicated landing zone with a deduplicated repository tier, scaling out across multiple EX-series appliances at a site. Because ExaGrid is normally the last line of defence for backup data, a fault here is often assessed alongside the backup software (Veeam, Commvault or Veritas) that manages retention and catalogue state on top of it.
Platform Lineage and Naming
ExaGrid built its product line around a two-tier design from early on: a landing zone that receives backup jobs at full speed without deduplication overhead, and a repository tier where data is deduplicated for long-term retention. The EX-series appliance range has grown in capacity and performance across generations while retaining this same tiering concept.
ExaGrid's scale-out model lets a site add further EX appliances as capacity or performance needs grow, with the appliances cooperating as a single logical system rather than being managed as isolated targets, which is a relevant factor when a fault or data-loss event affects more than one appliance at a site.
- ExaGrid EX-series appliances
- Landing zone (non-deduplicated ingest tier)
- Repository tier (deduplicated retention tier)
- Retention Time-Lock (delayed delete)
- Scale-out site configuration
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Appliances | ExaGrid EX-series appliances, various generations by capacity/performance tier |
Architecture and Data Layout
Backup jobs land first in the non-deduplicated landing zone, which allows the fastest possible backup and restore for the most recent jobs; ExaGrid's adaptive deduplication engine then processes data into the repository tier for space-efficient long-term retention, adjusting its approach based on data type and change rate.
Retention Time-Lock, ExaGrid's delayed-delete mechanism, is intended to protect the repository tier from ransomware or accidental deletion by holding deleted or aged-out data for a defined period before it is actually purged, which is often the first thing checked when data appears to be missing.
In scale-out configurations, multiple EX appliances at a site share the deduplication and retention workload as a single logical system, so understanding which appliance(s) held the affected data, and how they cooperate, is part of establishing the scope of any incident.
Protocols and formats: NFS, SMB/CIFS, Veeam Data Mover integration, Commvault integration, Veritas NetBackup / Backup Exec OST integration
- The landing zone and repository tier use different internal data organisation, reflecting their different roles (fast ingest versus deduplicated retention).
- Retention Time-Lock retains deleted data internally for a configured period, which is separate from, and in addition to, retention settings configured in the backup software itself.
Failure Scenarios
Logical failures
- Backup jobs or retention points deleted before or after the Time-Lock window
- Repository deduplication metadata corruption
- Failed appliance firmware upgrade
- Misconfigured retention policy in the connected backup software
- Scale-out site membership changes leaving orphaned repository segments
Hardware failures
- Multiple drive failures within an appliance exceeding internal RAID tolerance
- Appliance controller failure
- Network fabric faults isolating an appliance from the rest of a scale-out site
- Power-loss events affecting the landing zone during active ingest
What Not To Do Before an Evaluation
- Do not run rebuilds, reconstructions or re-initialisations against an array that has already lost more drives than its protection level allows.
- Do not recreate pools, aggregates, disk groups, storage pools or clusters — these operations write new metadata over the structures a recovery needs.
- Do not swap drives between slots, and do not reorder shelves. Record the original slot and shelf positions before removing anything.
- Do not run file-system repair tools against production volumes before the underlying storage layer has been evaluated.
- Do not restore a backup or replication set over the affected volumes until the recovery scope has been assessed.
- Do not eradicate deleted volumes or empty recycle/destroyed states on platforms that hold deleted data for a retention window.
Our Evaluation and Recovery Process
- Intake and platform identification — array model, generation, firmware, protection layout and the sequence of events that led to the failure.
- Read-only evaluation of the media and array structures, including assessment of drive health and the extent of any physical damage.
- Forensic imaging of all contributing media, with cleanroom work where drives require it. Originals are preserved unaltered.
- Reconstruction of the storage layer — pools, aggregates, parity groups, chunklets, extent groups or objects — from the images.
- Extraction of the layers above: file systems, virtual machines, databases, mailboxes and shares.
- Verification against a file list and customer-nominated critical data, followed by secure return on encrypted media.
Frequently Asked Questions
If backup jobs disappeared, is Retention Time-Lock likely to help?
If Time-Lock was enabled and the deletion happened within its configured window, the data may still be held internally pending purge — this is usually the first thing to check before assuming a deeper recovery is needed.
Does the backup software matter for an ExaGrid recovery?
Yes. Because ExaGrid appliances work closely with Veeam, Commvault or Veritas catalogues, understanding what the backup software believes about job and retention state is usually part of scoping the recovery.
If one appliance in a scale-out site fails, are the others affected?
It depends on how deduplication and retention data were distributed across the site's appliances; the evaluation needs to establish which appliance(s) actually held the affected segments.