How it works — high level and practical. The Panel (synconixm) lives on one VPS, it provisions two kinds of remote machines (Production and Storage), then moves data between them over SSH (or a locked rsync tunnel) into timestamped “backup points”. Restores run the opposite way.

What the installer lays down (Panel node)

• Creates/uses the Panel system user synconixm with home /home/synconixm.
• Installs the Panel app (RPM) and seeds the working tree /home/synconixm/.synconix: scripts (.synconix/scripts), sessions (.synconix/sessions), cron lists (.synconix/cron), private keys (.synconix/private_keys), downloads, cloud configs, and TLS certs (.synconix/certs).
• Web access can be IP-restricted via .synconix/security.txt (simple allow-list the Panel checks on each request).
• The Panel database keeps users/roles, servers, storages, schedules, logs, activity, and settings.

OS support

Production/Storage nodes are autodetected and handled via their native package managers: RHEL/CentOS/Alma/Oracle (dnf/yum), Debian/Ubuntu (apt), openSUSE (zypper), FreeBSD (pkg), and Slackware (slackpkg).

Provisioning a server (what happens on “Add Server / Add Storage”)

1) Panel logs in as root once (temporary RSA key) just to bootstrap.
2) Creates the system user synconix with sudo NOPASSWD and home /opt/synconix/home:
— on Production: standard UID with sudo.
— on Storage: root-equivalent account (UID 0) where required for low-level operations (per code path).
3) Generates a new per-server RSA keypair (passphrase-protected) and installs it: authorized_keys on the remote, .prv/.pub in /home/synconixm/.synconix/private_keys/ (0600).
4) Installs tools and the Panel’s own rsync 3.x under /opt/synconix/bin/rsync plus helper scripts in /opt/synconix/scripts; sets sudoers for the synconix user.
5) Detects control panels (cPanel/Plesk/DirectAdmin) and capabilities (ACL support, SQL client, IPs).

Key management & transport security

• Each remote gets a unique RSA keypair; private keys are stored locally under /home/synconixm/.synconix/private_keys/<server_ip>.prv and encrypted with a salt-derived passphrase. Permissions are strict (0600).
• A short-lived default key (with passphrase) is used only for first root login; it’s removed afterward.
• Default SSH flags include connect/keepalive timeouts, known-hosts off (first contact provisioning), and the cipher AES-128-CTR for predictable performance.
• Tunnel mode (optional): the Panel can configure a locked rsync daemon on a custom port (59123) on Production, with:
  — hosts allow listing only the Storage IPs,
  — an auth user and secret, and
  — service managed by systemd/init (installed as synconix.service).
This reduces SSH setup overhead when doing large pulls; credentials are injected only at run time.

Where data flows (two patterns)

• Linux Storage → Production (pull): for on-prem storage, the Storage node initiates the transfer and pulls from Production over SSH (or the tunnel), writing into /<your-partition>/<sha1(schedule_id)>/ on Storage. Files and MySQL live under separate paths.
• Cloud Storage (push): when the target is cloud, the Production server runs rclone with a per-storage config the Panel deploys, and pushes to the cloud remote. Filters and logs are still managed by the Panel.

What a backup run actually does

• The Panel builds include/exclude lists (files) or DB excludes (MySQL) under /home/synconixm/.synconix/cron/<sha1(schedule_id)>/ and sends them to the executor (Storage or Production).
• It starts a detached screen session remotely and runs the job script: backup.sh for files, mysql.sh for databases (under /opt/synconix/scripts).
• Incremental backups are enabled by default after the first full run (rsync – hardlink/XAttrs/ACL awareness if available). Each run creates a new backup point folder (timestamped).
• Logs and state are written under /opt/synconix/cron/<sha1(schedule_id)>/ on the executor (plus “running” markers at the Panel).

Retention & promotion

• The Panel enforces daily/weekly/monthly retention: oldest points are moved to scheduled_for_deletion_* then purged (merge runs “after” a job if configured).
• Weekly = rename an old daily to _weekly (typically Mondays). Monthly = rename an old weekly (or daily) to _monthly on day 1. Counts are kept exactly to your configured points.

Restores

• Granular: from the Panel, pick a point and restore file/folder paths back to Production (Storage pushes over SSH/tunnel).
• MySQL: restore specific dumps from the selected point using the job’s SQL connection settings.
• Disaster Recovery: Storage generates a temporary RSA key, authorizes it on the destination server’s root, then uses /opt/synconix/bin/rsync -aHAXW --numeric-ids to rebuild the filesystem from a chosen point, honoring your exclude list.
• End-user plugins (optional): cPanel/WHM or Plesk extensions let customers browse/restore their own files safely; the Panel installs/uninstalls these and writes the API endpoint & schedule ID automatically.

What gets installed on remotes

• User: synconix (sudo NOPASSWD), home /opt/synconix/home; on Storage it may run as UID 0 (root-equivalent) per code.
• Binaries: /opt/synconix/bin/rsync (Panel’s version), ssh/ssh-agent, and required utilities.
• Scripts: /opt/synconix/scripts/backup.sh, mysql.sh, exec.sh, session.sh.
• Runtime: /opt/synconix/cron/<sha1(schedule_id)>/ for lists, logs, and point markers.
• Keys: /opt/synconix/home/.ssh/authorized_keys (+ for Storage, per-production private keys like .ssh/<prod_ip>.prv when needed).

SSH keys, passphrases, and tunnels

• Per-server keys are passphrase-protected with a salt derived at deploy time; the Panel unlocks them only when needed (via ssh-agent).
• Tunnel mode uses a dedicated rsync daemon on 59123 with an auth user/secret and a hosts allow list. The Panel sets and rotates these, and exports the secret to the job only for the lifetime of that run.
• Optionally, a TLS-wrapped socat service can be enabled on Storage for secure, IP-limited file metadata operations (Panel generates per-storage CA/client certs and validates SOCAT_PEERADDR).

End to end in one minute

1) Add Storage → 2) Add Production → 3) Create a Schedule (files/SQL) → 4) Run → 5) New point appears under the schedule path → 6) Browse/restore → 7) Retention keeps your daily/weekly/monthly sets tight.