MokoSuiteBackup

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Overview

A content snapshot captures selected Joomla content (articles, categories, modules, and their tags, custom-field values and featured flags) into a JSON payload you can restore later. Snapshot Transfer lets you move a snapshot between sites two ways:

1. Download a snapshot as a portable .msbsnap file and Import it on another site.
2. Inject a snapshot directly from a master site into a slave site over the Web Services API.

This is content-level transfer, not a full-site archive.

The Portable .msbsnap Format

A .msbsnap is a ZIP containing:

On import the archive is validated before anything happens: both entries must be present, the format must be msbsnap and not a newer version than this site supports, and the payload is verified against payload.sha256 with a constant-time compare — a failed checksum aborts the import. If the source Joomla major version differs, the import still proceeds with a non-blocking compatibility warning. A successful import materialises a local snapshot record; it does not restore anything by itself — you then restore that record from the Snapshots page like any other snapshot.

Download & Import (Snapshots Page)

On the Snapshots page each row offers a Download action (streams a .msbsnap file) and the page has an Import button that accepts an uploaded .msbsnap. The imported snapshot appears as a new record you can restore. (The API also exposes GET .../snapshot/:id/download, which streams the raw snapshot.json payload rather than the zipped .msbsnap.)

Direct Master → Slave Injection (API)

A master site can push a snapshot straight into a slave's Web Services API:

POST /api/index.php/v1/mokosuitebackup/snapshot/inject

Request body:

{
  "snapshot":      { "version": 1, "content_types": ["articles"], "tables": { "...": [] } },
  "mode":          "overwrite",
  "content_types": ["articles"],
  "description":   "Injected from master"
}

• snapshot (required) — the payload inline, the same shape as snapshot.json.
• mode (optional) — conflict mode; defaults to the receiving site's snapshot_inject_mode.
• content_types (optional) — filter to restore only some types.

The endpoint requires the mokosuitebackup.snapshot.manage permission (403 otherwise) and the receiving site must opt in via snapshot_allow_inject (else 403 "Snapshot injection is disabled on this site"). It ingests the payload into a local record (422 if invalid), then restores it in the chosen mode, returning the resulting snapshot_id and any warnings.

Conflict Modes

