Welcome to the NZRT Wiki Podcast. Today we’re looking at Backup Strategy.
So, NZRT runs regular backups of its WordPress site covering both the database and the actual files. The goal is straightforward: if something goes wrong, whether that’s data loss, a hack, or corruption, you want to be able to recover quickly and confidently.
Let’s start with what gets backed up and how often. There are four main components. First, the database, which is backed up every single day and kept for thirty days. Second, the WordPress files, also daily with thirty days of retention. Third, the uploads folder, again daily, thirty days. And fourth, plugins and themes, which are backed up weekly and kept for twelve weeks. The daily items use tools called mysqldump, rsync, and tar, while the weekly plugin and theme backups use git or zip archives.
All of these backups land in a directory called Back-ups. Inside that folder you’ll find database dump files, compressed WordPress file archives, incremental backups, and restore scripts, so everything you need to recover is kept together in one place.
Now let’s talk about how the backups are actually made. For the database, the process runs a command that connects to the WordPress database as the root user and exports everything into a single file. The filename automatically includes today’s date, so you always know exactly when each backup was taken.
For the files, the process creates a compressed archive of the entire WordPress directory. Again, the filename gets today’s date stamped into it automatically.
On the production server specifically, there are a couple of key backup locations. WordPress archives live in a dedicated wordpress-backups folder on the server, and these are primarily managed by a tool called JetBackup, which runs automatically and is handled by the hosting provider. You can also trigger on-demand backups through cPanel’s Backup Wizard if you need one right now. If you want to browse or download these production archives from Windows, you can open a special WebDAV network path in Windows Explorer that connects directly to that wordpress-backups folder over a secure connection.
One important security point here: that wordpress-backups folder must never be publicly accessible from the internet. You can verify this by sending a request to the URL of that folder. If everything is configured correctly, the server should respond with a four-oh-three Forbidden status. If you get anything else back, that’s a problem that needs to be addressed immediately, because publicly accessible backups could expose sensitive data.
Now, what about restoring from a backup? If you need to restore the database, you run a command that reads a specific backup file and imports it directly into the WordPress database. You reference the backup by its date in the filename, so for example you’d point it at the file from the twelfth of April twenty twenty-six. For restoring the files, you extract the compressed archive back to the root of the server. Again, you reference the dated backup file you want to restore from.
Finally, in terms of who owns all of this at NZRT, that’s dan, the DBA. Dan is responsible for backup and recovery, so if you have questions or need to initiate a restore, that’s your first point of contact.
That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.