WordPress backups and restores must pair web files with the DB

WordPress core was updated 8 times in 2023 alone, and if you include 2022 as well, it reaches 20 times — changing that frequently. Netmarble runs a tech blog and a developer site, and has been checking plugin dependencies and rollback strategy together each time the core is updated.

The problem is that moving only the web files to a test server can't recreate the same state as live. Because plugins create separate tables or store values in wp_options, you need to copy the web files and the DB as a pair to get an environment identical to the real one.

Taking a snapshot of the entire infrastructure was judged too burdensome for flexibly finding and restoring files and data. Instead, they built their own backup and restore procedures with shell script, tailored to their Linux VM environment.

The backup was structured in the following order.

• Dump MariaDB with mysqldump --single-transaction
• Compress the WordPress web files with tar -zcf
• Transfer the results to a separate backup server via scp
• Keep logs to check total elapsed time, and clean up files older than 60 days with find -mtime +60

The restore was designed around the test server configuration. After locating the latest .sql and .tar.gz files, it renames the existing /wordpress directory and unpacks the web files into place. Then it creates a new DB, imports the dump, replaces the domain with the test domain in wp_posts, wp_postmeta, and wp_options, and also changes WP_HOME, WP_SITEURL, and DB_NAME in wp-config.php.

With this approach, some blogs had the entire backup and restore finish in around 10 minutes, while the developer site took about 1 hour. In the end, they even attached a Crontab that runs every Saturday at midnight, creating a setup that reproduces a sandbox nearly identical to live for update testing.