User guide

Protected in six steps

Most sites need about 10–15 minutes of setup. Use the defaults for the first run; tune exclusions and retention after you have one verified restore point.

Requirements

Install and activate

1. Get the plugin.

   The free build, Okleone Backups, comes from the wordpress.org directory: in your WordPress admin open Plugins → Add New Plugin, search for Okleone Backups, and select Install Now, then Activate; that is the whole install, and updates arrive on the same screen. To upload a file instead, the listing at wordpress.org/plugins/okleone-backups has a Download button that gives you okleone-backups.<version>.zip. With a premium licence, take wp-allbackup.zip from the customer portal under Downloads instead. Keep any file you upload zipped.

2. Uploading a ZIP: open Plugins → Add New Plugin → Upload Plugin.

   Choose the ZIP you downloaded, select Install Now, then Activate Plugin. Skip this step if you installed from the directory search.

3. Open the plugin in the WordPress menu.

   The menu carries the name of the build you installed: WP-AllBackup for the premium build, Okleone Backups for the free one. Everything inside is the same, and the Plugins screen lists each under the same name. If the menu is missing, confirm you are signed in as an Administrator and that activation completed.

4. Check the top of the page for warnings.

   Fix a non-writable or publicly accessible backup directory before keeping real backups there.

Connect your licence

1. Open WP-AllBackup (Okleone Backups) → Licence / Addons.

   This tab holds the licence, the account it belongs to, covered-site count, expiry, and managed-storage allowance.

2. Select Connect to your account.

   Sign in to the customer portal, choose the licence, and approve this site. There is no key to copy in the normal flow.

3. Return to WordPress.

   Confirm the card says Active and shows the expected plan and site usage. Standard, Business, and Agency show used sites against their limit; Enterprise says connected, no limit. Use Check now after changing a licence in the portal.

Use the customer portal

The portal is the account side of WP-AllBackup (Okleone Backups). Use it for licences, connected sites, storage, downloads, billing, and support; use the WordPress plugin for backup and recovery work on a site.

1. Dashboard: licence and billing.

   See the plan, masked key, connected-site allowance, expiry, subscription status, receipts, and any available cancellation or refund action.

2. Sites: connections and rescue access.

   Review the sites using a licence, disconnect a site you no longer control, and open a mirrored Rescue Protection entry when one is available.

3. Storage and Downloads.

   See managed-storage use and packages under Storage. Downloads holds the current install ZIP for a fresh WordPress site.

4. Support: keep the conversation together.

   Select New request, choose the closest category, and include the exact error and diagnostic reference. Replies and status stay in the same request.

5. Account: protect your sign-in.

   Keep the email current, use a unique password, and sign out on a shared computer. Staff accounts require two-factor authentication.

Connect storage

Keep a local copy for fast recovery and at least one independent off-site copy for a server failure. WP-AllBackup Storage is the simplest premium option; your own storage remains supported.

1. Open Targets.

   For included WP-AllBackup Storage, select Connect. For another service, select Add target.

2. Name the destination clearly.

   Examples: “S3, production backups” or “SFTP, off-site copy.” The name appears in policies and restore points.

3. Authorize or enter limited credentials.

   Dropbox, OneDrive, and Google Drive use provider sign-in, and each of those three allows one target per provider: once it is added, the dialog greys that provider out, and Reconnect on its row signs in again or switches the account. S3, Azure, SFTP, and FTP use the fields supplied by that provider, and can have as many targets as you like.

4. Test before saving.

   Do not schedule a target that does not say Connected. For SFTP, compare the presented host fingerprint with your provider's published value.

5. Disconnecting is not deleting.

   If you disconnect WP-AllBackup Storage, your existing archives stay readable for the period shown on the Targets card, so a restore you had planned still works. New backups stop going there straight away. The space is released when that period ends.

Schedule backups

1. Open Policy and edit the active policy.

   Only one policy runs at a time. Additional policies may be kept for later.

2. Choose a frequency and time window.

   Daily is a practical starting point for a normal business site. Busy stores may need more frequent database backups.

3. Choose what to include.

   Database, plugins, themes, uploads, and other content form the recoverable site. Exclude rebuildable caches and old backup folders.

4. Choose retention and destinations.

   Select the main target and, when useful, a second copy target. Retention must fit the available space.

