Back Up, Restore and Copy an Installation | Int4 Suite 4 Documentation

Overview

Three commands move the data of an Int4 Suite installation as one stream:

instance_export writes the installation's data, or the parts you choose, to a file or to another command.
instance_import reads such a stream and replaces the same parts of an installation with it.
instance_wipe empties parts of an installation and leaves them as a fresh installation has them.

With them you can back up an installation to a file and restore it later, copy an installation (for example a reference system onto a test or demo system), or reset parts of it. The data never has to be stored on the installation's own machines: a backup streams straight into a file wherever you run the command, and a copy streams from one installation into the other.

You choose what moves in scopes:

Scope	What it holds
`licence`	The uploaded licences.
`settings`	Global Parameters, including the uploaded SAP NetWeaver RFC SDK.
`users`	Users (email, name, active or not) and their dashboard and notification preferences.
`roles`	Project scopes, permission groups, roles and which groups a role grants.
`rest`	All test content: folders and tags, systems under test and system landscapes, automation objects, business objects, business dimensions, scripts, mapping objects, DB rulesets, processes, Messenger, API Explorer requests, crawler and trace scheduler set-ups, schedules, run templates, and test cases with their payloads.

Which roles a user holds moves when you select both users and roles. Test runs and their results move only when you add --with-history to rest. Job records, logs, notifications and the audit trail never move.

Credentials never leave an installation. Passwords and keys of systems under test, external channels, API Explorer authorizations and the AI provider are left empty in the stream, and users arrive without a password or a link to the identity provider. After an import, enter the credentials again, and let users sign in again.

Int4 Suite 3 moved a complete dataset — test cases, automation objects and DB validations — between SAP systems with transports. In Int4 Suite 4 these commands take that role on every way you run the product: on SAP BTP (Cloud Foundry or Kyma), on your own Kubernetes cluster, or as a local installation on Windows. They copy whole parts of an installation; to deliver selected objects into an installation that keeps its own content, use content packages instead.

Tasks

How to run the commands on your installation

The commands run in the installation's backend, through whatever access you have to it. In the examples below, <run> stands for the start of the command line that fits your installation:

Installation	`<run>`
Local installation on Windows	Not available as a ready command yet: the commands need the backend environment that the tray application sets up only for its own tasks. Contact Int4 support.
Kubernetes, including SAP BTP Kyma	`kubectl -n <namespace> exec -i deploy/worker-procrastinate -c worker-procrastinate -- /app/int4cloud-runtime manage`
SAP BTP Cloud Foundry	`cf ssh -T <prefix>-backend-web -c "/app/int4cloud-runtime manage …"` (the whole command goes inside the quotes)

Progress and the final report appear on screen; the stream itself goes only where you send it.

How to back up an installation to a file

Export everything into a file on the machine where you run the command:
Bash
```
<run> instance_export --all > backup-2026-10-30.int4.zst
```
Add --with-history to include test runs and their results. Use --scope (repeatable) instead of --all to back up only some parts, for example --scope rest for the test content.
Keep the file somewhere safe. It holds no credentials, but it does hold your business test data.

The export reads one consistent state of the installation, so you can run it while people keep working.

How to restore an installation from a file

Check the backup against the installation first. A dry run does the whole import, reports what it would do and changes nothing:
Bash
```
<run> instance_import --dry-run --wipe --admin-email you@example.com < backup-2026-10-30.int4.zst
```
The report also shows the name of the installation's database, which the real run asks you to confirm.
Restore:
Bash
```
<run> instance_import --wipe --confirm-database <database> --admin-email you@example.com --keep-active < backup-2026-10-30.int4.zst
```
--wipe replaces what the installation holds in the scopes of the backup. --admin-email names the account that is an administrator afterwards; it is required whenever users or roles are restored. --keep-active keeps schedules, crawlers, trace schedulers, Messenger instances and external channels running as they were when backed up — leave it out to have them arrive paused.
Enter the credentials again under Systems Under Test and Global Parameters, and ask users to sign in again.

How to copy an installation to another one

