Axcient x360Recover: protected systems, restore points, and boot verification

Axcient x360Recover is where your backup and disaster-recovery estate lives: the appliances on partner sites, the vaults they replicate into, and every protected system behind them. This connector reads that estate into Current so each partner's backup posture sits on their company record before anyone asks for it — how many systems are protected, when each one last backed up, which ones boot-verified, and how much storage they are using. Current reads Axcient and can never change anything in it.

1. 1
   1 · Sign in to x360Portal as an administrator who can see x360Recover

   Go to partner.axcient.com and sign in. Which administrator you use matters more than it looks: a key inherits the product permissions of whoever created it, so a key made by an admin without x360Recover rights signs in perfectly and then reads nothing at all.
2. 2
   2 · Open Settings ▸ API Keys

   Any administrator in your organization can create a key here, and every administrator can see and delete the keys other people made.
3. 3
   3 · Press Add API Key, fill in the details, and press Generate API Key

   Give it a name you will recognize later — something like "Current reporting" — so a colleague looking at this screen in a year knows what it feeds.
4. 4
   4 · Copy the key

   Copy it as soon as it appears and keep it somewhere safe. It is listed in the API key repository afterwards, so it is usually recoverable, but there is no reason to rely on that.

1. 1
   Open the Axcient card

   In Current's left sidebar open Integrations (it sits under Admin, so Tenant Admins have the link) and find Axcient under Backup & continuity.
2. 2
   Paste the API key and press Test connection

   There is one field: the key. Axcient runs a single global service with no regions to pick and no client id or secret pair to match, so there is nothing else to get wrong. Current sends the key as a header, reads back the organization record it belongs to, and shows you that organization's name so you can confirm it is the right Axcient tenant before anything is stored.
3. 3
   Check the name Current reports

   The success message names the Axcient organization the key resolved to. If that is not the organization you expected, the key belongs to a different Axcient tenant — Axcient gives no way to switch organizations with the same key, so you need a key created inside the right one.

On success the key is stored on Current's servers only; the browser never sees it again, and it is never written into any status, message or log.

Axcient syncs every 6 hours on a schedule, plus whenever you press Sync now on the card. Each run reads your partner list first — so the mapping panel fills on the very first sync — then walks your protected systems, then your appliances and vaults, and finishes by filling in per-partner storage a batch at a time. On a large estate the storage figures fill in across a few runs rather than all at once, which is deliberate: it keeps the sync well inside what the service will comfortably answer.

Every request Current makes to Axcient passes through a read-only guard that permits exactly six read addresses — your organization, your partner list, your protected systems, your appliances, your vaults, and per-partner storage — and nothing else. Two of Axcient's own endpoints are worth naming because they are the ones that would matter: one changes how long a vault may be unreachable before Axcient warns you, and one creates a new agent enrolment token. Both are absent from the guard's list, so neither can be reached, including by a bug in Current. Axcient's user accounts are never read either.

In Axcient each end-customer is a client. Current lists all of them and links each to a company by normalized name — lowercased, with punctuation and Inc/LLC/Ltd-style suffixes stripped — and only when exactly one company matches. Two companies that both fit stay unmapped for you to decide rather than being paired on a guess. Axcient carries no link back to your PSA, so name matching plus this panel is the whole story; each client's short code is shown beside its name to help you tell two similar ones apart.

1. 1
   Let the auto-matcher run first

   Every sync links each Axcient client to the one company whose normalized name matches. Most map themselves; only the ambiguous ones need a hand.
2. 2
   Open the mapping panel

   Integrations → Axcient → Manage → Customer mapping. It opens on the Unmapped tab, which lists every client the matcher could not place.
3. 3
   Map a client to its company

   On an unmapped row press Map, type a few letters of the company, and pick it. That client's protected systems and appliances attach to the company right away, rather than waiting for the next 6-hour sync.
4. 4
   Ignore internal or test clients

   For a client that should never map to a partner — your own systems, a lab, a demo — press Ignore. It moves to the Ignored tab and stops counting against the card's unmapped badge.
5. 5
   Fix a wrong match later

   The Mapped tab lists every linked client; Unmap corrects a bad auto-match, and the Ignored tab's Un-ignore brings a dismissed one back. A mapping you set by hand is never overwritten by a later auto-match, and neither is a manual unlink.

One definition drives the company card, the backups-failing alert and the dashboard tile, so they can never disagree with each other. A protected system counts as failing when Axcient's own health reads Troubled or Unprotected, or its most recent restore point is more than three days old, or its last boot verification failed and that failed run is itself more than three days old.

• ＋Warned is a caution rather than a miss, and does not count as failing on its own.
• ＋Parked does not count as failing either. Parked is Axcient's word for a partner you have deliberately suspended, and a paused backup is a decision, not a fault — Current treats it the same way it treats a paused backup from any other product.
• ＋A system with no boot verification is not counted as failed. AutoVerify is an optional feature, so its absence tells you nothing about whether the machine would boot.
• ＋A health word Current does not recognize counts as unknown rather than as either a pass or a failure. If Axcient adds a new one, Current says so instead of guessing.
• ＋A restore point is read as the most recent of the three Axcient tracks — local, vault and cloud — because which of them exists depends on how the system is protected. A Direct-to-Cloud machine has no local restore point, and an appliance-only machine has no cloud one.

• ＋The company record's backup section: protected systems and how many are failing, Axcient's health verdict and the reason behind it, the appliance / Direct-to-Cloud / cloud-archive split, the most recent restore point, boot-verification results, and storage.
• ＋The backups-failing alert on a company, which counts Axcient alongside any other backup product you have connected so a company raises one alert whichever tool saw the problem — and clears itself when the count returns to zero.
• ＋The backup chapter of a Strategic Business Review.
• ＋Dashboard backup metrics: protected systems and systems failing.
• ＋The Axcient card itself, for appliance and vault reachability — infrastructure of yours, kept off partner records on purpose.

Some backup-monitoring products watch Axcient directly. If you have one of those connected to Current as well, both connectors are describing the same machines from two different angles, so their counts are not meant to be added together. Current keeps them on separate cards with their source named on each rather than merging them, because there is no shared machine identifier between the two that would make a merge reliable rather than a guess.

Disconnect on the card stops the sync and forgets the key. Everything already synced stays where it is and simply stops updating, and reconnecting with a new key picks up from there — your partner mappings included.