5. Confirm the policy says Active.

   The Backup / Restore tab shows the next expected run. A cron warning means the time is only a promise until the scheduler is repaired.

Take and verify the first backup

1. Select Backup Now.

   Leave database and all file groups selected for the first run. Select Full file backup when the package must stand alone for migration.

2. Choose destinations.

   Tick the local target if you keep one, and the off-site target that should receive this copy. A backup needs at least one ready destination.

3. Wait for the job to finish.

   Keep the page open while it reports progress. If it stops, reload the page; resumable work should continue rather than silently start over.

4. Read the restore-point row.

   Confirm Complete, expected components, reasonable sizes, and the intended Target/Copy.

5. Open View log if anything differs.

   A backup is not successful merely because some archives exist. The final row and log must report completion.

Restore a site or component

1. Select exactly one restore point and choose Restore.

   Choose the local or remote copy to read from.

2. Select the components.

   Restore only what is broken when possible. A database restore can roll back orders, posts, users, and settings made after that backup.

3. Run Verify archives.

   The wizard checks the entire required backup chain and refuses missing or damaged data before touching the live site.

4. Review the preflight.

   Read path, database-prefix, collation, disk-space, and package warnings. Stop if the source is not the site or date you expect.

5. Confirm and wait for Finished.

   The restore runs in short, resumable requests. If the browser loses contact, reopen WP-AllBackup (Okleone Backups) and continue rather than starting another restore. Afterward, test the home page, admin login, forms, recent content, and permalinks. Clear caches only after the checks.

Restore a managed backup from another site

Use this when the source and destination are covered by the same licence and the source backup is still in WP-AllBackup Storage. The destination reads the backup without copying cloud credentials or taking ownership of the source site's storage folder.

1. Confirm both sites are on the same licence.

   Connect WP-AllBackup Storage on the destination with its own site connection. Each site keeps its own identity and folder even though the licence allowance is shared.

2. Open Backup / Restore and select Rescan remote storage.

   Select WP-AllBackup Storage, then tick Also look in the other sites on this licence. Leave it unticked for an ordinary rescan of only this site's folder.

3. Find the imported restore point.

   The row says Imported, names the source site, and keeps the original Full or Incremental and encryption badges. Use the origin filter when the history is long.

4. Add the recovery key if the row says Encrypted, no key.

   On the source, retrieve the recovery key from Settings → Encryption and move it through a password manager or another secure channel. On the destination, use Add a recovery key from another site. Never put the key in a ticket, email, or screenshot.

5. Restore through the normal wizard.

   Choose WP-AllBackup Storage as the copy to read, verify every archive, review the source and preflight, then confirm. The destination keeps its own site URL, database prefix, licence, instance, and encryption setting.

6. Remove the imported row when it is no longer needed.

   Deleting a restore point imported from another site removes destination metadata and local copies only. The source site's remote objects remain under the source site's control.

Create a staging site

Staging is part of the premium plan. On a free site the Staging tab says so and links to the licence tab and the plans; copies you made while licensed stay on your server if the licence lapses.

1. Open Staging and enter a short folder name.

   Keep Require a login enabled unless the copy must be publicly reviewed.

2. Decide whether to copy or link uploads.

   Copying is safer. Linking is faster and smaller, but deleting or replacing linked media also changes the live site's media.

3. Select Check required space.

   Create remains disabled until the preflight confirms files, database tables, routing, and free disk.

4. Create and wait for Ready.

   Use Open admin and confirm the red STAGING identity before changing anything.

5. Pull from live when the copy goes stale.

   Pull replaces the copy’s files, tables and settings with the live site as it is today, keeping the same address and settings. Changes made on the copy are lost, and the confirmation says so; the live site is only read. A copy whose build failed can be pulled to retry it.

6. Push to live when the copy holds work you want to keep.

   A push always asks what to move: files (changed only, or everything, with an off-by-default option to delete live files the copy no longer has) and database tables (all, or a picked set). Preview what would move, then type PUSH. A restore point of what the push touches is taken first, the tables land in one atomic swap with the previous ones set aside, and you keep the push or roll it straight back after looking at the site. WP-AllBackup’s own settings, storage accounts and history on the live site are never overwritten.

7. Delete the copy when finished.

   Deletion removes the owned directory and staging tables. Reload and confirm the row is gone.

