ProcessDbBackup — Database backup and restore

[maximus]

Hi everyone,

Every site I've launched eventually had a database incident — corrupted table, failed migration, bad deploy. Having a reliable backup system that runs automatically and stores offsite is non-negotiable. This module is what I use in production.

GitHub: https://github.com/mxmsmnv/ProcessDbBackup

What it does:

• Three independent backup types — Regular, Weekly, Monthly — each with its own LazyCron schedule and retention count
• Admin home widget — shows status (🟢 OK / 🟡 Outdated / 🔴 No backups) per type with "Create now" buttons
• Backblaze B2 upload — optional offsite storage after every backup, keep or delete local copy
• Chunked upload — upload .sql.gz from your computer in 2MB chunks, bypasses upload_max_filesize entirely
• Streaming restore — reads .gz line-by-line, flat memory usage regardless of dump size
• Partial restore — select individual tables from a backup
• Pre-restore auto-backup — safety backup of current DB before any restore
• Backup integrity verification — gzip check + SQL structure validation
• Lock file — prevents concurrent backup processes
• Exclude tables — skip cache, sessions etc. from all backups
• Storage protected with .htaccess deny-all

Backup methods: mysqldump (preferred, InnoDB-safe hot backup) with PHP PDO fallback. Restore via mysql CLI with PHP PDO streaming fallback.

Requirements: ProcessWire 3.0+, PHP 8.0+, zlib, PDO. mysqldump/mysql CLI optional but recommended for large databases.

MIT License.

[szabesz]

Hi @maximus,

Thanks for ProcessDbBackup, it's a great module.

I've hit a workflow gap I'm hoping you can help me out. My setup is a usual "two-tier" ProcessWire arrangement: a production site plus a local MAMP Pro dev copy.

I frequently clone the production database down to local. Because ProcessWire stores module install-state and module config in the database, the clone brings production's ProcessDbBackup schedule settings (cron_interval / cron_weekly / cron_monthly) into my local environment, so LazyCron
starts firing real backups on my dev machine, which I never want there.

The issue is that there's no clean per-environment way to switch scheduled backups off on local:

• Editing the schedule to "never" in the DB gets overwritten by the very next clone, and
• uninstalling the module locally is disruptive and defeats keeping the environments in parity.

What would solve this (for example) is a runtime opt-out that lives in config, not the database, so it survives DB clones and can differ per environment.

Something like a `$config` flag honored in init():

// ProcessDbBackup::init()
$noCron = (bool) $this->wire('config')->processDbBackupDisableCron;
if (!$noCron && $this->cron_interval && $this->cron_interval !== 'never') {
    $this->addHook('LazyCron::' . $this->cron_interval, $this, 'cronBackup');
}
// ...same guard for cron_weekly and cron_monthly

Then on my MAMP Pro copy I'd just add to config-local.php (which I already have, BTW):

$config->processDbBackupDisableCron = true;

If a config flag doesn't fit your design, an equally workable alternative for me would be to make the cron entry points hookable (i.e. rename to `___cronBackup` / `___cronBackupWeekly` / `___cronBackupMonthly`) so I can change them with a hook, though the config flag above is cleaner since it prevents the LazyCron hooks from being registered at all.

Would either of these be OK to add? I am happy to test the new module version against my setup.

Thanks again for the module and for considering this.

[szabesz]

Hello @maximus, I was just wondering if you have had time to consider my request.

[maximus]

Hi,

Thanks for the detailed explanation. I agree that this is a real issue when a local/staging database is refreshed from production, because module settings are stored in the database and the LazyCron schedules come along with the clone.

I added support for a config-level opt-out in the dev branch.

You can now add this to site/config-local.php, site/config.php, or any environment-specific config file that loads before modules:

$config->processDbBackupDisableCron = true;

When this is enabled, ProcessDbBackup will not register its LazyCron hooks for regular, weekly, or monthly scheduled backups. Manual backups, restores, uploads, migrations, and the admin UI remain available.

This should solve the MAMP/local clone case without needing to uninstall the module or manually reset the schedule fields after every database refresh.

Please try the current dev branch and let me know if it works as expected in your setup.

@szabesz