Aegisify Backup, DR & Migrate Product Guide

Version 1.5.6
Updated July 10, 2026
Product: Aegisify Backup, DR & Migrate for WordPress

Publication status: This guide is a documentation draft prepared from a static review of the Aegisify Backup 1.5.6 package and current Aegisify public pages. Complete a production acceptance test before publishing operational promises or recovery-time claims.

1. Product Overview

Aegisify Backup, DR & Migrate helps WordPress administrators create database, file, and full-site recovery packages; restore selected data; move sites between WordPress installations; preserve rollback points before updates; and maintain operational evidence through logs, reports, notifications, and retention controls.

The product is designed for WordPress owners, agencies, ecommerce operators, developers, and technical teams that need a more controlled backup and recovery workflow than an occasional manual export. Its strongest value is not merely creating archives. It is giving administrators a structured way to decide what to protect, define how often it should be protected, verify completed packages, restore carefully, and document what happened.

A backup is not proof of recoverability. A recoverable program combines successful backup creation, protected storage, documented retention, regular restore testing, controlled access, and a clear recovery procedure.

2. What This Guide Covers

This guide explains the reviewed 1.5.6 administration experience:

• Dashboard and operational status
• Full Backup and disaster-recovery packages
• Database overview and database tools
• Full-table and selected-column backups
• Minute, daily, weekly, and monthly scheduling
• File backup plans
• Restore workflows
• Push/pull Transfer Wizard
• Standalone Migration Wizard runner
• Remote storage
• SMTP, email alerts, and signed webhooks
• Before Updates rollback snapshots
• Logs, reports, retention, pruning, and licensing
• Operational runbooks, troubleshooting, and recovery planning

3. System Requirements

Before deployment, confirm PHP execution time, memory, upload size, disk space, database privileges, file permissions, cron behavior, and outbound network access.

4. Important Safety Principles

4.1 Test recovery, not only backup creation

A successful package does not prove that the package can restore the site under production conditions. Maintain a non-production restore target and test representative recovery scenarios on a defined schedule.

4.2 Keep more than one copy

Do not rely on a single local package stored on the same server as the live site. Use an offsite destination or another independently protected storage location when the business impact justifies it.

4.3 Use maintenance or read-only windows

Database and file content may change while a backup or chunked restore is running. Use a maintenance or read-only window for high-confidence restores, migrations, prefix changes, and other operations that should not compete with live writes.

4.4 Protect recovery interfaces

Backup archives, migration tokens, recovery links, database exports, and standalone restore interfaces are privileged assets. Limit access, rotate temporary credentials, remove temporary recovery surfaces after use, and avoid sharing URLs in tickets or public messages.

4.5 Record ownership

Assign an accountable owner for schedules, offsite storage, restore testing, notification recipients, retention, encryption, and incident recovery.

5. Administration Navigation

The reviewed package organizes the product under the Aegisify Backup administration menu.

Feature availability can depend on the active license. The Free and Pro descriptions below reflect the reviewed 1.5.6 interface and should be reconciled with the production pricing page before publication.

6. Free and Pro Capability Guide

Packaging note: Product packaging can change. Use the License screen and current Aegisify subscription page as the source of truth for the deployed environment.

7. What Is New in Version 1.5.6

Version 1.5.6 substantially strengthens selected-table backup and restore behavior.

Parent and child selection behavior

Selecting a table selects every loaded column. Clearing the table clears the column selection. Selecting only some columns places the table in an indeterminate state so the interface distinguishes a complete table snapshot from a selected-field backup.

Complete table snapshot canonicalization

When every column is selected, the job is treated as a complete table snapshot. The package carries the table schema, field definitions, generated-column behavior, and rows as one recovery unit.

Backup-wide consistency boundary

The table export process attempts one consistency boundary across all selected tables. Transactional InnoDB tables use a shared repeatable-read snapshot. When nontransactional tables are present, the workflow can use shared read locks to reduce cross-table inconsistency.

Stronger package validation

