Welcome to the NZRT Wiki Podcast. Today we’re looking at Backups.

Backups are the safety net for everything NZRT runs online — WordPress, Dolibarr, Nextcloud, and the full cPanel hosting account. In this episode, you’ll get a clear picture of where backups live, how often they run, and exactly what to do if you ever need to restore something.

Let’s start with where backups are stored. There are five main backup types at NZRT. WordPress archives live in a folder called wordpress-backups on the web server, managed by cPanel and JetBackup. Full cPanel account backups are handled automatically through JetBackup as well. Database dumps are bundled right in with those cPanel backups, so you don’t have to worry about databases being missed. Nextcloud data has its own dedicated folder on the server under the cloud dot nzrtnetwork dot com directory, managed by both Nextcloud and cPanel. And Dolibarr data sits in its own folder under erp dot nzrtnetwork dot com, covered by cPanel plus some manual steps.

If you ever need to access the WordPress backups directly, you can do that over a secure WebDAV connection — think of it like a network drive that maps straight to the server’s wordpress-backups folder, over an encrypted connection on port 2078.

Now let’s talk about what’s actually inside a WordPress backup. Each archive contains three main things: all the WordPress files — that includes your theme, plugins, and uploaded media in the wp-content folder — a full dump of the MySQL database, and the two critical configuration files, htaccess and wp-config dot php. So a full restore is genuinely possible from a single backup archive.

Those backups are generated by a few different tools. JetBackup is the primary one — it’s a cPanel plugin that runs automated scheduled backups without you having to do anything. The cPanel Backup Wizard is there for on-demand full account backups when you want one manually. And if a WordPress backup plugin like UpdraftPlus is installed on the site, that adds another layer of coverage on top.

So how often do backups run? There are five items in the schedule. WordPress files and the database are backed up daily, with seven days of copies kept. Dolibarr is the same — daily, seven days retention. Nextcloud is also daily with seven days kept. The full cPanel account backup runs weekly and keeps four weeks of copies. And offsite backups — where you download everything to Nextcloud or a local drive — are recommended monthly, keeping three months of copies. That monthly offsite step is the one most likely to get skipped, so it’s worth putting a calendar reminder on it.

Now, if the worst happens and you need to restore something, here’s how each service works.

For WordPress, you start by opening the wordpress-backups folder over that WebDAV connection and finding the archive with the right date. From there you can either use JetBackup’s built-in restore function, which is the easiest path, or do it manually by extracting the archive into the website’s root folder and importing the database through phpMyAdmin. If the database credentials have changed since the backup was made, you’ll also need to update wp-config dot php with the new details.

For Dolibarr, the steps are similar. Restore the files from JetBackup into the Dolibarr server folder, import the database through phpMyAdmin, and then check the configuration file inside the conf folder to make sure all the settings still point to the right places.

For Nextcloud, restore the files from JetBackup into the Nextcloud server folder and import the database — but there’s one extra step you can’t skip. You’ll need to run a command via SSH or the cPanel Terminal that switches Nextcloud out of maintenance mode. Essentially it tells Nextcloud that the maintenance window is over and it’s safe to go live again. It’s easy to forget, so make a note of it now.

Finally, there’s a maintenance checklist that keeps the whole system healthy over time. First, confirm that JetBackup is active and the schedule is properly configured. Second, run a test restore every quarter — don’t assume backups are working, actually verify it. Third, download an offsite copy of all services every month to Nextcloud or a local drive. Fourth, record the date of your last successful restore test somewhere in the wiki so there’s a clear audit trail. And fifth, check that the wordpress-backups folder is not publicly accessible — the htaccess file should be blocking outside access, but it’s worth confirming.

Backups only matter if they’re tested and accessible when you actually need them. The automated systems here are solid, but the human checklist steps — those quarterly restore tests and monthly offsite copies — are where most teams fall short. Keep those in your calendar and you’ll be in good shape.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Per-Subdomain Backups, specifically the underscore backup folder.

The core idea here is straightforward. On the NZRT server, each subdomain — things like your WordPress site, your Dolibarr ERP, your Nextcloud instance, and your mail service — each one has its own dedicated backup folder sitting right inside it. This keeps your backup history clean and separated by service, so you always know exactly where to look when something goes wrong.

Let’s talk about what that folder looks like. Inside each subdomain’s backup folder, you’ll find three subfolders. First, there’s a daily folder, which holds your automated daily snapshots. Second, there’s a weekly folder for automated weekly archives. And third, there’s a manual folder — this is where on-demand backups go, the ones you run yourself before a major update or a migration. Simple, clean, and predictable.

Now, where are these folders actually located on the server? There are four main subdomains covered. For WordPress, the backup path lives under the main nzrtnetwork.com folder in the server’s web root. For Dolibarr, it’s under the erp subdomain folder. For Nextcloud, it’s under the cloud subdomain folder. And for mail, it’s under the mail subdomain folder. Each one follows the same pattern — the subdomain’s root folder, then the backup folder inside it. You access these through WebDAV, using the SSL port 2078 to connect, then drilling down into whichever subdomain you need. If you’ve already mapped a network drive through cPanel’s WebDAV interface, that same approach applies here.

Naming your backup files consistently is really important, and NZRT has a clear convention for this. Each filename has three parts: the service name, the type of backup, and the date in year-month-day order, finished off with a compressed archive extension. So you might see something like wordpress-files followed by a date, or dolibarr-db followed by a date with an sql dot gz extension, or nextcloud-full followed by a date. At a glance you know what service it covers, what kind of backup it is, and exactly when it was made.

Let’s look at the schedule. The daily folder gets a new snapshot every single day, and you keep the last seven — so a rolling week of daily backups. The weekly folder runs every Monday and retains four files, giving you roughly a month of weekly history. Both of these are automated through JetBackup or a scheduled cron job, so you don’t have to think about them. The manual folder is different. You fill it yourself whenever you need to — typically right before a major update or a migration — and you clear it out once you’re confident those files are no longer needed.

It’s worth understanding how these per-subdomain backup folders relate to the root-level wordpress-backups folder that also exists on the server. That root-level folder is managed entirely by cPanel and JetBackup automatically — you don’t set it up or maintain it yourself. The per-subdomain backup folders are completely separate and in addition to that. Think of the cPanel folder as a safety net running quietly in the background, and the per-subdomain folders as the organised, scripted backups that follow NZRT’s naming convention and that you have direct control over. Over time, the per-subdomain setup becomes your primary reference, while the cPanel folder remains your fallback.

Finally, an important security point. Because these backup folders sit inside each subdomain’s web root, they are technically reachable from the internet unless you explicitly block them. You do not want anyone browsing your backup files. The fix is to add a single rule to the subdomain’s htaccess file — a directive that returns a 403 Forbidden response for any request targeting the backup folder path. Alternatively, you can handle this through cPanel’s File Manager by setting the folder permissions to non-executable. Either approach works. The key is to do this before your apps go fully live, so those backup archives are never exposed publicly.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.