The “ZimaOS Premium Snapshot Script” is not a ZimaOS snapshot in the filesystem/VM sense. It does not create a Btrfs snapshot or backup image. It is a community Bash script that collects a diagnostic report: system version, resource usage, temperatures, filesystems, RAID state, SMART health, Docker containers, AppData size, network configuration, and top processes.
That makes it potentially useful for support, but also means the generated text can contain environment details you may not want to post publicly. Zima-Giorgio praised the idea and suggested saving iterative report files under /DATA because that location is easier to access from Files. IceWhale did not adopt or certify the script as a built-in diagnostic tool in this thread.
The Script Builds One Human-Readable System Report
The source script collects:
- ZimaOS version, variant, build date, hostname, manufacturer, model;
- CPU load, memory, swap, and temperatures;
- filesystem usage and disk layout;
- RAID and Btrfs status;
- SMART health for disks;
- running and exited Docker containers;
- AppData and Main-Storage directory sizes;
- IPv4 interfaces, bridges, and default route;
- top CPU and memory processes.
A Diagnostic Report Is Not a Backup or Filesystem Snapshot
The word “snapshot” can be misleading. The script writes system information into a text file; it does not capture application databases, files, container layers, or point-in-time storage state for restoration.
Use ZimaOS Backup, application-aware exports, RAID protection, or actual filesystem/VM snapshot tools for recovery purposes.
The Original Script Wrote to Main-Storage
The V1 script created:
/media/Main-Storage/Zima_snapshot/and stored dated text reports there. That path assumes the user's storage space is actually named Main-Storage.
On another system, hard-coding that path can fail or write somewhere unintended if the mount is unavailable.
Zima-Giorgio Suggested /DATA for Easier Access
In the final source reply, Zima-Giorgio said that if the project kept iterating, he would suggest storing output files under /DATA because that directory is easier to access through the Files app.
This was official feedback on the community project, not an announcement that IceWhale had integrated the script.
SMART Output Needs Per-Device Interpretation
The example report showed traditional HDD SMART fields such as temperature, reallocated sectors, pending sectors, CRC errors, and power-on hours. It also showed “SMART not available” for the NVMe devices because the script's simple parsing did not produce equivalent NVMe output.
Do not interpret “not available” from this script as proof the NVMe has no health telemetry.
The Script Was Written Around the Author's RAID 5 Layout
The example explicitly labels md0 and prints a “RAID5 Status” section. Another ZimaOS installation can use RAID 1, RAID 6, JBOD, ZFS, single disks, or differently named md devices.
Before reusing the script, review every hard-coded device, mount path, and filesystem assumption.
Docker Output Can Expose Application Inventory
The report includes container image names and application names. That is useful to support staff, but a public paste can reveal which services you run, which versions are installed, and potentially which applications are outdated.
Redact unnecessary service names when the report is being posted outside a trusted support channel.
Network Output Can Reveal Internal Topology
The example report lists interface names, LAN IP addresses, virtual networks, Docker bridges, and default routes. The source author manually masked part of the IP information in the posted example.
Before sharing a report publicly, review:
- IP addresses and subnets;
- hostnames;
- VPN/overlay interface names;
- mount and share names;
- application/container names;
- any paths that include personal identifiers.
Prefer Read-Only Diagnostics
The strength of this kind of script is that most useful troubleshooting data can be collected through read-only commands such as system information, disk usage, SMART queries, Docker listing, and process inspection.
A diagnostic script should not quietly restart services, prune Docker, modify RAID metadata, or delete logs. Keep evidence collection separate from repair actions.
Current ZimaOS Already Exposes More Storage and App Diagnostics
Current Settings > Apps shows per-application storage usage and cache controls, while Storage exposes disk health and array information. Use built-in visibility first, then add a community report when support needs a broader one-file system snapshot.
The current app-storage visibility tools can answer many space-related questions without a custom script.
Diagnostic Snapshot FAQ
Does this script create a recoverable system snapshot?
No. It creates a text diagnostic report.
Did IceWhale officially adopt the script?
No. Zima-Giorgio praised it and suggested storing reports under /DATA, but the code remains community-created.
Should the report be posted publicly without review?
No. It can expose IP addresses, topology, storage names, application inventory, and other environment details.