Both directions ask before they act. Pull replaces the whole copy and confirms with a click, because the copy is disposable. Push writes to the live site, so it always asks what to move, previews it, takes a restore point first, and wants the word PUSH typed. Nothing moves that the preview did not list, and an undecided push is kept automatically after 48 hours with the previous tables held aside until then.

Migrate to another site

1. On the source, take a Full file backup.

   An incremental package cannot migrate by itself unless every earlier member of its chain travels with it. On a free site every file backup is already a full one.

2. Install WP-AllBackup (Okleone Backups) on the destination.

   Do not delete the old site yet. Keep both reachable during verification.

3. Make the package visible at the destination.

   For WP-AllBackup Storage on the same licence, use the explicit other-sites rescan. For another remote target, connect it and Rescan remote storage; or download the archives and manifest from the source and use Upload backup files; or copy them into the destination backup directory and Rescan local.

4. Open Migrate and choose the package under Bring another site here.

   Run the dry-run analysis. Review source URL, destination URL, paths, table prefix, and serialized-data-safe replacements.

5. Run the migration in maintenance mode.

   The rewrite is paced in short batches. Reopen WP-AllBackup (Okleone Backups) to Continue if the browser or PHP request is interrupted.

6. Verify before changing DNS or deleting the source.

   Test admin login, pages, images, forms, redirects, cron, cache, and storage. Activate the destination with its own licence slot.

   If the source used WP-AllBackup Storage, the copy cannot use it until you press Connect on the copy. A copied site carries the original's saved connection, and using it would let the copy write into the original's backups, so it is refused until the copy connects for itself.

Upload backup files

A WP-AllBackup (Okleone Backups) backup is a handful of files: one archive per component (backup_…-plugins.zip, backup_…-db.sql.gz and so on) and a manifest_….json that lists them. If you have those files, from another site, from a download you kept, or from storage this site cannot reach, the Backup tab can take them and turn them back into a restore point. There is no need for the two sites to share cloud storage, and nothing to copy over SFTP.

1. Get the files.

   On the source site, each entry in the Contents column of the restore points list is a download link, and the Manifest link beside them downloads the manifest. From cloud storage, download the archives and the manifest of one backup set into the same folder.

2. Open the Backup tab and select Upload backup files.

   Drop the whole set onto the dialog, or choose the files. Anything that is not a WP-AllBackup (Okleone Backups) backup file is refused on the spot by name; nothing is sent for it.

3. Select Upload and read the rows.

   Each file is sent in small pieces sized for the host, so the host's upload limit does not matter however large the archive. A file already in the backup directory is not sent again. If the connection drops or you close the tab, open the dialog again with the same files: it continues from where it stopped.

4. Read the outcome.

   When the manifest and every archive it names are present, the restore point is imported and appears in the list with an Imported badge. A set made on another site says which host it came from and is listed on the Migrate tab as a package. A manifest still waiting for an archive says which file it is waiting for, and archives whose manifest has not arrived yet say so.

Arm Rescue Protection

1. Open Settings → Recovery and housekeeping.

   Enable Rescue Protection. Enable portal mirroring if you want the recovery entry available from your account while WordPress is down.

2. Save settings, then open Advanced Tools.

   Confirm the console and crash pages are installed. Regenerate the access key if it may have been exposed.

3. Store the break-glass details securely.

   Use a password manager. Do not place them in a ticket, shared note, screenshot, or public repository.

4. Test before an emergency.

   Open the console address in a private browser session, confirm authentication, and close without running repair actions.

When WordPress or the database cannot load, the standalone console can inspect status and logs, disable a broken plugin, switch theme, or restore a verified backup. If another plugin owns WordPress's crash-page files, that page may remain while other rescue channels continue.

Free up space

Two tools under Advanced Tools → Tools, one for the database and one for the disk. Both answer the same question from different sides: what is this site carrying that nothing reads any more? Neither is part of backing up, and neither is reversible without a backup, so treat both as an edit to the site rather than as maintenance.

Database cleanup

1. Open Advanced Tools → Database cleanup and select Scan.

   The cards start empty on purpose. Counting things like duplicated metadata means reading a whole table, which is real work on a large site, so nothing is counted until you ask. The scan runs in short steps and fills the cards in as it goes.

2. Read the counts, then tick what you want removed.

   The items nothing would miss are ticked for you: spam, trashed comments, auto drafts, expired caches, and metadata belonging to posts, comments, users or terms that no longer exist.

