Salvocofre Backup Wordpress Plugin - Rating, Reviews, Demo & Download

Salvocofre Backup Preview Wordpress Plugin - Rating, Reviews, Demo & Download

No ratings yet

Free

Follow for free plugins, new theme releases and theme news

Plugin Description

Salvocofre Backup creates a ZIP archive with the site files and a SQL dump of the database, keeps the previous backups under a retention limit, and can restore the database from any complete archive. It works on a single WordPress installation; multisite is not supported.

Each backup is a set of two files in wp-content/salvocofre-backups/:

salvocofre-YYYYMMDD-HHMMSS.zip — the SQL dump plus every readable file in the WordPress installation.
salvocofre-YYYYMMDD-HHMMSS.sql — the same database dump on its own.

Names use the site time zone and are never reused: if two runs start in the same second, the second one gets a -2 suffix. A new backup never overwrites an older one; old sets are removed only by the retention limit or by hand.

The database dump

Starts with the site URL, the UTC date, SET SESSION sql_mode = '' and SET NAMES with the database charset and collation.
Disables foreign key checks and opens a consistent snapshot before reading the tables.
Writes DROP TABLE IF EXISTS and CREATE TABLE for every table, followed by one INSERT per row.
Ends with COMMIT and re-enables foreign key checks.
Checks $wpdb->last_error after every query, so a missing table or a failed read stops the backup instead of producing a partial file.
Writes binary or non-UTF-8 values as hexadecimal literals.
Includes every table in the current database, including tables created by other plugins.
Does not include views, triggers, stored procedures or events.

The ZIP archive

Contains the SQL dump at the archive root and the site files under their original relative paths.
Excludes the backup directory itself, wp-content/cache and wp-content/upgrade.
Includes wp-config.php, so treat the archive as sensitive data.
If a file cannot be added, the run fails and the partial archive is removed.

Managing backups

The top-level Salvocofre menu opens the Backups screen. The table shows the date, the file names, the total size and the actions for every backup set:

Download (.zip) and Download (.sql) stream one file through admin-post.php; the link carries a nonce and the path is rebuilt from the requested backup name.
Delete removes both files of the set. It is a POST request with a nonce tied to that set, so a stale link cannot delete another backup.
A set with only one file is marked Incomplete and is kept until it is deleted by hand. Retention never removes it.

The dashboard widget shows the latest backup, the number of sets and the total size on disk, with a link to the full screen and a Backup now button. The Backups screen also has a Backup now button.

Restoring the database

Tools > Salvocofre Restore restores the database from the .zip archive of a backup set. The screen shows a restore form only for sets whose ZIP exists and is not empty.

Type the exact backup name to confirm the operation.
The plugin creates a full safety backup first. If that backup fails, the restore is aborted.
The archive is extracted to a temporary directory outside the web root. Entries with absolute paths, .. references, null bytes or symbolic links are rejected before any archive entry is written, and archives with more than 50,000 entries are refused by default.
Only the SQL dump is executed. The site files in the archive are validated and then discarded; the files of the installation are not changed.
The restore routine does not delete the backup it used, and the safety backup is kept too. Both count toward the retention limit. The object cache is flushed when the process finishes.

A failing SET statement is logged and skipped, because restricted database users may not be allowed to change every session value. Any other failing statement stops the restore and shows the error, so a restore can leave the database partially restored. You may need to sign in again after the database changes.

The restore screen cannot restore a .sql file on its own, and it does not restore site files. To recover files, extract the ZIP over the WordPress directory manually.

Automatic backups

Settings > Salvocofre Backup controls scheduled backups:

The schedule is enabled by default with a daily frequency after activation.
Frequencies: hourly, twice daily, daily and weekly.
Changing the frequency replaces the existing event; it never creates a second event.
The same screen shows the last scheduled run, its result and the next due time, and warns when the event is overdue, missing or when DISABLE_WP_CRON is set.
A lock prevents two backups from running at the same time, whether they are scheduled or started by hand. A lock older than 15 minutes is treated as abandoned and can be taken over.

WP-Cron only runs when the site receives traffic. A quiet site can therefore run an automatic backup late. To keep the schedule on time, disable WP-Cron and call wp-cron.php from a system cron job.

