AdminsForum - aaPanel Backups & Migration Guides

Back Up and Restore a Flask App on an aaPanel Server

Wed, 14 Oct 2026 15:11:58 +0800

A backup is useful only when you can rebuild and run the application from it. This SSH-based guide backs up a small Flask project hosted by aaPanel, restores it outside the live website folder and tests it on a separate localhost port.

Tested lab: Ubuntu 22.04.5, aaPanel Free 8.0.7 and a Flask/Gunicorn sample. This is a source-and-dependency recovery exercise, not a complete VPS image or a walkthrough of an aaPanel backup plugin.

python-backup-workflow-20261014.jpg (Size: 107.98 KB / Downloads: 5)
Restore workflow diagram. The live app and the recovery test remain separate.

1. Define what must be recovered
Our sample has app.py and requirements.txt and no database, uploads or secret configuration. A real app may also need a consistent database export, uploaded files, environment secrets, Nginx configuration and its startup settings. Inventory those separately before claiming a complete backup.

The live project directory is /www/wwwroot/af-flask-lab. Its Gunicorn command uses app:app and binds 127.0.0.1:3200. Record your environment path, Python version, startup user, domain and mapping port in a protected recovery note.

2. Record the application's packages
Place a reviewed requirements.txt beside app.py. Our small sample contains:

Code:

Flask==3.1.3
gunicorn==26.2.0

These are the versions tested in this lab. This pins direct dependencies; it does not lock every transitive dependency. For stronger repeatability, retain a reviewed full dependency snapshot or a suitable lock file and test it in a clean environment.

3. Create a protected source archive
Choose a new archive name so you do not overwrite an older recovery point. From the VPS terminal, the equivalent command for our two-file sample is:

Code:

tar -czf /www/backup/af-flask-20261014.tar.gz   -C /www/wwwroot af-flask-lab/app.py af-flask-lab/requirements.txt
chmod 600 /www/backup/af-flask-20261014.tar.gz
tar -tzf /www/backup/af-flask-20261014.tar.gz

Check that both expected files are listed. Our archive was 377 bytes because this is a tiny text-only sample, not a full production application.

Do not publish backup archives inside a website document root. Rebuild the virtual environment rather than assuming a copied environment is portable between server paths or operating systems. Save a protected off-site copy through your approved backup destination; a local archive alone does not protect against losing the VPS. Off-site transfer was not performed in this exercise.

4. Restore into a new isolated directory
Use a new directory that does not already contain files:

Code:

mkdir /www/af-flask-restore-20261014
tar -xzf /www/backup/af-flask-20261014.tar.gz   -C /www/af-flask-restore-20261014

Only extract your trusted archive after inspecting its file list. Do not extract into the live project for a rehearsal. The restored app is now under /www/af-flask-restore-20261014/af-flask-lab.

Compare app.py and requirements.txt with the source copies. For example:

Code:

sha256sum /www/wwwroot/af-flask-lab/app.py
sha256sum /www/af-flask-restore-20261014/af-flask-lab/app.py

Our test compared both files with SHA-256 and both matched. A matching hash proves the file content matches; it does not yet prove the app can run.

5. Build a fresh environment
Use a Python version compatible with the application. Our existing lab uses /usr/bin/python3.10; choose a maintained compatible release for a new deployment. Ubuntu's matching venv package must already be installed.

Code:

python3 -m venv /www/af-flask-restore-20261014/venv
/www/af-flask-restore-20261014/venv/bin/python -m pip install   -r /www/af-flask-restore-20261014/af-flask-lab/requirements.txt
/www/af-flask-restore-20261014/venv/bin/python -m pip check

Our fresh environment installed the recorded direct versions and pip check reported No broken requirements found. Install from trusted package sources. If your project needs OS libraries, document and rebuild those too.

6. Run the restored app on a different local port
Set permissions only on the isolated restore directory for the intended application user. In our lab that user is www. From an administrator terminal:

Code:

chown -R www:www /www/af-flask-restore-20261014
cd /www/af-flask-restore-20261014/af-flask-lab
runuser -u www -- /www/af-flask-restore-20261014/venv/bin/gunicorn   --workers 1 --bind 127.0.0.1:3202 app:app

This foreground command occupies that terminal. From a second terminal:

Code:

curl -i http://127.0.0.1:3202/

Our restore returned HTTP 200 and AdminsForum Flask lab. Port 3202 stayed local and did not replace the live app on 3200. Stop the foreground recovery process with Ctrl+C when the test is finished. We stopped the temporary test process and rechecked the live HTTPS site, which still returned HTTP 200.

Before using this for a real recovery
Test database connectivity, uploads, background jobs, secrets, logging and the expected user workflow. A two-file Flask test cannot establish those properties. Restore missing resources before changing the live domain or project path. Plan cutover and rollback separately; a rehearsal should not overwrite your running deployment.

Completion checklist

Backup contents inspected and protected.
Isolated restore directory used.
Source file hashes compared.
Fresh environment built and dependencies checked.
Restored application tested on a separate local port.
Temporary process stopped and live website checked.
Off-site retention and application-specific data still included in the wider recovery plan.

