Documentation

Everything you need to install, configure and use Nota Backup & Restore.

Installation

Nota Backup can be installed just like any other WordPress plugin.

Method 1: WordPress Admin Dashboard

  1. Log in to your WordPress admin dashboard.
  2. Go to Plugins → Add New.
  3. Search for Nota Backup & Restore .
  4. Click Install Now, then Activate.

Method 2: Manual Upload

  1. Download the plugin ZIP file from your account on wp-nota.com.
  2. Go to Plugins → Add New → Upload Plugin.
  3. Choose the ZIP file and click Install Now.
  4. Click Activate Plugin.

Method 3: FTP/SFTP

  1. Unzip the plugin file on your computer.
  2. Upload the nota-backup-restore folder to /wp-content/plugins/ via FTP.
  3. Go to Plugins in your WordPress admin and activate it.
💡 Requirements: WordPress 5.6+, PHP 7.4+, MySQL 5.6+. The ZipArchive PHP extension is recommended but not required (PclZip is used as fallback). OpenSSL is required for encryption.

License Activation

After purchasing a license from wp-nota.com, you'll receive a license key by email.

  1. Go to Nota Backup → Settings → General.
  2. Enter your license key in the License Key field.
  3. Click Activate License.

Your license allows the plugin to receive automatic updates. Without an active license, the plugin continues to work but won't receive updates.

Your First Backup

Creating your first backup is simple:

  1. Go to Nota Backup in your WordPress admin sidebar.
  2. Choose a backup type: Full, Database Only or Files Only.
  3. Optionally nota-check a cloud destination to upload the backup automatically.
  4. Click Start Backup.
  5. Watch the progress bar — your backup will complete without any timeouts.

The backup ZIP is saved to /wp-content/uploads/nota-backup-restore/ and listed in the Backups table below.

Manual Backup

The main Nota Backup page lets you create backups on demand.

Available Options

  • Cloud destinations: Check any cloud service to upload after backup.
  • Backup Type: Full site, database only, or files only.
  • Notes: Add a description (e.g. "Before plugin update") for easy identification later.

Backups are processed in chunks — each AJAX request adds a batch of files to the ZIP. This means you can safely close the browser tab after starting a backup; the process will continue via WordPress cron.

Selective Backup

Nota Backup supports three backup modes:

  • Full: Files + database in one ZIP. Use this for a complete site backup.
  • Database Only: Only the MySQL database is exported. Ideal for frequent DB backups between full site backups.
  • Files Only: Only WordPress files are archived, without the database. Useful when you've made theme/plugin changes and want to save them quickly.
⚠️ Important: Files-only backups cannot be restored via the Admin Panel Restore feature. Use the standalone installer for files-only restores.

Scheduled Backups

Configure automatic backups under Settings → Auto Backup.

  • Frequency: Daily, weekly or monthly.
  • Backup Hour: Choose what time of day backups run (UTC).
  • Backup Type: Set the default type for scheduled runs.
  • Cloud Targets: Enable any cloud service to upload automatically.
  • Auto-delete local: Remove local backup file after successful cloud upload to save disk space.
  • Max Backups: Oldest backups are automatically deleted when the limit is exceeded.

Exclusion Rules

Under Settings → Exclusions, you can define paths to skip during backup.

Enter one path per line, relative to your WordPress root. Examples:

/wp-content/uploads/videos
/wp-content/uploads/large-images
/wp-content/custom-large-folder

The following directories are automatically excluded without any configuration:

  • /wp-content/cache (W3 Total Cache, WP Rocket, WP Super Cache)
  • /wp-content/uploads/cache
  • /wp-content/et-cache (Divi)
  • /wp-content/wpo-cache (WP Optimize)
  • /wp-content/breeze-cache
  • The Nota Backup backup directory itself

Backup Encryption

Enable AES-256 encryption under Settings → General → Backup Encryption.

  1. Check Enable AES-256 encryption for all backups.
  2. Enter a strong password in the Encryption Password field.
  3. Click Save Settings.

When encryption is enabled, the database.sql file inside each backup ZIP is encrypted using AES-256-CBC. The encrypted file is saved as database.sql.enc. The ZIP file itself remains unencrypted, so you can still see the file list.

⚠️ Critical: If you lose your encryption password, encrypted backups cannot be restored. Store your password in a secure password manager.

The password is stored encrypted in the WordPress database using your WordPress secret keys as the cipher key — so it's not stored in plain text.

Google Drive