The 1.5.6 workflow adds path validation, SQL-file hash checks, target-database enforcement, fail-closed SQL error handling, row-count verification, selected-field SHA-256 verification, and full-table schema SHA-256 verification.

Safer selected-column restore behavior

A selected-column backup is restored as a selected-field update rather than a full table replacement. This helps preserve unselected fields and reduces the chance that a partial backup overwrites unrelated data.

Overlap prevention

The product prevents concurrent table restore jobs and overlapping restore requests. It also prevents a minute-based scheduled table backup from overlapping an active run of the same plan.

Maintenance-window warning

The restore workflow warns administrators to use a maintenance or read-only window so new live writes do not change the result while a chunked restore is running.

Minute schedules and RPO guidance

Minute-based table schedules support values from 1 to 1,440 minutes. A dependable five-minute recovery point objective requires a server cron trigger that runs WordPress cron at least every minute, enough server capacity, and a backup duration shorter than the selected interval.

8. Installation and Initial Setup

1. Install and activate Aegisify Backup through the approved WordPress plugin deployment process.
2. Confirm that the environment meets the WordPress and PHP requirements.
3. Open Aegisify Backup → Dashboard.
4. Review local disk capacity, backup directory permissions, cron status, remote storage, alert recipients, and license state.
5. Create one small manual database or table backup.
6. Download or move that package to protected storage.
7. Test a restore in a non-production environment.
8. Only then configure recurring production schedules.

For regulated, revenue-critical, or high-change sites, document the configuration and approval before enabling automated operations.

9. Dashboard

The Dashboard is the operational starting point. It consolidates backup posture and recent evidence so an administrator can see whether the system is creating packages and whether attention is required.

Reviewed dashboard functions include:

• Last backup status
• Installed product version
• Remote-storage state
• Email-alert state
• License state
• Quick actions
• Recent backup packages
• Package and activity charts
• Recent package reports
• Retention and package pruning
• Diagnostic log download
• Saved Transfer Wizard connection or fleet information

Recommended daily review

Check the most recent scheduled job, failures, package size anomalies, offsite-transfer status, and available local disk. A sudden reduction in package size can be as important as a failed job because it may indicate an incomplete scope or excluded content.

Retention pruning

The dashboard can prune older packages and keep a defined recent set. Retention should be based on recovery requirements, not only disk pressure. Confirm that offsite copies exist before deleting the only usable package.

10. Full Backup and Disaster-Recovery Packages

A Full Backup / DR package is intended to preserve a broader WordPress recovery point than a table-only or file-only job.

Reviewed package content can include:

• WordPress content files
• Database export data
• .htaccess
• Optional wp-config.php
• Optional WordPress core files
• Environment and package metadata

The database component supports table-per-file export and additional export methods, including PHP streaming and mysqldump where the host provides it.

When to use a full package

Create a full package before:

• Major WordPress core upgrades
• Theme or page-builder changes
• Large plugin deployments
• Hosting migrations
• Database-prefix work
• Incident cleanup
• High-risk configuration changes

Recovery link

The Full Backup workflow can create a separate disaster-recovery link and token. Treat that link as a privileged credential. Store it in an approved secrets or incident-management system, not in public documentation, unsecured email, or ordinary chat.

Full-package limitations

A full package can still be affected by storage exhaustion, host timeouts, file exclusions, database permissions, corrupted downloads, or incomplete transfer. Validate package completion and perform periodic test restores.

11. Database Backups and Database Intelligence

The Database Backups area provides more than a one-click SQL export. It includes an operational view of database size, growth, tables, engines, and activity.

Reviewed database sections include:

• Overview
• Table Backups
• Optimize
• DB Prefix Manager
• DB Snapshots

Database Overview

Use the Overview to inspect:

• Table size
• Row counts
• Storage engine
• Database growth
• Recent database activity
• Large or unexpectedly growing tables