AdminsForum lab-tested guide. Illustration is a workflow diagram; commands describe the tested SSH recovery method.

Back Up and Restore a Node.js App on an aaPanel Server

Wed, 14 Oct 2026 11:00:27 +0800

A backup is useful only if you can restore and run the application. This guide backs up our aaPanel-managed Node.js sample, extracts it into a separate folder, compares the restored files and runs the copy on a temporary localhost port. The live website is not replaced.

node-backup-workflow-20261014.png (Size: 64.64 KB / Downloads: 4)
Backup and isolated restore workflow, based on the lab test below.

Tested setup: Ubuntu 22.04.5 LTS, aaPanel Free 8.0.7, Node.js 24.21.0. Source folder /www/wwwroot/af-node-lab; project afnodelab; live domain node.adminslab.com. Tested on 14 October 2026. These steps use SSH on the aaPanel server; they do not demonstrate aaPanel's native Backup / Restore button.

1. Decide what the backup must include
For this dependency-free sample, we preserved server.js, package.json and yarn.lock. For a real application, also identify configuration, required environment variables, uploaded files, generated assets and external services.

A source-file archive is not a database backup or a full aaPanel configuration backup. Record the project name, runtime, run user, startup command, port, domain mapping and Boot setting separately. Store secrets securely. Do not put an archive containing credentials under a publicly served website directory.

2. Check the live app before starting

Code:

curl -I https://node.adminslab.com/
ls -l /www/wwwroot/af-node-lab
df -h /www

Use your own domain and directory. Confirm the app is healthy and enough disk space is available. Our live app returned 200 before the test. For an application writing files or a database, plan a consistent backup process; copying changing files does not automatically produce a consistent recovery point.

3. Create the archive outside the website root
The following commands are for our lab. Use a unique archive filename to avoid overwriting an older backup:

Code:

sudo tar --exclude=af-node-lab/node_modules   -czf /www/backup/af-node-20261014.tar.gz   -C /www/wwwroot af-node-lab
sudo chmod 600 /www/backup/af-node-20261014.tar.gz

The -C option changes the base directory before archiving. The archive contains the af-node-lab folder rather than absolute server paths. We excluded node_modules for this sample; a real app needs a reproducible dependency installation or another deliberate dependency-backup strategy. Preserve its lockfile and build requirements.

Our archive was 878 bytes because the sample contains only a few tiny source and lock files. That size is not representative of a real application.

4. Inspect the archive and keep an off-server copy

Code:

sudo tar -tzf /www/backup/af-node-20261014.tar.gz
sudo sha256sum /www/backup/af-node-20261014.tar.gz

Check that the expected files appear. A readable archive list is useful, but it does not prove the app can run after restoration. Transfer a protected copy to a separate backup location and record its checksum. Our lab test verified a local archive and restore; an off-server transfer was not part of this test.

5. Restore into a new directory
Choose a directory that does not already exist. Never extract over the live app as your first recovery test:

Code:

sudo mkdir /www/af-node-restore-20261014
sudo tar -xzf /www/backup/af-node-20261014.tar.gz   -C /www/af-node-restore-20261014

The restored app is now under /www/af-node-restore-20261014/af-node-lab. This directory is separate from the live application's document root.

Before modifying the copy, compare hashes:

Code:

sha256sum /www/wwwroot/af-node-lab/server.js
sha256sum /www/af-node-restore-20261014/af-node-lab/server.js

Repeat for package.json and yarn.lock. Matching digests confirm identical file contents at this point. Our test compared all three and they matched. A file checksum does not validate database contents or application behaviour.

6. Prepare the restored copy for an isolated test
Set ownership only on the separate test directory:

Code:

sudo chown -R www:www /www/af-node-restore-20261014

In the restored server.js only, change the sample port from 3100 to 3102 and update its startup message to match. Leave the live server.js untouched. Confirm that the temporary port is unused:

Code:

ss -ltn | grep ':3102'

No matching listener should be present before this test. Do not use an occupied port. Keep the sample bound to 127.0.0.1 so the temporary copy is not exposed publicly.

Check its JavaScript syntax:

Code:

/www/server/nodejs/v24.21.0/bin/node --check /www/af-node-restore-20261014/af-node-lab/server.js

Replace the runtime path with your installed version. Real applications may also need dependencies, compilation and test environment configuration. Do not connect a recovery test to production services that could send mail, charge payments or modify live data.

7. Run the copy and check its response
In one SSH session, start it in the foreground as www:

Code:

sudo runuser -u www -- /www/server/nodejs/v24.21.0/bin/node /www/af-node-restore-20261014/af-node-lab/server.js

In a second SSH session:

Code:

curl -i http://127.0.0.1:3102/
curl -I https://node.adminslab.com/

The restored sample should return HTTP 200 and the AdminsForum Node.js Lab page. The live domain should still return 200 independently. We verified the restored response and the live domain during our test.

When finished, stop the foreground test with Ctrl+C. Our test also stopped its temporary process after validation; the live app remained running. Confirm that the temporary listener has gone before reusing the port.

8. Record the recovery result
Our test result was:

Code:

