Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Versioning & Trash.

If you’ve ever accidentally overwritten a file — or needed to roll back a document to an earlier state — Nextcloud’s built-in versioning and trash features are what save the day. Let’s walk through how they work and how NZRT uses them.

First, the basics. Every time you change a file in Nextcloud, the system automatically takes a snapshot of it. You don’t have to do anything — it just happens in the background. So if you edit a contract, update a spreadsheet, or revise a report, Nextcloud quietly keeps a copy of what that file looked like before your changes.

What can you actually do with those snapshots? Quite a lot. You can revert a file to any previous version with a single click — just pick the version you want and restore it. You can also download an older version as a brand new file, which is handy if you want to compare two drafts side by side without touching the current one. On top of that, Nextcloud keeps an activity log for each file, so you can see who changed what and when. That’s genuinely useful in a team environment where multiple people work on the same documents.

Now, versioning doesn’t come for free — it uses storage. By default, the system holds versions for up to thirty days, or up to fifty versions per file, whichever limit is reached first. Both of those numbers can be adjusted by an administrator.

Here’s where storage planning matters. The way to think about it is this: take your total active file storage, multiply it by the average number of versions you’re keeping per file, and that gives you the extra space versioning will consume on top of your normal storage. To put that in NZRT terms — if you have five hundred gigabytes of active documents, and each file has an average of five versions saved, you’re looking at an additional two and a half terabytes of storage overhead. That’s significant. For non-critical documents, the recommended approach is an aggressive cleanup schedule — clearing old versions every seven days rather than waiting out the full thirty-day window.

That brings us to trash, which works like a recycle bin. When you delete a file in Nextcloud, it doesn’t vanish immediately — it moves to the trash folder, giving you a window to recover it if you change your mind. Administrators can configure how long deleted files sit there before being permanently removed. The system can handle this automatically, letting Nextcloud decide based on available storage. There’s also a command-line tool admins can run to preview what would be cleaned up before anything is actually deleted — a dry run — so you can check what’s going before you commit to it.

For NZRT specifically, versioning is treated as critical infrastructure, not just a nice-to-have. The main reason is how tightly Nextcloud is woven into Dolibarr document workflows. Think about contract amendments — when a contract goes through multiple rounds of negotiation, each revision needs to be traceable. Invoice corrections, purchase order revisions — all of these benefit from a clear version trail. If something looks wrong on a document, you want to be able to pull up exactly what it said last Tuesday.

The EDM agent — you might know her as ema — is responsible for managing retention policies across NZRT’s document library. Different document types get treated differently. A working draft might be cleaned up aggressively to save space, while a signed contract or financial document gets a much longer retention window.

If you want to go deeper on any of this, the related areas to explore in the wiki are the Files App documentation, the occ Command Reference — which covers the command-line tools admins use to manage Nextcloud — and the Backups and Maintenance section.

The key takeaway is this: versioning and trash in Nextcloud are automatic safety nets, but they cost storage. Understanding your retention settings and planning your cleanup schedule is how you keep that cost under control without losing the ability to recover from mistakes.

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