Your Jira has a backup. Your Confluence has a backup. Your Assets schema, the thing your onboarding, ITSM and audits quietly depend on, may be the one nobody asked about. This page breaks down every way to back up Atlassian Cloud, what each tool does and does not do, when you can rely on them, when you can rely on us, and the eight questions that separate a safe choice from a hopeful one.

The short answer: when it comes to Assets, Twinit is the go-to

General backup tools treat Assets as one more thing on a long list. Twinit built Insight Assets Backup & Migration for Assets and nothing else, which is why it is the one to reach for when Assets is what your processes run on.

• Backup and migration on one engine. Cloud to Cloud and Data Center to Cloud. Among the tools compared on this page, it is the only one whose public page describes a Data Center to Cloud path.
• Your object keys survive. The keys your AQL queries, automations and integrations point at stay the same, so nothing silently breaks.
• The whole Assets picture. Schemas, objects, relationships, attachments, asset custom fields and references inside work items.
• Granular restore and a backup vault. Recover, migrate or merge assets, and reach your backups even if Cloud is down.
• Trusted by Assets admins. Rated 4.9 out of 5 on the Atlassian Marketplace and you can try it free.

Need Jira and Confluence backed up as well? Pair it with a general tool. For the Assets layer, this is the specialist. The rest of this page shows the other options fairly, so you can check us against them.

What "backup" means in Atlassian Cloud

Atlassian runs the platform and keeps infrastructure-level backups for disaster recovery. Your data is your responsibility under the shared responsibility model: deleted objects, bad bulk edits, a rogue automation or a failed migration are yours to recover from.

Atlassian's backup and restore documentation lists Assets as included in backups. The catch is on restore: it works at site and unit level, on Premium with units Assets is left out of restores by default, and on Enterprise it is restored into an empty, separate unit. The page does not describe restoring a single object.

What can you actually lose?

• Jira work items, fields and workflows
• Confluence pages, spaces and permissions
• Assets: object types, attributes, references and the object keys that link everything together
• Attachments
• Configuration: automation rules, permission schemes, apps

Who does what: the honest breakdown

Everything below comes from each vendor's own public pages, checked on 4 November 2026. Where a page does not mention something, we say so instead of guessing. Features and plans change, so confirm the details with the vendor before you buy.

Atlassian's native tools (backup and restore, JCMA, CSV import)

What it does. Backs up your site, Assets included, and restores it at site or unit level. For Data Center to Cloud, Atlassian's Assets migration guide describes a mostly manual path: export each object type to CSV, recreate schemas and references in Cloud, then import.

What it does not. That same guide says object keys are not imported, so imported objects get new keys, and that attachments, object history, Assets custom fields and automation rules do not come across automatically. Restoring one object is not described. Community threads also report that Legacy and Reference Assets field types are not supported by JCMA.

Rely on it when your schema is small, you are happy to rebuild references and rewire automation by hand, and you want a free, official safety net for the whole site. Rely on Twinit instead when you need to restore or move part of an Assets schema, or the keys your automations and queries point at must survive.

Revyz (Assets Data Manager and Backup)

What it does. Revyz runs daily automated backups of Assets configuration (schemas, object types, statuses) and objects. It offers granular restore of one object or a whole schema, point-in-time recovery, and site-to-site copy between Jira Cloud sites, such as sandbox to production, with an audit log. Its Marketplace listing shows Cloud Fortified status and SOC 2 Type II compliance.

What its public pages do not say. They do not mention object keys or attachments, and they do not describe Data Center to Cloud migration. Ask how keys are handled on restore and copy.

Rely on it when you want an Assets-focused tool with strong compliance credentials and regular sandbox-to-production copies between Cloud sites, and you have confirmed how it treats object keys.

Rewind (Backups for Jira)

What it does. Rewind says it backs up 75 Jira resource types across Jira, Jira Service Management and Assets, with daily automated backups, item-level restore, version comparison and schema-aware recovery that rebuilds relationships between Assets objects. Restoring into another Jira instance is on its Advanced and Enterprise plans, and default retention is 365 days.

What its public page does not say. It does not mention object keys or Data Center to Cloud migration. Cross-instance restore is described for staging, testing and disaster recovery, not as a migration path.

Rely on it when you want one tool for Jira, JSM and Assets backup with long retention, and Assets is one part of a wider backup requirement.

GitProtect

What it does. According to its product announcement, Assets protection is off by default and is switched on per backup plan. It then covers schemas, roles, icons, reference types, statuses, object types, attributes and objects, with granular restore of selected schemas, object types or objects. It says it can restore Assets with their original object IDs. No extra license is needed for Assets if you already protect Jira with it.

What its public page does not say. It does not mention object keys (an object ID and a human-readable key such as HW-1042 are not the same thing), cross-site restore or migration. Ask exactly what is preserved.

Rely on it when you already use GitProtect for Jira and want Assets under the same plans and policies.

Twinit (Insight Assets Backup & Migration): the Assets specialist

What it does. Backs up Assets from Jira Cloud, other Cloud sites or Data Center: schemas, objects, relationships, attachments, asset custom fields and references inside work items. Backups run manually or on a CRON schedule, data can be stored in the US, EU or your own database, BYOK encryption is available, and an Assets Backup Vault keeps backups reachable if Cloud is down. Restores are granular and can recover, migrate or merge assets. Migration runs Cloud to Cloud and Data Center to Cloud, and preserves your original object keys so references stay valid.

What it does not do. It is an Assets tool. It does not back up Jira work items, Confluence pages or configuration, so pair it with a general backup tool if you need those.

Rely on it when your processes run on Assets, you are migrating to Cloud or between Cloud sites, or object keys are baked into AQL queries, automations, integrations and issue fields.

Which one should you rely on? A quick guide

• Small schema, rebuilding by hand is fine: Atlassian's native tools.
• Jira, JSM and Assets backed up together, long retention: Rewind.
• Already on GitProtect: switch on Assets there.
• Assets-focused backup, compliance emphasis, sandbox copies: Revyz.
• Migrating Assets to Cloud, or object keys must survive: Twinit.
• You need both breadth and depth: a general tool for Jira and Confluence, plus Twinit for Assets.

Eight questions to ask any backup vendor

1. Does it cover Assets objects, or only Jira and Confluence?
2. On restore, do object keys stay the same?
3. Can I restore one object type, not the whole site?
4. Can I restore to a different site, for a migration or a sandbox?
5. Are attachments included, and how are they stored?
6. How often does it run, and can I see failed runs?
7. Where is the data stored, and who can access it?
8. What happens when I leave: can I take my data with me?

The Assets special case: why object keys matter

An object key such as HW-1042 is what AQL queries, automation rules, issue fields and API calls point at. If a restore or migration gives the same asset a new key, nothing errors out. References simply stop matching. That is why a backup that "worked" can still break a live process.

This is not hypothetical. Atlassian's own Data Center to Cloud Assets guide states that object keys are not imported and that imported objects receive new keys, so issue imports that reference the old keys do not update Assets fields.

Backup and migration are the same problem

A migration is a one-way restore to a new place. A tool that preserves keys on restore can preserve them on migration, Cloud to Cloud or Data Center to Cloud. One engine, two jobs.

Where Twinit is not the right fit

If you want one platform to back up all of Jira and Confluence, choose a general backup tool. If your Assets schema is small and you are happy to rebuild keys, references and automation by hand, Atlassian's native tools may be all you need. We are built for the case in between: Assets that your processes depend on.

For Assets, make Twinit your go-to: back up before you need to. Try Insight Assets Backup & Migration on the Atlassian Marketplace.Atlassian Marketplace.