overwrite and create run inside a DB transaction. duplicate is intentionally best-effort (Joomla's Nested tables issue LOCK TABLES, which implicitly commits the transaction), so each item is inserted defensively — a bad item is skipped and logged, never fatal.

Configuration (Options > Snapshot Transfer)

Snapshot retention (independent of transfer) is under Options > Snapshot Retention: snapshot_retention_count (default 20) and snapshot_retention_days (default 30); 0 = unlimited for that setting.

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Overview

MokoSuiteBackup can automatically run a full-screen backup before Joomla changes anything — before a Joomla core update, before an extension update, and before an extension uninstall. The backup runs on its own dedicated full-page screen (modelled on Akeeba's Backup-on-Update), shows a real progress bar, and then hands control back to Joomla so the original action continues.

The design goal is safety without white-screens: no backup ever runs synchronously inside the core update request. Running a large-site backup inside the update request is exactly what white-screened sites in earlier approaches, so the core-update flow always redirects to the standalone backup screen first.

Turning It On

Configure under Components > MokoSuiteBackup > Options > Pre-Action:

The backup runs with the component's default profile (default_profile, defaults to profile 1). Both features are Super User only — a non-super-user updating an extension is never intercepted.

One Backup Per Update Action

A pre-action backup fires once per Update/Uninstall action, not on a timer. A per-request dedupe guard means a batch update backs up only once, and a one-shot skip flag prevents the client-side and server-side paths from duplicating each other — while the next distinct action still backs up again. The core-update path uses its own session key so it never suppresses extension backups.

How It Works — Joomla Core Updates

For a core update the plugin intercepts server-side (in onAfterRoute) at the last moment before any files change:

1. The Install the update click is matched on the confirm/updating page.
2. The browser is redirected to the full-screen backup screen (view=runbackup) with a validated returnurl back to the update page.
3. The backup runs on its own page.
4. On return, a small injected script auto-ticks Joomla's "I have taken a backup" checkbox and clicks Install, so the update continues automatically (Akeeba-style) instead of stopping for a second manual click.

How It Works — Extension Updates / Uninstalls

Extension update/uninstall are POST actions carrying a CSRF token and a checked selection, so this path is handled client-side by the plugin's installer-backup.js, injected on Extensions > Update and Extensions > Manage. In Joomla 6 the toolbar buttons are web components, so the script uses a capture-phase click listener that runs before the toolbar's own handler:

1. Intercept the Update/Uninstall click and capture the checked selection into sessionStorage.
2. Send the browser to the full-screen backup screen with a validated returnurl.
3. The backup runs, then returns to the original page.
4. Resume — the script restores the selection and re-fires the toolbar action so the real POST proceeds. In Joomla 6 the click handler is bound to the inner button (not the outer task wrapper), and a list-selection button starts disabled until boxchecked fires a change event — the script handles both so the update actually submits. While the update runs, a full-screen “the update is now running — please wait” overlay is shown so you know it is working.

A server-side fallback still exists for the extension path; when it runs synchronously it raises PHP limits and sets ignore_user_abort(true) so a large-site backup can't exhaust the request. If the client-side redirect can't be built, the script bails without preventing the click, so Joomla's own action proceeds normally.

The Full-Screen Backup Screen

view=runbackup is the shared full-page screen used by both the pre-action flow and the dashboard Backup Now:

• Auto-starts the stepped backup over AJAX with a full-bleed, Atum-coloured progress bar on a black backdrop.
• While the backup runs it shows a prominent “do not close this window or switch to another window” warning and a Cancel button. Cancelling requires a double confirmation; on confirm it stops the backup, cancels the record, and returns to the dashboard without continuing any pending update.
• The returnurl is validated to block open-redirect / javascript: XSS — only a same-host absolute URL or a root-relative path is accepted.
• Pre-action flow: the screen shows an “Automatically continue the update when the backup finishes” checkbox, ticked by default. Checked → hands straight back to Joomla and the update continues seamlessly; unticked → stops on a completion panel with a View backup record link (opens in a new window) and a Continue the update button.
• Manual Backup Now: shows a View backup record button and Back to dashboard.
• On failure the update is blocked. The pre-action screen offers only Retry or Back to dashboard — never “continue without backup” — so a broken backup can never let the update proceed unprotected.

Notifications

Every pre-action backup surfaces its outcome in the admin as an enqueued message — success, warning, or failure — so a successful pre-update backup is visible, not just failures.

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Plugin Overview

MokoSuiteBackup is a Joomla package that ships with seven plugins and an admin module alongside the main component. All plugins are auto-enabled on installation.

Auto-Cleanup (System Plugin)

Automatically removes old backup records and archive files based on age and count limits.

• Max Age — Delete backups older than N days (default: 30, range: 1–365)
• Max Backups — Keep only the N newest backups (default: 10, range: 1–100)
• Runs once per hour on admin page loads (not AJAX), throttled via session
• Age-based deletion runs first, then count-based enforcement
• Retention prunes both the local archive/record and each enabled remote copy

Configure in System > Plugins > System — MokoSuiteBackup.

Backup Before Update & Uninstall (System Plugin)

The system plugin also provides full-screen backup-before-update protection. When enabled (Super User only), clicking Install the update on a Joomla core update, an extension update, or an extension uninstall redirects to a dedicated full-screen backup screen with a real progress bar, then continues the original action seamlessly — no backup runs synchronously inside the update request, so large sites don't white-screen. Enable Backup before update / Backup before uninstall in Components > MokoSuiteBackup > Options > Pre-Action. Fires once per Update/Uninstall action.

Dashboard Widget (Quickicon Plugin)

Adds a status widget to the Joomla Home Dashboard showing:

• Time since last backup (e.g. "2h ago", "3d ago")
• Total backup count and total storage used
• Warning states: no backups exist, recent failures, or stale backups (older than 7 days)

Automatic Pre-Update Backups (Content Plugin)

Triggers an automatic backup before Joomla extension installs or updates.

• Backup Before Install — Triggers before installing a new extension (default: disabled)
• Backup Before Update — Triggers before updating an extension (default: enabled)
• Profile — Which backup profile to use for automatic backups
• Non-fatal: if the backup fails, a warning is shown but the install/update proceeds

Configure in System > Plugins > Content — MokoSuiteBackup.

Action Logging (Action Log Plugin)

Records MokoSuiteBackup actions in Joomla's User Action Logs (Users > User Actions Log):

• Profile created, updated, or deleted
• Backup record deleted
• Backup completed or failed

Each log entry includes: user, IP address, item ID, and timestamp.

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Overview

Placeholders are tokens enclosed in square brackets that are resolved at backup time. Use them in the Backup Directory and Archive Name Format fields of a backup profile to create dynamic, portable paths and filenames.

Available Placeholders

Examples

Archive Name Format

Default: [HOST]_[DATETIME]_profile[PROFILE_ID]

Result: www.example.com_20260607_143025_profile1.zip

Custom: [SITE_NAME]_[TYPE]_[DATE]_[RANDOM]

Result: My-Joomla-Site_full_20260607_a3f2b1.zip

Backup Directory

Default: [DEFAULT_DIR] (resolves to the component's backups folder inside the web root)

Outside web root: /home/user/backups/[HOST]/[YEAR]/[MONTH]

Result: /home/user/backups/www.example.com/2026/06/

Organised by profile: /var/backups/joomla/[PROFILE_NAME]

Result: /var/backups/joomla/Daily-Full/

Notes

• Placeholders are resolved at backup time — the directory is created automatically if it doesn't exist
• The [DEFAULT_DIR] placeholder makes profiles portable across different server paths
• On CLI/cron there is no HTTP host, so set the site's live_site (with scheme) in Global Configuration to get the correct [HOST] in archive names
• Directory paths containing unresolved placeholders skip permission checks in the dashboard (they can't be validated until backup time)
• Sanitisation removes special characters, keeping only alphanumerics, dots, hyphens, and underscores

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Restore Methods

MokoSuiteBackup supports three ways to restore a backup:

1. Admin Panel — Select a backup record and click Restore in the toolbar
2. CLI — php cli/joomla.php mokosuitebackup:restore <record-id>
3. MokoRestore — Standalone restore script for bare-server deployment (no Joomla required)

Admin Panel Restore

The built-in restore engine runs a six-step process:

1. Extract archive to a temporary staging directory
2. Preserve configuration.php so database credentials and paths survive the restore
3. Restore files from the archive to the Joomla root
4. Import database from the SQL dump (if present)
5. Restore configuration.php with the preserved version
6. Clean up the staging directory

Supports ZIP, tar.gz, and 7z archive formats. Encrypted archives are supported with a password prompt.

MokoRestore Standalone Script

When Include MokoRestore is set to Standalone in a backup profile, the archive is packaged as:

outer.zip
├── restore.php      (standalone installer)
└── site-backup.zip  (the actual backup)

Upload both files to any PHP server and open restore.php in a browser. The wizard guides you through:

Step 1: Preflight Checks

• PHP version (8.3+ required)
• Required extensions: ZipArchive, PDO MySQL, mbstring, JSON
• Backup file exists and is readable
• Directory is writable
• Free disk space (500 MB minimum)
• PHP memory limit

Step 2: Extract

Extracts the site backup archive. Pre-reads any existing configuration.php to pre-fill database credentials. Supports encrypted archives.

Step 3: Test Database

Enter database credentials and test the connection before proceeding.

Step 4: Import Database

Imports database.sql with foreign key checks disabled. Reports statements executed and any errors.

Step 5: Configuration

Updates or creates configuration.php with your database credentials, paths, a fresh secret key, site name, and live site URL.

Step 6: Admin Management

Lists super administrator accounts and optionally lets you reset a password using bcrypt hashing.

Step 7: Cleanup

Removes restore.php, site-backup.zip, and database.sql artifacts from the server with a self-delete mechanism.

Security

• MokoRestore includes CSRF token protection on all forms
• Encrypted archive support (AES-256)
• Self-contained in a single PHP file — no dependencies
• Always delete restore.php after use

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Overview

MokoSuiteBackup can send notifications when backups complete or fail, over both email and ntfy push. Notifications are configured per profile, giving you fine-grained control over who gets notified and when.

Configuration

Open a backup profile and go to the Notifications tab:

Email addresses and user group members are combined. Duplicate addresses are automatically filtered.

Email Content

Subject Line

[MokoSuiteBackup] SUCCESS: Daily Full Backup — My Joomla Site
[MokoSuiteBackup] FAILED: Daily Full Backup — My Joomla Site

Email Body Includes

• Site name and URL
• Backup status (success/failure)
• Profile name and backup type
• Backup description and origin (backend, CLI, scheduled, web cron)
• Archive filename and total size
• Duration, start time, and end time
• Remote filename (if uploaded to SFTP/FTP/S3/Google Drive)
• File count and table count

On failure, the last 30 lines of the backup log are appended to help diagnose the issue.

Tips

• For critical production sites, enable Notify on Failure and add the site admin's email or an ntfy topic
• Use user group notifications to automatically include new team members
• Notification errors are logged but never block the backup process — a failed email won't cause a backup failure

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Overview

MokoSuiteBackup provides CLI commands via the Joomla console plugin (plg_console_mokosuitebackup). All commands run through Joomla's console entry point from the site root:

php cli/joomla.php <command> [options]

All commands run through the shared BackupRunner service, producing the same complete / warning / fail outcome as the web UI. A legacy standalone script (administrator/components/com_mokosuitebackup/cli/mokosuitebackup.php) is also bundled for existing cron setups.

Commands

mokosuitebackup:run

Run an immediate backup.

php cli/joomla.php mokosuitebackup:run --profile=1 --description="Nightly backup"

Exit code is 0 on success, 1 on failure. The origin is recorded as cli.

mokosuitebackup:profiles

List all backup profiles (use this to find a profile ID).

php cli/joomla.php mokosuitebackup:profiles

Output columns: ID, Title, Type, Published.

mokosuitebackup:list

List backup records, newest first.

php cli/joomla.php mokosuitebackup:list --status=complete --limit=10

Output columns: ID, Profile, Status, Type, Size, Origin, Started.

mokosuitebackup:restore

Restore a completed backup by record ID. This overwrites the current site, so it prompts for confirmation.

php cli/joomla.php mokosuitebackup:restore 42

The record must be marked complete and the archive must still exist on disk.

mokosuitebackup:cleanup

Prune old backup records and archive files by age and/or count.

php cli/joomla.php mokosuitebackup:cleanup --max-age=14 --max-count=5
php cli/joomla.php mokosuitebackup:cleanup --dry-run

mokosuitebackup:snapshot

Create, restore, list, or delete content snapshots (articles, categories, modules) — a lightweight alternative to a full backup for content-only rollbacks.

php cli/joomla.php mokosuitebackup:snapshot create --types=articles,categories,modules --description="Before edit"
php cli/joomla.php mokosuitebackup:snapshot list
php cli/joomla.php mokosuitebackup:snapshot restore --id=5 --mode=replace
php cli/joomla.php mokosuitebackup:snapshot delete --id=5

Cron Integration

# Daily full backup at 2 AM
0 2 * * * cd /var/www/html && /usr/bin/php cli/joomla.php mokosuitebackup:run -p 1

# Weekly cleanup on Sundays
0 3 * * 0 cd /var/www/html && /usr/bin/php cli/joomla.php mokosuitebackup:cleanup --max-age=30 --max-count=10

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Joomla Scheduled Tasks

MokoSuiteBackup integrates with Joomla's built-in Scheduled Tasks (System > Manage > Scheduled Tasks). This is the recommended way to automate backups on any Joomla 6 site (Joomla 4/5 supported), and works just like Akeeba Backup Pro's scheduled backups.

Task type: Run Backup Profile

1. Go to System > Manage > Scheduled Tasks > New
2. Select MokoSuiteBackup: Run Backup Profile as the task type
3. Choose which published backup profile to run from the dropdown
4. Set your Execution Rule (e.g. daily at 2:00 AM, weekly on Sundays)
5. Save and enable the task

Each task instance has its own profile and schedule, so you can, for example, run a nightly full backup and an hourly database-only backup. Runs execute through BackupRunner with origin scheduled; a failure returns a KNOCKOUT status so the task is flagged accordingly.

Task type: Run Content Snapshot

A second task type, MokoSuiteBackup: Run Content Snapshot, captures content-only snapshots on a schedule. Pick the content types (articles, categories, modules) and a description template that supports [date] and [datetime] placeholders.

Joomla Cron Setup

Joomla's Scheduled Tasks require the scheduler to actually run — via the built-in Lazy Scheduler, a real cron entry, or a web-cron hit. A system crontab entry looks like:

*/5 * * * * /usr/bin/php /path/to/joomla/cli/joomla.php scheduler:run --all

Web Cron (Shared Hosting)

If you don't have access to system cron (common on shared hosting), the System plugin exposes a token-protected web-cron URL that any external cron service can trigger.

Setup

1. Go to Components > MokoSuiteBackup > Options > Web Cron
2. Enable Web Cron
3. Set a Web Cron Secret — a long random string that acts as a password
4. Optionally restrict by IP with the IP Whitelist field

Web Cron URL Format

https://yoursite.com/index.php?mokosuitebackup_cron=YOUR_SECRET&profile_id=1

External Cron Services

Use any external cron service (cron-job.org, EasyCron, UptimeRobot, etc.) to hit the web cron URL on your schedule. The trigger runs on onAfterInitialise before routing and without any admin login, and returns a JSON response with the backup result (HTTP 200 on success, 500 on failure, 403 when rejected). Backups run this way are recorded with origin webcron.

Security

• The web cron secret is compared using a timing-safe hash_equals() to prevent timing attacks
• IP whitelist support restricts which addresses can trigger backups
• PHP execution limits are automatically overridden (set_time_limit(0), memory_limit=512M)

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Dashboard Overview

The Dashboard is the default landing page when you open MokoSuiteBackup in the Joomla administrator. It gives you a real-time overview of your backup status, system health, and quick access to common actions.

Status Cards

Four clickable cards appear at the top of the dashboard:

Quick Actions

The Quick Actions panel provides:

• Backup Now — Select a profile from the dropdown and click to start an immediate backup. The full-screen backup screen shows a real-time progress bar, and on completion offers a View backup record button.
• Navigation links — Direct access to Backup Records, Backup Profiles, Content Snapshots, Scheduled Tasks, and Update Sites.

System Health

The System Health panel runs automated checks and displays pass/fail status for:

• PHP Version — Must be 8.3 or higher (required for Joomla 6.x)
• ZipArchive — Required PHP extension for ZIP archives
• AES-256 Encryption — Requires libzip 1.2.0+ for encrypted archives
• Backup Directory — Checks the configured directory exists and is writable
• Free Disk Space — Warns if less than 1 GB free

Default Directory Warning

If any published profile stores backups in the default directory inside the web root (administrator/components/com_mokosuitebackup/backups), a warning banner is displayed. For better security, configure a backup directory outside the web root.

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Positioning

MokoSuiteBackup is a native Joomla 6 full-site backup and restore solution (Joomla 4/5 supported) built to replace Akeeba Backup Pro. Like Akeeba it dumps the database, archives the files, and can preserve or restore configuration.php, and it integrates with the same Joomla subsystems — the console, the Scheduler, and the extension update flow. For the common "back up my site, restore it, do it automatically, and back up before I update" workflow it aims for parity.

Feature Parity at a Glance

How to Move from Akeeba

MokoSuiteBackup does not read Akeeba's .jpa/.jps archives or import Akeeba profiles — it uses its own profiles and archive formats, so migration is a parallel cut-over rather than an import:

1. Install the pkg_mokosuitebackup package (plugins auto-enable).
2. Set live_site in Global Configuration to your full site URL including the scheme, so CLI/cron archive names resolve the correct host.
3. Recreate your profiles — pick the archive format, set an encryption password if wanted, and configure remote destinations.
4. Recreate your schedule with a Scheduled Task, the web-cron URL, or a CLI cron entry running mokosuitebackup:run.
5. Re-point backup-on-update — turn off Akeeba's, enable MokoSuiteBackup's Backup before update / Backup before uninstall.
6. Run a test backup and restore, then uninstall Akeeba (ideally with Backup before uninstall enabled).

Backup-on-Update — the Akeeba-Style Flow

When you click Install the update, you're redirected to a dedicated full-screen backup screen with a real progress bar. An opt-in auto-continue checkbox (ticked by default) hands you straight back to the update the moment the backup completes — no second manual click; untick it to stop on completion and get a link to the new backup record plus a manual Continue the update button. No backup runs synchronously inside the update request (which is what used to white-screen large sites). While it runs, a “do not close or switch windows” warning and a full-screen “update is running” overlay stay on screen, and a double-confirmed Cancel is available. If the backup fails, the update is blocked outright — your only choices are to retry the backup or go back without updating. The same screen fronts extension updates and uninstalls.

What MokoSuiteBackup Adds

• Content snapshots — capture just articles, categories and modules for a fast content-only rollback.
• Snapshot transfer / master→slave injection — export a snapshot as a portable .msbsnap file, import it on another site, or push it directly into another site's Web Services API.
• Web Services API — manage backups and inject snapshots remotely.

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

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 checksum is computed after archive creation. Use the Verify Integrity button to detect corruption or tampering.

MokoRestore 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 & MokoRestore.

Backup Directory

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

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

REST API Endpoints

Routes are registered by plg_webservices_mokosuitebackup and are wire-compatible with the mcp_mokosuitebackup MCP server. The API Application and the Web Services plugin must be enabled. All routes require authentication — send a Joomla API token in the X-Joomla-Token header (or a Bearer token):

X-Joomla-Token: <your-api-token>
Accept: application/json

Base URL: /api/index.php/v1/mokosuitebackup/.... Each action also enforces a component ACL permission; a failed check returns HTTP 403.

Backup Endpoints

Snapshot Endpoints

Content snapshots capture selected content types (articles, categories, modules) as portable JSON. All require the mokosuitebackup.snapshot.manage permission.

MCP Server

The mcp_mokosuitebackup MCP server is wire-compatible with these endpoints, so an AI assistant can start backups, list records, manage profiles, and create or inject content snapshots remotely.

CLI

php cli/joomla.php mokosuitebackup:run --profile=1
php cli/joomla.php mokosuitebackup:run --profile=2 --description="Pre-deploy"

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Storage Backends

A profile can push each finished archive to one or more remote destinations, managed per profile in the profile's Remote Destinations panel. Each destination is stored as one row (with its settings as JSON) in #__mokosuitebackup_remotes.

SFTP, S3 and Google Drive appear in the Add/Edit modal's Type selector; FTP is a fully supported backend used by existing/imported destinations. All uploaders are pure PHP with cURL — no SDK dependencies.

S3-Compatible Services

• AWS S3: https://s3.amazonaws.com
• Wasabi: https://s3.wasabisys.com
• Backblaze B2: https://s3.us-west-001.backblazeb2.com
• MinIO: your server URL

Keep Local Copy

Each destination has a Keep local copy toggle (default on). When off, the local archive is removed once it has uploaded to every enabled remote without any upload failure.

Remote Retention Pruning

RetentionManager is the single retention authority and prunes remote copies as well as the local one. When a record is pruned by age or count it deletes the DB row, unlinks the local archive and its log, and deletes the archive from every currently enabled remote destination for that profile. Remote deletion is idempotent and best-effort — a failure is logged but never blocks local pruning. The shared standalone restore.php is intentionally never pruned from remotes.

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Backup Types

Set on the profile's General tab (default full):

Default Profile

The component-wide default profile (Options > General, defaults to profile 1) is what runs when a trigger doesn't name a specific profile — including the pre-update / pre-uninstall full-screen backup, the dashboard Backup Now screen, and a web-cron call with no profile_id.

Profile Tabs

• General: title, description, backup type
• Archive: format (zip, tar.gz, 7z), compression level, split size, backup directory, archive name format, Include MokoRestore (None / Wrapped / Standalone), encryption password
• Sanitization: scrub the DB dump — sanitize passwords (with preserve super admin), sanitize emails, sanitize sessions
• Filters: exclude directories, files (glob wildcards, e.g. *.bak), and database tables
• Retention: per-profile overrides of the global cleanup age/count (a value of 0 falls back to the global default)
• Notifications: email recipients, notify user groups, notify on success/failure, plus ntfy topic/server/token

Remote Destinations

Off-site upload is configured per profile with remote destinations (SFTP, FTP, S3, Google Drive). The Keep local copy setting lives in each destination's Add/Edit modal and controls whether the local archive is removed after a fully successful upload to every enabled remote. See Remote Storage.

Differential Backups

Compares the current filesystem against a manifest from the last full backup; only new/modified files are included, while the database is always fully dumped. Falls back to a full backup if no base manifest exists.

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

Installation

1. Download the latest pkg_mokosuitebackup-*.zip package from Releases
2. Go to System > Install > Extensions in the Joomla Administrator
3. Upload the package ZIP (or use Install from Folder / Install from URL)
4. The single package installs the component, all plugins, the admin module and the CLI/Web Services resources in one step, and auto-enables its plugins
5. Wait for the postflight to complete — the installer verifies that every bundled child extension actually registered and that the component's schema tables exist, and reports an error rather than a false "installed successfully" message if anything is missing

Package Contents

Requirements

• Joomla 6.x or later (Joomla 4/5 supported; Scheduled Tasks need 4.1+)
• PHP 8.3+ required (Joomla 6)
• MySQL 8.0 or MariaDB
• PHP extensions: ext-zip, ext-curl, ext-ftp, ext-mbstring, ext-pdo_mysql

First Backup

1. Navigate to Components > MokoSuiteBackup (the admin Backup menu, with Dashboard, Backup Records, Content Snapshots and Backup Profiles)
2. A default backup profile is pre-configured
3. Open Dashboard, select the profile from the dropdown and click Backup Now
4. A full-screen backup screen runs the stepped backup with a real-time progress bar; on completion a View backup record button links to the new record

Post-Install Options

Several capabilities are Super User only and off by default. Open Components > Backup > Options to enable Backup before update / Backup before uninstall, Allow Snapshot Injection (on a receiving/slave site), confirm the Default profile and backup directory, and set email/ntfy notifications.

Documentation

Full documentation is on the MokoSuiteBackup Wiki.

Details

Last Updated: July 14, 2026

• Applicable Software: MokoWaaS (Joomla)
• Applicable Version: 02.64.00

What is MokoSuiteBackup?

MokoSuiteBackup is a comprehensive backup and restore solution for Joomla 6 (Joomla 4/5 supported), built as a complete replacement for Akeeba Backup Pro. It provides full-site backups (database + files), multiple backup profiles, scheduled tasks, remote storage (FTP, Google Drive, S3), AES-256 encryption, content snapshots, automatic backup-before-update protection, and a standalone restore script.

Key Features

• Full, database-only, files-only, and differential backup types
• Multiple backup profiles with independent settings
• Backup before update & uninstall — a full-screen backup fronts Joomla core updates and any extension update or uninstall, so you always have a fresh restore point without white-screening large sites. An opt-in auto-continue checkbox (on by default) hands back to the update the moment the backup finishes; a prominent “do not close or switch windows” warning and a full-screen “update is running” overlay guard the process; and you can Cancel at any time (double-confirmed). If the pre-update backup fails, the update is blocked — you retry the backup or go back without updating
• Content snapshots & transfer — capture articles, categories and modules and move them between sites as a portable .msbsnap file, or push them master→slave directly via the injection API
• Joomla Scheduled Tasks integration plus web-cron for automated backups
• Remote storage: FTP/FTPS, Google Drive, Amazon S3 (+ Wasabi, B2, MinIO), with retention that prunes remote copies too
• AES-256 archive encryption for GDPR compliance
• MokoRestore standalone restore script for bare-server restores
• SHA-256 integrity verification
• Email and ntfy notifications on success, warning and failure
• REST API compatible with the MokoSuiteBackup MCP server
• AJAX step-based engine for shared hosting
• One-click Akeeba Backup Pro migration and JPA archive import
• Admin dashboard status widget

Documentation

Full documentation is available on the MokoSuiteBackup Wiki.