Redacting data in support zip
When generating a support.zip file, you can choose to redact sensitive data. Data redaction replaces personal data, such as usernames, email or IP addresses, projects keys, and domain names, with stable pseudonymized values before the zip is created.
This helps you protect sensitive data when sharing the support.zip externally or uploading it to Atlassian Cloud.
To learn how to redact data in support.zip, see Create a support zip.
はじめる前に
Important information and limitations.
Data redaction is not exhaustive
Data redaction uses pattern-based detection. Data that doesn’t match known patterns (unusual email formats, custom entity names embedded in free text, binary files) may not be redacted.Binary files aren’t redacted
Only text-based files (logs, configs, properties) are processed. Binary attachments, heap dumps, and JFR recordings are included as-is.Mapping expiration
For Jira and Confluence, we use database-backed mappings to make sure that the same data in different support.zip files is replaced with the matching values. These mappings expire after 5 days. Zips created more than 5 days apart may have different values for the same original data.File size limit
If the estimated uncompressed size of selected files exceeds 2 GB, you won’t be able to create the support.zip. To fix this, you need to reduce the number of files included in the zip.
Every support.zip file with redacted data gets an redacted- prefix (for example, redacted-support-zip-2026-03-23.zip), so you can distinguish it.
What data is redacted and how
The following table describes items that are redacted.
カテゴリ | 例 | Treatment | Where it applies |
|---|---|---|---|
メール アドレス | Replaced with redacted-{8chars}@example.com | Log lines, configuration files across all bundles. | |
Usernames | jsmith, admin | Replaced with redacted-{pseudonym} | Log lines, configuration files. |
IP addresses (IPv4) | 10.1.2.3, 192.168.0.1 | Replaced with 240.x.y.z (Class E range to avoid conflicts while preserving IPv4 pattern) | Log lines, configuration files. |
IP addresses (IPv6) | 2001:db8::1 | Replaced with fd00::-prefixed address | Log lines, configuration files. |
Company domains | Domain portion replaced with redacted-{pseudonym} | HTTP/HTTPS URLs in logs and configuration. | |
Jira entities | Project keys (PROJ), issue keys (PROJ-123) | Replaced with redacted-{pseudonym} | Jira log and configuration bundles. |
Confluence entities | Space keys, space names, page titles, labels, group names, template names, version comments, principals | Replaced with redacted-{pseudonym} | Confluence log and configuration bundles. |
Bitbucket entities | Project keys (PROJ), repository slugs (my-repo) | Replaced with redacted-{pseudonym} | Bitbucket log and configuration bundles |
Bamboo entities | Project keys, plan segments, job segments | Replaced with redacted-{pseudonym} | Bamboo log and configuration bundles. |
Crowd entities | Directory names, application names, group names | Replaced with redacted-{pseudonym} | Crowd log and configuration bundles. |
Infrastructure - AWS | Resource names, resource IDs | Replaced with redacted-{pseudonym} | Logs containing cloud resource references. |
Infrastructure - Azure | Resource names, resource IDs | Replaced with redacted-{pseudonym} | Logs containing cloud resource references. |
Infrastructure - GCP | Resource names | Replaced with redacted-{pseudonym} | Logs containing cloud resource references. |
Infrastructure - On-prem | Hostnames, server names | Replaced with redacted-{pseudonym} | Log lines, configuration files. |
Infrastructure - File paths | /opt/atlassian/jira, C:\\Atlassian\\ | Path components replaced | Log lines, configuration files. |
What are bundles?
A bundle mentioned on this page is a logical group of files collected for a support.zip (for example, "application logs," "configuration files," "thread dumps").
How redaction rules are selected
Redaction rules are selected based on product, bundle type, and file path. Each combination maps to a set of applicable rule types via a rules engine. For example, Jira log bundles get the email, username, IP, domain, infrastructure, and Jira entity rules, while Confluence bundles get the Confluence entity rule instead of the Jira one. Product-specific entity rules only run on their own product's bundles.
How processing works
Each file in the support zip is processed line by line. For every line, the selected redaction rules run in sequence. Each rule scans for patterns it recognizes (e.g., email regex, IP address format, known project keys) and replaces matches with pseudonymized values.
Stable data redaction mappings
Stable mappings ensure that the same original value always produces the same replacement within a zip. For example, if user@company.com is replaced with redacted-a1b2c3d4@example.com in one log file, it gets the same replacement in every other file in the zip. This preserves the ability to correlate events across files.
The redacted- prefix on replacement values makes redacted content distinguishable from original data.
Data redaction mappings
Data redaction mappings ensure that the same data is replaced with matching values. Here are the details of how this works for different products.
| 製品 | DB-backed mapping persistence | 詳細 |
|---|---|---|
| Jira | はい | Full persistence via Active Objects. |
| Confluence | はい | Full persistence via Active Objects. |
| Bamboo | いいえ | Mappings exist only in memory while the zip is created. |
| Bitbucket | いいえ | Mappings exist only in memory while the zip is created. |
| Crowd | いいえ | Mappings exist only in memory while the zip is created. |
| Fisheye/Crucible | いいえ | Mappings exist only in memory while the zip is created. |
How persistence works for Jira and Confluence
Mappings expire after 5 days. After this time, the same original value may get a different replacement. We can store a max of 100,000 mappings. When this limit is reached, the oldest 10% are evicted.
Products without mapping persistence
Data redaction still works for these products. Mappings are consistent within a single support.zip file, but not across different files.
File size check and limit
Before creating a support.zip with redacted data, the system estimates the total uncompressed size of all selected files. This estimate is compared against a configurable limit.
| Aspect | 詳細 |
|---|---|
| What is estimated | Uncompressed size of all files in selected bundles. |
| What is compared to the limit | The uncompressed total. |
| Default limit | 2 GB |
| System property to override | com.atlassian.troubleshooting.size.limit.bytes |
| When the checks runs | Before the zip creation begins. |
| What happens if exceeded | The zip creation is blocked, you’ll see a message with a warning. |
Sequential processing across Data Center nodes
When data redaction is enabled in a clustered Data Center environment, zip creation processes one node at a time (sequentially) rather than in parallel.
That’s because data redaction mappings must be consistent across all nodes. If a node maps user@company.com → redacted-a1b2c3d4@example.com, another node must use the same mapping to keep the values consistent. Sequential processing allows each node to load the latest mappings before processing its own files.