Send the export of one installation straight into the import of the other. Run the command on a machine that reaches both installations well: the stream passes through it.

Bash

<run on the source> instance_export --scope rest \
  | <run on the target> instance_import --wipe --confirm-database <target database>

This example copies the test content and keeps the target's users, roles, settings and licence. The authors of copied objects are matched to the target's users by email; authors the target does not know arrive as inactive users without roles. Copy everything with --all and add --admin-email.

The target installation may run a slightly different version than the source, for example a newer release or a development build. The import then matches the data to the target and lists every difference in its report: values the target has no place for are left out, new fields get their default value. It stops, and changes nothing, only where a value would change on its way in, or a field the target requires has no value.

How to empty parts of an installation

Bash

<run> instance_wipe --scope rest --confirm-database <database>

The selected parts are emptied and left as a fresh installation has them: the Test Cases root folder, the standard roles and permission groups, and the default automation object settings come back. Wiping users or roles (or --all) also needs --admin-email. The audit trail is kept, and users that it or other remaining records still refer to stay as inactive users without roles. Credentials stored for the wiped records are removed from the installation's secret store.

How to check what a command will do

Add --dry-run to instance_import or instance_wipe. The command runs completely, prints its report and then undoes everything. A dry run needs no --confirm-database.

Field reference

Option	Commands	What it does
`--scope <scope>`	all three	A part to move or empty: `licence`, `settings`, `users`, `roles` or `rest`. Repeat it for several parts. On import, it picks parts out of a stream that holds more.
`--all`	export, wipe	Every part.
`--with-history`	export	With `rest`: also test runs and executions with their messages, crawler, trace scheduler and schedule runs, Messenger exchanges and API Explorer history.
`--wipe`	import	Replace parts that already hold data. Without it, an import into parts that hold data is refused.
`--confirm-database <name>`	import, wipe	The installation's database name, as a safeguard against changing the wrong installation. A dry run shows it.
`--admin-email <email>`	import, wipe	The account that is an administrator afterwards. Required when users or roles are imported or wiped.
`--keep-active`	import	Keep imported automation running as exported instead of paused.
`--force`	import, wipe	Replace or empty test content even while test runs, crawls or other jobs are running.
`--dry-run`	import, wipe	Do everything, report, and undo it.

The commands end with exit code 0 when done, 1 when something failed and everything was undone, 2 when they refused to start (nothing changed), and 3 when the change is in place but a step after it failed — for example removing the credentials of wiped records; the report names the step.

Tips & edge cases

All or nothing. An import or wipe runs as one change. If the connection drops, the file is damaged or anything goes wrong, nothing is changed.
Plan a quiet moment. While an import runs, the parts it replaces are locked: users and running jobs that need them wait until it finishes. Copying about 850,000 test cases took about 11 minutes.
Memory. The command needs about 500 MB of memory in addition to what the installation uses. On Kubernetes, run it in the worker pod as shown above; on Cloud Foundry, in the web application, which is the one with room for it.
Licences are bound to their server. A copied licence works only where it is valid; the import report says whether it is active on the target or why not.
SAP NetWeaver RFC SDK. The target checks the copied SDK on its own server. An SDK built for a different processor type is kept but marked invalid; upload the matching one under Global Parameters.
Runs that were still running when exported arrive as cancelled or failed.
Paused automation. After an import without --keep-active, switch schedules, crawlers, trace schedulers, Messenger instances and external channels back on once their credentials are in place.
Storage cleanup. Payloads that no longer belong to anything after a wipe are removed from storage within about an hour.

Licenses — the licences an import brings along.
Global Parameters — settings, the RFC SDK and the AI provider key to enter again.
Systems Under Test — credentials to enter again after an import.
Users and Roles — who signs in and what they may do after users or roles were imported.
Content Packages — deliver selected objects into an installation that keeps its own content.

Prerequisites & permissions

These commands are not part of the application's screens and are not governed by its roles. You need operator access to the installation itself: access to the Kubernetes namespace or cf ssh access to the Cloud Foundry space. Only give that access to people who may replace the installation's data.