Growth review is especially useful on ecommerce, membership, logging, analytics, and form-heavy sites. Large tables are not automatically defective. Investigate what produces the data, whether it has a retention policy, and whether it is needed for business or audit purposes.

12. Table Backups

Table Backups are designed for granular recovery and tighter recovery-point objectives.

12.1 Create a complete table backup

1. Open Backups → Database Backups → Table Backups.
2. Select the database.
3. Select one or more tables.
4. Confirm that every required column is selected.
5. Review the job name, destination, and retention.
6. Run the job manually or save the schedule.
7. Confirm package completion and verification status.
8. Copy the package offsite when required.

A complete table backup is the appropriate choice when the recovery objective is to recreate the whole table, including schema and all fields.

12.2 Create a selected-column backup

1. Select the table.
2. Clear columns that are outside the required recovery scope.
3. Confirm that the table shows a partial or indeterminate state.
4. Verify that the selected columns include a stable key needed to target existing rows.
5. Save or run the job.
6. Document why only those fields are protected.

A selected-column restore updates selected fields rather than dropping and replacing the full table. It is useful for narrowly scoped recovery, but it is not a substitute for a complete table snapshot.

12.3 Generated columns

Generated database columns are derived from schema logic. The package records schema context so a complete table restore can recreate derived behavior without treating generated values as ordinary writable fields.

12.4 Verification evidence

The reviewed workflow verifies package metadata and SQL content with SHA-256 values. Post-restore checks can compare row counts, selected-field data hashes, and full-table schema hashes.

Hash verification helps detect unintended change or corruption. It does not prove that application-level relationships, business logic, or user-visible behavior are correct. Complete an application test after restore.

13. Table Backup Scheduling and Recovery Point Objectives

Schedules can run by minute interval or on daily, weekly, and monthly patterns.

Five-minute RPO requirements

A five-minute schedule does not automatically deliver a five-minute RPO. The following must all be true:

• WordPress cron is triggered reliably at least every minute
• The backup begins on time
• The backup finishes within the interval
• The package passes completion and hash validation
• Storage and transfer complete successfully
• Retention does not remove the required point
• A restore procedure has been tested

On low-traffic sites, use a server cron rather than relying on visitor-triggered WP-Cron.

14. Database Snapshots

Database snapshots provide a protected database recovery point that can be downloaded, restored, or deleted through the administration interface.

Use snapshots before database optimization, prefix changes, bulk content updates, imports, or other database-sensitive work.

Recommended controls:

• Label snapshots with the change or ticket identifier
• Keep a copy outside the production host
• Restrict download access
• Confirm the target database before restore
• Test after restoration
• Delete temporary snapshots when their approved retention ends

15. Database Optimize

The Optimize area can provide table analysis, optimization, repair, and cleanup-oriented actions.

Optimization is not automatically beneficial for every table or storage engine. Before running it:

1. Create a verified database snapshot.
2. Review the affected tables.
3. Schedule a maintenance window.
4. Confirm available disk and database privileges.
5. Measure the result.
6. Preserve logs for the change record.

Do not remove revisions, transients, logs, sessions, or other records only because they are large. Confirm ownership, retention requirements, and application dependencies.

16. Database Prefix Manager

The DB Prefix Manager supports controlled changes to the WordPress table prefix.

Prefix changes affect database names and WordPress configuration. Treat the operation as a maintenance change:

1. Create and export a full database snapshot.
2. Create a full-site recovery package.
3. Confirm database privileges.
4. Review the preview.
5. Put the site into maintenance mode.
6. Apply the change.
7. Verify login, frontend, cron, REST API, ecommerce, integrations, and scheduled tasks.
8. Retain rollback evidence until acceptance is complete.

Changing the database prefix is not a complete security control by itself.

17. File Backups

File Backups support full or selected WordPress paths through a tree-based selector.

Common file backup scopes include:

• Themes
• Plugins
• Must-use plugins
• Uploads
• Custom application directories
• Configuration or web-server files when explicitly supported

Create a file backup

