Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Administration Overview.

So if you’re working with NZRT’s self-hosted tech stack, Nextcloud is a core piece of infrastructure. It serves over fifty users, and keeping it running smoothly is a shared responsibility between two key roles — the admin account, which is xc, and the database administrator, known as dan. Together they cover everything from keeping apps updated to making sure backups are running and security patches are applied on time.

Let’s walk through what that actually looks like day to day.

There are seven main admin tasks, and each one has a set frequency and an owner. First, updating apps — that happens monthly, and both xc and dan are responsible for it. Second, backing up the database and files — that’s a daily job owned by dan, so it’s happening every single day to make sure nothing is lost. Third, monitoring storage usage — dan handles that weekly, keeping an eye on how much space is being consumed across the system. Fourth, reviewing audit logs — that’s also weekly, but this one belongs to xc. Audit logs are important for spotting anything unusual in user activity or system behaviour. Fifth, user provisioning — that means creating accounts, managing access, and setting up new users — and that’s handled by xc on an as-needed basis. Sixth, performance tuning — this one is quarterly and belongs to dan. It involves things like optimising the cache and tuning the database to keep everything running fast. And seventh, security updates — those get applied as soon as they’re released, and both dan and xc share that responsibility together.

Now, the admin panel is broken down into four main sections. The first is Apps and Plugins, where you can install, enable, disable, and update any of the apps that extend Nextcloud’s functionality. The second is Backups and Maintenance, which covers the backup strategy and how you’d restore data if something went wrong. The third is Performance Tuning, where you’d look at cache optimisation and database settings to keep response times fast. And the fourth is Logging and Monitoring, which gives you health checks, alerts, and log analysis tools to stay on top of what the system is doing.

To get into the admin dashboard, you navigate to your NZRT Nextcloud instance, go to the admin section of the settings area, and log in with the xc account or any other account that has admin privileges. That single page is your central control panel for everything we’ve just discussed.

One thing worth understanding is the broader context here. For NZRT, Nextcloud isn’t just a nice-to-have — it’s mission-critical infrastructure. With over fifty users relying on it daily, the expectation is high availability, solid security, and consistent performance. That’s why responsibility is split the way it is. Dan handles the more technical, scheduled maintenance — daily backups, weekly storage checks, quarterly tuning. xc handles the governance and access side — audit log reviews, user provisioning, and security decisions. It’s a clean division that makes sure nothing falls through the cracks.

If you want to go deeper on any of these areas, the wiki has dedicated notes on each of the four sections we mentioned — Apps and Plugins, Backups and Maintenance, Performance Tuning, and Logging and Monitoring. Each of those goes into much more detail on the specific procedures and tools involved.

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 📦 Apps & Plugins.

Nextcloud on its own is already a powerful platform, but where it really shines is in its app ecosystem. You can extend what Nextcloud does by installing apps and plugins that plug straight into the core system. At NZRT, there’s a curated list of recommended apps that are either already installed or considered essential additions, and today we’re going to walk through all of that.

So let’s start with the recommended apps. There are three broad categories to think about: core functionality, security, and compliance or performance.

On the core side, you’ve got Talk, which handles chat, video, and calls. Then Calendar for scheduling and events, and Contacts for your address book. Deck handles task management, and Collectives gives you a built-in wiki and documentation space. Rounding out the core apps is Nextcloud Office, which lets you edit documents directly inside Nextcloud.

Then there are the security-focused apps. User LDAP handles Active Directory integration, so your existing user accounts can connect through. Two-Factor Authentication lets you enforce two-factor login across the platform. And Suspicious Login does exactly what it sounds like — it watches for unusual access patterns and flags anomalies.

Finally, from a compliance and performance angle, Audit Logging captures compliance-grade logs of activity on the system, and Full-Text Search indexes your documents so you can actually find things quickly.

Now, when you need to install a new app, you’ve got two ways to do it. The first is through the graphical interface. You go into Settings, then across to Apps, and you use the search field to find the app you want. Once you find it, you hit Install, approve whatever permissions it asks for, and then enable it. That’s the straightforward GUI route — no command line needed.

The second method is through the command line, and this is what system administrators often prefer for consistency and automation. There are two commands you’d run in sequence. The first tells the system to install the app by name. The second command then enables it so it becomes active. Simple two-step process on the server side.