server.js file hash: MATCH
package.json file hash: MATCH
yarn.lock file hash: MATCH
Restored app on localhost:3102: EXPECTED PAGE
Live HTTPS website: 200

The archive and isolated restored folder were retained for later inspection. This proves recovery of this small source-based sample, not a full server or database restore.

9. Before replacing a real deployment
Keep the current release and its backup, restore any database consistently, verify dependencies and secrets, then plan the switch and rollback. Use aaPanel to configure the intended project directory and runtime only after the recovery copy passes its checks. Repeat response tests after the change. This guide deliberately stops before a live cutover.

Related guide: Deploy a Node.js app in aaPanel with a domain and HTTPS.

Verify a Full WordPress Backup Restore in aaPanel

Tue, 13 Oct 2026 11:52:24 +0800

Quick answer
A full WordPress recovery needs both website files and the database. Test the backup in an isolated location before replacing a live site. Our aaPanel backup rehearsal restored 3,935 files with matching hashes, imported 12 database tables and loaded the restored WordPress installation successfully.

restore-rehearsal-branded-20261013.jpg (Size: 51.34 KB / Downloads: 6)
This was a private staging rehearsal, not an overwrite of the live WordPress website. It proves the tested archive's file restoration, SQL import and WordPress bootstrap; browser pages, login, email, payment integrations and a production cutover require their own checks.

1. Choose the correct backup set
In the WordPress backup area, identify the site, backup time and archive. Keep the matching database and files together. Download an independent copy and record the intended recovery point so you know which newer changes would be lost in a live rollback.
Our tested archive was wp.adminslab.com_20261012_163830.zip. Its outer ZIP contained meta.json, database.sql.gz and files.zip. That format is specific to this lab backup; inspect your own archive rather than assuming every aaPanel backup has the same layout.
A website ZIP containing uploads and PHP files is not automatically a database backup. A database dump does not contain all your themes, plugins or uploaded images.

2. Keep the rehearsal outside the public website
Use a new private working directory outside /www/wwwroot, with restrictive permissions. Do not extract wp-config.php or SQL dumps into a public URL just for convenience. Confirm the target directory is empty before extraction so an older test is not silently overwritten.
Our working copy was under a root-owned private directory with mode 0700. Credential files used mode 0600. No new public website or hostname was created for this rehearsal.
Do not use your live document root or live database name as a staging destination.

3. Check both archive layers
Validate the outer ZIP, then the nested files.zip and the compressed SQL member. Our outer archive had three members, and the nested file archive had 4,423 entries including directories. Both ZIP integrity checks passed.
You can inspect an archive with Python's built-in ZIP tools:

Code:

python3 -m zipfile -l /path/to/your-backup.zip
python3 -m zipfile -t /path/to/your-backup.zip

Do not treat a valid ZIP checksum as proof that WordPress can be restored. It only verifies that the stored archive entries are readable without that integrity error.
Our extraction also checked that every destination stayed inside the private staging folder and rejected symlink entries needing review. Inspect the archive paths before extracting an unfamiliar backup.

4. Restore the website files into staging
Extract the outer package into the private work area. Extract files.zip into a separate empty staging directory. Check that the expected WordPress structure is present: wp-admin, wp-includes, wp-content, wp-load.php and wp-config.php.
Keep the archive unchanged. We compared each extracted regular file against its archive member using SHA-256 before editing staging configuration; 3,935 file hashes matched. Directories are not counted as regular files in that result.
For a smaller manual spot check, compare several important files and an uploaded image, but label that as a sample. It is not the same as the full file comparison used in this rehearsal.

5. Create a separate restore database
Use a new clearly named temporary database. Our database was af_restore_verify_20261013, separate from the active WordPress database. Confirm it does not already exist before creating it.
Use existing authorized database-administration access for the import, and keep credentials out of command-line arguments, screenshots and forum posts. A private MySQL client option file is one approach:

Code:

[client]
user=YOUR_AUTHORIZED_DATABASE_ADMIN
password="YOUR_EXISTING_PRIVATE_PASSWORD"
host=localhost

Store it in a private administration directory with permissions 0600. Do not paste real credentials into this article's examples.
Before importing, inspect the dump for database-switching statements such as USE, CREATE DATABASE or DROP DATABASE. Our dump had none; the importer explicitly targeted the temporary database. Stop and review a dump that would redirect the import to another database.
A representative import uses the private option file and the chosen staging database:

Code:

set -o pipefail
gunzip -c /private/work/database.sql.gz | mysql --defaults-extra-file=/root/wp-restore-auth.cnf YOUR_STAGING_DATABASE

Replace every example path and name with your verified staging values. Check both decompression and import exit status. Do not run this against the live database while rehearsing.
Our import succeeded and the staging database contained 12 tables.

6. Point only the staging configuration to that database
Edit the staging copy of wp-config.php so DB_NAME, DB_USER, DB_PASSWORD and DB_HOST refer to the intended private restore database and authorized identity. Verify the file you are editing is the copy, not the live configuration.
Preserve the table prefix from the backup. A correct database name with the wrong prefix can make a restored site appear uninstalled or empty.
Use a restricted application database identity before exposing a restored site publicly. The lab's temporary administration identity was used only inside an inaccessible private rehearsal; it is not a recommendation to put a database root account into a public website.
Check PHP syntax with the interpreter appropriate for the restored site. Resolve any configuration error before loading WordPress.

