How to Restore Your Site (Disaster Recovery)

First: which situation are you in?

All three do the same core job: they put your files and database back the way they were in the backup. You only need one of them.

A restore overwrites your current site. It replaces the current files and/or the current database with what was in the backup. That is exactly what you want in a disaster — just know that any changes made after the backup was taken will be gone. If you're not 100% sure the current state is worthless, take a fresh backup first so you can change your mind.

Path A — Restore from the admin panel

Use this when you can still log in to Joomla.

1. Log in to your Joomla administrator and go to Components → MokonyxBackup.
2. Find the backup you want in the list. Backups are listed with their date, so pick the most recent one from before the problem started.
3. Select that backup, then click Restore in the toolbar.
4. Confirm when you see the warning: “WARNING: Restoring will overwrite your current site files and/or database. Are you sure you want to continue?” This is your safety check — nothing is overwritten until you say yes.
5. In the restore options, choose what to bring back. By default you get both:
   • Restore files — your Joomla files (extensions, templates, media).
   • Restore database — your content, users, and settings.
   • Preserve current configuration.php — leave this checked (recommended). It keeps your current database credentials and site paths, so the restored site connects correctly on this server. The label help says it plainly: “Keep your current database credentials and site paths. Recommended unless you know the backup has the correct credentials.”
6. If your backup is encrypted, enter its password in the password field (placeholder text: “Leave blank if archive is not encrypted”). This is the AES-256 password you set on the backup profile — it is required to restore an encrypted archive. See Encrypted backups below.
7. Start the restore. While it runs you'll see “Restore in Progress” — do not navigate away or close this window while the restore is running.
8. Wait for it to finish. You'll get one of: Restore Complete, Restore Complete (with warnings), or Restore Failed. “With warnings” usually means a few non-critical database statements were skipped — the site is still restored.

Verify it worked

1. Open your site's front page in a new tab — check it loads and looks right.
2. Log in to the admin again to confirm your account still works.
3. Spot-check a page or article that you know existed in the backup.

That's it. For most people, Path A is the whole story.

Path B — Restore from the command line

Use this when the admin panel is unusable but you can reach the server over SSH.

MokonyxBackup ships a Joomla CLI command. You restore by the backup's record ID (the ID shown next to each backup in the admin list, or in the CLI backup listing).

1. SSH into your server and change to your Joomla root directory.
2. Run the restore, replacing <id> with your backup's record ID:

   php cli/joomla.php mokonyxbackup:restore <id>

3. It will show the archive path and type and ask you to confirm before doing anything destructive: “This will overwrite the current site files and/or database. Are you sure you want to continue?” Answer yes to proceed.
4. When it finishes you'll see a success message, or a clear error explaining what stopped it (for example, the backup isn't marked complete, or the archive file is missing).

Handy options

Add these flags to the command when you need them:

Example — restore only the database from an encrypted backup with ID 42:

php cli/joomla.php mokonyxbackup:restore 42 --db-only --password "your-encryption-password"

Path C — The standalone restore.php wizard

Use this when the site is completely down, or when you're rebuilding on a fresh or empty server. This wizard is self-contained — it does not need a working Joomla to run.

You need two files on the target server, side by side in the web root:

restore.php        (the MokonyxRestore wizard)
site-backup.zip    (your backup archive)

Where does restore.php come from? How the restore script travels with your backup is set per destination in MokonyxBackup (None, Inside the archive, or Outside as a separate file). If it was delivered Outside, you already have a separate restore.php beside the archive. If it was delivered Inside, it's wrapped in the archive. For the full breakdown, see the companion article “MokonyxBackup Restore & MokonyxRestore.”

Step by step

1. Get both files onto the host. Upload restore.php and your backup .zip into the web root (the folder your domain serves) using SFTP, your host's File Manager, or however you normally move files.
2. Open restore.php in your browser — e.g. https://yourdomain.com/restore.php.
3. Enter the security code. For safety, the wizard writes a small file named mokonyxrestore-security.txt next to restore.php and asks you to type the code from inside it. This proves you really have access to the server. Open that file (via File Manager or by visiting https://yourdomain.com/mokonyxrestore-security.txt), copy the code, and paste it in.
4. Pre-flight checks. The wizard confirms the server can do the job — PHP 8.3+, the ZipArchive / PDO MySQL / mbstring / JSON extensions, that your .zip is present, that the directory is writable, and that there's enough free disk space. Fix anything flagged red before continuing.
5. Extract. The wizard unpacks the archive. If an existing Joomla install is detected, it asks you to confirm the overwrite a second time before writing any files. If the archive is encrypted, you'll be prompted for the password here.
6. Test the database connection. Enter your database host, name, user, and password for this server. Click to test the connection — you must get a successful connection before the import button unlocks.
7. Import the database. The wizard loads your content and settings from the backup's SQL dump and reports how many statements ran (and any warnings).
8. Configuration. The wizard writes a fresh configuration.php with the database details you just entered, correct paths, and a brand-new secret key. See the note below if your domain or host changed.
9. Admin account. The wizard lists the site's super administrator accounts and, if you need it, lets you reset a super admin password so you can get back in.
10. Cleanup. The final step deletes restore.php, the security file, and the leftover restore artifacts, then offers links to open your restored site and its admin. Always let cleanup run (or delete restore.php yourself) — never leave the restore script on a live server.

If your domain or host changed

Restoring to a new URL (e.g. moving from a temporary domain to the real one, or from staging to production) is the classic cause of a “too many redirects” loop. MokonyxRestore handles the common cases for you:

• Site URL (live_site): leave it blank unless you have a specific reason not to. Joomla then auto-detects the correct address on the new domain. Carrying over the old site's URL across a domain change is what triggers the redirect loop.
• Force HTTPS (force_ssl): the wizard defaults this off on restore. Only turn on “force SSL” once you've confirmed the new host serves HTTPS end-to-end — forcing it before that also causes redirect loops.

Post-restore checks (Path C)

1. Visit the front page and the admin login on the new address.
2. Log in (use the reset password from the admin step if needed).
3. In the admin, clear the Joomla cache (System → Clear Cache) so nothing stale is served.
4. Only after the site loads cleanly over HTTPS should you consider re-enabling “force SSL” in System → Global Configuration → Server.

Encrypted backups

If you set an encryption password on your backup profile, you'll need that same password to restore — there's no way around it, so keep it somewhere safe and separate from the backups. Where you enter it depends on your path:

• Path A (admin): in the password field on the restore screen (placeholder: “Leave blank if archive is not encrypted”).
• Path B (CLI): with the --password (or -p) flag.
• Path C (restore.php): at the Extract step, when the wizard detects the archive is encrypted and prompts you.

Before disaster strikes: test your restore

The best time to find out your backups work is before you need them. Every so often, restore a recent backup to a scratch/staging site and confirm it comes up clean. A backup you've never restored is a hope, not a plan. For the technical details of each restore method, see the companion article “MokonyxBackup Restore & MokonyxRestore.”

Need the internals — exact restore engine steps, delivery modes, security model? See “MokonyxBackup Restore & MokonyxRestore” (technical) and the Restore & Recovery wiki page.