Backup and restore

What you will do: know which directory holds everything you would need to rebuild a deployment, back it up on your schedule, and restore configuration, version or single objects when something goes wrong.

Everything XPLG is configured with lives in one place. On V7 it is the external configuration directory (EXTERNAL_CONFIGURATION_DIRECTORY, extConf); without one, the installation directory. On X8 it is the shared /home/data tree (extConf) under XPLG_SHARED_HOST_PATH. PortX > Settings > System Settings shows which directory is in use. Keep it on fast storage and back it up: a fresh installation pointed at an existing directory picks up the whole configuration, which is also how cluster nodes share it.

What to protect

Keep the .lic file XPLG sent you with the backup: a license is dedicated to one server or cluster and is issued against its server key — see How licensing works.

Automatic configuration backups (V7)

XPLG stores a daily backup of its whole configuration and keeps the backups for 30 days under <extConf>/temp/backups/, one zip per day with a conf and a collection directory inside. For X8 the wiki documents no equivalent — pending engineering. To return to an earlier configuration state (an undesired change, an object removed by mistake):

1. Stop every XPLG process — all nodes of a cluster. This is critical.
2. In <extConf> rename conf to conf.current and collection to collection.current.
3. Unzip the backup of the day you want from <extConf>/temp/backups/.
4. Copy its conf and collection directories into <extConf>.
5. Start the processes and reload the browser; the console comes up with the restored configuration.

Roll back a version

• V7. Under PortX > System > About choose Publish Patch, select the zip of the earlier build and run it; the system restarts. Then open conf/ui/strings/info.properties in the configuration directory and lower build= to a number below the build you just applied, restart every node and confirm the version on the About page. The page that documents this is from 2021 — confirm with support before using it on a current build. The Java 17 migration keeps a java8_backup of the previous runtime; see Upgrades.
• X8. Restore the previous tag in XPLG_IMAGE, docker compose pull, up -d.

Export and import single objects

• Logs and folders. In Data > Folders and Logs mark the checkbox of a log or folder and export it with its configuration or its data only; import an exported zip under any folder with Import Log/Folder (right-click or the three-dots menu, also from the Log Viewer). Only exports from version 7 and later can be imported.
• Apps and dashboards. Export / Import an App and Export / Import a Dashboard under Apps Administration.
• Templates. Export and import under Patterns (Templates).
• The whole configuration as a snapshot. The security specification describes the configuration as exportable in versioned snapshots for backup, rollback, environment cloning and audit evidence; the wiki's mechanisms for it are the daily zips above and the Geo-redundancy zip below.
• System Report. About > Export System Report writes an XML for support; it is not a backup.

Geo-redundancy

XPLG replicates selected configuration between a primary and a secondary site so that, on a regional outage, users redirected to the secondary site find the identical configuration. It does not replicate raw data: your own process copies the data to both sites, and copies each site's Outbox to the other site's Inbox keeping the files' last-modified time. Two files in <extConf>/conf/general/ drive it: configMerge.xml (what is synchronised — by default the Address Book, Folders and Logs, AppTags, monitors, saved searches and user specifics, apps with their dashboards and widgets, user templates and the collection policies; filesToKeep for each box; Excludes; BinaryIncludes) and configMerge.user.xml (the cron in ScheduleOp, the Inbox and Outbox paths; commenting ScheduleOp out pauses the sync after a restart).

1. Baseline. With Geo-redundancy disabled and both sites stopped, copy the synchronised directories from the primary to an empty secondary, start both and verify the configuration is identical.
2. Activate. Configure both files on each site with its own paths, make sure both boxes exist and are empty, enable Geo-redundancy on both sites, and put the copy process in place.
3. Operate. Change a given object on one site only; if the same object changes on both, the later file wins.

X8 day-2 and resets

docker compose down stops the stack and keeps the data; down -v deletes volumes but bind-mounted data survives. Copy XPLG_BASE_HOST_PATH and XPLG_SHARED_HOST_PATH with the stack down. A full reset — down --remove-orphans, remove both trees, xplg-preflight.sh --fix-dirs, up -d — destroys the data. A documented X8 backup and restore procedure (daily configuration zips, snapshots) is pending engineering; until then treat the two trees as the backup unit.

Next: Air-gapped

Source: XPLG wiki, pages 1595637833, 1602846740, 1594133053, 1597539296, 1597539362, 1594133024, 1594133026, 1594133348, 1594132976, 3161587738, 1599570438, 1594132180, 3150544899, 3151659011, 1597964372, 1594133274 (https://xpolog.atlassian.net/wiki/spaces/XPOL/pages/1595637833). Pending from XPLG engineering: the X8 configuration backup mechanism; a raw-data backup procedure beyond the archive.