7. Load WordPress without scheduling or shared-cache side effects
Our test runner disabled traffic-triggered cron, persistent Redis access and early page-cache loading for the private copy before loading its wp-load.php. It then confirmed the configured database was the staging database and queried the restored posts and options tables.
The bootstrap passed. The snapshot contained 9 post-table rows and 163 option-table rows. These counts are evidence from that backup, not numbers every WordPress installation should have.
Keep scheduled jobs and external integrations isolated while rehearsing. A restored copy should not take over the live site's cache namespace or run duplicate live schedules.

8. Add browser and application checks before cutover
If you later make a private browser-accessible staging site, verify its URL settings, HTTPS, login, images, permalinks, forms, plugins and essential application functions. Moving to a different domain may require a WordPress-aware URL migration; a blind SQL text replacement can damage serialized values.
Before a live restore, take a fresh rollback copy of the current files and database, plan a maintenance window and document the expected data-loss interval. The rehearsal did not perform that cutover.

Do not rely on a success notification alone
An earlier lab check of the native WP Toolkit Restore action reported success, but test changes remained. That native behavior has not been repaired or revalidated by this manual rehearsal. The independently tested archive restore is the verified result here.
After any actual restore, confirm a known file and database value match the selected backup point. Checking only that the home page loads can miss a partial restore.

Final lab result

Outer and nested archives were readable and passed integrity checks.
3,935 extracted regular files matched their archive hashes before configuration changes.
The SQL imported into a separate private database with 12 tables.
The restored WordPress copy loaded and its data tables were readable.
The current public website and its active database were not overwritten.

The private rehearsal copy remains available for review. Keep backup and credential material private throughout cleanup and recovery.

Reference: WordPress backup documentation. © AdminsForum.

Verify a WordPress Backup Before Restoring in aaPanel

Tue, 13 Oct 2026 00:36:54 +0800

Quick answer
A backup job finishing successfully proves that the panel created a backup, not that your website can be recovered. Before relying on a WordPress backup, confirm its site and date, check the archive components, preserve another private copy and test restoration on an isolated site.

This guide uses a real full backup from our AdminsForum lab: aaPanel 8.0.6, WordPress 7.1.3 and a root-installed WP Toolkit site. We verified the archive and compression checks on 12 October 2026. It is a verification walkthrough, not a claim that a completed restore was proven.

1. Create a current full backup
Open WP Toolkit, find the correct domain and click its Backup / Restore entry. Check that the configured backup type includes both files and database, then start the backup and wait for the job to finish.

Our task displayed 1 success, 0 failed. If yours fails, investigate that job before testing restoration. See the backup creation walkthrough for the initial panel steps.

wp-backup-check-completed-branded-20261012.jpg (Size: 107.92 KB / Downloads: 8)

2. Identify the exact archive
In the backup list, check the domain, backup time, file size, backup type and storage location. Do not select an older archive just because it is first in a downloaded folder.

Our selected entry was:

File: wp.adminslab.com_20261012_153210.zip
Size displayed by aaPanel: 41.13 MB
Type: Full Backup
Storage: Local Server

wp-backup-check-list-branded-20261012.jpg (Size: 96.98 KB / Downloads: 9)

The panel's displayed backup time can use a different timezone from a timestamp embedded in the filename. Record the exact filename and check the selected site's identity. The warning Subsites not included also matters: a backup of the parent site is not proof that every separate subsite has been captured.

3. Preserve a private copy
Keep the original archive while you investigate. We made a second private copy and confirmed its SHA-256 matched the original. That second copy was on the same lab VPS: it protects against accidentally changing the original during testing, but not against losing the server.

For disaster recovery, keep a verified copy in separate storage or on another machine. Do not put backups in a public website directory, attach SQL dumps to support posts, or share archive contents that include wp-config.php or database credentials.

4. Check the archive without restoring it
Our full-backup ZIP contained meta.json, database.sql.gz and files.zip. We checked the outer ZIP, decompressed the SQL gzip, tested the nested files ZIP and confirmed wp-config.php was included.

The following read-only example was also tested against this archive. Open the aaPanel Terminal and change the p = Path(...) line to your actual backup file before running it. It needs Python 3 and its standard library; it does not extract files into your website, import SQL or modify the backup.

Code:

python3 - <<'PY'
from pathlib import Path
import gzip, io, json, zipfile
p = Path('/www/backup/wordpress/wp.adminslab.com_20261012_153210.zip')
if not p.is_file():
    raise SystemExit('STOP: backup file not found')
