Most teams think of Jira Service Management backup as protecting tickets. Requests, queues, SLAs, the stuff agents touch every day. That is the visible half. The half that quietly sinks recovery projects is your Assets data, the configuration management database (CMDB) that maps every server, laptop, license, and dependency in your environment. Lose your tickets and you lose history. Lose your Assets graph and you lose the map of how your entire operation is wired together. This post explains what JSM Assets and CMDB data actually is, why it is uniquely painful to rebuild, where the shared responsibility line sits, and how Rewind backs up JSM, including that Assets data.
What is JSM Assets and CMDB data, exactly?
Jira Service Management includes Assets (formerly Insight), a native configuration management database. It is where you model the real-world things your service desk supports and the relationships between them.
A CMDB is not a spreadsheet of objects. It is a graph. Each object, a laptop, a cloud instance, a software license, a business service, is a node. The connections between them, “this server runs this application,” “this app supports this business service,” “this license belongs to this employee,” are the edges. That web of relationships is what turns a pile of records into something useful. It powers impact analysis, change management, incident triage, and the automations your team leans on every day.
Here is what lives inside JSM Assets:
- Object schemas and types: the structure that defines what a “server” or “license” even means in your instance
- Objects and their attributes: the individual records and every field on them
- Reference relationships: the links between objects that make the CMDB a graph rather than a list
- Automation and rule dependencies: assignment logic, SLAs, and workflows that read from Assets to make decisions
The tickets are the surface. The CMDB is the wiring behind the wall.
Why losing your CMDB is so much worse than losing tickets
A deleted ticket is a bad day. A corrupted or deleted CMDB is a bad quarter. The difference comes down to how the data was created in the first place.
Tickets are generated as a byproduct of work. They accumulate on their own. Your Assets data is the opposite. Someone sat down and designed those object schemas. Someone imported the objects, cleaned them up, and connected them. Someone built the reference relationships by hand or through carefully tuned integrations. That is high-effort, high-value configuration work, and almost none of it regenerates on its own.
Now picture rebuilding it from nothing. You are not restoring records. You are reconstructing a map. You have to remember which application ran on which server, which license was tied to which person, which service depended on which upstream system. Every relationship you miss is a broken automation, a failed impact analysis, or an incident that gets routed to the wrong team.
This matters more than ever because recovery expectations are tight. 69% of organizations require Jira or other critical tool recovery within one to four hours (Rewind SaaS Resilience Report, Q4 2025). You cannot hand-rebuild a CMDB inside a four-hour window. It is not even close.
And the cost of the gap is real while you scramble. During an outage, downstream disruption runs to $9,000 per minute (Ponemon Institute). A degraded CMDB does not just slow your recovery. It degrades every service decision you make until the map is whole again.
The uncomfortable part: how CMDB data actually gets lost
People assume this kind of loss requires a catastrophe, but it usually does not. In my day-to-day working with teams, the causes are almost always mundane:
- A well-meaning cleanup. An admin bulk-deletes objects they think are stale and takes live dependencies with them.
- A bad import. A CSV re-import overwrites attributes or duplicates objects, and the relationships silently break.
- A misfiring automation. A rule updates or removes objects at scale based on a condition nobody tested at volume.
- A departing admin. The person who designed the schema leaves, and the next reorganization quietly undoes months of work.
- Ransomware or account compromise in your own environment, encrypting or corrupting data through legitimate credentials.
None of these are Atlassian failing. Every one of them happens inside your instance, driven by your users, your automations, your integrations, which brings us to the part most teams get wrong.
Shared responsibility: who takes care of your Assets data?
Under the Shared Responsibility Model, the split is clean once you see it. Atlassian is responsible for keeping the platform running, available, and secure at the infrastructure level. You are responsible for the data you put into it. That includes your tickets, your automations, and yes, your entire Assets CMDB.
49% of organizations blame confusion about the Shared Responsibility Model for their data loss (Rewind survey). The CMDB is where that confusion bites hardest, because it feels like part of the platform. It is not. It is your configuration, and recovering it is your responsibility.
Native tools do not close the gap. Atlassian’s export options are manual, partial, and built for migration rather than surgical recovery. There is no granular, point-in-time, per-object restore that puts one accidentally deleted server object back with its relationships intact. And backing up your JSM data inside Atlassian is like backing up your hard drive to your hard drive. There is no independent copy sitting outside the platform when you need one.
That last point is the heart of the 3-2-1 backup rule: three copies of your data, in two different locations, with at least one copy independent of the SaaS provider. A CMDB with no independent copy is a single point of failure for your entire service operation.
How Rewind backs up JSM, including Assets data
Rewind is the #1 most-downloaded Jira and Confluence backup app on the Atlassian Marketplace, and it protects Jira Service Management including your Assets and CMDB data. The goal is simple. When something breaks, you restore the map, not just the records.
Here is what that looks like in practice:
| Capability | What it means for your CMDB |
|---|---|
| Automated backups | Your Assets objects, schemas, and relationships are captured continuously, not on a manual export cadence |
| Surgical item-level restore | Put back a single object, a set of objects, or a schema without rolling back the entire instance |
| Metadata and relationship preservation | The reference links between objects come back intact, so the graph is restored, not flattened into a list |
| Version comparison before restore | See exactly what changed before you commit, so you restore the right state |
| Long retention | 365-day default, configurable up to 99 years for regulated environments |
| Security and residency controls | Bring Your Own Key, Bring Your Own Storage on AWS, RBAC, audit log, enforced 2FA, and configurable data residency including the UK |
One important caveat, and it is the whole ballgame with backup: Rewind has to be installed before a loss to restore from it. There is no retroactive backup. The time to protect your CMDB is while it is still whole.
Setup takes about three clicks, and a single app can protect up to 16 integrations or sites. For a team already running Jira, Confluence, and JSM, that is one install covering the whole Atlassian footprint.
What good CMDB protection looks like
If you want a quick gut check on where you stand, run through this:
- Do you have an independent copy of your Assets data outside Atlassian right now?
- Can you restore a single deleted object with its relationships intact, without rolling back your whole instance?
- Would your restore preserve the graph, or just dump the objects back as a flat list?
- Can you recover within your target window, which for most teams is one to four hours?
- Is your backup installed and running today, not something you plan to set up later?
If any answer is “no,” your CMDB is exposed. The map that runs your service desk is one bulk edit away from a manual rebuild.
Frequently asked questions
Does JSM back up my Assets and CMDB data automatically?
Atlassian protects the platform’s infrastructure and availability, but recovering your own Assets data is your responsibility under the Shared Responsibility Model. Native export tools are manual and do not offer granular, point-in-time restore of individual objects and their relationships.
What is the difference between JSM tickets and Assets data?
Tickets are generated as a byproduct of daily work and accumulate on their own. Assets and CMDB data is deliberately designed configuration: schemas, objects, and the relationships that connect them. That relationship graph is high-effort to build and does not regenerate if lost.
Can Rewind restore individual Assets objects?
Yes. Rewind offers surgical, item-level restore with metadata and relationship preservation, so you can put back a single object or schema without rolling back your entire instance. You can also compare versions before restoring.
Do I need a backup if Atlassian already runs the platform?
Yes. Atlassian keeps the platform available; it does not protect you from accidental deletion, bad imports, misfiring automations, or account compromise in your own environment. An independent copy is the point of the 3-2-1 backup rule.
How far back can Rewind recover my JSM data?
Retention defaults to 365 days and is configurable up to 99 years for regulated industries. Rewind must be installed before a loss occurs in order to restore from it.
Protect the map, not just the tickets
Your JSM tickets tell you what happened. Your CMDB tells you how everything connects. One of those rebuilds itself. The other takes months of careful work you cannot afford to redo inside a recovery window. If your Assets data does not have an independent, restorable copy today, that is the gap worth closing first.
Talk to a SaaS resilience expert at Rewind to see how JSM backup, including your Assets and CMDB data, fits your recovery targets.
Subscribe to Retro, Rewind’s monthly newsletter, for practical SaaS resilience insights delivered once a month.
Daniel Laframboise">
