Ozeki Database Backup for S3 is a security-focused WordPress database and uploaded-media backup plugin for Amazon S3.<\/p>\n\n
The plugin is designed for environments where WordPress can obtain AWS credentials through the AWS SDK for PHP default credential provider chain, such as an EC2 instance using an IAM role.<\/p>\n\n
The plugin does not provide fields for storing an AWS Access Key ID or Secret Access Key in the WordPress database.<\/p>\n\n
Current features include:<\/p>\n\n
mysqldump<\/code> or mariadb-dump<\/code> when available.<\/li>\n- PHP-based database dump fallback when native database dump utilities or process execution are unavailable.<\/li>\n
- Configurable retention using any positive integer keep count.<\/li>\n
- Backup history stored locally in WordPress.<\/li>\n
- S3 connection testing with temporary test objects.<\/li>\n
- Automatic cleanup of plugin Cron events when the plugin is deactivated.<\/li>\n
- On-demand uploads-directory backups started from WordPress administration.<\/li>\n
- Background media inventory, checksum preparation, multipart upload, and verification using WordPress Cron.<\/li>\n
- Per-file SHA-256 inventory and a final S3 completion marker.<\/li>\n
- WP-CLI media status, worker, preparation, submission, and explicit failed-job cleanup commands.<\/li>\n<\/ul>\n\n
AWS authentication<\/h4>\n\n
Ozeki Database Backup for S3 uses the AWS SDK for PHP default credential provider chain.<\/p>\n\n
The plugin does not ask you to enter an AWS Access Key ID or Secret Access Key in the WordPress administration interface and does not intentionally store long-lived AWS credentials in the WordPress database.<\/p>\n\n
For WordPress hosted on Amazon EC2, using an IAM role attached to the EC2 instance is recommended.<\/p>\n\n
Other credential sources supported by the AWS SDK default credential provider chain may also work, depending on the hosting environment.<\/p>\n\n
The AWS identity used by WordPress must have appropriate permissions for the configured S3 bucket and prefix.<\/p>\n\n
Database backup<\/h4>\n\n
Database backups are created as SQL dumps, compressed with gzip, and uploaded to the configured S3 bucket.<\/p>\n\n
Backup objects are stored below:<\/p>\n\n
<configured-prefix>\/backups\/database\/YYYY\/MM\/DD\/\n<\/code><\/pre>\n\nThe plugin prefers a native MySQL-compatible dump utility such as mysqldump<\/code> or mariadb-dump<\/code> when available.<\/p>\n\nWhen a suitable native dump utility or PHP process execution is unavailable, the plugin can use its PHP database dump backend instead.<\/p>\n\n
Media backup<\/h4>\n\n
Media backup covers regular files below the current single-site WordPress uploads directory. It is separate from database backup and must be started explicitly.<\/p>\n\n
Media jobs prepare a sorted file inventory and SHA-256 checksums in bounded background steps, upload files as individual S3 objects, and publish a completion marker only after the inventory and uploaded objects have been verified. Large files use S3 multipart upload.<\/p>\n\n
Media objects are stored below:<\/p>\n\n
<configured-prefix>\/backups\/media\/<random-job-id>\/\n<\/code><\/pre>\n\nBefore media backup can be started from WordPress administration, the server administrator must define ODBFS3_MEDIA_WORK_DIR<\/code> in wp-config.php<\/code>. Its value must be an existing persistent POSIX directory owned by the WordPress PHP user, with mode 0700, outside the web root, wp-content<\/code>, and uploads. Do not use a publicly served path or a temporary directory that may be cleared while a job is running.<\/p>\n\nFor example:<\/p>\n\n
define('ODBFS3_MEDIA_WORK_DIR', '\/private\/persistent\/wordpress-media-work');\n<\/code><\/pre>\n\nKeep the uploads tree unchanged while a media backup runs. New, removed, renamed, or changed files or directories can stop the job safely. Media backup has no automatic schedule or retention in this release. A failed job must be inspected and its exact Job ID explicitly cleaned with WP-CLI before another media job is submitted.<\/p>\n\n
This release does not provide a production media restore command. The S3 completion marker and inventory are intended to support independent restoration and full SHA-256 verification. A complete WordPress recovery requires both an appropriate database backup and the corresponding media backup.<\/p>\n\n
Automatic database backups and WP-Cron<\/h4>\n\n
Automatic backups use WordPress WP-Cron.<\/p>\n\n
WP-Cron is triggered by WordPress requests and is not a real-time operating system scheduler. A backup scheduled for a particular time may therefore run later if the site receives no requests around that time.<\/p>\n\n
For environments where predictable execution is important, use an operating system scheduler to run WordPress Cron periodically.<\/p>\n\n
For a standard WP-CLI installation, an example is:<\/p>\n\n
*\/5 * * * * cd \/path\/to\/wordpress && wp cron event run --due-now --quiet\n<\/code><\/pre>\n\nFor a Docker Compose installation with a WP-CLI service, an example is:<\/p>\n\n
*\/5 * * * * cd \/path\/to\/docker-project && docker compose run --rm wp-cli cron event run --due-now --quiet\n<\/code><\/pre>\n\nThese are examples only. Paths, users, container configuration, and execution permissions depend on your hosting environment.<\/p>\n\n
Retention<\/h4>\n\n
Retention can be disabled or configured with any positive integer as the number of latest database backups to keep.<\/p>\n\n
Retention operates only on database backup objects matching the plugin's expected backup naming structure below the configured S3 prefix.<\/p>\n\n
Manual backups do not automatically apply retention.<\/p>\n\n
Automatic backups and backups executed through the plugin's WP-CLI backup command apply the configured retention policy after a successful backup.<\/p>\n\n
Uninstall behavior<\/h4>\n\n
Deactivating the plugin removes its scheduled database and media WordPress Cron events but keeps plugin settings, backup history, and media job state.<\/p>\n\n
Uninstalling the plugin removes its local WordPress settings, backup history, current media job state, and archived media job metadata.<\/p>\n\n
Uninstalling Ozeki Database Backup for S3 does NOT delete database or media backups stored in Amazon S3. It also does not automatically remove private media work directories or discover unknown incomplete multipart uploads.<\/p>\n\n
This is intentional. Remote backups should not disappear merely because the WordPress plugin is removed.<\/p>\n\n
External Service<\/h3>\n\n
Ozeki Database Backup for S3 connects to Amazon Web Services (AWS), specifically Amazon Simple Storage Service (Amazon S3), in order to store and manage database and media backup objects.<\/p>\n\n
The plugin uses the AWS SDK for PHP to communicate with AWS.<\/p>\n\n
When the plugin performs a database backup, it sends the following to Amazon S3:<\/p>\n\n
\n- The configured S3 bucket name.<\/li>\n
- The configured S3 object prefix and generated backup object key.<\/li>\n
- The gzip-compressed SQL database backup file.<\/li>\n<\/ul>\n\n
When the plugin performs a media backup, it sends the following to Amazon S3:<\/p>\n\n
\n- The configured S3 bucket name.<\/li>\n
- The configured S3 object prefix and generated media backup keys.<\/li>\n
- Files from the WordPress uploads directory.<\/li>\n
- A generated inventory containing relative paths, sizes, SHA-256 checksums, and object mappings.<\/li>\n
- A generated completion marker after all media objects and the inventory have been verified.<\/li>\n<\/ul>\n\n
Media upload and verification may create, list, inspect, complete, or abort multipart uploads and may inspect uploaded objects. Explicit cleanup of an exact failed media job may abort only its recorded incomplete multipart upload. The plugin does not automatically delete completed media backup objects.<\/p>\n\n
Files in the WordPress uploads directory may contain personal, private, copyrighted, or otherwise sensitive content. Administrators are responsible for selecting an appropriate S3 destination, access policy, encryption configuration, retention policy, and legal basis for storing that content.<\/p>\n\n
A database backup may contain any information stored in the WordPress database. Depending on the site, this may include personal or sensitive data such as user accounts, email addresses, post content, comments, plugin settings, and other database records.<\/p>\n\n
When the S3 connection test is run, the plugin:<\/p>\n\n
\n- Checks access to the configured bucket.<\/li>\n
- Creates a temporary test object containing a generated test string and timestamp.<\/li>\n
- Reads the temporary object back to verify access.<\/li>\n
- Deletes the temporary test object.<\/li>\n<\/ul>\n\n
Retention operations may list and delete database backup objects within the configured backup prefix according to the selected retention policy.<\/p>\n\n
Use of Amazon S3 is subject to Amazon Web Services terms and privacy policies:<\/p>\n\n
AWS Customer Agreement:\nhttps:\/\/aws.amazon.com\/agreement\/<\/p>\n\n
AWS Privacy Notice:\nhttps:\/\/aws.amazon.com\/privacy\/<\/p>\n\n
AWS Service Terms:\nhttps:\/\/aws.amazon.com\/service-terms\/<\/p>\n\n
No telemetry, analytics, advertising, or unrelated tracking data is intentionally sent by Ozeki Database Backup for S3 to the plugin author.<\/p>\n\n
WP-CLI<\/h3>\n\n
Create a database backup:<\/p>\n\n
wp ozeki-database-backup-for-s3 backup\n<\/code><\/pre>\n\nDisplay backup configuration and status:<\/p>\n\n
wp ozeki-database-backup-for-s3 status\n<\/code><\/pre>\n\nQueue media preparation and upload using an existing private work directory:<\/p>\n\n
wp ozeki-database-backup-for-s3 media enqueue \/private\/persistent\/wordpress-media-work\n<\/code><\/pre>\n\nDisplay safe media job status:<\/p>\n\n
wp ozeki-database-backup-for-s3 media status\n<\/code><\/pre>\n\nRun one bounded media worker callback, for example from a server scheduler:<\/p>\n\n
wp ozeki-database-backup-for-s3 media tick\n<\/code><\/pre>\n\nFor a directory that exceeds the background enumeration budget, prepare and submit from WP-CLI:<\/p>\n\n
wp ozeki-database-backup-for-s3 media prepare \/private\/persistent\/wordpress-media-work\n\nwp ozeki-database-backup-for-s3 media start \/private\/persistent\/wordpress-media-work\/odbfs3-preparation-...\n<\/code><\/pre>\n\nAfter inspecting an exact failed media job, explicitly clean only its recorded incomplete multipart upload and private workspace:<\/p>\n\n
wp ozeki-database-backup-for-s3 media cleanup <job-id> --yes\n<\/code><\/pre>\n\n\n\n- Install and activate Ozeki Database Backup for S3.<\/li>\n
- Make sure the WordPress server can obtain AWS credentials through the AWS SDK default credential provider chain.<\/li>\n
- Grant the AWS identity access to the intended S3 bucket and prefix.<\/li>\n
- Open Settings > Ozeki Database Backup for S3.<\/li>\n
- Enter the AWS Region, S3 Bucket, and optional S3 Prefix.<\/li>\n
- Save the settings.<\/li>\n
- Use \"Test Connection\" to verify S3 read\/write\/delete access.<\/li>\n
- Use \"Backup Now\" to create the first database backup.<\/li>\n
- Optionally enable the daily automatic database backup schedule and configure retention.<\/li>\n
- To use media backup, create a persistent private POSIX directory outside all web-accessible directories, owned by the WordPress PHP user with mode 0700.<\/li>\n
- Define
ODBFS3_MEDIA_WORK_DIR<\/code> in wp-config.php<\/code> with that directory's absolute path.<\/li>\n- Return to the settings page and use \"Start Media Backup\". Keep uploads unchanged until the job succeeds or fails.<\/li>\n<\/ol>\n\n
For Amazon EC2, an IAM role attached to the instance is recommended instead of storing long-lived AWS access keys on the WordPress server.<\/p>\n\n\n
\nDoes this plugin store my AWS Access Key ID or Secret Access Key?<\/h3><\/dt>\nThe plugin does not provide settings fields for long-lived AWS Access Key IDs or Secret Access Keys and does not intentionally store them in the WordPress database.<\/p>\n\n
AWS authentication is handled through the AWS SDK for PHP default credential provider chain.<\/p><\/dd>\n
Is an EC2 IAM role required?<\/h3><\/dt>\nNo.<\/p>\n\n
An EC2 IAM role is the recommended authentication method when WordPress is hosted on Amazon EC2, but other credential sources supported by the AWS SDK default credential provider chain may also work.<\/p><\/dd>\n
Are database backups encrypted?<\/h3><\/dt>\nThe plugin uploads backups to Amazon S3 over the AWS SDK connection.<\/p>\n\n
Encryption at rest depends on the configuration of the destination S3 bucket and applicable AWS settings.<\/p>\n\n
Administrators should configure the S3 bucket according to their own security and compliance requirements.<\/p><\/dd>\n
Does uninstalling the plugin delete my S3 backups?<\/h3><\/dt>\nNo.<\/p>\n\n
S3 database backup objects are intentionally preserved when the plugin is uninstalled.<\/p><\/dd>\n
Does the automatic backup run at an exact time?<\/h3><\/dt>\nNot necessarily.<\/p>\n\n
The automatic backup uses WP-Cron, which depends on WordPress requests to trigger due events.<\/p>\n\n
For more predictable execution, configure a real operating system scheduler to periodically execute due WordPress Cron events.<\/p><\/dd>\n
What happens if mysqldump is not available?<\/h3><\/dt>\nThe plugin can fall back to a PHP-based database dump implementation when a supported native dump utility or process execution is unavailable.<\/p>\n\n
The PHP fallback opens a separate database connection using the database constants already defined by WordPress. This keeps its consistent-snapshot transaction isolated from WordPress's shared database connection; it does not accept database connection values from an HTTP request or plugin setting.<\/p><\/dd>\n
What does the S3 connection test do?<\/h3><\/dt>\nIt checks access to the configured S3 bucket, writes a temporary test object, reads it back, verifies the contents, and then deletes it.<\/p><\/dd>\n
What does media backup include?<\/h3><\/dt>\nIt includes regular files under the current single-site WordPress uploads directory. It does not include the WordPress database, themes, plugins, wp-config.php<\/code>, or other site files. Run a separate database backup for the corresponding database state.<\/p><\/dd>\nCan this plugin restore a media backup?<\/h3><\/dt>\nNot in this release. A completed media backup contains a verified inventory, individual file objects, and a completion marker intended for an independently verified restore process. Test restoration procedures before relying on any backup system.<\/p><\/dd>\n
Can media backup run automatically or apply retention?<\/h3><\/dt>\nNot in this release. Media backup is started explicitly and is separate from the daily database schedule and database retention setting.<\/p><\/dd>\n\n<\/dl>\n\n\n
0.2.0<\/h4>\n\n\n- Added on-demand backups of the WordPress uploads directory from the settings page.<\/li>\n
- Added bounded background file enumeration, sorting, SHA-256 preparation, upload, and verification through WordPress Cron.<\/li>\n
- Added individual S3 media objects, multipart support for large files, a verified inventory, and a final completion marker.<\/li>\n
- Added authenticated media start and status controls with safe progress reporting.<\/li>\n
- Added WP-CLI media enqueue, prepare, start, tick, status, and explicit failed-job cleanup commands.<\/li>\n
- Added persistent leases, workspace locking, crash recovery, and stale-worker fencing for media jobs.<\/li>\n
- Added exact, idempotent cleanup for a failed job's recorded incomplete multipart upload and private workspace without deleting completed backups.<\/li>\n
- Added strict private-work storage validation and source-change detection.<\/li>\n<\/ul>\n\n
0.1.1<\/h4>\n\n\n- Renamed the plugin to Ozeki Database Backup for S3.<\/li>\n
- Removed the fixed 7, 14, or 30 backup retention choices; any positive integer keep count is now supported.<\/li>\n
- Clarified the separate database connection used by the PHP dump fallback.<\/li>\n
- Fixed Daily Cron registration when settings are saved for the first time.<\/li>\n<\/ul>\n\n
0.1.0<\/h4>\n\n\n- Initial public release.<\/li>\n
- Added manual database backup to Amazon S3.<\/li>\n
- Added automatic daily database backups using WP-Cron.<\/li>\n
- Added configurable S3 backup retention.<\/li>\n
- Added WP-CLI backup and status commands.<\/li>\n
- Added native MySQL\/MariaDB dump support with PHP fallback.<\/li>\n
- Added backup history.<\/li>\n
- Added plugin activation, deactivation, and uninstall lifecycle handling.<\/li>\n
- Added AWS default credential provider authentication.<\/li>\n<\/ul>","raw_excerpt":"Back up WordPress databases and uploads to Amazon S3 without storing long-lived AWS access keys in WordPress.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/355094","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=355094"}],"author":[{"embeddable":true,"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/ozekihiroshi"}],"wp:attachment":[{"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=355094"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=355094"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=355094"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=355094"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=355094"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/sv.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=355094"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}