with zipfile.ZipFile(p) as archive:
    if archive.testzip() is not None:
        raise SystemExit('STOP: outer ZIP integrity failed')
    required = {'meta.json', 'database.sql.gz', 'files.zip'}
    if not required.issubset(archive.namelist()):
        raise SystemExit('STOP: expected full-backup components missing')
    meta = json.loads(archive.read('meta.json'))
    print('Backup domain:', meta.get('domain'))
    print('Backup site root:', meta.get('site_path'))
    sql = gzip.decompress(archive.read('database.sql.gz'))
    if not sql:
        raise SystemExit('STOP: SQL data is empty')
    print('SQL compression and non-empty data: PASS')
    with zipfile.ZipFile(io.BytesIO(archive.read('files.zip'))) as files:
        if files.testzip() is not None:
            raise SystemExit('STOP: nested files ZIP integrity failed')
        if not any(n.endswith('wp-config.php') for n in files.namelist()):
            raise SystemExit('STOP: wp-config.php missing')
    print('Files ZIP integrity and wp-config.php presence: PASS')
print('Integrity checks finished. A restore test is still required.')
PY

This example matches the archive layout observed in our aaPanel version. A different backup format needs a different check; a missing component should be investigated rather than renamed to make the script pass. It loads the compressed components into memory, so for large backups use an appropriate streaming/offline verification process instead of copying this small-lab example blindly.

wp-backup-check-integrity-branded-20261012.jpg (Size: 40.97 KB / Downloads: 8)

Read the result carefully:

The domain and site root should describe the website you intended to back up.
ZIP integrity checks detect archive corruption; they do not prove the application data is complete or safe.
Successful SQL gzip decompression and non-empty data do not prove that the SQL will import successfully or contain every required table.
wp-config.php being present confirms inclusion of that file, not that its database settings match the restore target.

5. Test recovery on an isolated site
Use a disposable staging environment and preserve its current state before overwriting it. Keep production traffic, outgoing email and scheduled jobs out of the recovery test so a copied website does not send duplicate messages or run live integrations.

Record something that must be recovered from the backup: for example an existing test file's contents, a draft's content, an uploaded image and a harmless database setting. Make a controlled change after the backup, then perform the staging restore through the appropriate restore workflow.

Afterward, independently check both files and database. Open the restored homepage and a deep page, sign in to WordPress, inspect media and confirm the chosen pre-backup state returned. A page loading alone is not enough.

A caution from our own test
In a separate restore test on this lab, WP Toolkit returned a success response, but a changed backed-up file and a disposable database marker remained afterward. We did not count that as a verified recovery. We have not established the cause or claimed that the result applies to other servers or versions. The disposable markers were removed and our private backup was preserved.

Extra files created after a backup can also remain in an overwrite-style restore. Their presence alone is not decisive: check an existing backed-up file and a database value as well.

If any check fails

Stop before overwriting production or deleting older backups.
Confirm the intended backup filename, domain, site root and database target.
Review the backup/restore task result and relevant errors; redact credentials before sharing diagnostics.
Keep the original archive and try recovery in an isolated environment before relying on it.

What this walkthrough verified
The full backup completed, archive checks passed, SQL gzip data decompressed, the nested files ZIP contained wp-config.php, and a matching private safety copy was kept. Successful end-to-end recovery was not verified; that remains a separate requirement.

Reference: aaPanel WP Toolkit documentation. Screenshots are original AdminsForum lab captures.

Schedule Automatic MySQL Database Backups in aaPanel

Mon, 12 Oct 2026 11:10:41 +0800

Quick answer
Open Cron → Backup Database, choose the MySQL database type and your specific database, then set a daily time, destination and retention count. Click Add Task, use Execute for the first test, and read the Log. Check the resulting SQL archive before trusting future runs.

Tested result
On the AdminsForum lab with aaPanel 8.0.6 and MariaDB 10.11, we created Backup Database[af_wordpress]--mysql. The daily schedule was 02:25 on the server's clock, with Local Disk and three retained copies. The first manual run exported a 2.11 MB database and produced a 193.33 KB .sql.gz file. The log reported Successful, and gzip integrity checking passed. We paused this tutorial-only task after testing. The next unattended daily trigger and restoration of this particular dump were not tested.

1. Find the correct database
Open Databases and identify the database used by your application. Do not assume its name matches the domain. For WordPress, the DB_NAME value in its configuration identifies the database, but keep that file private because it also contains credentials.

If your application uses more than one database, include each required database in the backup plan. Our example selects af_wordpress only. It does not back up the other databases on the server.

2. Open the backup task form
Click Cron in the left-hand menu. Under Add Task, set Task type to Backup Database. In Backup database, select MySQL for this MySQL/MariaDB example. The lab runs MariaDB but aaPanel presents this engine family as MySQL in the task form.

Use Database to select the required database instead of leaving ALL selected unless every listed database should be included. The task name is generated from your selection.

3. Choose a time and destination
Set Execute cycle to Daily and enter the hour and minute. We used 02:25 so it did not start at the same time as the website-file job. Check the server clock and time zone first. Staggering jobs helps avoid simultaneous compression and database activity, but does not guarantee that file and database backups represent the same instant.

For this first test we selected Local Disk and kept the latest three copies. Choose a retention count based on available space and how far back you need to recover. Repeated manual executions can also create copies; retention is not automatically equivalent to a number of days.

cron-database-settings-20261012.jpg (Size: 209.88 KB / Downloads: 9)
AdminsForum lab: the selected WordPress database, daily schedule, local destination and copy count.

The Backup reminder setting was left at non-receipt. No notification delivery was tested. If you enable alerts later, test the notification channel rather than assuming it works.