Speaking of permissions — and this is important — whenever you’re installing an app, you should always stop and review what access it’s asking for. There are three main things to look at. First, file access: can this app read or write to user files? Second, user data: can it see usernames and email addresses? And third, admin functions: can it actually change system settings? These aren’t just checkbox exercises. Understanding what an app can access is how you prevent unintended data exposure.

Which brings us to how NZRT actually handles this process. It’s not a free-for-all. There’s a structured approval workflow before any new app hits production. Step one, your admin — that’s xc — evaluates whether the app actually meets the business requirement. Step two, there’s a permissions and security audit to understand what the app touches and whether that’s acceptable. Step three, the app gets tested in a staging environment first, not straight onto the live system. Step four, once it passes testing, it gets deployed to production and users are notified. And step five, the team monitors it after deployment — if something doesn’t look right, the app gets disabled.

The key people involved in that vetting process are xc on the admin side and dan on the security side. Together they make sure nothing goes into production that could cause data leakage or introduce vulnerabilities.

The bigger picture here is that apps are how you make Nextcloud fit NZRT’s actual workflows rather than working around a generic tool. Talk keeps internal communication inside the platform. Deck and Collectives mean project management and documentation don’t have to live in separate external systems. Office means you’re not exporting files to edit them elsewhere. Each app closes a gap, and the approval process makes sure closing that gap doesn’t open a new one.

If you want to dig deeper into related topics, the wiki also covers Administration Overview, Performance Tuning, and Audit Logs — all connected to this area.

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 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.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Logging & Monitoring.

Nextcloud generates logs constantly in the background, and understanding where those logs live and what they’re telling you is a core part of keeping the system healthy. At NZRT, logging ties directly into security auditing, performance monitoring, and catching issues before they become outages. So let’s walk through how all of this fits together.

First, let’s talk about where the logs actually are. There are five main log files you need to know about. The primary one is the Nextcloud application log, sitting at var www nextcloud data nextcloud dot log. This captures all Nextcloud events and is your first stop when something goes wrong. Next is the Apache access log at var log apache2 access dot log, which records every HTTP request hitting the server. Then the Apache error log at var log apache2 error dot log, which captures web server errors specifically. You also have the PHP-FPM log at var log php-fpm dot log for PHP-level errors, and finally the MySQL error log at var log mysql error dot log for anything going wrong at the database layer.

Now, how is logging configured? Inside Nextcloud’s main configuration file, there are a handful of settings that control this. The log type is set to file, so everything writes to disk. The log file path points to that nextcloud dot log location we just mentioned. There’s a log level setting that runs from zero to four — zero being debug, which logs everything including very verbose output, one for informational messages, two for warnings, three for errors, and four for fatal events only. NZRT runs at level two, so warnings and above get captured. The timezone is set to UTC for consistency, and there’s an automatic rotation setting — once the log file hits ten megabytes, it rolls over automatically so you’re not filling up your disk with a single enormous log file.

Next up is health checks. Nextcloud exposes a server info endpoint you can call to get a snapshot of system health. When you query that endpoint with admin credentials, the response tells you the current Nextcloud version, which PHP version and modules are loaded, the database connection status, current disk usage figures, how many users are active, and the state of background jobs. This is your go-to for a quick system pulse check, and it’s also something you can script to run on a schedule.

Speaking of schedules, let’s talk about monitoring thresholds. NZRT watches six key metrics. Disk usage triggers a warning at eighty percent and goes critical at ninety percent. Active concurrent users above one hundred is a signal to think about upgrading your plan. Database connections above eighty percent of the configured maximum need attention. Failed logins exceeding ten per hour are flagged as a potential attack. Background job queues with more than one hundred pending jobs indicate something is backed up. And Redis memory usage above eighty percent of its allocation means your cache is under pressure.

For alerting, there’s a bash script that runs on a cron schedule. What it does is check the current disk usage percentage for the Nextcloud data directory. If that number is above eighty, it sends an email alert to the admin address. It’s a simple but effective early warning for one of the most common failure modes — running out of space.

Now, how do you actually look at the logs day to day? You have two options. Through the web interface, you go into Settings, then Logging, and you’ll see the last entries displayed right there in your browser — no terminal needed. If you prefer the command line, you can stream the log live as events come in using tail, which is great for watching what’s happening in real time during a troubleshooting session. You can also search the log file for error entries and pull just the most recent twenty, which is usually enough to identify a pattern quickly.

