DataPower GitOps read/write reports a successful export but silently omits all symlinked local: content (e.g. local:///disk on disk-backed storage), producing incomplete config/file backups with no warning — making automated backup, DR and drift detection

We adopted DataPower GitOps (operation mode read/write) to automate backup of our domain configuration and local: files into Git as a single, trustworthy config-as-code pipeline for backup, disaster recovery and drift detection.

We found that on appliances where a local: directory is a symbolic link (local:///disk, pointing to disk-backed/persistent storage — a standard DataPower layout), GitOps exports NONE of that content. On these appliances all domain files live under that symlink (configuration, service maps, WSDLs, reference data, security artifacts), so GitOps captured object config only and zero files.

Critically, the operation reported SUCCESS. The push completed, the repository looked populated, and there was no warning, no error, and no indication that the entire file tree had been left out.

Evidence — GitOps debug log:
 DEBUG gitops::util::file - ignoring symlink /drouter/local/ESB2_SVP1/disk
 FileFinder { ... opt_include_symlinks: false ... }

WebGUI File Management resolves the symlink and shows the full content under local:///disk/, proving the data is present and valid. On another appliance running IDENTICAL firmware (IDG.10.6.0.10, build 386419) and IDENTICAL GitOps configuration, where the same folders are real directories, GitOps exports them correctly. The only difference between the working and failing appliances is the symlinked, disk-backed local: layout — same software, same config, opposite result.

Blocker:
1. Silent, undetectable data loss — GitOps excludes symlinked directories yet reports success. Operators have no signal the backup is incomplete.
2. No visibility or control — no log warning, no skipped-path report, and no exposed setting to detect, prevent or remediate the gap.
3. A standard, supported storage layout (disk-backed local: via symlink) cannot be backed up by GitOps at all.

Business impact:
- Automated backup is unreliable — incomplete backups that look complete; cannot be trusted as a source of truth.
- Disaster recovery risk — a restore would be missing all domain files; false sense of DR coverage on production-like systems.
- Detection is blind — file changes under the symlink are never captured, so compliance/drift reporting is incomplete.
- Audit exposure — "green" backups that are silently partial undermine assurance that configuration is protected and recoverable.

Any customer using disk-backed local: storage (a supported, common layout) who adopts GitOps for automated config/file backup is exposed to the same silent, incomplete-backup condition, with no way to know.

We ask IBM to consider ensuring GitOps read/write reliably backs up domain configuration and files regardless of whether local: uses a symlinked, disk-backed layout — and, where content cannot be captured, to make that visible and unmistakable rather than reporting success.