4. Create the task and run it once
Click Add Task. Check the new row's database name, Running status, time and destination. Click Execute in that exact row and confirm the prompt. Wait for the export and compression to finish, then read Log or use Refresh log.

cron-database-log-20261012.jpg (Size: 254.24 KB / Downloads: 9)
AdminsForum lab: successful database export, compressed size, output path and retention result.

A successful result should identify the database you intended and the location of a non-empty archive. A task being present in the list does not prove a backup was produced.

Our archive was placed under:

Code:

/www/backup/database/mysql/crontab_backup/af_wordpress/

The log provided its exact timestamped filename. Your version or storage configuration may use a different path; follow your own log.

5. Verify the compressed SQL file
Find the file using aaPanel Files or your normal secure server-access method. Keep it outside public website directories. A database dump can contain member information, application settings and other private data.

If you use the terminal, verify gzip integrity without extracting the dump:

Code:

gzip -t /path/to/your-database.sql.gz && echo 'Compressed backup integrity OK'

Replace the example path with the real file from your log. We ran this successfully on the lab dump. It confirms that the compressed stream is intact; it does not prove the SQL will import successfully or that every application component can be restored.

A much smaller compressed file can be normal. Compare with the logged database size and inspect its structure privately when needed. Do not publish SQL contents in a support thread.

6. Plan an isolated restore test
The strongest check is to import a copy into a separate test database and confirm the expected tables and application content. Avoid overwriting the live database just to test a backup. Record the original application configuration and use a separate test site if you need to point an application at the restored database.

The database backup and restore guide covers the separate restore workflow. This article tests creation and archive integrity, rather than claiming a restore of the new cron archive.

7. Keep website files and database backups together
A database dump does not include WordPress uploads, themes, plugins or website configuration files. Pair it with a scheduled website-file backup.

For a busy store or other frequently changing application, consider application-supported consistent backups or a brief maintenance period. Two independently timed backup jobs do not automatically guarantee a consistent recovery point.

8. Keep an off-server copy and check the next run
Transfer a copy to protected off-server storage and confirm it can be retrieved. A same-server copy is not enough if the VPS disk or account is lost. Limit who can access the dump and avoid public download links.

After the first scheduled time passes, inspect Last execute time and Log and confirm a fresh archive exists. A manual Execute test verifies the backup operation, while the scheduled trigger still needs its own check.

After the lab test, we selected the task checkbox, chose Stop task in the list action menu, clicked Execute and confirmed. The task now shows Stopped. The dump remains available. Enable your real schedule when you intend to keep it operating, and review the results regularly.

Troubleshooting

Access denied during export: check the database connection and the relevant task log. Do not paste passwords into a forum post.
No database in the selector: confirm it is managed by the appropriate aaPanel database connection and review support for that connection type.
Empty or missing archive: inspect the export/compression error and available disk space; a last-execution timestamp alone is insufficient.
Remote database: verify the actual capabilities shown by your aaPanel version. The lab UI warns that remote databases do not support backup tables; our test used a local database.
Scheduled run missed: check Running status, server time, cron service and task logs.

Completion checklist

Correct application database selected.
Schedule, destination and retention reviewed.
First manual export completed with a successful log.
Compressed SQL archive exists and passed integrity checking.
Website-file coverage and protected off-server storage included.
Isolated restore and first unattended run planned and checked.

Reference: aaPanel official Cron documentation.

Schedule Automatic Website Backups in aaPanel

Mon, 12 Oct 2026 11:08:36 +0800

Quick answer
Open Cron, choose Backup Site, select the website, set a daily time and a backup destination, then click Add Task. Run the task once with Execute and check its Log before trusting the schedule. Website files and the database need separate backup coverage.

Tested on the AdminsForum lab
We created Backup Site[adminslab.com] in aaPanel 8.0.6, scheduled it for 02:10 using the server's clock, selected Local Disk and retained three copies. We manually executed the new task. The log reported Successful and created a 45.78 MB archive from a 119.08 MB document root. The archive passed a tar readability check. We paused the tutorial-only schedule after testing; the archive was preserved. An overnight scheduled execution and a restore of this specific archive were not tested.

1. Decide what you need to protect
For a WordPress or other database-driven website, keep both the document-root files and its database. Files include application code, uploads and configuration. Database content such as posts, settings and accounts is separate.

Check the site you want to back up, its document-root path and the available disk space first. Keep backup archives outside the public document root. A same-server backup helps with accidental file changes but cannot protect you from losing the entire server.

2. Select Backup Site
Click Cron in the left-hand menu. In the Add Task section, open Task type and choose Backup Site. Select your particular website in Backup site. The lab's task name changed automatically to Backup Site[adminslab.com]. Choose ALL only when you actually want every listed site included.

3. Set the schedule and retention
Choose Daily in Execute cycle, then enter the hour and minute. Our example is 02:10. These fields use the server's clock; check its time zone before treating the value as your local time. Choose a quiet period and avoid overlapping with other large backups or imports.

For this first test, select Local Disk in Backup to and set Retain the latest to 3. This is a number of copies, not a guaranteed number of days. Extra manual executions can also consume retained copies. Use a retention count that covers your recovery needs and fits your storage capacity.

