Axcient Devices

Axcient Devices

Overview

A device is one protected server or workstation — either backed up through a local appliance or replicating directly to the cloud (D2C). Devices carry their own health status, usage figures across up to three storage tiers (local appliance, private vault, Axcient cloud), and the list of backup jobs running against them.

Anti-triggers

• The appliance itself (hardware/capacity) — use the appliances skill; a device is what's protected, an appliance is what's doing the protecting.
• A specific backup run's pass/fail history — device-level latest_*_rp fields are point-in-time snapshots, not history. Use the jobs skill's axcient_get_job_history for that.

Tools

axcient_list_devices is the only device tool with pagination (limit/offset, in pages of ~100). axcient_list_devices_by_client returns a client's full device set in one call — no pagination arguments.

Device Type & Product

Health Status

"current_health_status": { "status": "NORMAL", "reason": null, "timestamp": "2024-01-03T11:33:07.000Z" },
"previous_health_status": null

Status values follow the same tier Axcient uses in the portal UI (NORMAL/WARNED/similar — the OpenAPI schema does not enumerate the full set). reason is populated when the status is not NORMAL and is the fastest way to understand why a device is unhealthy without cross-referencing job history. previous_health_status lets you detect a status transition (e.g. just recovered vs. been healthy for weeks) from a single call.

Usage & Recovery Points

These three latest_*_rp timestamps are independent — a device can be current locally while its vault or cloud replication has silently stalled. Always check all three that apply to the device's configuration rather than treating "backed up" as a single boolean.

AutoVerify

axcient_get_device_autoverify

Returns the most recent automated screenshot-boot-test result: whether the last recovery point actually boots, with screenshot_url and screenshot_thumbnail_url for visual confirmation, plus is_healthy and timing fields. This is the strongest signal that a backup is actually recoverable, not just that a backup job reported success — a job can succeed while producing an image that fails to boot.

Restore Points

axcient_get_device_restore_points

Lists available recovery points for the device across its storage tiers. Use this before recommending a restore — the device's latest_*_rp fields tell you the newest point exists, not what the full available history looks like.

Common Workflows

Backup Health Check for One Device

1. axcient_get_device — pull current_health_status, all three latest_*_rp timestamps, and jobs (list of job IDs/names)
2. axcient_get_device_autoverify — confirm the latest recovery point actually boots, not just that it exists
3. For any latest_*_rp older than expected, axcient_get_job_history (see the jobs skill) on the relevant job to see whether it's been failing or simply hasn't run

Fleet-Wide Backup Audit

1. axcient_list_devices (paginate with limit/offset if the organization is large)
2. Filter/sort by current_health_status.status and latest_local_rp / latest_cloud_rp age
3. Flag devices where the newest recovery point is older than the client's expected RPO — device thresholds (thresholds.*_rp_threshold) define what "too old" means per-device, not a global constant

Verifying a Recovery Is Actually Possible

1. axcient_get_device_restore_points for the candidate device
2. axcient_get_device_autoverify — do not proceed on a device whose most recent AutoVerify failed or is stale, even if latest_local_rp looks current
3. Confirm target vault/appliance capacity before a real restore — see the vaults and appliances skills

Error Handling

Device Not Found

Cause: Invalid device_id, or a numeric-looking ID for a device the credential's organization doesn't own Solution: Verify against axcient_list_devices or axcient_list_devices_by_client.

AutoVerify Returns Empty/Null

Cause: AutoVerify has never run for this device, or it's a device type AutoVerify doesn't support (not every protected system is bootable-image verifiable) Solution: Don't treat an empty AutoVerify result as a failure signal — check whether the device type supports it before escalating.

Best Practices

• Prefer axcient_get_device_autoverify over latest_local_rp alone when the question is "can we actually recover this," not just "did a backup run."
• A device's jobs array on the full-detail response gives you job IDs directly — use those with the jobs skill's tools instead of re-listing.
• excluded_volumes on a device is worth checking before assuming full coverage — a device can look protected while explicitly skipping a volume.

Related Skills

• api-patterns - Authentication, tool catalog, error codes
• clients - Client-level health rollup and protected-system counts
• jobs - Backup job status and run history
• vaults - Where vault-tier replication data lives
• appliances - The hardware protecting appliance-based devices