Updated to Mariadb standardization with new service name and db storage method - included script to convert to new system#110
Closed
stealthinnovative wants to merge 39 commits intolitespeedtech:masterfrom
Closed
Conversation
Complete WordPress Backup/Restore/Copy System
Three production-ready scripts forming a safety-first WordPress workflow. Every operation creates protected safety backups before changes.
Retention Policy
Type Retention Examples
Manual backups Unlimited 2026-01-13_15-01-00/
Cron backups Last 30 2026-01-13_12-01-00_cron/
Safety backups Never deleted *Pre-Restore-AutoSave, *Pre-Copy-AutoSave
backup.sh - Full Site Backup
Purpose: Complete DB + files backup with smart naming and pruning.
Usage:
bash
./bin/backup.sh example.local # Manual (unlimited)
./bin/backup.sh example.local "My Note" # Manual w/ note
CRON_BACKUP=1 ./bin/backup.sh example.local # Cron (30 limit)
./bin/backup.sh example.local "Pre-Copy-AutoSave" # Safety (called by copy.sh)
Creates: ${domain}_db.sql.gz + ${domain}_site.tar.gz + restore-info.json
restore.sh - Smart Restore
Purpose: Restore with 4 timestamp modes + cross-domain support.
Usage:
bash
./bin/restore.sh example.local latest # Newest REGULAR backup
./bin/restore.sh example.local autosave # Newest SAFETY backup
./bin/restore.sh example.local precopy # Newest Pre-Copy-AutoSave
./bin/restore.sh example.local 2026-01-13_12-01-00 # Specific
./bin/restore.sh new.local latest example.local # Cross-domain
Always creates: Pre-Restore-AutoSave of current state before restore.
copy.sh - Site Duplication
Purpose: Complete site clone with URL replacement + safety.
Usage:
bash
./bin/copy.sh example.local copy1.local
Safety workflow:
Creates Pre-Copy-AutoSave of source ✅
New DB + wp-config update ✅
File copy + permissions ✅
WP-CLI serialized data fix ✅
Database URL replacement ✅
Real-World Workflows
bash
# 1. Safety copy for testing
./bin/copy.sh prod.local staging.local
# Test changes on staging...
# 2. Revert staging to exact pre-copy state
./bin/restore.sh staging.local precopy
# 3. Promote working staging to prod
./bin/copy.sh staging.local prod.local
# 4. Emergency restore
./bin/restore.sh prod.local latest
# 5. Cross-domain disaster recovery
./bin/restore.sh prod.local latest staging.local
Cron Setup Instructions
1. Daily backup at 2AM (edit crontab):
bash
crontab -e
2. Add this line (runs daily at 2:00 AM):
bash
0 2 * * * cd /path/to/your/project && CRON_BACKUP=1 ./bin/backup.sh example.local >> /var/log/backup.log 2>&1
3. Multiple domains (daily backup all sites):
bash
0 2 * * * cd /path/to/project && for domain in site1.local site2.local; do CRON_BACKUP=1 ./bin/backup.sh $domain >> /var/log/backup.log 2>&1; done
4. Verify cron:
bash
tail -f /var/log/backup.log
grep CRON /var/log/backup.log
Directory Structure After Use
text
./backups/example.local/
├── 2026-01-13_15-01-00/ # Manual (KEEP FOREVER)
├── 2026-01-13_12-01-00_cron/ # Cron litespeedtech#1 of 30 (rolling)
├── 2026-01-13_12-05-00_Pre-Copy-AutoSave/ # Safety (KEEP FOREVER)
├── 2026-01-13_12-10-00_Pre-Restore-AutoSave/ # Safety (KEEP FOREVER)
└── restore-info.json # Per-backup manifest
Permissions Setup
bash
chmod +x bin/backup.sh bin/restore.sh bin/copy.sh
chown 1000:1000 -R ./backups ./sites
✅ Production-ready ecosystem - safety-first, unlimited manual history, controlled cron space, perfect copy/restore integration.
replaced docker compose exec -T mysql with docker compose exec -T mariadb
Update to add variable for backup root location in .env if variable not given backup location uses ./backups env option BACKUP_ROOT=/opt/stacks/backup
Update .env for BACKUP_ROOT Variable # BACKUP_ROOT=/opt/stacks/backup ← Remove # to enable
Update restore.sh to reference .env BACKUP_ROOT variable
docker-compose.yml - FULL MARIA DB STANDARDIZATION
Update .env - MariaDB Standardized
Update backup.sh Mariadb standardization
Update copy.sh for mariadb standardization
Update database.sh - mariadb standardization
Update demosite.sh - mariadb standardization
Update restore.sh - mariadb standardization
Update appinstallctl.sh - mariadb standardization
Update database.sh - added missing source .env
Update docker-compose.yml - Mariadb health check added to clear test procedure.
Update docker-compose.yml - added mardiadb healthcheck
Update docker-compose.yml - Force mariadb11.8 and name db volume
Update docker-compose.yml - update with mariadb digest lock and db volume corrections.
… and .env
ZERO user action required. Dual fallback system preserves ALL old data/configs:
1. DUAL VOLUME SYSTEM
text
ORIGINAL: "./data/db:/var/lib/mysql:delegated"
NEW: "./data/db:/var/lib/mysql:delegated" + "mariadb_data:/var/lib/mysql"
RESULT:
├── OLD USERS (./data/db exists) → Uses ./data/db (data preserved!)
└── NEW USERS (./data/db missing) → Creates mariadb_data (fresh)
Docker mount priority: First volume wins → ./data/db ALWAYS takes precedence.
2. DUAL ENVIRONMENT FALLBACK
text
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:-${MARIADB_ROOT_PASSWORD}}
# ↑ Fallback syntax = Magic ✨
OLD .env → MYSQL_ROOT_PASSWORD=secret123 → ✅ Works
NEW .env → MARIADB_ROOT_PASSWORD=secret456 → ✅ Works
MIXED → MYSQL_* takes priority → ✅ Works
3. Service Name Handling
text
ORIGINAL: mysql service + PMA_HOST: mysql
NEW: mariadb service + PMA_HOST: mariadb
SCRIPTS: docker compose exec mariadb # Updated to new name
PMA: localhost:8080 → mariadb # Fixed in new config
4. UPGRADE FLOW (2 minutes total)
bash
git pull origin main # Gets new docker-compose.yml
docker compose down
docker compose up -d # Uses existing ./data/db + .env
sleep 90 # Healthchecks pass
docker compose ps # All healthy ✅
🎯 RESULT BY USER TYPE:
User ./data/db .env vars Outcome
OLD ✅ Exists MYSQL_* Data + passwords preserved
NEW ❌ Missing MARIADB_* Fresh named volume install
MIXED ✅ Exists Both Old data + old passwords
✅ GUARANTEED:
text
✅ NO data loss
✅ NO .env changes
✅ NO manual migration
✅ NO volume copying
✅ Scripts updated (mariadb vs mysql)
✅ GitHub Actions pass
✅ Production ready
Dual volumes + env fallback = Seamless upgrade path. Everyone wins! 🎉
Added fallback Compatibility with old version of volumes and env (V1).
Update .env for backwards compatbility with old env and volumes
…s priority Update docker-compose.yml to backwards compatibility, old volumes priority load if present.
Update acme.sh added legacy volume detection
…stability test for existing users) Create verify-legacy.sh - test legacy volume detection and operation(stability test for existing users)
Updated legacy test to run combined verify helper and removed database simulation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updated to Mariadb standardization with new service name and db storage method - included script to convert to new system
New installs will not be affected.