cron-site-settings-20261012.jpg (Size: 178.69 KB / Downloads: 9)
AdminsForum lab: the website backup settings before creating the task.

If you later configure a remote storage integration, verify that a complete archive actually reaches that destination. Selecting a destination is not proof that its credentials, permissions or connectivity work.

4. Review exclusions carefully
The Exclusion rules field can omit unwanted paths. We left it blank for the first test so the website document root was covered. Excluding uploads or a configuration file without a separate backup can prevent a complete recovery. Do not place your backup destination inside the site and then accidentally include old backups in every new archive.

The Backup reminder field was left at non-receipt in our test. No failure notification was configured or tested. Configure and test notifications separately if you depend on them.

5. Create and run the task
Click Add Task. Check the new row's site name, status, execution time, copy count and destination. It should show Running when enabled for future executions.

In that row, click Execute and confirm the prompt. Wait for the run to finish. Use Log or Refresh log to read the outcome. A task row or last-execution timestamp alone does not prove that the backup succeeded.

cron-site-log-20261012.jpg (Size: 232.92 KB / Downloads: 8)
AdminsForum lab: successful first backup, including the archive path, size and retention setting.

Our completed archive was saved under:

Code:

/www/backup/site/adminslab.com/

Use the exact filename shown in your own log rather than copying a timestamped name from a tutorial.

6. Verify the archive
Check that the file exists and has a plausible size. A compressed archive is usually smaller than the source directory, so compare with the actual content rather than expecting matching sizes.

If you use the terminal, this read-only check verifies that tar can read the archive listing:

Code:

tar -tzf /path/to/your-backup.tar.gz > /dev/null && echo 'Archive readable'

Replace the path with the real archive path from your log. We ran this check successfully on the lab archive. It does not prove that the application's database is included or that the website will recover correctly.

For stronger recovery assurance, test extraction and application recovery in an isolated directory or separate test site. Avoid overwriting a live website simply to test a backup. See the website file backup and restore guide for the separate restore workflow.

7. Keep a copy away from the server
Transfer an archive to protected off-server storage and verify that it can be downloaded again. Treat it as sensitive: website configuration files can contain database credentials. Do not attach backup archives to a public forum post or place them at a public download URL.

Pair the file backup with a database backup from a compatible point in time. A rapidly changing site may need coordinated backups or a brief maintenance window for consistency.

8. Check future runs
After the next scheduled time, inspect Last execute time and Log. Confirm a new archive appeared and that retention behaves as expected. We tested the task manually; you should still verify its first unattended execution on your server.

To pause a task, select its checkbox, choose Stop task in the list action menu, click Execute and confirm. Reload the list and verify Stopped. We used this explicit stop action for the lab task. We preserved it for reference instead of leaving an unnecessary tutorial schedule running.

Troubleshooting

No archive: read the task log, check the selected website and document root, and confirm free disk space and permissions.
Unexpectedly small backup: review exclusions and the actual source directory. Verify archive contents before relying on it.
Missed scheduled run: check task status, server clock, cron service and logs. A manual Execute success does not prove the scheduled trigger ran.
Storage fills up: review retention, other backup jobs and whether archives are being copied into the source site. Preserve needed recovery copies before changing cleanup behavior.

Completion checklist

Correct website and document root selected.
Schedule checked against the server clock.
Destination, retention and exclusions reviewed.
First Execute run has a successful log and an archive.
Archive readability checked and off-server storage planned.
Database backup and an isolated recovery test included in the plan.
First unattended run checked afterward.

Reference: aaPanel official Cron documentation.

Back Up and Restore Website Files in aaPanel Free Edition

Sun, 11 Oct 2026 03:11:29 +0800

Quick answer
In aaPanel Free Edition, open Website → PHP Project, find your domain, and click its Backup / Restore entry. Check the configured backup type, click Backup, and wait for completion. Keep an off-server copy and test recovery on a disposable site.

Website files and database are separate
Our lab's backup configuration was Only Site File → Local Server. This backs up site files, not the application's database. Pair it with a database backup. Do not assume every backup labelled Website contains both.

1. Open the website backup dialog
Go to Website → PHP Project. Find the correct domain and check its description. Click the Backup / Restore entry; for a new site this can read 0 Backup. Dismiss the optional first-use help wizard if it blocks the controls.

2. Check the backup configuration
Read the Current configuration line before starting. In this tested guide it was Only Site File stored on Local Server. Other configurations may behave differently. Record what is included and where it is stored. Ensure enough free disk space for the backup and restoration.

3. Create the backup
Click Backup and wait for the task to complete. Confirm the archive appears with its file size, time, backup type and storage destination. Our small lab site produced a ZIP archive; actual sizes vary.

AdminsForum tutorial lab: aaPanel reports the website backup completed successfully.

4. Keep a copy outside the server
Use the archive's Download action and confirm the transfer completed. Keep the file securely off the VPS. Website archives may contain configuration secrets and private uploads; never post a production archive publicly. A local backup will not protect against losing the entire server.