Go to Settings → Google Drive to connect your account.

  1. Enter your Google OAuth2 Client ID and Client Secret. (You'll need to create a project in the Google Cloud Console.)
  2. Click Authorize with Google and follow the OAuth flow.
  3. Once authorized, select a destination folder using the folder picker.
  4. Optionally enable Auto-upload for scheduled backups.
💡 Tip: You can create a dedicated folder (e.g. "WP Backups") to keep your backups organized.

Amazon S3

Go to Settings → Amazon S3 and enter:

  • Access Key ID and Secret Access Key from your AWS IAM user.
  • Region (e.g. us-east-1).
  • Bucket Name — must already exist in your AWS account.
  • Path Prefix — optional folder inside the bucket (e.g. my-site/backups).

Click Test Connection to verify your credentials, then click Save Settings.

Wasabi

Wasabi setup is identical to Amazon S3. Go to Settings → Wasabi and enter your Wasabi Access Key, Secret Key, region and bucket name.

Wasabi is an S3-compatible service with lower nota-pricing than AWS — a great option for cost-conscious users.

Dropbox

Go to Settings → Dropbox:

  1. Enter your Dropbox App Key and App Secret.
  2. Click Connect Dropbox and authorize the app.
  3. Select a destination folder using the folder picker.

Microsoft OneDrive

Go to Settings → OneDrive:

  1. Enter your Azure App Client ID and Client Secret.
  2. Click Connect OneDrive and complete the Microsoft OAuth flow.
  3. Select a destination folder using the folder picker.

Admin Panel Restore

You can restore any local backup directly from the WordPress admin panel without the standalone installer.

  1. Go to Nota Backup (main page).
  2. Find the backup you want to restore in the Backups table.
  3. Click the ↩ Restore button.
  4. The modal shows the backup's source URL compared to your current site URL. If they differ, a URL override field appears pre-filled.
  5. Choose a Restore Mode (see Partial Restore below).
  6. Type I confirm in the confirmation field and click Yes, Restore.
⚠️ Warning: Admin Panel Restore overwrites your current database and/or files depending on the selected mode. Always create a fresh backup before restoring.

Partial Restore

When opening the Restore modal, you can choose exactly what to restore:

  • Full Restore — Imports the entire database and overwrites files from the backup. Best for disaster recovery.
  • Database Only — Shows a scrollable list of all tables found in the backup. Check only the tables you want to restore. Unchecked tables are skipped entirely.
  • Files Only — Shows the backup's folder tree (e.g. wp-content/, wp-includes/). Select individual folders or files to overwrite on the live server. The database is not touched.
💡 Tip: The table and file lists are read directly from the backup ZIP — so you can restore a table or file that was deleted after the backup was taken.

Files are extracted in chunks of 300 per AJAX request to avoid timeouts on large backups. For encrypted backups, click Load Tables and enter your encryption password to populate the table list for Database Only mode.

Files Only mode is not available in the standalone installer — the installer already extracts all files. Partial file selection is an admin panel–only feature.

Emergency Recovery

Emergency Recovery is a standalone restore page that works completely independently of WordPress. Use it when wp-admin is inaccessible — white screen of death, database errors, a failed update, or a corrupted installation.

Setup

  1. Go to Settings → General → Emergency Recovery.
  2. Set a strong Access Password and click Enable Recovery Page.
  3. The recovery page URL is shown — bookmark it or save it somewhere safe.
⚠️ Security: The recovery page is publicly accessible via URL. Always set a strong, unique password. Disable it when not in use.

How to Restore via Emergency Recovery

  1. Navigate to the Emergency Recovery URL (e.g. https://yoursite.com/?wpbn_recovery=your-key).
  2. Enter your access password.
  3. Select a backup from the list of backups found on the server.
  4. Choose a restore mode: Full Restore, Database Only or Files Only.
  5. For encrypted backups, click Load Tables and enter your encryption password to see the table list.
  6. Click Start Restore and monitor the progress bar.

Restore Modes

  • Full Restore — Extracts all files first (restoring wp-config.php), then imports the database. This order ensures the database connection works even when wp-config.php was missing or corrupted.
  • Database Only — Imports only the selected database tables. Files are not touched. Useful for recovering from a bad database migration.
  • Files Only — Extracts only selected files or folders from the backup. The database is not touched. For encrypted backups, enter your password before starting.
💡 Note: Emergency Recovery reads backups from the same folder as the plugin (wp-content/uploads/nota-backup-restore/). The server must be able to serve PHP files from that location. If your hosting restricts PHP execution in wp-content, use the standalone installer instead.

Cloud Pull — Copy Backup from Cloud to Server

If a backup was uploaded to cloud storage and the local file was deleted (e.g. with auto-delete enabled), you can pull it back to your server without leaving the admin panel.

  1. In the Backups table, find the cloud-only backup (shown with a cloud badge such as Drive, S3, Wasabi, etc.).
  2. Click the cloud badge button.
  3. A modal opens with a note explaining the action and a link to open the file directly in your cloud storage.
  4. Click Copy to Server.
  5. The backup ZIP is downloaded in 8 MB chunks directly to your server's backup folder. A progress bar shows real-time download progress.
  6. Once complete, the page reloads and the backup is available locally for restore or download.
💡 Note: Cloud Pull only copies the ZIP file to your server. It does not restore or overwrite any WordPress files or database. After pulling, use the normal Restore button to restore the backup.

Supported providers: Google Drive, Amazon S3, Wasabi, Dropbox, Microsoft OneDrive. If a backup exists both locally and in the cloud, clicking the badge opens the cloud storage link directly instead of showing the pull modal.

Migration Installer

Each backup ZIP contains a standalone installer.php file. This installer works completely independently of WordPress — perfect for restoring when WordPress is broken, or migrating to a new server.

How to use the installer:

  1. Download your backup ZIP file.
  2. Extract all contents to your server's document root (or a subfolder).
  3. Navigate to https://yoursite.com/installer.php in your browser.
  4. Fill in the database credentials for your new/target server.
  5. Enter the new site URL if you're migrating to a different domain.
  6. Click Start Installation and wait for completion.
💡 Security: After successful restore, delete installer.php from your server immediately. The installer is a powerful tool and should not be left publicly accessible.

Site Migration

Nota Backup makes migrating WordPress sites straightforward:

  1. Create a full backup on your source site.
  2. Download the backup ZIP.
  3. Upload your WordPress files to the new server (or use the files from the ZIP).
  4. Extract the backup ZIP contents to the new server.
  5. Open installer.php in your browser.
  6. Enter new database credentials and the new site URL.
  7. The installer will automatically replace all URLs and file paths — including inside serialized data.

Staging

Staging lets you create a full working copy of your live WordPress site in a subdirectory or on a separate database. Make changes safely, then push them back to live when you're ready.

Creating a Staging Site

  1. Go to Nota Backup → Staging.
  2. Click Create Staging Site.
  3. Choose a mode:
    • Full Isolation — A completely separate database and files in a subdirectory. Nothing on the live site is shared. Recommended for major changes.
    • Shared Database — Files copied to a subdirectory, but staging uses the same database with a different table prefix. Faster to create; use for theme/layout testing.
  4. Enter the destination subdirectory (e.g. staging) and the staging database credentials if using Full Isolation.
  5. Click Create. The plugin copies the database, copies files, then replaces all URLs and file paths in the staging database.

Progress is shown in phases: Copy Database → Copy Files → Update URLs → Done. You can safely close the browser tab — the process continues in the background and will resume when you return.

💡 Tip: Staging creation can take several minutes on large sites. The URL replacement phase iterates over every text column in every database table to ensure serialized data is handled correctly.

Accessing Your Staging Site

Once complete, the staging URL is shown (e.g. https://yoursite.com/staging/). The staging site is protected by an access key — share this key only with trusted collaborators.

⚠️ Warning: Do not use the staging site for production traffic. It shares the same server resources and is not hardened for public access.

Pushing Staging to Live

  1. On the Staging page, click ⚡ Push to Live.
  2. Choose what to push: Database Only, Files Only or Full Push.
  3. The plugin copies the staging database back to live, replaces all staging URLs with live URLs (reverse replacement), then copies any changed files.
  4. A backup of the current live database is taken automatically before the push begins.
⚠️ Warning: Pushing to live overwrites your production site. Always verify your staging changes are correct before pushing. The automatic pre-push backup can be used to roll back if needed.

Deleting a Staging Site

Click Delete Staging on the Staging page. This removes the staging subdirectory and, for Full Isolation mode, drops all tables in the staging database. The live site is not affected.

General Settings

Go to Settings → General to configure:

  • Maximum Backups to Keep: Number of local backups retained before old ones are deleted.
  • ZIP Chunk Size: How many MB of files are processed per AJAX request. Reduce on low-memory servers.
  • Backup Encryption: Enable AES-256 encryption for all backups.

Email Notifications

Go to Settings → Notifications to configure:

  • Email Address: Where to send notifications. Leave blank to use the WordPress admin email.
  • On Success: Receive an email after every successful backup.
  • On Failure: Receive an email when a backup fails (recommended).
  • Test Email: Send a test notification to verify your email setup is working.

Stale Backup Alert

Under Settings → Notifications, you can enable an automatic alert if no successful backup has been created within a configurable number of days.

  • Enable the "Alert if no backup in the last X days" option.
  • Set the threshold (e.g. 7 days).

Nota Backup checks daily (via WordPress cron) whether any backup — manual or scheduled — has completed successfully within the configured window. If not, an alert email is sent to your configured notification address.

The alert considers both manual and scheduled backups. A repeat alert is suppressed for 23 hours to avoid inbox flooding if the issue persists.

💡 Use case: If your scheduled backup silently stops working (e.g. WP-Cron is disabled by your host), the stale alert will notify you within the configured number of days so you can investigate.

Troubleshooting

Backup gets stuck / doesn't finish

The plugin uses heartbeat detection to identify stuck backups. If a backup has no activity for 10 minutes, it's automatically marked as failed and logged in the backup history. You can then start a new backup.

To prevent backups from getting stuck:

  • Reduce the ZIP Chunk Size in General Settings (try 5 MB).
  • Add large files/folders to Exclusion Rules.
  • Make sure WordPress cron is working on your server.

Out of memory errors

If you see memory exhaustion errors in the backup history, try:

  • Reducing the ZIP Chunk Size in Settings.
  • Excluding large directories (videos, large uploads) from backups.
  • Asking your host to increase the PHP memory limit to at least 256 MB.

Cloud upload fails

If the backup completes but cloud upload fails:

  • Check your cloud service credentials in Settings.
  • Test the connection using the Test Connection button.
  • Make sure your API keys have the necessary permissions (read + write).
  • Check if your cloud storage bucket/folder exists and has write access.

Installer or restore gets stuck on "Updating URLs"

The URL/path replacement phase iterates over every text column in every database table using cursor-based pagination. On some sites, certain tables (e.g. security plugin file-scan tables) contain binary or non-UTF-8 data in their primary key column. The plugin handles this automatically — if you notice the phase progressing very slowly on a specific table, it is processing rows in batches and will complete.

If progress genuinely stops for more than 15 minutes:

  • Check the backup logs (Nota Backup → Logs) for any error messages.
  • For the standalone installer, the log is shown in the View Log panel at the bottom of the installer page.
  • If a specific table is named repeatedly in the log, you can safely continue — the plugin will move past it after exhausting all rows.
💡 Note: Tables like wp_wffilemods (Wordfence) may contain binary filenames as primary keys and can slow down the replace phase. This is normal and does not indicate an error.

Installer: MySQL TIMESTAMP errors (error 1293)

On older MySQL 5.5 servers, a CREATE TABLE statement with multiple TIMESTAMP columns using DEFAULT CURRENT_TIMESTAMP causes error 1293. The installer detects this automatically and rewrites the problematic statement to be compatible. No action is required on your part — the table will be created correctly.

Installer: "Could not save installer state" error

This error means the installer cannot write its progress file to disk. Possible causes:

  • The directory where installer.php is located does not have write permission. Check that your web server user can write to that directory.
  • The server has reached its disk quota.
  • A security plugin or server rule is blocking file writes. Check your error log for permission-related messages.

Staging: creation stuck or progress bar doesn't advance

Staging creation runs in polling chunks — each AJAX call processes one phase. If the progress bar stops:

  • Check your browser console for network errors. A 504 Gateway Timeout or 502 Bad Gateway usually means the chunk took too long.
  • If you're copying a very large database, the "Copy Database" phase can take several minutes per chunk. This is normal on shared hosting.
  • Refresh the Staging page — the plugin resumes from where it left off.
  • Check Nota Backup → Logs for any PHP error messages written during the stuck phase.

Staging: "Updating URLs" stuck on a specific table count

The same cursor-based URL replacement is used in staging as in the admin restore and installer. If it appears stuck on a specific table (e.g. "108 / 139 tables"), the plugin is processing a large table in batches. Wait a few minutes — it will continue automatically. See the "Installer or restore gets stuck on Updating URLs" section above for more detail.

Staging: push to live doesn't update some pages

After a push to live, some cached pages may still show old staging content.

  • Clear your caching plugin (W3 Total Cache, WP Rocket, LiteSpeed Cache, etc.).
  • Clear any CDN cache if you use one.
  • Clear your browser cache with Ctrl+Shift+R (or Cmd+Shift+R on Mac).

Getting help

If you can't resolve an issue, email us at support@wp-nota.com with a description of your problem, your PHP/WordPress/MySQL version, and any relevant log entries from Nota Backup → Logs.