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

If you’re running NZRT’s Nextcloud instance, backups are not optional. They protect against data loss, ransomware, and hardware failure, and they cover Dolibarr and WordPress data too. So let’s walk through exactly how the backup strategy works, what the restore process looks like, and what regular maintenance tasks you need to keep on top of.

First, the strategy at a high level. Backups run on two cycles. Daily incremental backups capture only what’s changed since the last run. Weekly full backups capture everything from scratch. Retention is thirty days for backups you can access online, and one year for archived copies. Storage spans two locations: a local NAS device on-site, and an off-site destination, either an S3 cloud bucket or tape storage. Two important numbers to know here: RPO and RTO. RPO stands for Recovery Point Objective, meaning the maximum amount of data you’re willing to lose. For NZRT Nextcloud that’s four hours. RTO stands for Recovery Time Objective, meaning how fast you need to be back online after a failure. That target is one hour.

Now let’s talk about what actually gets backed up. There are three components. First is the MySQL database, which runs between five and ten gigabytes. That backs up every day at four in the morning using either mysqldump or Percona XtraBackup. Second is the Nextcloud data folder containing all user files, which can range from five hundred gigabytes up to two terabytes. That one backs up weekly, on Sunday nights at two in the morning, using rsync or tar. Third are the configuration files, which are under one gigabyte and back up monthly to the NAS using rsync.

Now let’s walk through the backup script itself. The script is written in Bash and runs automatically. It starts by setting up a destination folder on the NAS and generating a timestamp so every backup file gets a unique name. It then runs a database dump, which exports the entire Nextcloud database into a single SQL file named with that timestamp. Once that’s done, it compresses the file to save space. Next it uses rsync to copy all Nextcloud user files across to the NAS. After that, it sweeps through the backup folder and deletes any compressed database files that are older than thirty days, keeping storage tidy. Finally, if the script detects it’s running on a Sunday, it pushes everything up to the S3 cloud bucket for off-site storage.

So what happens when you actually need to restore? There are four steps, and the order matters.

Step one: put Nextcloud into maintenance mode. This locks out users and prevents any data being written while you’re restoring.

Step two: restore the database. You feed your backup SQL file directly into MySQL and it rebuilds the database from that file.

Step three: restore the files. You use rsync to copy everything from the NAS backup location back into the Nextcloud data directory. You also reset file ownership so the web server process can read and write those files correctly.

Step four: bring Nextcloud back online by switching maintenance mode off. If the database schema looks different from what Nextcloud expects, there’s an additional command you can run that converts the file cache to handle larger integers, which is sometimes needed after a schema change.

Recovery procedures must be tested quarterly. That responsibility sits with xc, the admin. Dan, the DBA, manages the backup infrastructure itself.

On the maintenance side, there are four recurring tasks to stay on top of. The first is a monthly database integrity check, which ensures the internal file tracking database is healthy. The second is a weekly trash cleanup that clears out deleted files from the Nextcloud trash and reclaims storage space. Third is updating the dot-htaccess file, which you run as needed to keep web server rules in sync with Nextcloud’s configuration. Fourth is a weekly file scan that checks all user files are correctly indexed so search and file listings stay accurate.

To wrap up: daily database backups at four AM, weekly file backups Sunday nights at two AM, thirty days online retention, one year archived, local NAS plus S3 off-site, a four-hour data loss ceiling, and a one-hour recovery target. Dan owns the infrastructure, xc tests restores every quarter. Keep those maintenance commands running on schedule and you’ll be in good shape.

For more detail, check the related wiki notes on Administration Overview, Logging and Monitoring, and the occ Command Reference.

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