The status e-mail is sent for manual backups started from the admin screens: a failure is reported whenever the administrator address is valid, and a success is reported only when the salvocofre_email_on_success option is enabled (there is no setting for it in the admin screens yet). The message goes to the site administrator address and can be redirected with the salvocofre_status_email_recipient filter. A failed scheduled run is recorded in the settings status and in the site log, but it does not send an e-mail.

Retention

The Backups to keep setting defaults to 5 and accepts 0 to 50. Zero keeps every backup. The limit is applied after every successful backup, manual or scheduled, and only complete sets count. Sets left incomplete by an interrupted run stay on disk until they are deleted.

Pre-flight checks

Before writing any file, the plugin estimates the database size from information_schema (cached for 10 minutes) and checks three limits:

Memory: a fixed floor of 64 MB. The dump is streamed to disk in chunks, so the requirement does not grow with the database.
Disk: about twice the database size plus 16 MB against the free space of the backup directory.
Time: about five seconds plus one second per 2 MB against max_execution_time.

A backup that would exceed a known limit is stopped with an explanatory error before the dump starts. When PHP does not expose a limit, that check is skipped.

The backup directory

The plugin creates wp-content/salvocofre-backups/ on activation and on every admin request if it is missing. The directory receives an .htaccess file that denies direct access and an empty index.php. Define SALVOCOFRE_BACKUP_DIR in wp-config.php before the plugin loads to use another absolute path.

Downloads do not rely on direct access to that directory: they are served by admin-post.php after the capability and nonce checks.

Who can run a backup

Users with the manage_options capability by default. The capability can be changed with the salvocofre_backup_capability filter.

Uninstall

Deactivation removes the scheduled event and any run lock; the backups are left untouched. Uninstall removes every plugin option and the run lock, so nothing is left in the database. The backup directory is kept unless the site owner has enabled the salvocofre_delete_backups_on_uninstall option; when enabled, the directory is removed as well.

Limitations

These limits are known and accepted for the current version:

Database size. Tested with a table of 150,000 rows: a 37.8 MB dump and a 42 MB archive in 8 seconds, with a peak of 42 MB of memory under a 128 MB limit. The dump is written to disk in chunks of 500 rows and the restore reads it back in 64 KB blocks, so memory stays flat. The remaining limit is time, not memory (see below).
Request time. Manual and scheduled backups run inside a request. A small site takes about 9 seconds; the 150,000-row test took 8 seconds to back up and 19 seconds to restore. Under Apache the default limit is 30 seconds, so a database several times larger than the test will hit the timeout. There is no background processing yet.
WP-Cron depends on traffic. Automatic backups only start when WordPress receives a request or when wp-cron.php is called by a system cron job. A quiet site can run a backup late.
Apache dependency. Directory protection relies on .htaccess. On nginx or another server that ignores .htaccess, you must add your own rule or move the directory outside the web root with SALVOCOFRE_BACKUP_DIR.
Multisite. Not supported. See the FAQ above.
Restore scope. Only the database is restored. The site files in the archive are not written to the installation. A restore that fails halfway can leave the database partially restored.
Restore input. Only backups with a non-empty .zip archive can be restored from the screen. A .sql file on its own cannot be restored there, and extraction needs a temporary directory outside the web root.
ZipArchive. The PHP zip extension is required. Without it, backups and restores fail with an error.
Database objects. Views, triggers, stored procedures and events are not included in the dump.
Retention and incomplete sets. Retention only deletes complete sets; a set with one missing file stays until it is deleted by hand.
Concurrent runs. A second backup started while one is running is refused with a warning instead of running in parallel. The refusal is not queued: you have to try again after the first run finishes.
Sensitive archive. The ZIP contains wp-config.php and the database dump, including password hashes and personal data. Keep it private.

Roadmap

Multisite support, restoring site files, background processing for large sites and dumping database objects such as views and triggers are not part of version 0.2.1. No release date is promised.

Screenshots

The Backups screen with the table of sets, the download and delete actions, and the total size on disk.
The Salvocofre Restore screen under Tools, with the warning, the backup table and the typed confirmation field.
The Salvocofre Backup settings screen with the schedule status, the frequency selector and the retention field.
The Backups screen right after a run, with the success notice and the new set at the top of the table.
The Backups screen after a failed run, with the notice naming the limit that stopped the backup.