1. Open Backups → File Backups.
2. Choose the required paths.
3. Review exclusions.
4. Select local or configured remote handling.
5. Run the manual job or save a licensed schedule.
6. Confirm completion and ZIP integrity.
7. Test extraction and representative restore behavior outside production.

Scope guidance

Avoid selecting unnecessary cache, temporary, session, generated, or backup-within-backup directories. Nested backup archives can sharply increase package size and execution time.

Large file sets

Hosts with short execution limits or limited memory may require smaller scopes, lower batch sizes, or multiple plans. Monitor package duration and test under realistic load.

18. Restore Center

The Restore area provides guided recovery workflows for supported backup packages.

Pre-restore checklist

• Confirm the package source and date
• Verify the package hash or integrity evidence
• Confirm the target site and target database
• Create a current rollback package
• Put the site into maintenance or read-only mode
• Stop competing jobs
• Confirm local disk space
• Confirm database credentials and privileges
• Notify business owners
• Define acceptance tests

Restore into an existing installation

The existing-installation workflow uses the current WordPress environment and database configuration. Depending on package type, it can replace supported tables and files, then perform URL, path, or permalink-related adjustments.

Restore into a new database

Advanced recovery can use administrator-supplied database credentials and restore into an isolated database. This should be performed only by a qualified administrator who understands wp-config.php, database privileges, host networking, and rollback.

Post-restore validation

Test at minimum:

• Homepage and key templates
• WordPress login
• Administrator access
• Media
• Forms
• REST API
• Cron
• Email
• Search
• Ecommerce checkout and account flows
• Membership or portal access
• Redirects and permalinks
• Integrations
• Logs and security controls

19. Transfer Wizard

The Transfer Wizard connects a source WordPress site to a destination WordPress site and moves supported backup or file packages through a controlled workflow.

Destination workflow

1. Open the Destination tab.
2. Generate a short-lived connection token.
3. Copy it through a protected channel.
4. Keep the destination page available for monitoring.
5. Revoke or allow the token to expire after use.

The reviewed connection uses an HMAC-signed token and expects HTTPS outside an explicitly configured development condition.

Source workflow

1. Open the Source tab.
2. Enter the destination URL and short-lived token.
3. Test the connection.
4. Select the intended package or file scope.
5. Start the transfer.
6. Monitor live logs.
7. Confirm receipt on the destination.
8. Restore only after validating the destination and package.

Finalization

The destination can produce a migration report and provide a finalization workflow for supported URL or path corrections. Review every automated change before accepting the migration.

Migration acceptance

Before DNS cutover, test the temporary destination hostname and verify content, authentication, ecommerce, forms, email, scheduled tasks, integrations, redirects, security headers, and backups.

20. Standalone Migration Wizard

The Migration Wizard can expose a standalone recovery interface at /aegismw/. It is intended to operate without loading the normal WordPress application during database overwrite.

Critical deployment warning: Treat /aegismw/ as a privileged, temporary maintenance surface. In the reviewed 1.5.6 package, the standalone runner should not be considered sufficiently protected by the plugin alone. Keep it disabled except during a controlled recovery, add host-level authentication or an IP allowlist, monitor access, and disable or remove it immediately after use.

Safe operating procedure

1. Prepare the backup and recovery plan before enabling the runner.
2. Restrict the path at the web server, control panel, reverse proxy, or hosting firewall.
3. Use a maintenance window.
4. Enable the runner only when the authorized operator is ready.
5. Complete the upload and restore.
6. Save the recovery report.
7. Validate the site.
8. Disable or remove the runner.
9. Confirm that /aegismw/ is no longer publicly reachable.
10. Rotate temporary credentials and preserve the change record.

The runner can provide a report path under /aegismw/report/. Protect reports because they may contain operational details.

21. Remote Storage

The reviewed Remote Storage settings support:

• Generic HTTP or HTTPS PUT
• SFTP when the PHP SSH2 extension is available
• S3-compatible object upload through a simple PUT workflow

S3-compatible storage