To put this all in NZRT context — logging and monitoring aren’t just housekeeping. Failed background jobs can mean the Dolibarr sync isn’t running. A spike in failed logins could be a brute force attempt on the platform. Slow database queries show up in logs before they become user-facing problems. That’s why Dan, our DBA, reviews the logs on a daily basis. Catching something early in the logs is almost always cheaper than dealing with the downstream consequence.

If you want to go deeper, check out the related wiki notes on Administration Overview, Audit Logs, and the occ Command Reference. Those give you more detail on how to act on what the logs are telling you.

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 Nextcloud Performance Tuning.

If you’ve ever noticed Nextcloud feeling sluggish when a lot of people are using it at once, or when you’re dealing with large files, this episode is for you. At NZRT, performance tuning comes down to three main areas: caching, PHP configuration, and database optimisation. Let’s walk through each one.

First up is caching, and the tool NZRT uses here is Redis. Redis is an in-memory data store, and Nextcloud integrates with it really well. The configuration lives in Nextcloud’s main config file, and what it does is tell Nextcloud to use Redis for three things. Local memory caching, which is the everyday object cache that reduces how often Nextcloud has to hit the database. Distributed locking, which prevents conflicts when multiple users access or modify the same files at the same time. And session storage, which is what makes logins feel fast. You point Nextcloud at Redis running on localhost, on port 6379, and give it a password. That’s the core setup. The payoff is fewer database queries, faster page loads, and much smoother performance for things like Nextcloud Talk and the Calendar app, which are especially chatty with the cache.

Next is PHP-FPM tuning, and this one is about making sure PHP can handle many users at once without running out of workers. The configuration file for Nextcloud’s PHP pool sets a dynamic process model, meaning the number of running PHP processes scales up and down with demand. The key numbers here are: a maximum of 100 child processes so you can handle heavy load, 20 processes started at boot so you’re ready to go immediately, a minimum of 10 spare servers sitting idle waiting for requests, and a maximum of 50 spare servers at any given time. Each worker also resets itself after 500 requests, which keeps memory usage healthy over time. On top of that, the PHP settings themselves are tuned for large files. Upload limits and the maximum post size are both set to 2 gigabytes, and the memory limit per PHP process is set to 512 megabytes. If you’re handling Dolibarr invoice exports or large WordPress media uploads through Nextcloud, these limits matter.

Now let’s talk about database optimisation. NZRT runs MySQL, and there are a couple of things you can do here. First, you can enable query caching through Nextcloud’s own command-line tool, which tells Nextcloud to cache the results of repeated database queries rather than running them every time. Second, you can run an optimise command directly against the file cache table in MySQL. This table can grow quite large over time and optimising it reclaims space and improves read performance. Third, you can use Nextcloud’s system info command to pull diagnostic output and check database health at a glance.

For file input and output, the recommendation is to use an SSD for your primary Nextcloud data directory, because fast random write performance makes a noticeable difference when many users are uploading files. If you’re mounting network storage, like a NAS, you want to use asynchronous writes and tune your SMB mount options. The mount command you’d use includes flags like async to avoid blocking on writes, hard and intr so the system handles network interruptions gracefully, and you can specify the protocol version to match your NAS setup. NZRT uses this approach for archival storage mounted from a local network path.

Finally, monitoring. You want to keep an eye on three things. Redis cache hit rate, which you can check using the Redis command-line tool’s stats output. This tells you how often Redis is actually serving data versus falling through to the database. PHP-FPM pool status, where a simple process list filtered to your Nextcloud pool shows you how many workers are active. And slow query logging in MySQL, where you can turn on a slow query log and set a threshold of two seconds, so any database query taking longer than that gets flagged for review.

To put this all in context, NZRT’s Nextcloud instance supports over 50 concurrent users who regularly work with large files. Redis caching is considered essential, particularly because Talk and Calendar generate a lot of short, repeated calls that would otherwise hammer the database. Getting these settings right means the system stays responsive even during busy periods.

If you want to go deeper, the related wiki notes on Administration Overview, Architecture and Tech Stack, and Logging and Monitoring are good next stops.

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