MokonyxBackup Security, Encryption & Integrity

AES-256 Encryption

Encryption is per-profile and driven entirely by the profile's Encryption Password in Archive Settings — a blank value means no encryption, any non-empty value turns AES-256 on. Support depends on the archive format:

• ZIP — WinZip-compatible AES-256 applied per entry after the archive is written (requires PHP 7.2+ with libzip 1.2.0+). File contents are encrypted; filenames stay visible.
• 7z — native 7z CLI encryption with header encryption (-mhe=on), so filenames are hidden too (requires p7zip / 7-Zip on the server).
• tar.gz — encryption is not supported; the backup completes unencrypted and logs a warning.

If encryption is configured but the encryption step fails, the plaintext archive is deleted and the backup is recorded as failed, so an unencrypted copy is never left behind.

Data Sanitization

Independently of encryption, a profile can scrub the database dump before it is archived: sanitize passwords (with preserve super admin), sanitize emails, and sanitize sessions. Credentials in configuration.php are also stripped automatically. Use encryption and sanitization together when shipping backups off-site.

SHA-256 Integrity

A SHA-256 checksum is computed for every archive after creation (after encryption, when enabled) and stored on the backup record — it is also exposed on the backup record in the REST API. Use the Verify Integrity button to re-compute the archive's SHA-256 and detect corruption or tampering. Only backups created after this feature was added carry a stored checksum.

MokonyxRestore Restore Script

Self-contained restore.php with CSRF protection, pre-flight checks, and encrypted-archive support. Upload it to any PHP server for a bare-server restore. See Restore & MokonyxRestore.

Backup Directory

Protected with .htaccess (Deny from all) and index.html. For best security, set a backup directory outside the web root.

Permissions & ACL

Every MokonyxBackup capability is a granular Joomla ACL action, set per user group and per site under Options → Permissions. Super Users inherit all actions via core.admin; delegate individual capabilities to other groups by granting the specific actions below (enforced server-side in the controllers and on the REST API).

• mokonyxbackup.backup.run — start backups (incl. the pre-action backup)
• mokonyxbackup.backup.cancel / mokonyxbackup.backup.stall — cancel / mark-stalled a running backup
• mokonyxbackup.backup.restore — restore (admin, stepped, WAF re-apply)
• mokonyxbackup.backup.download — download archives
• mokonyxbackup.backup.purge — purge / delete backup records
• mokonyxbackup.backup.compare — differential comparisons
• mokonyxbackup.backup.browse — browse archives, snapshots and directories; view logs
• mokonyxbackup.remote.manage — manage backup destinations (remote storage)
• mokonyxbackup.tuning.manage — run / reset the Execution-Tuning wizard
• mokonyxbackup.setup.manage — run / reset the first-run Setup wizard
• mokonyxbackup.snapshot.manage — all content-snapshot operations

Backup Profiles use the core create / edit / delete actions.