The reviewed implementation performs a single-object PUT rather than a multipart upload. Large packages may encounter PHP, proxy, network, or object-store limits. Test with production-sized packages before relying on it.

Remote-storage checklist

• Use TLS
• Restrict credentials to the required bucket or path
• Avoid permanent administrator credentials
• Enable provider-side encryption where available
• Define object retention or immutability separately
• Test upload and retrieval
• Monitor failed offsite transfers
• Rotate credentials
• Document ownership

Remote storage is a destination, not a complete backup policy. Confirm that the offsite object can be retrieved and restored.

22. SMTP, Notifications, and Webhooks

Aegisify Backup can use shared Aegisify Core SMTP or plugin-local SMTP settings.

Reviewed notification events include:

• Backup success
• Restore success
• Backup failure
• Restore failure
• Offsite-transfer failure

The interface also supports a webhook URL and secret. Signed webhook requests use an HMAC SHA-256 signature in the X-AegisBackup-Signature header.

Notification guidance

Send alerts to a monitored operations address, not one individual. Route failures to a channel with an escalation owner. Test the email and webhook after configuration and after mail, DNS, firewall, or hosting changes.

Do not include recovery tokens, database credentials, or sensitive archive locations in ordinary alert content.

23. Before Updates

The Before Updates feature can create a fast rollback snapshot before supported WordPress core, plugin, or theme updates. The workflow keeps the most recent rollback point for supported use.

This snapshot is a risk reducer, not a replacement for a full backup program. Before a major release:

1. Create a verified full recovery point.
2. Confirm offsite storage.
3. Confirm the Before Updates setting.
4. Apply the update in staging when practical.
5. Deploy during an approved window.
6. Test the site.
7. Keep rollback evidence until acceptance.

24. Logs, Reports, and Diagnostics

Operational records help answer:

• What job ran?
• What scope was selected?
• When did it start and finish?
• Did package and hash validation pass?
• Was the package moved offsite?
• Did a restore run?
• What errors occurred?
• Who approved the change?

Use the Settings Logs area and dashboard diagnostics to investigate failures. Download logs before deleting packages or changing settings when evidence may be needed.

Sanitize logs before sharing them outside the authorized support team.

25. Retention and Pruning

Retention should align with business recovery needs.

A common layered model is:

The reviewed table and file workflows support local retention values from 1 to 90 days and can purge or move packages offsite before local deletion, depending on configuration.

Do not configure retention only to maximize disk space. Model ransomware, accidental deletion, silent corruption, delayed discovery, and legal requirements.

26. Recovery Objectives

Recovery Point Objective

RPO defines how much data loss the organization can accept, measured backward from an incident. A five-minute RPO requires successful, verified recovery points at the required interval.

Recovery Time Objective

RTO defines how quickly service should be restored. RTO depends on package size, download time, infrastructure availability, database speed, operator readiness, DNS, third-party systems, and acceptance testing.

Do not publish a fixed recovery time without environment-specific test evidence.

27. Operational Runbooks

Daily

• Review the latest scheduled jobs
• Investigate failed or unusually small packages
• Confirm offsite-transfer status
• Check local storage
• Confirm alert delivery

Weekly

• Review package retention
• Download or validate one representative package
• Review database growth
• Confirm cron execution
• Review Transfer Wizard connections
• Confirm the standalone Migration Wizard remains disabled

Monthly

• Perform a representative restore test
• Verify remote-storage retrieval
• Review schedule scope and business changes
• Rotate credentials where required
• Review administrator access
• Update recovery documentation
• Record tested RPO and RTO evidence

Before a major release

• Create a full package
• Create a database snapshot
• Confirm offsite copies
• Confirm rollback ownership
• Test staging
• Define acceptance checks
• Schedule the change

During an incident

• Preserve current evidence
• Stop destructive cleanup until scope is understood
• Identify the last known-good recovery point
• Verify package integrity
• Build a clean recovery target when appropriate
• Restore in a controlled window
• rotate credentials
• validate security controls
• document decisions and outcome