5. Test restoration on a disposable site
For a real application, restore into an isolated test setup before trusting the backup. In our dedicated lab we created a harmless text file containing a known value, made the backup, changed that file, and restored the archive.

Open the correct site's Backup / Restore dialog.
Identify the intended archive and its date.
Click Restore.
Read the confirmation carefully. Our panel displayed Will be restoring the site files and database, continue?, even though the archive type was Only Site File. Check the actual backup type rather than inferring its contents from this generic warning.
Confirm only after protecting current data and planning downtime.
Wait for the recovery task to finish and inspect its log.
Verify the recovered files, ownership/permissions, HTTPS site and application behavior.

Restore can replace current files and interrupt service. In our test the website briefly returned HTTP 403 while its directory was being restored, then returned HTTP 200 after completion. Plan a maintenance window for a live site and do not treat the temporary state as a completed restore.

6. Check the result
Verify a known file or upload, the homepage, application login and important functions. Restore the corresponding database when needed, using a consistent recovery point. Website files alone do not restore a database-backed application fully.

What we tested
On 10 October 2026, aaPanel Free Edition 8.0.6 created an Only Site File backup for our dedicated lab domain. We copied the archive to a separate computer, changed a disposable test file and restored through the panel. Both a filesystem check and an HTTPS request confirmed the original text returned. The homepage returned HTTP 200 after recovery.

Common questions
Is this a VPS snapshot?
No. This backup does not capture the whole operating system or all server settings.

Does this set up scheduled backups?
No. The dialog has a separate Schedule & Remote Storage section. A reliable schedule also needs retention, off-server storage, monitoring and restore testing.

Should I leave backup archives in the website root?
No. Keep backups outside publicly served folders and protect them appropriately.

What if the application still fails after files are recovered?
Check the database recovery point, PHP version and extensions, environment settings, file permissions and logs. File recovery alone may not undo application/database changes.

Related guides
Back up and restore a database in aaPanel Free Edition
Change PHP 8.3 to 8.5 in aaPanel Free Edition

website-backup-success-safe-20261010.jpg (Size: 11.5 KB / Downloads: 8)

Back Up and Restore a Database in aaPanel Free Edition

Sun, 11 Oct 2026 03:07:18 +0800

Quick answer
In aaPanel Free Edition, open Databases, find your MySQL/MariaDB database, and click its Backup column. Click Backup, wait for the archive to appear, then use Download to keep a copy off the VPS. Test recovery before relying on a backup.

1. Choose the correct database
Open Databases → MySQL. Match the database name with your application's configuration. Do not expose passwords or production dumps in screenshots or public posts. When no backup exists, click Not exist in the Backup column. Otherwise click the existing backup entry to open Database Backup Details.

2. Create a manual backup
Click Backup and wait for completion. Confirm a new archive appears with a filename, file size, backup time and storage type. Our aaPanel Free Edition 8.0.6 lab created a .sql.zip archive on local disk.

AdminsForum tutorial lab: completed backup controls. Database names and internal paths are excluded from this image.

File size depends on database contents. Our tiny tutorial database is not representative of a production database. The backup time follows the server/panel timezone.

3. Download an off-server copy
Click Download beside the archive and confirm the download completed. Store it securely outside this VPS. A local backup can be lost with the server. Database archives may contain user data and password hashes; never post a production archive publicly.

4. Test recovery safely
For a real website, restore into a separate test database and test a staging copy of the application. Do not practice on a live database. In our disposable lab, we backed up a known tutorial row, changed it, and recovered the archive to check whether the original value returned.

Open the intended database's backup details.
Identify the correct archive by database name and backup time.
Click Recover.
Read the warning: Database will be overwritten, continue?
Confirm only after verifying the target and protecting any newer data you need to retain.
Wait for import completion, review its result/log and check the restored tables and records.

Recover can overwrite existing data. Before restoring a live database, take a current backup and plan for downtime or paused application writes. Switching to an older backup can lose data created after that backup.

5. Verify restored data
Check expected tables and a known record, then test relevant application operations such as login and pages that read the database. A ZIP download or successful import message alone is insufficient.

What we tested
On 10 October 2026, we used aaPanel Free Edition 8.0.6 on Ubuntu 22.04 with MariaDB 10.11. We created a backup in the panel, downloaded the archive to another computer, changed a disposable tutorial row and used Recover. A database query confirmed the row returned to its original value, AdminsForum backup tutorial. Larger applications require their own recovery and consistency checks.

Common questions
Does this include website files?
No. Back up the website directory separately, and keep file/database recovery points consistent before an application upgrade.

Does this create scheduled backups?
No. This is a manual backup. Automatic backups need a separate schedule, storage destination, retention policy and successful-run checks.

What if backup or import fails?
Read the task log, check free disk space and database service status, and verify the selected archive. Do not repeatedly restore over live data without understanding the failure.

Can old backups be removed?
Keep enough verified recovery points for your needs. Do not remove the only known-good backup while testing a replacement.

Related guides
Create a database and user in aaPanel Free Edition
Change PHP 8.3 to 8.5 in aaPanel Free Edition

database-backup-controls-safe-20261010.jpg (Size: 9.59 KB / Downloads: 5)