Covered in this article:

• Overview
• What's backed up
• Connecting ScriptRunner
• Restoring
• Limitations
• Related articles

Overview

ScriptRunner for Jira, by Adaptavist, lets admins extend Jira with Scheduled Jobs, Script Listeners, Behaviours, Scripted Fields, and more. ScriptRunner stores this logic itself rather than in Jira, so a standard Jira backup doesn't capture it. If a script is deleted or changed, Jira has no record of what it looked like before, and ScriptRunner doesn't keep a version history of its own.

You can connect ScriptRunner to Rewind as an add-on to the Jira instance it's installed on. Rewind backs up ScriptRunner daily, alongside that Jira instance, so your Jira data and your ScriptRunner configuration stay on the same point in time. Every item is versioned, and for scripts you can compare any two versions to see exactly what changed.

What's backed up

Rewind backs up these ScriptRunner item types:

• Scheduled Jobs, including the schedule and the script that runs
• Script Listeners, including the events they respond to
• Scripts, the script code stored in Script Manager
• Script Folders, the folders your scripts are organized in within Script Manager
• Script Fragments, the UI extensions ScriptRunner adds to Jira
• Behaviours, including the projects and issue types they're scoped to
• Scripted Fields
• Script Variables
• Escalation Service rules
• Settings, captured for reference only (see Limitations)

You can filter your ScriptRunner backup by any of these types.

Workflow scripts

ScriptRunner post functions, conditions, and validators attached to workflow transitions aren't stored inside ScriptRunner. ScriptRunner registers them as rules on the Jira workflow itself, so your regular Jira backup captures those rules on any plan, with no setup.

Whether the script comes back with the rule depends on how it was attached:

• Written inline when the rule was created: the script is stored with the Jira workflow and comes back with it.
• Loaded from Script Manager: the workflow stores a reference to the script, and the script itself is protected by your ScriptRunner backup.

If you're looking for a workflow script, look in your Jira backup rather than your ScriptRunner backup.

Connecting ScriptRunner

Before you begin

Before starting, confirm the following:

• ScriptRunner for Jira is installed on your Jira instance
• The same Jira instance is connected to Rewind and on the Advanced plan
• You have the email address and an Atlassian API token for an Atlassian account with Jira administrator access. Rewind uses these to read your ScriptRunner data, and gets exactly the access that account already has.

Enable ScriptRunner backups

1. In the left sidebar, expand your Jira integration and click Explore add-on backups.
   
2. On the Add-ons for Jira page, select your Jira instance from the dropdown.

3. On the ScriptRunner card, click Enable.

   • If Enable stays unavailable after you select a Jira instance, that instance may not be on the Advanced plan. This is the Rewind plan for that Jira instance, not your Jira or ScriptRunner subscription.

   

4. Enter your Atlassian account email and API token, then click Connect ScriptRunner.
   
5. Select a storage option, then click Continue.
   
6. Review the data region, then click Submit. The region is set to match your Jira instance.
   

Nothing is backed up until you complete these steps. Your first ScriptRunner backup runs with the Jira instance's next scheduled backup.

Restoring

ScriptRunner restores are automated. There's no file to export and nothing to re-import, and script code is restored along with the item it belongs to. You can restore a single item, or rebuild your whole ScriptRunner configuration.

Restoring a single item

Open the ScriptRunner section of your backup, find the item, and restore it. Nine of the ten item types can be restored individually: Scheduled Jobs, Script Listeners, Scripts, Script Folders, Script Fragments, Behaviours, Scripted Fields, Script Variables, and Escalation Service rules. Settings can't be restored.

Comparing and restoring script versions

For scripts, you can open the version history, compare any two versions, and restore the one you want. You can also copy a script's code directly from the backup.

Restoring your whole configuration

An account-level restore rebuilds your ScriptRunner configuration in dependency order. Scripts are restored before the jobs, listeners, and fields that use them, so no item is left pointing at a script that doesn't exist yet.

If a restore fails

In most cases, a failed item doesn't stop the rest of the restore. The remaining items continue, and Rewind shows you which items succeeded and which failed. Details of each failure are in the error report you can download from the restore.

A small number of failures stop the whole restore. When that happens, the remaining items aren't attempted and don't appear in the totals. If your restore stopped partway through and items you expected are missing rather than listed as failed, contact support with the error report instead of retrying. The same item will usually stop the restore again.

Limitations

• ScriptRunner for Jira only
  ScriptRunner for Confluence and ScriptRunner for Bitbucket aren't currently supported.
• Settings are backed up but not restored
  You can see what your ScriptRunner settings looked like at any point, which is useful for checking what changed, but Rewind can't write them back.
• Execution history and logs aren't backed up
  Rewind captures your configuration and logic, not the record of individual runs.
• Restores are to the same Jira instance
  ScriptRunner data isn't included when you restore to a different Jira instance.
• Restoring an item whose script has been deleted
  If you restore a scheduled job, scripted field, or escalation service whose script has been deleted, Rewind stops that item and the error report tells you which script to restore first. Restore the script, then restore the item. Script listeners are the exception: a listener whose script has been deleted restores and reports success, but it won't run until the script is restored too. If you're restoring a listener on its own, check that its script still exists in Script Manager. An account-level restore avoids both cases because it restores scripts first.
• Restoring a deleted scripted field creates a new custom field
  The scripted field comes back, but Jira assigns it a new custom field. Boards, filters, dashboards, and saved JQL that used the previous field will need to be updated to use the new one. This doesn't apply when you restore an earlier version of a scripted field that still exists.
• Behaviours depend on the projects and issue types they're scoped to
  If a project or issue type has been deleted since the backup, the restore reports an error for that behaviour, but the behaviour is still created, scoped to nothing. If you're restoring after significant changes to your Jira projects, check your behaviours afterward.
• Restoring adds items back rather than rolling everything back
  For Script Fragments, Script Variables, and Script Listeners, restoring an item returns it to your live configuration without removing anything created since the backup.
• Some failures don't include a reason
  A failed item may show as failed without an error message explaining why. If the cause isn't clear, contact support with the error report.

Related articles

• Backing up and restoring Xray for Jira — Explains how to back up and restore Xray, another add-on for Jira.
• What does Rewind Backup for Jira Cloud? — Lists everything Rewind backs up for Jira.
• Restoring JIRA Data — Explains how to restore data from a Jira backup.
• Item-Level Restores for JIRA — Explains how to restore individual items from a Jira backup.
• Jira Billing — Covers how your Jira instance's plan and subscription are billed.

Need help?

If you have questions or need assistance, contact help@rewind.com or submit a request.