28. Troubleshooting

Scheduled jobs do not run

• Confirm WP-Cron is enabled
• Confirm the site receives traffic or configure server cron
• Verify the saved schedule
• Check for an active overlap lock
• Review logs
• Check PHP and hosting limits
• Confirm the license for scheduled features

Five-minute plans run late

Use a server cron that calls WordPress cron at least every minute. Measure actual backup duration. Reduce scope or improve resources if a job cannot finish inside the interval.

Package size is unexpectedly small

Review selected tables, columns, paths, exclusions, database connection, file permissions, free disk, export logs, and hash or completion status.

Package creation times out

Reduce scope, split file plans, exclude caches and existing archives, adjust supported batch values, improve hosting limits, or use a more capable environment.

Offsite upload fails

Confirm outbound access, TLS, credentials, bucket or path permissions, PHP SSH2 for SFTP, object size, proxy limits, and network timeout. Test with a production-sized package.

Restore is blocked by an active job

Wait for the current job to complete or investigate a stale lock through authorized support procedures. Do not bypass overlap protection while another write operation is active.

Selected-column restore does not recreate the table

Selected-column restore is designed to update selected fields in existing rows. Use a complete table snapshot when the recovery objective includes schema and full-table recreation.

Transfer Wizard cannot connect

Confirm HTTPS, destination URL, token age, clocks, firewall rules, REST access, DNS resolution, and destination availability. Generate a new short-lived token if required.

Migration Wizard is reachable when it should not be

Disable it from the administration interface and apply host-level access restrictions. Confirm the path returns an unavailable response after recovery.

29. Frequently Asked Questions

Does Aegisify Backup guarantee recovery?

No. It provides backup, transfer, restore, verification, logging, and recovery workflows. Recoverability still depends on configuration, package integrity, storage, infrastructure, credentials, and tested procedures.

Is a local backup enough?

Usually not for business-critical sites. A server failure, compromise, or storage loss can affect both the live site and local backups. Maintain an independently protected copy.

What is the difference between a complete table snapshot and a selected-column backup?

A complete table snapshot includes schema and all fields and is intended for full-table recovery. A selected-column backup restores selected fields into existing rows and preserves fields outside the selected scope.

Can I schedule backups every five minutes?

The reviewed table scheduler supports minute intervals, including five minutes. Dependable five-minute recovery points require reliable server cron, enough resources, jobs that complete inside the interval, and successful validation.

Does the plugin provide network-level disaster recovery?

It creates and restores WordPress recovery packages. Hosting, DNS, network, database-server, object-storage, and infrastructure recovery remain separate responsibilities.

Can I migrate without FTP or SSH?

The Transfer Wizard can move supported packages between connected WordPress sites. Environment size, network policy, authentication, and hosting limits still apply.

Should I leave /aegismw/ enabled?

No. Keep the standalone runner disabled except during a controlled maintenance operation. Add server-level access protection and disable or remove it immediately afterward.

Does S3-compatible upload use multipart transfer?

The reviewed implementation uses a simple single-object PUT. Test large packages and storage-provider limits before relying on it.

Are database optimization and prefix changes risk-free?

No. Both can affect production data. Create verified recovery points, use a maintenance window, and test after the change.

How often should I test restores?

At least on a schedule that matches business criticality and after material environment changes. High-impact ecommerce or portal sites may require more frequent testing than a low-change brochure site.

30. Glossary

31. Related Aegisify Resources

• Aegisify Backup product page
• Aegisify Backup User Guide and Documentation
• Aegisify Help Center
• WordPress migration article
• Database growth and optimization article
• WordPress Plugin Handbook: Cron
• WordPress backup documentation

32. Final Operational Recommendation

Start with a small, verified backup; establish independent storage; configure alerts; document retention; protect recovery interfaces; and perform a test restore before depending on the system for production recovery. For high-change sites, use table-level schedules only after measuring job duration and validating that cron, storage, and restoration can meet the intended recovery objective.