3. Decide about the four that are not ticked.

   Post revisions are the only copy of what a page said before the last edit. Trashed posts are content someone may still want back. Unapproved comments are unread mail rather than litter. Optimize tables is a different kind of work, described below. None of these are wrong to remove; they are wrong to remove without looking.

4. Confirm, then select Clean selected.

   Removal runs in short steps and reports what went. Posts and comments are removed the way WordPress removes them, so their metadata and category links go with them instead of becoming the next set of orphans.

What the autoload summary is telling you

Below the cards is a list of the options WordPress loads on every single page request, for every visitor, whether the page needs them or not, largest first. It is the one number on the screen that visitors feel rather than one that merely takes up room, and anything much past 800 KB is worth acting on.

Nothing in that list is offered for deletion, deliberately. Only the plugin that wrote an option knows whether your site still needs it, and a cleaner that guesses breaks sites. Treat it as evidence instead: if one plugin owns the top of the list, that is the plugin to ask about, reconfigure, or replace.

File cleanup

1. Select Scan files.

   The scan measures sizes and changes nothing. It runs in short steps so it cannot time out on a large site, and the page reloads into the finished report.

2. Start with the folder table, not the findings.

   It shows where the disk actually went, one level deep and two levels inside plugins, themes and uploads, so you get plugins/some-slider: 780 MB rather than a useless plugins: 900 MB. The answer is very often one plugin, one forgotten archive, or one cache nobody has swept in a year.

3. Review the findings.

   Leftover archives and database dumps, log files, editor and operating-system leftovers, and page cache directories. Each is listed with its size and its date, largest first.

4. Tick and remove, or empty a cache directory.

   Ticks are yours to make; nothing is pre-selected. Emptying a page cache is safe (everything in it is rebuilt on demand), but the first few page loads afterwards will be slow.

Encryption

Off by default. Switch it on under Settings → Encryption and every new backup is encrypted on your own server before it is stored anywhere, the local disk included. Each archive and the database dump become AES-256-GCM ciphertext; whoever holds the files afterwards, a cloud provider, your host, or WP-AllBackup Storage, holds something they cannot read. Backups made before you switched it on are left exactly as they were.

1. Settings → Encryption → Switch on encryption.

   A key is made on this server and the card shows your recovery key: WPAB1- followed by eight groups of eight letters and digits. Copy it into your password manager or print it, tick "I have written the recovery key down", and press Done. Until you do, the card keeps reminding you.

2. Back up as usual.

   Every archive is sealed the moment it is written and before anything is uploaded, so the storage targets only ever see .enc files. The restore points list marks encrypted sets with an ENCRYPTED badge, and the manifest that lists a backup’s files stays readable, so listings, rescans, uploads and imports keep working without the key.

3. Restore as usual.

   Restores decrypt on this server as they read; the decrypted copy lives inside the backup directory for the length of the restore and is removed when it ends. The dry-run check says in words if a set was encrypted with a key this site does not hold.

4. Bringing an encrypted set to another site.

   Rescan or upload it there as usual, then paste the source site’s recovery key into "Add a recovery key from another site" on the destination’s Encryption card. The badge changes from ENCRYPTED, NO KEY to ENCRYPTED and the set restores or migrates like any other. The imported key opens that source package; it does not switch on encryption or become the key for new destination backups.

When WordPress will not load

The rescue console lists encrypted archives like any other and asks for the recovery key on the restore row; it opens the archive with the plugin’s own code, so the plugin files need to be on the server. And for any machine with PHP, bin/wpab-decrypt.php in the plugin folder turns a downloaded .enc back into the ordinary zip or database dump: php wpab-decrypt.php backup-file.zip.enc backup-file.zip, and it asks for the key.

Permissions and safety

Protect a backup folder inside the web root

The best fix is moving the folder outside the public directory. Apache and IIS can read the deny files shipped by the plugin; nginx and Caddy need a server rule.

After changing server configuration, use the plugin's exposure check. A direct request must return a refusal, never an archive or directory listing.

Troubleshooting

Before opening a support request

• Copy the final plain-language error
• Note the failed action and time
• Open Advanced Tools diagnostics
• Use the diagnostic report reference
• Keep the affected restore point
• Remove passwords, keys, and secrets